Progress Audit
Measure what is delivered, not what is reported. The output is a per-feature
progress matrix plus a global verdict, honest enough to plan against.
When to use
- "How far along are we / what's left / are we on track?"
- A progress, status, or completion report across a whole project or domain.
- Comparing specs / functional docs / requirements to the code actually on a branch.
- Before scoping remaining work (feeds
completion-plan).
Method
- Map the requirement sources. Enumerate the specs, functional docs,
requirement registers, and any priority/sequencing tiers. This is the
denominator — what should exist.
- Map the code. Enumerate the real modules, routes/endpoints, jobs, tables,
and UI screens on the target branch. Split backend vs frontend explicitly.
- Diff per feature/subfeature. For each capability the spec requires, find
and read the actual code. Rate done / partial / skeleton / gap / gated, with
an honest percent, concrete file-path evidence, and what's missing.
- Roll up to per-domain and global figures, and to a layered verdict (e.g.
backend vs frontend vs governance) — a single average hides imbalance.
Verify, don't trust
- A capability is done only when it is wired and tested — not because a
status doc, a task checkbox, a type, or a schema-only table exists. See the
verified-progress-signal instinct.
- Distinguish gap (simply unbuilt) from gated (blocked on a
decision/credential) — they need different follow-up.
- Separate backend from frontend: an API with no screen is not a
delivered feature.
Run at scale
For anything beyond a few features, fan out one sub-agent per feature/domain
returning a structured schema (id, status, percent, evidence, gaps), then run
an adversarial verification pass that tries to refute every "done"/high
claim by opening the cited files. Reconcile assessor vs verifier before rolling
up. Deterministic orchestration (a workflow) keeps it repeatable.
Output
- A per-feature/subfeature matrix: status, percent, evidence, gaps, gated items.
- Per-domain rollup + global figure + a layered honest verdict.
- Optionally reconcile against any existing status doc and explain divergences.
- Feed the result into
completion-plan to scope the remaining work.
1---2name: progress-audit3description: Audit how much of a project is actually built by diffing its specs, functional docs, and requirement registers against the real code into an honest, verified progress matrix (per feature/subfeature and global). Use when asked how far along a project is, what's left, percent complete, a progress or status/completion report, or to "compare the specs to the code".4---56# Progress Audit78Measure what is *delivered*, not what is *reported*. The output is a per-feature9progress matrix plus a global verdict, honest enough to plan against.1011## When to use1213- "How far along are we / what's left / are we on track?"14- A progress, status, or completion report across a whole project or domain.15- Comparing specs / functional docs / requirements to the code actually on a branch.16- Before scoping remaining work (feeds `completion-plan`).1718## Method19201. **Map the requirement sources.** Enumerate the specs, functional docs,21 requirement registers, and any priority/sequencing tiers. This is the22 denominator — what *should* exist.232. **Map the code.** Enumerate the real modules, routes/endpoints, jobs, tables,24 and UI screens on the target branch. Split backend vs frontend explicitly.253. **Diff per feature/subfeature.** For each capability the spec requires, find26 and read the actual code. Rate done / partial / skeleton / gap / gated, with27 an honest percent, concrete file-path evidence, and what's missing.284. **Roll up** to per-domain and global figures, and to a layered verdict (e.g.29 backend vs frontend vs governance) — a single average hides imbalance.3031## Verify, don't trust3233- A capability is **done** only when it is wired and tested — not because a34 status doc, a task checkbox, a type, or a schema-only table exists. See the35 `verified-progress-signal` instinct.36- Distinguish **gap** (simply unbuilt) from **gated** (blocked on a37 decision/credential) — they need different follow-up.38- Separate **backend** from **frontend**: an API with no screen is not a39 delivered feature.4041## Run at scale4243For anything beyond a few features, fan out **one sub-agent per feature/domain**44returning a **structured schema** (id, status, percent, evidence, gaps), then run45an **adversarial verification pass** that tries to *refute* every "done"/high46claim by opening the cited files. Reconcile assessor vs verifier before rolling47up. Deterministic orchestration (a workflow) keeps it repeatable.4849## Output5051- A per-feature/subfeature matrix: status, percent, evidence, gaps, gated items.52- Per-domain rollup + global figure + a layered honest verdict.53- Optionally reconcile against any existing status doc and explain divergences.54- Feed the result into `completion-plan` to scope the remaining work.
me-cedric