Programme status
Computed from the repository. Traced means a commit carrying
the requirement's trailer reached main through a merged PR.
Satisfied is the fraction of that requirement's criteria in
requirements/coverage.yaml that actually pass. They disagree
often, and the gap is the point — a requirement can be fully traced and
barely built.
100%
requirements satisfied
10/10
role packs
5/5
ceremonies
11/11
PRD §14 areas
21
agent-delivered PRs
Rollout (PRD §15)
| Phase | Scope | Satisfied | Requirements |
|---|---|---|---|
| Phase 0 | Prove the spine |
100% |
REQ-001, REQ-002, REQ-003, REQ-005, REQ-009, REQ-012, REQ-014 |
| Phase 1 | The team — all roles, ceremonies, estimation |
100% |
REQ-006, REQ-007, REQ-011 |
| Phase 2 | The client — PRDs, sign-offs, demos, portal |
100% |
REQ-008 |
| Phase 3 | Pluggability and learning — Jira, 2nd harness, memory |
100% |
REQ-004, REQ-013 |
Requirements — traced vs satisfied
| REQ | Traced | Satisfied | Requirement |
|---|---|---|---|
| REQ-001 | traced |
3/3 · 100% |
Coordination through the tracker; every action leaves an artifact |
| REQ-002 | traced |
3/3 · 100% |
Harness-neutral role packs, with attribution by per-role credential tier and the Agent-Role trailer 8 of the 9 roles PRD §3 names have packs. The ninth, Delivery Lead (governance: policies/, gates, budgets, escalation), was added later (#64) and is not the same role as Delivery Manager (client-facing: status reports, demo packages, the portal) — see role-packs/delivery-lead/charter.md's "Do not conflate this with the Delivery Manager" section. Delivery Manager has no pack; that is a real gap (REQ-008's client portal is also unbuilt), not a naming collision resolved by counting Delivery Lead twice (#184). Attribution is by credential tier and the Agent-Role trailer, not by signature — a decision, not a gap. Distinct per-role bot identities were considered and rejected for v0; see adrs/. |
| REQ-003 | traced |
4/4 · 100% |
Harness adapter — role packs compile for whichever harness a session runs under These checks prove existence, not use — read a 100% here as "three compile_* functions exist and are exercised by compiler/test_compile_pack.py", never as "three harnesses have run a session". Only claude-code has: every merged PR this programme has produced carries a `Harness: claude-code/*` trailer (#210). #222 closed part of the "compiles" vs "has run" gap this note used to describe in full: every role pack has declared `harness_compat.codex.supported: true` since the packs were first written (#42) — that half of the old note was already stale, not newly fixed — and `.github/workflows/dispatch.yml` no longer hard-codes `--harness claude-code`; `harness` is now a dispatch input, gated by compile-pack.py's own harness_compat check, with its own codex agent step (installs `@openai/codex`, runs `codex exec --profile <role>` against the compiled `sandbox-policy.toml`) that preserves the same checkout/budget/session-start/session-end contract claude-code runs under. `scripts/test-diagnose-workflow-push-refusal.sh` now also proves, structurally, that which GitHub credential a role gets does not depend on which harness is driving it — every codex-eligible role compiles to the same `token-secret` under both harnesses. What is still true, and still the thing this note exists to say plainly: **no codex session has ever run.** The agent step's preflight fails closed without a `CODEX_API_KEY` repository secret, which no role pack can provision for itself — #241 is the live trial this needs, blocked on that secret, tracking exactly the "has run a session, produced a merged PR" bar this note has always meant. Until #241 closes, read a 100% here the same way as before: the dispatch path exists and is tested, not that it has been exercised. opencode (#210) compiles and passes compiler/test_compile_pack.py but has no dispatch.yml step at all yet — a separate, smaller version of the same gap. DeepSeek, Kiro, Cursor, and Copilot are not implemented; awslabs/aidlc-workflows' `harness/` tree is the reference for what each would need. |
| REQ-004 | traced |
3/3 · 100% |
Tracker adapter — GitHub Projects and Jira swappable scripts/sync-project.py is now rewired through adapters/tracker/base.py (#192): every tracker call is an interface call, and which implementation backs a run is a single config read (`TRACKER_IMPL`, default `github`). A test drives the script's full sync algorithm against both adapters' stubs and gets the same result from each. That proves the seam is load-bearing, not merely present — but it is proof against stubs, not against a live Jira. adapters/tracker/jira has still never been run against a real Jira instance; there are no credentials or instance to run it against here. "Seam proven against stubs" and "Jira integration works" are different claims, and only the first one is made. |
| REQ-005 | traced |
4/4 · 100% |
Git-native traceability spine |
| REQ-006 | traced |
6/6 · 100% |
All five ceremonies run autonomously and end in artifacts All five ceremonies run — standup, refinement and retro, plus planning and review, which landed in #152. |
| REQ-007 | traced |
4/4 · 100% |
Human-in-the-loop as decision gates, never free-text supervision |
| REQ-008 | untraced |
3/3 · 100% |
Client layer — transcript to PRD, sign-offs, CRs, demos, portal scripts/transcript-to-prd.py and policies/signoff.yaml both exist (#133, |
| REQ-009 | traced |
4/4 · 100% |
QA veto, DoD as policy-as-code, published QA reports The veto is enforced. QA reports are published as dashboards/qa.html via GitHub Pages (#110), not only comments. |
| REQ-010 | untraced |
3/3 · 100% |
Environment ladder preview to prod, human gate, rollback plans The ladder is declared (policies/environments.yaml), four GitHub Environments are configured with a required-reviewer rule on prod, and a deploy workflow now walks it. The prod gate has been exercised for real, not just declared: run 33887826522 paused for 31 minutes waiting on @Shashank2577's approval, then proceeded and emitted its rollback plan. But no application is deployed by any of this — there is no application in this repository, so the deploy step is a documented no-op. The ladder, the gate and the rollback-plan mechanism are proven; deploying a real workload is not, and 3/3 here should not be read as "this programme ships software" (#184). |
| REQ-011 | traced |
4/4 · 100% |
Visibility — boards, generated dashboards, computed matrix Traceability, standup, programme status, and burndown/velocity. One known inaccuracy on the status page as of #184: its role-pack tile counts against a literal list in dashboards/status.py that still names "delivery-manager" instead of the newly-distinguished Delivery Lead / Delivery Manager pair, so it undercounts by one until #185 derives that list from something reviewable instead of a Python literal. Tracked, not silently wrong. |
| REQ-012 | traced |
4/4 · 100% |
Least privilege, per-item budgets, escalation ladder |
| REQ-013 | traced |
2/2 · 100% |
Persistent engineering memory across ephemeral sessions Store built (#119): write/read/search on refs/notes/foundry. Dispatcher reads and writes it (#120). Seam built (#158): adapters/memory/base.py + adapters/memory/git_notes/, mirroring the tracker seam (#135); scripts/memory.py itself still calls git notes directly, unrewired, by the same design as the tracker seam. No MCP/Seal-backed second implementation (PRD §12's later phase) — that describes the code, not an event. #165 forced the first real exercise of the write path: it had shipped in #153 but every session since had succeeded, so it had never actually fired. Dispatching #169 against a devops session with an unmeetable ask made it escalate, and session end wrote and pushed a note to refs/notes/foundry on commit 773451c (run 33855463986). A second dispatch on the same issue then received that note in its assembled prompt — visible verbatim in its own run log (run 33855617391) and quoted back in its first comment — before escalating again. Read, search and write are now proven in production, not just wired and unit-tested. |
| REQ-014 | traced |
3/3 · 100% |
Self-hosting — the system builds itself through itself Demonstrated, not unproven: 46 merged pull requests have been produced by a dispatched agent session, out of 73 merged overall (measured by `collect_facts` in dashboards/status.py). The central claim holds. note contradicts its checks matched "unproven" while scoring 100% |