The four projects, in their own words.

poor-mans-ci — tests, attestations, artifact mirrors

// 0.4 protocol baseline · 212/212 BDD scenarios · language-agnostic

Runs tests and builds without GitHub Actions, CircleCI, Buildkite, or any centralized provider. Produces signed attestations and artifact hashes that delegates can use when deciding to merge. The protocol is documented in a human-readable spec and a machine-readable manifest so a compatible CI engine can be implemented in any language.

What it owns

• Commit-addressed runner checkouts with pinned runner image evidence.
• Head-build and synthetic test-merge attempts on every branch and patch ref.
• Local pmci-out/ evidence layout: attestations, hashes, run summaries.
• Artifact mirror at /artifact/<sha256> with an integrity model that refuses any byte that doesn’t match.
• Stage retention matrices, infra/test retry policy, canary-before-fleet rollout evidence.
• Optional conformance gates including ECSC-ready Envoy route, Network Service Mesh, and VPP packet-path checks.

Operational shape

• Single-binary runner; multiple suites composable via pipeline JSON.
• Hooks for Telegram and Radicle patch comments out of the box.
• Pairs natively with poor-mans-cd for the deploy half and radicle-seed-kit for evidence replication.

poor-mans-cd — deploy by manifest, verify by hash

// local-first dashboard · receipts on disk · gated CD

A local-first continuous delivery control plane that deploys exact bytes by release manifest, records durable evidence on disk, and serves a GitHub-Actions-style dashboard for CI attempts, branch/patch checks, gated promotion, and release deploys — without depending on a hosted CI/CD provider.

What it owns

• Release manifests that bind service, version, sha256, mirror URLs, SBOM pointers, health checks, and trace metadata.
• Deploy-only pipelines that can pause at gates, resume prior runs, re-run failed stages, record triage, and cancel runs.
• Importer for PMCI evidence: CI labels, post-deploy checks, runner identity, source refs, and artifact evidence stay preserved.
• Continuous delivery restricted to the declared canonical ref (normally rad/main) with explicit gated-CD activation per repo.
• Pull-style CD where deploy hosts poll for promoted manifests, and deploy only when the promotion changes.

Design principles in plain words

• Deploy by manifest. The manifest is the source of truth; URLs are transport.
• Verify by hash. Refuse to install bytes that don’t match sha256.
• Secrets out-of-band. .secrets/ locally, /etc/ on servers.
• Evidence on disk. Dashboards and operators can rebuild state from local run, CI, receipt, and gossip files.
• CI/CD boundary. CI produces attestations and artifacts; CD verifies and deploys them.

radicle-seed-kit — always-on seed, private repos that stay private

// availability layer · private-by-default · NAT-friendly mirroring

A toolbox for running an always-on Radicle seed node and keeping private repos replicated and available while contributor laptops are offline. Includes an org-style workflow where collaborators behind NAT can trigger mirroring to the seed via a restricted SSH reverse-tunnel account — no shell access required.

What it owns

• DigitalOcean seed automation (provision, mirror, sync, telegram-routed alerts).
• Friend onboarding for cloning private repos from the seed.
• Circle Source collaboration protocol: stewards / catalysts / ally circles via patches.
• Resilient networking patterns: Tor onion endpoints and multi-seed redundancy.
• Privacy guardrails so a private repo cannot accidentally become public.
• Fingerprinting + leak-response runbooks for out-of-band sharing.

Its role in the suite

Seed Kit is the availability and governance layer for everything else. PMCI evidence, PMCD receipts, and the canonical backlog all replicate through it. If your seed is healthy, the rest of the suite can replicate. If your seed is captured, nothing else compensates.

radicle-priorities — the canonical backlog protocol

// 1.16 protocol · BDD-first · board reads working tree

Treats BDD .feature files as the single source of truth for the backlog and Radicle issues as the collaboration surface. The board UI reads your working tree directly — no commit required to see the backlog. The full methodology, walkthrough video, and onboarding guide live on the dedicated site at extremebdd.com.

What it owns (from the community-infra angle)

• Per-repo protocol declaration in bdd/RADICLE_PRIORITIES.json: protocol version, capability tiers (required, optional, planned).
• Stakeholder mode + read-only mode for hosted operator boards.
• Performance contract (compact payloads, response cache, side-view trimming) so a single seed can serve many repos.
• Suite evidence read model that surfaces PMCI / PMCD signals next to the BDD backlog.

Why it belongs here

Every other project in the suite uses Extreme-BDD scenarios as its own acceptance criteria. Radicle Priorities is the substrate that makes that workable across repositories. It also makes the dependency obvious: the same backlog protocol replicates with the code, on the same seed, through the same Radicle issues mirror.