@antoneeo/agentic-sdlc-skill 1.35.0 → 1.37.0

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

@@ -1,6 +1,6 @@
 ---
 name: agentic-sdlc
-version: 1.35.0
+version: 1.37.0
 description: Documentation-First SDLC protocol with risk-proportional triage, Vision as a guide, a complete Standalone mode and optional symbiosis with devPNT. Use for features, significant bugs, refactors, audits and documented maintenance.
 author: Antonio Pinto (https://github.com/Antoneeo)
 copyright: (c) 2026 Antonio Pinto
@@ -20,7 +20,7 @@ Support files in the skill directory:
 - `vision.md`: how to write a Vision a cold reviewer can actually apply — the properties that make a rule hold, the minimum operable sections, and the blind check run before promoting one to APPROVED.
 - `hybrid.md`: the devPNT seam — the authoritative hierarchy, the ownership matrix (who owns what when both authorities are live), the triage equivalence, the feature-state mapping and the shadow discipline. Read it when the `devpnt_*` tools point at this project; a Standalone session never needs it.
 - `routing.md`: which lens owns this unit of work. Read ONLY when a sibling lens skill is installed alongside this one; a single-lens install never reads it.
-- `scripts/sdlc_check.py` + `scripts/sdlc_core.py`: the mechanical validator for the docs root (`check`, `validate`, `index`, `stale`, `mark`, `benefit`, `gate`, `plan`, `orient`, `migrate`).  Keep the entry point, `scripts/sdlc_core.py` and `scripts/knowledge.py` together; the last supplies common memory and KB integrity.
+- `scripts/sdlc_check.py` + `scripts/sdlc_core.py`: the mechanical validator for the docs root (`check`, `validate`, `index`, `stale`, `mark`, `benefit`, `gate`, `plan`, `orient`, `migrate`).  Keep the entry point, `scripts/sdlc_core.py` and `scripts/knowledge.py` together; the last supplies common memory and KB integrity.
 - `ENFORCEMENT.md`: optional setup for CI and hooks.
 
 Read these files only when needed. `SKILL.md` is the operating contract; the support files are progressive resources.
@@ -37,15 +37,15 @@ Read these files only when needed. `SKILL.md` is the operating contract; the sup
 
 If a patch looks easy but you do not understand why the current code is shaped the way it is, investigate first.
 
-## Shared project memory
-
-Project memory is available by default, independently of installed sibling lenses.
-Read `memory.md` for the common consult/capture contract during orientation and
-closure. Use `recall` for cross-domain discovery; `index` registers original guides,
-plans and decisions without copying them. One owner still governs each unit.
-The validator now ships as three files: entry point, `sdlc_core.py`, `knowledge.py`.
-
-## Rule Zero: Triage
+## Shared project memory
+
+Project memory is available by default, independently of installed sibling lenses.
+Read `memory.md` for the common consult/capture contract during orientation and
+closure. Use `recall` for cross-domain discovery; `index` registers original guides,
+plans and decisions without copying them. One owner still governs each unit.
+The validator now ships as three files: entry point, `sdlc_core.py`, `knowledge.py`.
+
+## Rule Zero: Triage
 
 Always classify the request before choosing the process. Declare the chosen level to the user when you start operational work.
 
@@ -59,11 +59,12 @@ Always classify the request before choosing the process. Declare the chosen leve
 | **Spike** | Time-boxed exploration to reduce uncertainty | Code not mergeable into main. Outcome in `ai_docs/solutions/SPIKE_[topic].md`. For production, reclassify as L2 or L3. |
 
 Cross-cutting rules:
-- **Domain routing (multi-lens installs only).** After the level is set, and only when a sibling lens skill of this family is installed (`kb-agentic`, `mkt-agentic-sdlc`), run the router in `routing.md` for every L2, L3 and Spike: it decides which lens's method and validation rules govern this unit of work. L1 never reaches it, and a single-lens install never reads the file — detection fails open. In such a project, never refer to a document whose meaning differs by lens ("threat model", "vision", `principles.md`, `handoff.md`) by its bare name: qualify it with its domain, or name its path.
+- **Domain routing (multi-lens installs only).** After the level is set, and only when a sibling lens skill of this family is installed (`kb-agentic`, `mkt-agentic-sdlc`, `course-creator`), run the router in `routing.md` for every L2, L3 and Spike: it decides which lens's method and validation rules govern this unit of work. L1 never reaches it, and a single-lens install never reads the file — detection fails open. In such a project, never refer to a document whose meaning differs by lens ("threat model", "vision", `principles.md`, `handoff.md`) by its bare name: qualify it with its domain, or name its path.
 - Parsing of external input, authN/authZ, cryptography, networking, personal data and filesystem access are security-sensitive: never L1.
 - If a bigger impact emerges during L1/L2 work, stop, reclassify and declare it.
 - When in doubt, pick the higher level.
-- **Before asking the user anything — any phase, any level — the question must pass the legality test: search first and name the search with its result; name the decision or fact blocked without the answer.** Blocking the work is the exception, not the default. `elicitation.md` §The question discipline owns the rule and is the only place it is stated — read it before you ask, and do not work from a summary of it.
+- For L2/L3 bugs, load `debugging.md` at the start of analysis, before proposing a cause or fix: incident evidence, ranked hypotheses and causal verification precede correction.
+- **A real doubt is asked when it emerges, before its answer is written — any phase, any level; a question is legal only after naming the search with its result and the decision it blocks.** `elicitation.md` §The question discipline owns the rule — what is a real doubt, the pros-and-cons weighing, the form — and is the only place it is stated: read it before you ask or assume, and do not work from a summary of it.
 - The full audit does not start for L1/L2 unless explicitly requested.
 
 Triage rationalizations — the thought on the left is the signal to STOP and re-triage:
@@ -204,7 +205,7 @@ Hybrid L3:
 - Implementation work follows the TDD discipline in `tdd.md` (RED/GREEN/REFACTOR — the L2/L3 default; record the reason when it does not apply).
 - Before implementing (L2/L3; L1 exempt), **consult the guide router** — the verdict already declared with the triage level (`## Operative Guides`). Re-run the lookup here only if the work has moved to a topic the first one did not cover, and say so if the verdict changes.
 - If the environment does not allow automated tests, declare the alternative verification and the reason.
-- For bugs (L2/L3), follow the systematic debugging method in `debugging.md`.
+- For bugs (L2/L3), continue the investigation and design-verification method in `debugging.md`; implementation follows the `tdd.md` discipline above.
 - Circuit breaker: after 3 consecutive runs without progress on the tests, stop, switch to the systematic method in `debugging.md`, and ask for instructions if still stuck. `debugging.md` also covers **chronic fragility** — a component that breaks repeatedly across sessions is a comprehension + complexity signal (write the `source_kind: code` guide AND escalate a refactor), not a fourth patch.
 - Update the ANALYSIS Diary or the Action Plan when you complete milestones, hit blockers, change decisions, or a session ends with work unfinished.
 - **Opt-in subagent execution**: for an L3 with an approved design, the orchestrator MAY execute the work via subagents per `dispatch.md`, gated by `sdlc_check.py plan validate` ("no valid plan, no dispatch"); default stays same-session. Hybrid: the executable `PLAN_[feature].md` is `derived-from` the accepted E-TDD, never independently authored. `dispatch.md` also carries the family-wide **delegation boundary** (what may be delegated at all, and what never may) — that section is not gated by the opt-in trigger and applies at any level, dispatch or no dispatch.

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

@@ -1,215 +1,215 @@
-# The Architect Pass
-
-Applies at L3, in phase 3, AFTER the spec elicitation and BEFORE the Impact is
-drafted. It answers the one question the Impact cannot ask: *does the system
-already have the components and services this feature needs?*
-
-Why it exists: **a feature is not a unit of construction.** Left alone, an agent
-designs the feature and builds whatever it lacks inside the feature's own code
-path — so no component owns the capability, the next feature that needs it
-rebuilds it differently, and the platform accretes feature-shaped code nobody can
-reuse. That is myopia one level above the file: the change is complete, the tests
-pass, and the architecture is worse.
-
-## 1. State the feature as capabilities, not as files
-
-Write what the system must be able to DO for this feature to exist — "persist a
-draft across sessions", "notify a third party asynchronously", "authorize per
-tenant". A capability is a verb over a domain noun. It names no file, no class and
-no library: **that** is the decoupling. Files come later, in the Impact.
-
-Two or three capabilities is a normal feature. When the list has one obvious entry
-and it plainly exists, say so in one line **under the `## Capability Ledger`
-heading, still naming the component and where it lives**, and move on — this pass
-is a question to answer, not a form to fill. The heading is what makes a cheap
-answer distinguishable from a skipped pass; a bare "everything already exists"
-names nothing and is the **Paper ledger** anti-pattern, not the licence.
-
-## 2. Rule each capability against the platform
-
-One verdict per capability:
-
-| Verdict | Meaning | What the row must carry |
-|---|---|---|
-| **EXISTS** | a component already owns this capability and covers the need | the component, where it lives (path / symbol), and the one guarantee you re-read it to confirm |
-| **INADEQUATE** | a component owns it but does not cover the need | the same, plus the gap in one line |
-| **MISSING** | no component owns it | the terms you searched, the tool, and the areas covered |
-
-Read the **`## Component Map`** in `strategic/architecture.md` first — the project's
-inventory of what owns which capability, kept so this pass does not re-derive the
-platform from source every session.
-
-**The map is a cache of evidence somebody already paid for. It lowers the COST of a
-verdict, never the STANDARD of one.** Every verdict carries the same evidence
-whether the map answered it or not; a hit means the search is already written down,
-a miss means you pay full price. Reading a row does not excuse you from checking
-that it is still true — the map is the index, the code is the evidence.
-
-**Its silence is unread, not empty.** The map covers only the areas `audit/
-audit_plan.md` marks ANALYZED — and that state is a claim someone made, not a fact
-the tooling verified: marking asserts *the area was read closely enough to name the
-capabilities it owns*, so an area marked after two greps is a false ANALYZED and
-the person who wrote it owns the duplicate that follows. In an area still PENDING —
-or SKIPPED, or absent from the plan entirely — **the map can never ground a MISSING
-verdict.** Nothing there has been looked at yet, and "the inventory does not mention
-it" is the reasoning that builds a second copy of a component that already exists.
-
-**Searching for an owner** is text search first, symbol-graph second — in that
-order, because you are looking for a name you do not know yet, and a call-hierarchy
-tool needs a resolved symbol as *input*. Grep the repository (minus SKIPPED areas)
-for the domain noun, at least two plausible synonyms, and the verb; then use the
-symbol-graph tool to confirm or dismiss the candidates the search surfaced.
-
-**The floor for a MISSING** is about triage, not term count: every hit that lands in
-an unmapped area gets opened, or the MISSING is **provisional** and says so in its
-row. Record what you ran — terms, tool, areas — and stop when the terms are
-exhausted and no candidate remains unopened. A provisional MISSING is honest and
-cheap; an unfalsifiable one is the same defect as an EXISTS with no symbol named.
-
-**Understanding is never deferred; only WRITING the map is.** You may leave the rest
-of the repository unmapped and grow the inventory feature by feature — you may not
-leave unexamined anything this change touches or depends on. That blast zone is
-understood now, at full standard, mapped or not. The incremental licence is about
-the artifact, never about the comprehension.
-
-Ground every verdict. An EXISTS with no named symbol is an assumption wearing a
-verdict's clothes, and it is the row that breaks in implementation. A MISSING
-declared without a real search is how duplication enters — the component may be
-there under a name you did not guess. This is the DRY check at architecture level.
-
-## 3. Design what is missing as a component, not as feature internals
-
-INADEQUATE and MISSING produce design work of their own, governed by one rule:
-
-**The component's contract is stated in the component's own vocabulary. The feature
-is one consumer, never the owner.**
-
-The test is mechanical: write the contract — what it does, what it takes, what it
-guarantees — *without naming the feature*. If you cannot, the contract is
-feature-shaped, and the second consumer will force it open. **Renaming the
-feature's nouns is not stating the contract in the component's vocabulary**:
-`store(ConfirmationPayload) -> id` described as "stores records by id" still fails.
-The question the wording cannot dodge — *would a second plausible consumer have to
-change this signature?* If yes it is feature-shaped, however it is phrased.
-
-The opposite error is equally real: this is not a licence to build a framework.
-Build for the need you have, at the size you need. What the rule constrains is the
-contract's **vocabulary and ownership**, not its scope — a five-line component with
-a clean contract satisfies it in full.
-
-## 4. Decide the unit of change
-
-A capability that needs building becomes **its own ANALYSIS, its own branch and its
-own closure** when ANY of these holds:
-
-- it will have more than one consumer, now or in the declared roadmap;
-- **it can ship before this feature does** — merged and adopted on its own cadence,
-  with the feature still unfinished. (Not "buildable and testable on its own": §3
-  requires that of every component, so reading it that way makes the default branch
-  below unreachable and puts every five-line helper through its own L3.) IN: a
-  storage layer another team can adopt next sprint while this feature is still in
-  design. OUT: a helper nobody can use until the feature that motivated it lands;
-- it carries its own risk surface: security, a public contract, a data model, or a
-  new dependency.
-
-Otherwise it is a **phase inside this feature's plan** — the first phase, before the
-feature consumes it — and it is still a component: own contract, own tests, never
-inlined into the feature's code path. **The split rule decides the paperwork; it
-never decides whether the component exists.**
-
-When it does become its own unit, each document names the other: the feature's
-ANALYSIS points at the component's, and the component's lists its consumers.
-
-## 5. Order
-
-The component is designed before the feature that consumes it, and normally built
-and tested before it too. A feature blocked on a capability it does not have is not
-"in progress" — it is a component task wearing a feature's name.
-
-## Anti-patterns
-
-- **Inlining** — the capability is implemented inside the feature's code path and no
-  component owns it. Symptom: the next feature that needs it must copy it or
-  refactor yours. This is the failure the pass exists to prevent.
-- **Feature-shaped platform** — the component exists, but its contract speaks the
-  feature's vocabulary. Symptom: the second consumer forces a contract change.
-- **Silent degradation** — a capability comes out MISSING, nobody wants to build it,
-  so the feature is quietly reshaped around what exists and ships as less than what
-  was asked. The reduced benefit must be surfaced to the user as a scope change and
-  recorded in the ANALYSIS; absorbing it silently is the Vision-divergence rule
-  broken one level down.
-- **Speculative platform** — a general framework built for a single known need.
-- **Paper ledger** — every row EXISTS, nothing named. Unfalsifiable, exactly like a
-  review that reports "I checked".
-- **Empty-map MISSING** — ruling a capability MISSING because the Component Map is
-  silent about it, in an area nobody has analyzed yet. The map's silence is
-  *unread*, not *empty*. On a project the methodology has just arrived in, the map
-  is nearly all silence, and this is the anti-pattern that duplicates the existing
-  codebase one component at a time.
-
-## Where the output is recorded
-
-Standalone: the `## Capability Ledger` section of the ANALYSIS (`templates.md`),
-immediately before `## Impact`, which it feeds — every INADEQUATE or MISSING row
-lands there as files to create or change. The closure review maps the ledger row by
-row (`review.md`).
-
-**A component that gets built lands in the `## Component Map`** of
-`strategic/architecture.md`, in the same closure — capability owned, contract,
-where it lives. This is the loop that makes the pass repeatable instead of
-per-session: the ledger asks the map what exists, so a component the map never
-learned about is one the next feature rules MISSING and builds a second time. The
-trigger is the component's birth, not a stack change (Write Triggers).
-
-**So does a component you merely discovered.** When the pass searches an unmapped
-area and finds an existing owner, write that row too, then `sdlc_check.py mark` the
-area you covered — **in that order, and never the mark without the rows.** Marking
-an area ANALYZED while its owners stay unwritten is the worst of both states: the
-area now looks read, so the map's silence there becomes groundable, and the next
-feature rules MISSING and builds a duplicate — lawfully. What a mark asserts is
-exactly this: *the area was read closely enough to name the capabilities it owns.*
-The map then grows by the feature that needed the knowledge instead of by an
-up-front sweep — the understanding was paid for either way, and this is the step
-that stops the next session paying for it again.
-
-Hybrid: the ledger goes in the `E-ISP`, above its Impacted Components map. A
-capability split out as its own unit of change gets its own `E-ISP`/`E-TDD`, and the
-feature's `E-ISP` names it as a dependency.
-
-## Mechanical backstops
-
-Prose is not enforcement; these are the checks that notice when the pass did not
-run or its output rotted. Both are **advisories** — printed as `[note]`, never
-counted as warnings, and never failing a build, **not even under `--strict`**. That
-is deliberate: the ceremony budget accepted for this pass was a signal, and a
-warning that reddens a pipeline is a gate under another name.
-
-- **Skipped pass**: `validate` notes an L3 ANALYSIS started on/after 2026-07-28
-  that lacks `## Capability Ledger`. Grandfathered by `start_date` alone —
-  analyses born before the pass existed never nag — and deliberately NOT by
-  status: closure flips the ANALYSIS to COMPLETED *before* `check` runs, so a
-  status filter would silence the backstop at the exact moment the process
-  mandates the validator.
-- **Rotting map**: `validate` resolves every path-shaped ref in the Component
-  Map's `Where` column — a path that no longer exists, or a `#symbol` no longer
-  present as a whole word in the file, is flagged; so is a map whose rows carry
-  no checkable path at all, or whose header has no `Where` column (an inert check
-  reported as a clean one is the same defect as an unread map reported as empty).
-  This is the map's equivalent of the guides' `source_hash`, with the same honest
-  limit: it proves the ref resolves, never that the row still describes the
-  component correctly.
-- **A mark nobody paid for**: `validate` notes an area the audit plan marks
-  ANALYZED that owns no Component Map row. Marking is one cheap command and it is
-  what converts the map's silence into a groundable MISSING — so this is the other
-  half of the loop, the check that a mark asserted something real.
-- **Adherence** (non-gating, **skill development only** — `evals/` is not shipped
-  in the installed package): `architect_rules_before_impact.md` runs the pass
-  cold; `unmapped_never_grounds_missing.md` sets the brownfield trap — an existing
-  component in a PENDING area, where ruling MISSING from the map's silence is the
-  failure.
-
-## Below L3
-
-L1 and L2 do not run this pass. A capability discovered MISSING during L2 work is
-itself an escalation trigger: stop, reclassify to L3, declare it (Rule Zero). "The
-component was not there" is never a reason to build it inside an L2.
+# The Architect Pass
+
+Applies at L3, in phase 3, AFTER the spec elicitation and BEFORE the Impact is
+drafted. It answers the one question the Impact cannot ask: *does the system
+already have the components and services this feature needs?*
+
+Why it exists: **a feature is not a unit of construction.** Left alone, an agent
+designs the feature and builds whatever it lacks inside the feature's own code
+path — so no component owns the capability, the next feature that needs it
+rebuilds it differently, and the platform accretes feature-shaped code nobody can
+reuse. That is myopia one level above the file: the change is complete, the tests
+pass, and the architecture is worse.
+
+## 1. State the feature as capabilities, not as files
+
+Write what the system must be able to DO for this feature to exist — "persist a
+draft across sessions", "notify a third party asynchronously", "authorize per
+tenant". A capability is a verb over a domain noun. It names no file, no class and
+no library: **that** is the decoupling. Files come later, in the Impact.
+
+Two or three capabilities is a normal feature. When the list has one obvious entry
+and it plainly exists, say so in one line **under the `## Capability Ledger`
+heading, still naming the component and where it lives**, and move on — this pass
+is a question to answer, not a form to fill. The heading is what makes a cheap
+answer distinguishable from a skipped pass; a bare "everything already exists"
+names nothing and is the **Paper ledger** anti-pattern, not the licence.
+
+## 2. Rule each capability against the platform
+
+One verdict per capability:
+
+| Verdict | Meaning | What the row must carry |
+|---|---|---|
+| **EXISTS** | a component already owns this capability and covers the need | the component, where it lives (path / symbol), and the one guarantee you re-read it to confirm |
+| **INADEQUATE** | a component owns it but does not cover the need | the same, plus the gap in one line |
+| **MISSING** | no component owns it | the terms you searched, the tool, and the areas covered |
+
+Read the **`## Component Map`** in `strategic/architecture.md` first — the project's
+inventory of what owns which capability, kept so this pass does not re-derive the
+platform from source every session.
+
+**The map is a cache of evidence somebody already paid for. It lowers the COST of a
+verdict, never the STANDARD of one.** Every verdict carries the same evidence
+whether the map answered it or not; a hit means the search is already written down,
+a miss means you pay full price. Reading a row does not excuse you from checking
+that it is still true — the map is the index, the code is the evidence.
+
+**Its silence is unread, not empty.** The map covers only the areas `audit/
+audit_plan.md` marks ANALYZED — and that state is a claim someone made, not a fact
+the tooling verified: marking asserts *the area was read closely enough to name the
+capabilities it owns*, so an area marked after two greps is a false ANALYZED and
+the person who wrote it owns the duplicate that follows. In an area still PENDING —
+or SKIPPED, or absent from the plan entirely — **the map can never ground a MISSING
+verdict.** Nothing there has been looked at yet, and "the inventory does not mention
+it" is the reasoning that builds a second copy of a component that already exists.
+
+**Searching for an owner** is text search first, symbol-graph second — in that
+order, because you are looking for a name you do not know yet, and a call-hierarchy
+tool needs a resolved symbol as *input*. Grep the repository (minus SKIPPED areas)
+for the domain noun, at least two plausible synonyms, and the verb; then use the
+symbol-graph tool to confirm or dismiss the candidates the search surfaced.
+
+**The floor for a MISSING** is about triage, not term count: every hit that lands in
+an unmapped area gets opened, or the MISSING is **provisional** and says so in its
+row. Record what you ran — terms, tool, areas — and stop when the terms are
+exhausted and no candidate remains unopened. A provisional MISSING is honest and
+cheap; an unfalsifiable one is the same defect as an EXISTS with no symbol named.
+
+**Understanding is never deferred; only WRITING the map is.** You may leave the rest
+of the repository unmapped and grow the inventory feature by feature — you may not
+leave unexamined anything this change touches or depends on. That blast zone is
+understood now, at full standard, mapped or not. The incremental licence is about
+the artifact, never about the comprehension.
+
+Ground every verdict. An EXISTS with no named symbol is an assumption wearing a
+verdict's clothes, and it is the row that breaks in implementation. A MISSING
+declared without a real search is how duplication enters — the component may be
+there under a name you did not guess. This is the DRY check at architecture level.
+
+## 3. Design what is missing as a component, not as feature internals
+
+INADEQUATE and MISSING produce design work of their own, governed by one rule:
+
+**The component's contract is stated in the component's own vocabulary. The feature
+is one consumer, never the owner.**
+
+The test is mechanical: write the contract — what it does, what it takes, what it
+guarantees — *without naming the feature*. If you cannot, the contract is
+feature-shaped, and the second consumer will force it open. **Renaming the
+feature's nouns is not stating the contract in the component's vocabulary**:
+`store(ConfirmationPayload) -> id` described as "stores records by id" still fails.
+The question the wording cannot dodge — *would a second plausible consumer have to
+change this signature?* If yes it is feature-shaped, however it is phrased.
+
+The opposite error is equally real: this is not a licence to build a framework.
+Build for the need you have, at the size you need. What the rule constrains is the
+contract's **vocabulary and ownership**, not its scope — a five-line component with
+a clean contract satisfies it in full.
+
+## 4. Decide the unit of change
+
+A capability that needs building becomes **its own ANALYSIS, its own branch and its
+own closure** when ANY of these holds:
+
+- it will have more than one consumer, now or in the declared roadmap;
+- **it can ship before this feature does** — merged and adopted on its own cadence,
+  with the feature still unfinished. (Not "buildable and testable on its own": §3
+  requires that of every component, so reading it that way makes the default branch
+  below unreachable and puts every five-line helper through its own L3.) IN: a
+  storage layer another team can adopt next sprint while this feature is still in
+  design. OUT: a helper nobody can use until the feature that motivated it lands;
+- it carries its own risk surface: security, a public contract, a data model, or a
+  new dependency.
+
+Otherwise it is a **phase inside this feature's plan** — the first phase, before the
+feature consumes it — and it is still a component: own contract, own tests, never
+inlined into the feature's code path. **The split rule decides the paperwork; it
+never decides whether the component exists.**
+
+When it does become its own unit, each document names the other: the feature's
+ANALYSIS points at the component's, and the component's lists its consumers.
+
+## 5. Order
+
+The component is designed before the feature that consumes it, and normally built
+and tested before it too. A feature blocked on a capability it does not have is not
+"in progress" — it is a component task wearing a feature's name.
+
+## Anti-patterns
+
+- **Inlining** — the capability is implemented inside the feature's code path and no
+  component owns it. Symptom: the next feature that needs it must copy it or
+  refactor yours. This is the failure the pass exists to prevent.
+- **Feature-shaped platform** — the component exists, but its contract speaks the
+  feature's vocabulary. Symptom: the second consumer forces a contract change.
+- **Silent degradation** — a capability comes out MISSING, nobody wants to build it,
+  so the feature is quietly reshaped around what exists and ships as less than what
+  was asked. The reduced benefit must be surfaced to the user as a scope change and
+  recorded in the ANALYSIS; absorbing it silently is the Vision-divergence rule
+  broken one level down.
+- **Speculative platform** — a general framework built for a single known need.
+- **Paper ledger** — every row EXISTS, nothing named. Unfalsifiable, exactly like a
+  review that reports "I checked".
+- **Empty-map MISSING** — ruling a capability MISSING because the Component Map is
+  silent about it, in an area nobody has analyzed yet. The map's silence is
+  *unread*, not *empty*. On a project the methodology has just arrived in, the map
+  is nearly all silence, and this is the anti-pattern that duplicates the existing
+  codebase one component at a time.
+
+## Where the output is recorded
+
+Standalone: the `## Capability Ledger` section of the ANALYSIS (`templates.md`),
+immediately before `## Impact`, which it feeds — every INADEQUATE or MISSING row
+lands there as files to create or change. The closure review maps the ledger row by
+row (`review.md`).
+
+**A component that gets built lands in the `## Component Map`** of
+`strategic/architecture.md`, in the same closure — capability owned, contract,
+where it lives. This is the loop that makes the pass repeatable instead of
+per-session: the ledger asks the map what exists, so a component the map never
+learned about is one the next feature rules MISSING and builds a second time. The
+trigger is the component's birth, not a stack change (Write Triggers).
+
+**So does a component you merely discovered.** When the pass searches an unmapped
+area and finds an existing owner, write that row too, then `sdlc_check.py mark` the
+area you covered — **in that order, and never the mark without the rows.** Marking
+an area ANALYZED while its owners stay unwritten is the worst of both states: the
+area now looks read, so the map's silence there becomes groundable, and the next
+feature rules MISSING and builds a duplicate — lawfully. What a mark asserts is
+exactly this: *the area was read closely enough to name the capabilities it owns.*
+The map then grows by the feature that needed the knowledge instead of by an
+up-front sweep — the understanding was paid for either way, and this is the step
+that stops the next session paying for it again.
+
+Hybrid: the ledger goes in the `E-ISP`, above its Impacted Components map. A
+capability split out as its own unit of change gets its own `E-ISP`/`E-TDD`, and the
+feature's `E-ISP` names it as a dependency.
+
+## Mechanical backstops
+
+Prose is not enforcement; these are the checks that notice when the pass did not
+run or its output rotted. Both are **advisories** — printed as `[note]`, never
+counted as warnings, and never failing a build, **not even under `--strict`**. That
+is deliberate: the ceremony budget accepted for this pass was a signal, and a
+warning that reddens a pipeline is a gate under another name.
+
+- **Skipped pass**: `validate` notes an L3 ANALYSIS started on/after 2026-07-28
+  that lacks `## Capability Ledger`. Grandfathered by `start_date` alone —
+  analyses born before the pass existed never nag — and deliberately NOT by
+  status: closure flips the ANALYSIS to COMPLETED *before* `check` runs, so a
+  status filter would silence the backstop at the exact moment the process
+  mandates the validator.
+- **Rotting map**: `validate` resolves every path-shaped ref in the Component
+  Map's `Where` column — a path that no longer exists, or a `#symbol` no longer
+  present as a whole word in the file, is flagged; so is a map whose rows carry
+  no checkable path at all, or whose header has no `Where` column (an inert check
+  reported as a clean one is the same defect as an unread map reported as empty).
+  This is the map's equivalent of the guides' `source_hash`, with the same honest
+  limit: it proves the ref resolves, never that the row still describes the
+  component correctly.
+- **A mark nobody paid for**: `validate` notes an area the audit plan marks
+  ANALYZED that owns no Component Map row. Marking is one cheap command and it is
+  what converts the map's silence into a groundable MISSING — so this is the other
+  half of the loop, the check that a mark asserted something real.
+- **Adherence** (non-gating, **skill development only** — `evals/` is not shipped
+  in the installed package): `architect_rules_before_impact.md` runs the pass
+  cold; `unmapped_never_grounds_missing.md` sets the brownfield trap — an existing
+  component in a PENDING area, where ruling MISSING from the map's silence is the
+  failure.
+
+## Below L3
+
+L1 and L2 do not run this pass. A capability discovered MISSING during L2 work is
+itself an escalation trigger: stop, reclassify to L3, declare it (Rule Zero). "The
+component was not there" is never a reason to build it inside an L2.