How the four projects fit together

One replication surface. One evidence model. Clear boundaries.

The architecture below is the dependency graph an operator has to accept to run the whole stack. There is no implicit ordering hidden in a vendor portal — the seams are explicit, and each seam is its own forkable protocol.

The dependency graph

        contributor laptop                      always-on seed (radicle-seed-kit)
   +----------------------+           +--------------------------------+
   | rad clone <rid>      |  <---->   | rad node + replication        |
   | rad sync             |           | private repo availability     |
   | local board UI       |           | patch / issue gossip          |
   +----------+-----------+           +----------------+---------------+
              |                                        |
              | reads working tree                     | replicates evidence
              v                                        v
   +----------------------+           +--------------------------------+
   | radicle-priorities   |           | poor-mans-ci (pmci)            |
   | bdd/features/*.feature|           | tests + builds + attestations  |
   | bdd/BOARD_STATE.json |   ==>     | pmci-out/ evidence on disk     |
   | bdd/ISSUE_MAP.json   |  emits    | artifact/<sha256> mirror       |
   +----------------------+  scenarios +----------------+---------------+
                                                       |
                                                       | imports evidence,
                                                       | binds to release manifest
                                                       v
                                       +--------------------------------+
                                       | poor-mans-cd (pmcd)            |
                                       | release manifest (service,     |
                                       |   version, sha256, mirrors)    |
                                       | deploy-by-manifest, verify-by- |
                                       |   hash, receipts on disk       |
                                       +----------------+---------------+
                                                       |
                                                       v
                                       +--------------------------------+
                                       | deploy target host             |
                                       | bytes installed iff sha256 ok  |
                                       | systemd + caddy + receipts     |
                                       +--------------------------------+

Roles in plain words

Project	What it owns	What it does not own
radicle-seed-kit	Source replication, identity gossip, private-repo availability, patch routing.	The deploy decision. The build verdict. The backlog truth.
radicle-priorities	Backlog truth (`.feature` files), board projection, scenario-to-issue mapping.	Test execution. Release identity. Artifact bytes.
poor-mans-ci	Test + build execution, attestations, artifact mirror at content hash.	The deploy. The promotion gate. The runtime host.
poor-mans-cd	Release manifests, deploy execution, hash verification, receipts, dashboard.	Building anything. Holding source. Owning the backlog.

Where the trust lives

A given community decides what to trust, but the architecture makes the surfaces explicit so the decision can be made on purpose:

Source identity is held by Radicle keys, replicated through the seed. Capture surface: anyone who can run rad id update on the canonical doc.
Backlog truth is held by .feature files on the canonical branch. Capture surface: whoever can merge to rad/main.
Build verdict is held by a PMCI attestation pinned to a commit. Capture surface: the runner image and the signer.
Deploy authority is held by a PMCD release manifest binding a sha256 to a service. Capture surface: anyone who can write the manifest into the canonical pipeline.

What is intentionally NOT here

No central forge. There is no GitHub/GitLab account that holds the canonical view.
No hosted CI provider. There is no third-party that the build verdict depends on.
No custodial settlement. Service settlement, when it lands, is bilateral and off-chain (see ECSC, queued).
No mandatory dashboard. PMCD ships one, but every receipt is a file an operator can read with cat.

Bring-up order In production the order is: seed-kit first (because the others need a healthy seed), then radicle-priorities to land the backlog, then pmci on the runner host, then pmcd on the deploy host. See Get started for the concrete commands.