!!! abstract “Why this doc exists”
The whitepaper describes a target architecture with 16 companion docs and hundreds of capabilities across safety, security, observability, self-healing, memory, and more. Without a single source of truth for “what’s real vs. planned”, readers (including future-you) have to piece it together from retraction callouts, “TL;DR — deployed but largely unexercised” admonitions, and context. This doc is the flat answer: every named capability, its current status, a link to its whitepaper section, and a link to the tracking ticket (if any).
pie title Capabilities by status
"Deployed" : 17
"Partial" : 7
"Planned" : 32
"Deferred" : 9
"Rejected" : 13
View Mermaid source
pie title Capabilities by status
"Deployed" : 17
"Partial" : 7
"Planned" : 32
"Deferred" : 9
"Rejected" : 13
Total tracked: 78 capabilities across 11 domains. Deployed + partial: 24 (31%). Planned + deferred: 41 (53%). The whitepaper is a multi-month-to-year vision, not a today snapshot. Partial-status rows are the honest-gap flags — they exist because reality isn’t as tidy as the design.
2026-04-21 update: Priority 1 of the whats-next whitepaper has landed ACs 1–4 of 5 (dangerous-command guard, git worktrees per task, GUARD_BLOCKED event projection, GitHub App 1h tokens with no PAT fallback). AC 5 (default-deny egress Cilium L7) is the remaining slice — it is the heaviest and needs cluster-side Cilium capability verification before starting. Four Safety/Security rows flipped from Planned → Deployed; one new row added below (GUARD_BLOCKED event type + projection).
Shipped 2026-04-21. Bare clone at _bare/<owner>/<repo>.git reused across tasks; worktree at tasks/<task-id>/<repo>/ per task. 17 test cases. Task prompt in stream-consumer.js now uses task-workspace create.
Shipped 2026-04-21. 1h installation tokens minted from App PEM, refreshed every 50 min. No PAT fallback when App mint fails (fail loud). GITHUB_PERSONAL_ACCESS_TOKEN env var removed from dev-e and review-e pods; SealedSecret key still present, prune at next rotation.
On new ticket: add a row to the relevant domain table with Status: Planned and a link to the ticket
On PR merge: update the row — Planned → Deployed (or Partial if known gap). Update Evidence column with the merge commit SHA or live resource path
On retraction: update status. Add an honest note if the capability was reduced in scope
Weekly review ritual (development-process.md): include a 5-minute status-doc scan. Is anything stale? Any ticket that’s moved past its status? Any capability without a row that should have one?
Monthly: validate Evidence column for 5 random deployed rows — kubectl get, grep the repo, or similar. Catches doc-vs-reality drift.
A GitHub Action that queries issues with whitepaper:* labels, aggregates by domain, regenerates the tables in this doc, commits back. Requirements:
Label convention: every issue implementing a whitepaper capability gets a label like whitepaper:safety/stuck-guard (domain / capability slug)
Front-matter source: a capabilities.yaml that lists all capabilities with their canonical whitepaper-section link, so rows persist even when no issue exists
Action: cron-weekly or on-issue-update, merges the live GitHub Issues state into the YAML, regenerates the markdown tables
Effort estimate: ~1-2 days. Worth it when this doc has accumulated enough content that manual maintenance starts slipping — probably after 40+ tracked capabilities reach Deployed/Partial status.
Live status from cluster state + rig-conductor event store, not from this doc. “Capability X is Deployed” verified by presence of the resource (HelmRelease exists, Kyverno policy applied, Flagger Canary running). Drift between claimed and actual state surfaces as an alert. This is the full-fidelity version; worth pursuing once the rig can reliably inspect itself.
Not a roadmap. The roadmap lives in index.md’s Phase 0-7 Gantt. This doc tracks status per capability; the roadmap sequences them.
Not a substitute for the whitepaper. Each row links to the authoritative whitepaper section. The status tells you whether it’s real; the whitepaper tells you what it is and why.
Not a change log. Retractions and evolutions live in each doc’s own retraction log (especially tool-choices.md). This doc is a snapshot of current reality.