◎community-infra
How the projects fit together

One way to share. One evidence model. Clear edges.

The diagram below shows the dependency graph for the whole stack. Nothing is hidden in a vendor portal. Each seam between projects is its own protocol that you can fork. ECSC sits on the side as a settlement layer — it consumes PMCI and PMCD evidence and binds a Lightning channel receipt to it, so payment only settles when the proof matches.

The dependency graph

Dependency graph for the community-infra suite The contributor laptop and the always-on seed sit at the top. The laptop feeds radicle-priorities. The seed feeds poor-mans-ci. radicle-priorities emits scenarios to poor-mans-ci. poor-mans-ci feeds poor-mans-cd. poor-mans-cd deploys to the target host. On the side, ecsc reads PMCI attestations and PMCD receipts and binds them to a Lightning channel update between operator A and operator B. Payment only settles when the evidence matches. contributor laptop rad clone <rid> rad sync local board UI always-on seed (radicle-seed-kit) rad node + replication private repo availability patch / issue gossip reads working tree replicates evidence radicle-priorities bdd/features/*.feature bdd/BOARD_STATE.json bdd/ISSUE_MAP.json board UI poor-mans-ci (pmci) tests + builds + signed attestations pmci-out/ evidence on disk artifact/<sha256> mirror emits scenarios imports evidence, binds release manifest poor-mans-cd (pmcd) release manifest (service, version, sha256, mirrors) deploy by manifest, verify by hash receipts on disk install only if sha256 matches deploy target host bytes installed iff sha256 ok systemd + caddy + receipts ecsc (evidence-coupled service channels) signed service_state binds channel_update_receipt to PMCI/PMCD proof no matching evidence → no HTLC PMCI attestations PMCD receipts binds payment_hash Lightning HTLC + channel (bilateral, non-custodial) operator A  ⇔  operator B one channel carries both directions update_add_htlc · commitment_signed revoke_and_ack (node-backed proof)

Roles in plain words

ProjectWhat it ownsWhat it does not own
radicle-seed-kit Copying source between machines, identity gossip, keeping private repos reachable, routing patches. The deploy choice. The build verdict. What’s in the backlog.
radicle-priorities What’s in the backlog (.feature files), the board view, the scenario-to-issue map. Running tests. Naming releases. Producing the bytes.
poor-mans-ci Running tests and builds, signed test results, an artifact mirror keyed by content hash. The deploy. The promotion gate. The runtime host.
poor-mans-cd Release manifests, running deploys, checking the hash, writing receipts, the dashboard. Building anything. Holding the source. Owning the backlog.
ecsc Signed service state bound to a Lightning channel receipt, the proof-gate that refuses claims without matching PMCI/PMCD evidence, offline replay of the audit bundle, reciprocal netting between two operators. Custodial escrow. Public payment routing. Adopting a new chain or token. Deciding what work is worth — that’s the operators’ contract.

Where the trust lives

Each community decides what to trust. The architecture makes those decisions easy to see, so you can make them on purpose:

What is on purpose missing

Bring-up order In production, set up seed-kit first because the others need a healthy seed. Next, add radicle-priorities for the backlog. Then pmci on the runner host. Then pmcd on the deploy host. ecsc joins last, once two operators want to settle service work between them. See Get started for the commands.