@antoneeo/agentic-sdlc-skill 1.17.0 → 1.19.0

package/skills/agentic-sdlc-skill/templates.md

@@ -238,8 +238,27 @@ end_date:
      use-case = what they do. Derived from the elicitation round; the Impact below
      must cover each, and the closure review checks coverage + actor UX fit. -->
 
+## Capability Ledger
+<!-- the architect pass (`architect.md`), run BEFORE the Impact below. One row per
+     capability the feature requires the system to be able to DO — a verb over a
+     domain noun, naming no file. Verdict EXISTS (name the component and where) /
+     INADEQUATE (same, plus the gap) / MISSING (say what you searched). Every
+     INADEQUATE or MISSING row becomes a component with its own contract, stated
+     without naming this feature, and lands in the Impact below. Evidence is what
+     makes a verdict falsifiable: for EXISTS/INADEQUATE the one guarantee you
+     re-read to confirm it; for MISSING the terms, the tool and the areas searched
+     (and say "provisional" when the area is still PENDING in the audit plan).
+     A question, not a form: when every capability plainly exists, one line under
+     this heading answers it — still naming the component and where it lives. -->
+
+| Capability | Verdict | Component / gap | Evidence |
+|---|---|---|---|
+| persist an order | EXISTS | `path/to/store.py#OrderStore` | re-read `save()`: durable, returns the id |
+| notify the customer | MISSING | — | grep notify/alert/dispatch + send, over src/ and legacy/; no owner |
+
 ## Impact
-<!-- existing files touched, APIs/contracts, performance, new dependencies -->
+<!-- existing files touched, APIs/contracts, performance, new dependencies.
+     Derived from the ledger above: every INADEQUATE/MISSING row appears here. -->
 
 ## Security and Threat Model
 <!-- ALWAYS mandatory, also in Standalone.
@@ -368,6 +387,39 @@ Date: 2026-06-11 (UTC)
 <!-- one or two lines: release pending, environment quirks that affect everyone -->
 ```
 
+## ai_docs/audit/reviews/REVIEW_LOG.md
+
+One row per completed review (`review.md` §When a review is due). Append-only; it
+is the record that the gate ran and what it was worth. **One schema for both
+modes** — a Hybrid project's devPNT gates write to this same file, so Standalone
+adds values to the existing columns rather than a second table.
+
+```markdown
+# Independent Review Log
+
+| date | doc_key | tier | reviewer | findings_raised | findings_real | verdict | revise_rounds |
+|---|---|---|---|---|---|---|---|
+| 2026-06-11 | ANALYSIS_login_sso.md | design | subagent (opus, fresh ctx) | 4 | 3 | PASS | 2 |
+| 2026-06-12 | diff feature/sso-login | closure | self-pass (declared; no subagent facility) | 2 | 2 | PASS | 1 |
+
+## Notes
+<!-- One short paragraph per review that found something worth remembering: what
+     the findings actually were, and what changed because of them. The table
+     answers "was it reviewed and by what"; this answers "what did it find" —
+     which is where `review.md`'s per-finding outcomes live. Omit for a clean
+     review; a row with 0 findings needs no note. -->
+```
+
+`tier` is the moment plus, in Hybrid, the reviewer weight: `design`, `design (late)`
+and `closure` (Standalone); `deep`, `light`, `code`, `guide`, `vision` (devPNT gates
+and the Vision blind check). The validator reads this column by its header name, so
+extra or reordered columns are fine — but the header must say `tier`. `reviewer`
+records the realization actually used — fresh subagent, one-shot client run, or a
+**declared** self-pass. Writing `self-pass` where independence was unavailable is
+honest; writing nothing, or implying independence you did not have, is the failure
+this column exists to prevent. `findings_real` is how many raised findings survived
+triage: over time it is the only evidence of whether the gate earns its cost.
+
 ## ai_docs/audit/HANDOFF_[feature].md — volatile resume logistics (ephemeral)
 
 **Resume logistics ONLY; the ANALYSIS Diary keeps the durable narrative (DRY).**
@@ -399,12 +451,39 @@ Canonical docs: they open with the header (`description:`/`status:`) so they ent
 
 ```markdown
 ---
-description: Stack, directory structure and architectural patterns of the project.
+description: Stack, directory structure, component map and architectural patterns of the project.
 status: CURRENT
 ---
 # Project Architecture
 ## Technology Stack
 ## Directory Structure
+## Component Map
+<!-- The inventory the architect pass reads BEFORE searching the code
+     (`architect.md` §2). One row per component that OWNS a capability:
+     Capability = what it lets the system DO (a verb over a domain noun, naming
+     no file). Contract = what it guarantees its consumers, in one line, stated
+     without naming any single consumer. Where = a path, or `path#symbol` when
+     the component is smaller than its file.
+     Seeded at bootstrap; a row is added or corrected in the SAME closure that
+     builds — or merely discovers — a component, and the area is marked ANALYZED.
+     A directory is not a component: rows name what owns a capability, not where
+     files sit (that is ## Directory Structure above). An absent or stale map is
+     why the next feature rules the same capability MISSING a second time and
+     builds it again. -->
+
+Coverage: whatever `audit/audit_plan.md` marks ANALYZED — **read it, do not trust a
+list restated here** (a hand-copied list is a cache with no invalidation). Outside
+those areas this map is **unread, not empty**: it can never ground a MISSING
+verdict, and the code is searched instead (`architect.md` §2).
+
+| Component | Capability it owns | Contract | Where |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+<!-- Where is `path/to/file.py#Symbol`. Leave the placeholder row untouched until
+     the map has a real component: the validator skips an all-`...` row, so a
+     freshly seeded project is never nagged about a table nobody has filled in. -->
+
 ## Architectural Patterns
 ```