@ahmed-g-gad/apothem 0.1.1

package/src/apothem/rules/authority-inquiry.md

@@ -0,0 +1,54 @@
+---
+name: "authority-inquiry"
+description: "Inquire, do not invent — names, emails, handles, hostnames, organizations, scope, security, naming, infrastructure, and version pins are discovered or asked, never fabricated. Routes through the canonical structured-inquiry channel."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Authoritative Inquiry — Inquire, Do Not Invent
+
+## What this rule enforces
+
+This rule binds **M5 — Authority Principle** (inquiry half; the discovery half lives at `rules/host-discovery.md`). The ecosystem MUST NOT fabricate personal, authoritative, or otherwise user-bound data. Names, emails, handles, hostnames, organizations, tenants, endpoints, credentials, scope direction, host-unratified naming choices, retention policies, version pins on host-mutable surfaces, and undeclared infrastructure decisions — none is invented. Each is either (i) **discovered** from a ratified host source of truth with provenance recorded per `rules/host-discovery.md`, or (ii) **inquired** from the user via the typed inquiry surface at `rules/interactive-questions.md`. A plausible-looking guess is never an acceptable substitute for either path.
+
+## Pre-conditions
+
+The rule applies whenever any host-project artifact about to be emitted depends on data in one of the seven inquiry categories below. Required-category inquiries (Identity, Scope direction, Security, Naming-of-public-surfaces) MUST block emission until answered; optional-category inquiries fall back to the recommended option per `rules/option-annotation.md` and record the fallback as a finding.
+
+## Required behavior
+
+### The Seven Inquiry Categories (Companion Sub-Rule Anchor)
+
+The seven categories are: **Identity**, **Scope direction**, **Preference**, **Security**, **Naming**, **Infrastructure**, **Version pins**. Required-category inquiries (Identity, Scope direction, Security, Naming-of-public-surfaces) block emission via `<USER-CONFIRM:id=<id>>` placeholders rejected at pre-emission gate row 5; optional-category inquiries fall back to the **Recommended** option per `rules/option-annotation.md` and record the fallback as a finding. Full per-category "Forbidden to invent" / "Inquire because" columns and the required-vs-optional explanatory paragraph live at `rules/authority-inquiry-categories.md` §1 (Companion Sub-Rule Anchor).
+
+### Inquiry surface — canonical channel
+
+Every inquiry MUST route through the canonical structured-inquiry schema at `rules/interactive-questions.md` §2 Structured-Inquiry Shape. The structured-inquiry subset (the `questions` array, the option-set shape, the three-segment annotation, the recommendation taxonomy, the per-file destructive-op confirmation) is owned there; this rule carries the **outward-projection form** — the seven-category catalog naming *what* must be inquired, *when*, and *which* categories are required versus optional.
+
+Where the host runtime exposes no structured inquiry, the structured prose fallback at `rules/interactive-questions.md` §5 replaces the tool invocation. Every fallback use MUST be logged in the change ledger per `rules/disclosure-ledger.md` so the degradation is never silent.
+
+### Carved-Out Auto-Decisions (Companion Sub-Rule Anchor)
+
+To prevent inquiry fatigue, a closed catalog of carve-out classes (pure validity, pure rigor, universally-safe security, pure formatting normalization, internal reference repair) is decided **without inquiry** — disclosed in the change ledger as `[Default — applied: <decision>; class: <carve-out>]`. Anything outside the carve-out goes through the inquiry surface. The full bulleted carve-out catalog lives at `rules/authority-inquiry-categories.md` §2 (Companion Sub-Rule Anchor).
+
+## Disclosure surface
+
+Inquiry outcomes are recorded in the disclosure ledger per `rules/disclosure-ledger.md`:
+
+- `[Inquiry — id: <inquiry-id>; category: <category>; outcome: <user-choice|fallback-to-recommended>]` for every inquired-and-resolved choice.
+- `[Default — applied: <auto-decision>; class: <carve-out class>]` for every carve-out auto-decision.
+- `<USER-CONFIRM:id=<id>>` placeholders for unresolved required inquiries (these block emission per the pre-emission gate row 5 at `rules/pre-emission-gate.md`; the mechanical matcher at `conformity/user_confirm_grep.py` enforces the placeholder absence at hook level).
+
+## Failure tells (Companion Sub-Rule Anchor)
+
+The full failure-tells enumeration — invented identity / endpoint / handle data, unverified `mailto:` fields, guessed CODEOWNERS handles, host-mutable version pins without ratification, unfilled `<USER-CONFIRM:…>` placeholders, silently-resolved required-category decisions — lives at `rules/authority-inquiry-categories.md` §3 (Companion Sub-Rule Anchor).
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** Every authoritative-data emission across every ecosystem surface. The pre-flight inquiry set every `commands/*.md` Step 1 emits per `rules/authority-inquiry.md`. The inquiry surface every `agents/*.md` return format carries. The mechanical `<USER-CONFIRM:…>`-placeholder grep at `conformity/user_confirm_grep.py`.
+- **Satisfies →** the fifteen-mandate registry row **M5 — Authority Principle**. `rules/authority-inquiry.md` — Required Categories (the seven-row catalog this rule canonicalizes). `rules/authority-inquiry.md` Carved-Out Auto-Decisions (the carve-out catalog this rule reproduces).
+- **Established by ↑** the fifteen-mandate registry (ratifies M5). `rules/authority-inquiry.md` (the seven-category catalog this rule reproduces with operational depth). `rules/authority-inquiry.md` Carved-Out Auto-Decisions.
+- **Gated by ←** The §8.1 trivial-vs-non-trivial threshold (trivial work runs the abbreviated check covering only the placeholder-presence sweep). `CLAUDE.md` always-loaded preamble.
+- **Cross-bound with ↔** `rules/authority-inquiry-categories.md` (path-filtered companion sub-rule carrying the §1 seven-category catalog, §2 carve-out auto-decisions, and §3 failure-tells enumeration). `rules/interactive-questions.md` (the canonical structured-inquiry invocation schema, three-segment annotation, recommendation taxonomy, harness fallback, and per-file destructive-op confirmation are owned there; this rule carries the seven-category outward-projection catalog and delegates the structured-inquiry subset). `rules/host-discovery.md` (M5 discovery half — the discovery and inquiry halves form a complete coverage of authority data). `rules/disclosure-ledger.md` (M2 — every inquiry outcome and carve-out default is recorded in the ledger). `rules/option-annotation.md` (M7 — every inquiry's option set carries the recommended marker). `rules/operational-mandates.md` §CM-2 Zero Assumptions (M5 is the outward-projection form of CM-2's structured-inquiry discipline). `rules/pre-emission-gate.md` (M4 — bar 5 of the gate enforces this rule's `<USER-CONFIRM:…>`-placeholder absence and unresolved-inquiry array population). `rules/i18n-discipline.md` (M5 — cohort amendments routed via the structured-inquiry channel). `rules/source-accessibility.md` (M5 — the inaccessible-source escalation reaches a trusted source through the operator-interview channel owned here).

package/src/apothem/rules/auto-memory-topic-files.md

@@ -0,0 +1,86 @@
+---
+name: "auto-memory-topic-files"
+description: "Path-filtered companion sub-rule carrying the topic-file management discipline, ecosystem-specific memory hygiene, session-end evaluation procedure, decision tree, and anti-patterns declared at the parent `auto-memory.md` rule's anchors; demand-loaded when the assistant edits any memory artifact."
+pathFilter: "**/memory/**, **/MEMORY.md, **/projects/**/memory/**, **/promotion-ledger.md"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Auto Memory — Topic Files & Lifecycle (Companion Sub-Rule)
+
+## Purpose
+
+Specify the topic-file management contract, ecosystem-specific memory hygiene, session-end evaluation procedure, decision tree, and anti-patterns delegated by the parent `rules/auto-memory.md` Companion Sub-Rule Anchors. This companion is path-filtered: it loads when the assistant edits any memory artifact (any file under `memory/**`, `projects/**/memory/**`, root-level `MEMORY.md`, or the global `promotion-ledger.md`), keeping the parent's always-on payload lean while preserving full convention fidelity at the demand-load surface. The parent rule remains the canonical home for the §1 Memory vs. Other State Files classification and §2 What NOT to Write bans; this companion carries the operational depth.
+
+## Obligations
+
+### 1. Ecosystem-Specific Memory Discipline
+
+- **MEMORY.md as index:** MUST stay under 200 lines, used as a concise index pointing to topic files. **Overflow procedure:** when approaching 200 lines, identify groups of related entries (3+ on the same domain), promote each group to a new topic file, and replace the group in MEMORY.md with a single index pointer. MEMORY.md MUST NOT exceed 200 lines — entries beyond 200 are truncated by the loader and become invisible.
+- **Topic files:** Kebab-case names reflecting the domain (e.g., `debugging.md`, `patterns.md`). Each self-contained.
+- **Deduplication:** Before writing, check whether an existing entry covers the topic; update it rather than duplicate.
+- **Staleness pruning:** When reading memory files, evaluate accuracy and remove entries referencing outdated versions, deleted files, or changed conventions.
+- **Contradiction resolution:** Current project state and user instructions always win over memory entries; update or remove contradictions immediately.
+- **Corruption resilience:** If MEMORY.md or a topic file is malformed (truncated, garbled, unparseable), re-derive its content from the other memory files and project state. MEMORY.md is an index — reconstruct from topic files on disk. Topic files are self-contained — reconstruct from project artifacts and CLAUDE.md. Log the corruption and notify the user.
+
+### 2. Topic File Management
+
+- **Naming:** Kebab-case, domain-reflective. File name should be the topic's natural label (e.g., `debugging.md`, `api-patterns.md`, `overhaul-log.md`). Avoid generic names (`notes.md`, `misc.md`).
+- **Size target:** 50–150 lines per topic file. Under 50: consider merging into a related topic. Over 150: consider splitting by subtopic.
+- **Split signal:** A topic file covers 3+ distinct subtopics with no shared context → split into separate files. Update MEMORY.md index.
+- **Merge signal:** Two topic files have >50% overlapping content or are always consulted together → merge into one. Update MEMORY.md index.
+- **Self-containment:** Each topic file must be independently useful. Minimize cross-references between topic files — prefer duplicating a key fact over creating a dependency chain.
+- **MEMORY.md index discipline:** Every topic file must be listed in the Topic Files table. Orphan topic files (on disk but not indexed) are invisible and unmaintained — either index them or delete them.
+- **Cross-project patterns:** Two memory tiers exist: project-specific (`<harness-root>/projects/{hash}/memory/`) and global (`<harness-root>/memory/`). Project memory is the default destination. At PUBLIC_LAUNCH seriousness, when the user reports or you recall (from global memory) that a pattern appears in another project, flag the current instance as an extraction candidate for user approval. On approval, move to global memory and remove the project-specific copy. Global memory follows the same MEMORY.md-as-index discipline. At lower seriousness levels, cross-project extraction requires explicit user request.
+- **Promotion-ledger discipline:** Every promotion event between the project-specific and global tiers is recorded in `<harness-root>/memory/promotion-ledger.md` with the canonical four-field record schema — `source` (project-specific path being promoted) · `target` (global path post-promotion) · `date` (ISO 8601 `YYYY-MM-DD`) · `rationale` (one-sentence justification grounded in a concrete driver: cross-project recurrence count, architectural anchor, or convention universality). The ledger is the authoritative record; promotion events without a ledger row are convention violations. The same schema applies in reverse for the rare demotion case (global → project-specific) when the cross-project applicability assumption no longer holds.
+
+### 3. Session-End Evaluation
+
+Context-management §2.5 and the Stop hook delegate session-end memory evaluation to this rule. At session end:
+
+- **Scan for write candidates:** Review decisions, corrections, confirmed patterns, and user preferences from the session. Apply the parent rule's §1 decision rule: plan/task-specific → skip (goes to PROGRESS.md). Reusable technique → skip (goes to skill). Stable fact/convention/preference/insight → memory candidate.
+- **Deduplicate:** Check existing memory files for each candidate. If already covered, update if stale; skip if current.
+- **Write or skip:** At EXPLORING, write only if user explicitly requested. At PERSONAL_USE+, write confirmed patterns and preferences. At SHARED+, also write architectural decisions and debugging insights.
+- **Prune:** At SHARED+, remove any entries contradicted or made stale by this session's work.
+
+### 4. Decision Tree
+
+```mermaid
+%%{ init: { "theme": "neutral" } }%%
+%% verified: 2026-04-27 %%
+%% provenance: rules/auto-memory.md §1 (memory vs. other state) %%
+%% cross-reference: rules/auto-memory-topic-files.md §3 (session-end evaluation) %%
+flowchart TD
+    Start[Memory write candidate surfaces] --> Q1{Plan or task specific?}
+    Q1 -->|yes| Plan[Write to PROGRESS.md or PLAN-NOTES.md]
+    Q1 -->|no| Q2{Reusable technique with detection signal?}
+    Q2 -->|yes| Skill[Write a skill at skills/-name-/SKILL.md]
+    Q2 -->|no| Q3{Stable fact, convention, preference, or insight?}
+    Q3 -->|no| Skip[Discard]
+    Q3 -->|yes| Q4{Existing memory entry covers the topic?}
+    Q4 -->|yes| Update[Update existing entry · prune staleness]
+    Q4 -->|no| Q5{User · feedback · project · or reference type?}
+    Q5 --> Topic[Choose or author topic file in memory/]
+    Topic --> Index[Append index pointer to memory/MEMORY.md]
+    Index --> Done[Memory persisted]
+```
+
+### 5. Anti-Patterns
+
+- **DON'T** write speculative conclusions from reading a single file — **BECAUSE** unverified entries pollute memory.
+- **DON'T** duplicate CLAUDE.md content in memory — **BECAUSE** contradictions emerge as CLAUDE.md evolves.
+- **DON'T** use memory as a task tracker — **BECAUSE** PROGRESS.md and PLAN-NOTES.md serve that purpose.
+- **DON'T** store ephemeral facts (branch names, PR numbers, temporary URLs) — **BECAUSE** they will be stale by next session.
+
+## Enforcement
+
+Path-filtered (the four glob patterns in this rule's `pathFilter` field — `**/memory/**`, `**/MEMORY.md`, `**/projects/**/memory/**`, `**/promotion-ledger.md`), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/auto-memory.md`. The parent rule carries the §1 Memory vs. Other State Files classification table, the §2 What NOT to Write bans, and the Seriousness Scaling table; this companion carries the topic-file management contract, ecosystem-specific hygiene, session-end evaluation procedure, decision tree, and anti-patterns. Together they constitute the canonical specification for memory lifecycle.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every topic-file naming, sizing, splitting, merging decision under any project's `memory/` tree. ● The MEMORY.md index discipline (under-200-lines invariant; orphan-topic prevention). ● Every promotion / demotion event between the project-specific and global memory tiers (the four-field ledger schema at §2). ● The session-end memory evaluation procedure that the Stop hook fires.
+- **Satisfies →** ● CM-26 (Auto Memory Lifecycle — rule-delegated mandate; this companion is the path-filtered subset). ● the rules registry row "Auto Memory" (the canonical specification splits across the parent and this companion). ● `rules/auto-memory.md` Companion Sub-Rule Anchors (the parent rule's pointers to this companion's full specification).
+- **Established by ↑** ● `rules/auto-memory.md` (parent-rule anchors). ● CM-26 inline definition. ● the artifact directories (memory paths declared there).
+- **Gated by ←** ● The path-filter (`**/memory/**`, `**/MEMORY.md`, `**/projects/**/memory/**`, `**/promotion-ledger.md`) — this rule demand-loads only on memory-artifact touches. ● `rules/auto-memory.md` always-on baseline (parent rule's anchors must be live for the companion to demand-load coherently).
+- **Cross-bound with ↔** ↔ `rules/auto-memory.md` (parent rule; this companion's content is delegated through the parent's Companion Sub-Rule Anchors). ↔ `rules/context-management.md` (the §2.5 phase-exit protocol delegates memory evaluation to the parent rule, which delegates the procedure here). ↔ `rules/persistent-conventions-vigilance.md` (memory feeds gap-detection per §4 of the conventions rule; gap-detection writes to memory). ↔ `hooks/messages/stop.md` (the Stop hook context that operationalizes the §3 session-end evaluation). ↔ `memory/promotion-ledger.md` (the global memory's promotion-ledger anchor declared at §2).

package/src/apothem/rules/auto-memory.md

@@ -0,0 +1,67 @@
+---
+name: "auto-memory"
+description: "Auto memory lifecycle augmenting the harness built-in — classifies memory against PROGRESS.md / PLAN-NOTES.md / skills (stable fact/convention/preference/insight → memory; plan/task-specific → PROGRESS/PLAN-NOTES; reusable technique with detection signal → skill), bans session-specific context / incomplete info / CLAUDE.md duplicates / plan-specific decisions / ephemeral facts, and anchors topic-file hygiene to the path-filtered companion."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Auto Memory Lifecycle
+
+## Purpose
+
+Augment the harness's built-in auto memory with ecosystem discipline: separate memory from other state artifacts, enforce topic organization, and prevent content misplacement. Canonical specification for CM-26 (Auto Memory Lifecycle).
+
+## Obligations
+
+### 1. Memory vs. Other State Files
+
+Memory is one of four persistent-state artifacts. Place content by destination:
+
+| Artifact | Location | Holds |
+| -------- | -------- | ------- |
+| **Memory** | `<harness-root>/projects/{hash}/memory/` | Stable patterns, conventions, preferences, architectural decisions, debugging insights |
+| **PROGRESS.md** | Plan suite directory | Current task state, phase tracker, Resumption Contract |
+| **PLAN-NOTES.md** | Plan suite directory | Decisions, Q&A audit trail, gap analysis |
+| **Skills** | `skills/*/SKILL.md` | Reusable techniques with detection signals and procedures |
+
+**Decision rule.** Plan- or task-specific → PROGRESS.md or PLAN-NOTES.md. Reusable technique with a detection signal → skill. Stable fact, convention, preference, or insight → memory.
+
+### 2. What NOT to Write
+
+Memory MUST NOT carry any of six classes:
+
+- **Session-specific context** — current task details, in-progress work, temporary state (→ PROGRESS.md).
+- **Incomplete information** — unverified assumptions, single-file speculative conclusions.
+- **CLAUDE.md duplicates** — anything that duplicates or contradicts CLAUDE.md.
+- **Plan-specific decisions** (→ PLAN-NOTES.md).
+- **Reusable techniques with detection signals** (→ skills).
+- **Ephemeral facts** — values stale by next session (branch names, PR numbers).
+
+### 3. Topic-File Hygiene & Lifecycle (Companion Sub-Rule Anchor)
+
+MEMORY.md indexing, topic-file naming / sizing / split / merge, deduplication, staleness pruning, contradiction resolution, corruption resilience, two-tier project / global layout, promotion-ledger schema, Stop-hook session-end procedure, decision tree, anti-patterns. See `rules/auto-memory-topic-files.md`.
+
+## Seriousness Scaling
+
+> **Invariant.** §2 bans (no session-specific context, no incomplete information, no CLAUDE.md duplicates, no plan-specific decisions, no reusable techniques in memory, no ephemeral facts) apply at every seriousness level. The table below specifies what to ADD per level on top of those bans, not what to relax.
+
+| Level | Memory Behavior |
+| ----- | --------------- |
+| EXPLORING | Write only user-requested memories. If the user's request conflicts with §2 bans, explain the conflict and decline rather than silently proceed |
+| PERSONAL_USE | Write confirmed patterns and user preferences |
+| SHARED | Full lifecycle. Write architectural decisions, debugging insights. Prune stale entries on detection |
+| PUBLIC_LAUNCH | Full lifecycle. Staleness audit mandatory at session start. Cross-project extraction candidates flagged proactively. Active pruning every session |
+
+## Enforcement
+
+Always-on at every seriousness level, scaling per the table above. Implements CM-26. Canonical specification for memory lifecycle, topic organization, and content placement.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every memory write/update/prune cycle across every project's `<harness-root>/projects/{hash}/memory/` tree. ● Session-end memory evaluation per the Stop hook's CM-26 dispatch. ● `MEMORY.md` index discipline (under-200-lines invariant). ◐ Cross-project pattern extraction at the highest seriousness tier (the promotion-ledger discipline at `rules/auto-memory-topic-files.md` §2 records every promotion event). ◐ The two-tier memory layout (project-specific `<harness-root>/projects/{hash}/memory/` vs. global `<harness-root>/memory/`).
+- **Satisfies →** ● CM-26 (Auto Memory Lifecycle — rule-delegated mandate). ● the rules registry row "Auto Memory". ● the artifact directories (project vs. global memory tier declaration).
+- **Established by ↑** ● CM-26. ● the artifact directories (memory paths declared there). ● `rules/context-management.md` §2.5 Externalize-On-Phase-Exit (memory evaluation is delegated here).
+- **Gated by ←** ● Session-end Stop hook firing (the canonical session-boundary trigger). ● PROGRESS.md / PLAN-NOTES.md / skill artifacts taking precedence per the §1 decision rule (memory is the residual destination).
+- **Cross-bound with ↔** ↔ `rules/auto-memory-topic-files.md` (path-filtered companion sub-rule carrying §1 ecosystem-specific hygiene, §2 topic-file management, §3 session-end evaluation, §4 decision tree, and §5 anti-patterns). ↔ `rules/context-management.md` (the §2.5 phase-exit protocol delegates memory evaluation here; this rule's §5 session-end evaluation pairs with that delegation). ↔ `rules/persistent-conventions-vigilance.md` (memory feeds gap-detection per §4 of the conventions rule; gap-detection writes to memory). ↔ `hooks/messages/stop.md` (the Stop hook context that operationalizes the session-end evaluation). ↔ `memory/promotion-ledger.md` (the global memory's promotion-ledger anchor declared at `rules/auto-memory-topic-files.md` §2).

package/src/apothem/rules/bidirectional-binding.md

@@ -0,0 +1,123 @@
+---
+name: "bidirectional-binding"
+description: "Every substantive structural element carries reciprocal bindings to its peers in canonical five-direction notation — Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. Every binding declared in one direction has a reciprocal back-pointer at the other end; half-edges are structural failures. A Bidirectional Binding Matrix appendix summarizes the graph where structure permits."
+pathFilter: "**/*.md, **/docs/**, **/CLAUDE.md, **/rules/**, **/skills/**, **/agents/**, **/commands/**, **/adr/**, **/rfcs/**, **/architecture*, **/design*"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Bidirectional Binding & Phase-Execution Threading
+
+## What this rule enforces
+
+This rule binds **M10 — Bidirectional Binding & Phase-Execution Threading**. Every substantive structural element in a host-project artifact — section, sub-section, contract, requirement, test, dependency declaration, citation, cross-reference, phase, sprint, milestone — MUST carry **explicit, reciprocal, persistently-maintained bindings** to its peers in the canonical **five-direction notation** below. Every binding declared in one direction MUST have a **reciprocal back-pointer** at the other end. A binding without its reciprocal is a **half-edge** — a structural failure, never an aesthetic preference or a deferral candidate. Where structure permits, a **Bidirectional Binding Matrix** MUST be appended summarizing the graph.
+
+**Phase-execution threading.** Where the artifact describes ordered execution (a pipeline, a migration, a release process, a deployment, a research procedure), the order MUST be **named, numbered, anchor-bearing, and fully cited at both ends** — every phase declares what it invokes, what it advances, what gates it, and what it gates. Standing gates (mandates active throughout) MUST be explicitly marked.
+
+## Pre-conditions
+
+The rule applies whenever a host-project artifact carries substantive structural elements — sections depending on sections, contracts satisfying or establishing contracts, phases driving or gating phases, peers mutually reinforcing. Trivial-scope artifacts per the trivial-vs-non-trivial threshold (single-file edits ≤ 5 lines AND no public-API change AND no behavioral shift) are exempt; the trigger is structural surface, not Markdown presence. A linear narrative with no structural dependencies (a top-to-bottom how-to with no cross-references) is exempt — but the moment the artifact carries a cross-reference, a satisfies-relation, a gate, or mutual reinforcement, the bindings requirement applies.
+
+## Required behavior
+
+### 1. The Five Directions — Canonical Notation
+
+The bindings notation reproduces the five canonical symbols **verbatim**. Variants, abbreviations, translations, or substitutions (Unicode-emoji arrows, ASCII-only `->`, alternative wording like "Causes" or "Contributes-to") are non-conformant.
+
+| Direction | Symbol | Semantic | Reciprocal direction |
+|---|---|---|---|
+| **Drives →** | `→` (forward arrow) | What this element causes, produces, advances downstream | **Driven by ←** |
+| **Driven by ←** | `←` (backward arrow) | What introduces / gates / triggers this element | **Drives →** |
+| **Satisfies →** | `→` (forward arrow) | What end-state / criterion / acceptance test this element establishes | **Established by ↑** |
+| **Established by ↑** | `↑` (upward arrow) | What element(s) produce this outcome (anchors, ratifications, design sources) | **Satisfies →** |
+| **Cross-bound with ↔** | `↔` (bidirectional arrow) | Sibling elements that mutually reinforce; symmetric reciprocal | **Cross-bound with ↔** (self-reciprocal) |
+
+**Reading discipline.** The arrow reads in the natural direction of the prose: "Drives → A" reads "drives A"; "Driven by ← B" reads "driven by B". The arrow belongs to the section header, not as a separator inside a sentence — `**Drives →** A, B, C` is canonical, never `**Drives** → A, B, C` or `Drives -> A, B, C`.
+
+**Section-header form.** Every artifact carrying bindings emits a `## Bindings (§0.j five-direction)` section with one bullet per direction:
+
+```markdown
+## Bindings (§0.j five-direction)
+
+- **Drives →** <enumeration of downstream targets, comma-separated or sub-bulleted>
+- **Driven by ←** <enumeration of upstream triggers / gates>
+- **Satisfies →** <enumeration of end-states / criteria>
+- **Established by ↑** <enumeration of anchors / ratifications>
+- **Cross-bound with ↔** <enumeration of sibling reinforcements> `rules/propagation.md` (propagation's reciprocity surface is operationalised through this rule's five-direction notation).
+```
+
+A direction with **no bindings** is omitted — a section with three populated and two absent directions is conformant (the absent ones read as "this element neither drives nor is gated beyond its own scope"). Placeholder entries (`- **Drives →** TBD`) are non-conformant per `rules/definitiveness.md`.
+
+### 2. Reciprocity — The Half-Edge Failure Pattern
+
+**Every binding is reciprocal.** When A declares `Drives → B`, B declares `Driven by ← A`. When A declares `Satisfies → criterion C`, C declares `Established by ↑ A`. The reciprocal back-pointer lives **at the other end of the edge**, not in the artifact that emitted the forward declaration.
+
+**Half-edge failure pattern.** A binding declared in one direction without its reciprocal at the other end is a **half-edge**:
+
+- `A: Drives → B` declared, but B has no `Driven by ← A` — half-edge.
+- `A: Satisfies → C` declared, but C has no `Established by ↑ A` — half-edge.
+- `A: Cross-bound with ↔ B` declared, but B has no `Cross-bound with ↔ A` — half-edge (the self-reciprocal direction is the only one that requires identical wording on both ends).
+
+Half-edges are **structural failures**. The `binding-reciprocity-grep` matcher at `conformity/binding_reciprocity_grep.py` scans every emitted artifact, extracts every declared binding, and verifies the reciprocal back-pointer exists at the cited target. Half-edges produce HIGH-severity findings at the pre-emission gate per `rules/pre-emission-gate.md` row 10.
+
+**Closure protocol.** A forward declaration lacking its reciprocal MUST gain the reciprocal in the **same change-set**. A patch adding `A: Drives → B` while B is unmodified is non-conformant — the patch updates B's `Driven by ←` line in the same change. Where the cited target is outside modifiable scope (a cross-repository reference, a vendor-controlled artifact), the citation declares the asymmetry: `Drives → <target> (one-way: target outside our control)` — the explicit one-way label is the documented escape hatch, never a default.
+
+### 3. Phase-Execution Threading — Ordered Work Surfaces
+
+Where the artifact describes ordered execution — a pipeline, a migration, a release process, a deployment, a research procedure, a sprint sequence — the bindings carry phase-execution threading:
+
+- **Named.** Every phase has a stable identifier (`Phase 01`, `Sprint 3`, `Step 5`). Identifiers are anchor-bearing (Markdown headings the rest of the artifact can link to).
+- **Numbered.** Order is explicit through the identifier's numeric component. Zero-padding (`01`, `02`, …, `10`, `11`) is conformant where the host's discovered convention is zero-padded; otherwise honor the host's pattern.
+- **Anchor-bearing.** Every phase emits a heading the rest of the artifact references (`## Phase 01 — Discovery`). Internal cross-references use the heading's anchor, not free-text mentions.
+- **Fully cited at both ends.** Every phase declares what it invokes (`Drives →` next phase, downstream consumers), what it advances (`Satisfies →` end-states), what gates it (`Driven by ←` prerequisite phases, standing gates), what it gates (the reciprocal `Driven by ←` declaration in the next phase). Both ends are populated; one-sided declarations are half-edges.
+- **Standing gates marked.** Mandates active throughout the entire ordered execution (e.g., a CM-N or M-N rule that gates every phase, not just the first) are marked **explicitly** as standing — `Driven by ← (standing) <rule-citation>`. Standing gates are inherited by every phase by default; the explicit marking lets the reader distinguish phase-specific gates from ecosystem-wide ones.
+
+### 4. The Bidirectional Binding Matrix — Appendix Discipline
+
+Where the artifact's structure permits — multi-section specs, multi-phase plans, multi-element architectural documents, multi-rule rule sets — a **Bidirectional Binding Matrix** is appended summarizing the graph. The matrix surfaces drift the inline bindings cannot reveal at a glance.
+
+**Matrix shape.** The matrix is a square table indexed by element identifier on both axs. Each cell records the binding direction from the row element to the column element, using the canonical symbols:
+
+| | A | B | C | D |
+|---|---|---|---|---|
+| A | — | → | ↔ | ↑ |
+| B | ← | — | → | — |
+| C | ↔ | ← | — | → |
+| D | ↓ | — | ← | — |
+
+Reading the row: "A drives B; A is cross-bound with C; A is established by D." Reading the column: "B is driven by A; B drives C; B has no relation to D." The matrix's reciprocity invariant is mechanical — when row R, column C carries `→`, then row C, column R MUST carry `←`. When row R, column C carries `↔`, then row C, column R MUST carry `↔`. The diagonal is `—` (an element does not bind to itself; self-citation is not a binding).
+
+**When the matrix is mandatory.** The matrix is mandatory when the artifact carries five or more bound elements AND at least one element binds to three or more peers. Below this threshold, inline bindings sections suffice (a sparse matrix adds no clarity). At or above it, the matrix is the canonical reciprocity-audit surface.
+
+**Matrix placement.** The matrix lives in an `## Appendix — Bidirectional Binding Matrix` section near the artifact's tail, after the last substantive section but before the closing bindings citation (the artifact's own outward bindings live at the artifact's `## Bindings (§0.j five-direction)` section, separate from the inter-element matrix).
+
+### 5. Maintenance Discipline — Bindings Are Persistent
+
+Bindings are **persistently maintained**, not authored once and frozen:
+
+- **Element rename.** When an element's identifier changes, every reciprocal back-pointer is updated in the same change. The `binding-reciprocity-grep` matcher catches stale citations.
+- **Element removal.** When an element is removed, every reciprocal back-pointer pointing AT the removed element is removed in the same change. Dangling back-pointers (`Driven by ← <removed-element>`) are non-conformant.
+- **Element split / merge.** When an element splits (one element becomes two), the original's bindings distribute to the new elements based on which new element inherits each binding's semantic. When elements merge, the union of their bindings becomes the merged element's bindings (deduplication required — two `Driven by ← X` declarations from the pre-merge elements collapse to one).
+- **Cross-rule citations.** When a rule cites another rule (`Cross-bound with ↔ rules/<peer>.md`), the cited rule's `Cross-bound with ↔` section MUST cite this rule. The `binding-reciprocity-grep` matcher enforces the rule-set's bidirectional closure as part of the pre-emission gate.
+
+## Disclosure surface
+
+Every binding emission, update, or reciprocal closure is recorded in the disclosure ledger per `rules/disclosure-ledger.md`:
+
+- `[Binding — emitted: <element>; direction: <Drives → | Driven by ← | Satisfies → | Established by ↑ | Cross-bound with ↔>; target: <peer>]` for new bindings.
+- `[Binding — closed: half-edge between <element-A> and <element-B>; reciprocal added at <element-B> in the same change-set]` for half-edge closures.
+- `[Binding — removed: <element>; reason: <element-removed | binding-no-longer-applies>; reciprocals updated at <peer-list>]` for binding removals.
+- `[Binding — Matrix appended: <appendix-path>; element-count: <N>]` for matrix emissions.
+
+## Failure tells
+
+`See Section 3` with no reciprocal back-pointer in Section 3 (half-edge — Section 3 does not declare it is being seen-from). A migration step that depends on a prior step without declaring the dependency in its `Driven by ←` (half-edge in the prerequisite direction). A test that satisfies an unstated requirement (the test's `Satisfies →` cites a requirement that has no `Established by ↑` declaration). A bindings section using ASCII-only arrows (`->` instead of `→`) — notation drift. A bindings section listing only `Drives →` and `Cross-bound with ↔`, omitting `Driven by ←` and `Satisfies →` and `Established by ↑` despite the artifact clearly being gated, satisfying criteria, and established by upstream anchors (incomplete population). A `Cross-bound with ↔` citation where the cited peer's section omits the reciprocal `Cross-bound with ↔` (asymmetric self-reciprocal). A multi-phase plan where Phase 03's `Drives → Phase 04` is declared but Phase 04 has no `Driven by ← Phase 03` (phase-execution threading half-edge). An artifact with five elements, dense bindings (each element binds to three or more peers), and no Bidirectional Binding Matrix appendix (mandatory matrix omitted). A renamed element whose old identifier still appears as a citation target in another element's binding line (stale citation). An element removed from the artifact whose reciprocal back-pointers in peer elements were not removed (dangling back-pointer).
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every substantive structural element across every emitted host-project artifact (the five-direction notation is the binding floor for every section, sub-section, contract, phase). ● The `## Bindings (§0.j five-direction)` section at every `rules/*.md` body. ● The phase-execution threading at every `<project-root>/.apothem/plans/*/MASTER-PLAN.md` and `phases/NN-topic/PHASE.md`. ● The Bidirectional Binding Matrix appendix at every spec / multi-element design document. ● The `binding-reciprocity-grep` mechanical matcher at `conformity/binding_reciprocity_grep.py` — operationalizes the §2 reciprocity invariant.
+- **Satisfies →** ● the fifteen-mandate registry row **M10 — Bidirectional Binding**. ● the Pre-Emission Gate row 10 (M10 bidirectional-binding check).
+- **Established by ↑** ● the fifteen-mandate registry (ratifies M10). ● the Pre-Emission Gate row 10. ● The ecosystem's existing practice — every `rules/*.md` already carries a `Bindings (§0.j five-direction)` section; this rule canonicalizes that practice rather than introducing it.
+- **Gated by ←** ● The trivial-vs-non-trivial threshold (trivial linear artifacts without cross-references are exempt). ● `CLAUDE.md` always-loaded preamble. ● The path-filter declared in this rule's frontmatter (Markdown / docs / structural-artifact directories).
+- **Cross-bound with ↔** ↔ `rules/visual-leverage.md` (M9 — diagram `cross-reference:` metadata is the diagram-side projection of the M10 reciprocal-binding surface). ↔ `rules/canonical-layout.md` (M12 — phase / sub-phase reporting binds producer / consumer / cross-references through M10 notation). ↔ `rules/disclosure-ledger.md` (M2 — binding emissions / closures / removals are recorded in the ledger). ↔ `rules/pre-emission-gate.md` (M4 — bar 10 of the gate enforces this rule's reciprocity invariant via the mechanical matcher). ↔ `rules/definitiveness.md` (M8 — placeholder bindings like `Drives → TBD` violate both this rule's reciprocity discipline and M8's closure-of-open-markers discipline). ↔ `rules/token-efficiency-rewrite.md` (L3 anchor loss is a half-edge failure on the same axis as §2 reciprocity).

package/src/apothem/rules/canonical-layout-reporting-tiers.md

@@ -0,0 +1,212 @@
+---
+name: "canonical-layout-reporting-tiers"
+description: "Path-filtered companion rule carrying the operational depth of `rules/canonical-layout.md` — the two-tier reporting body (per-sub-phase + phase rollup), the numeric-prefix discipline, the orphan-output recovery surface, the reciprocal producer / consumer cross-reference body, the surface-imposition table, and the M11 ↔ M12 correspondence table; demand-loaded on plan-suite / phase / migration touches."
+pathFilter: "**/.apothem/plans/**, **/.plans/**, **/phases/**, **/REPORT.md, **/PHASE.md, **/MASTER-PLAN.md, **/PROGRESS.md, **/migrations/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Canonical Layout — Reporting Tiers & Operational Body (Companion Sub-Rule)
+
+## Purpose
+
+Carry the operational depth of the canonical-layout discipline declared at the parent `rules/canonical-layout.md` rule. Path-filtered: loads on any per-suite plan artifact, per-phase artifact, per-sub-phase report, migration script, or progress / master-plan singleton. The parent owns the M12 standing directive and the per-section summaries; this companion owns each section's full body — §1 two-tier reporting, §2 canonical layout, §2.1 numeric-prefix discipline, §2.2 `_outputs/`, §2.3 anti-inflation, §2.4 maintenance suites, §3 orphan prevention, §4 reciprocal cross-references, §5 surface imposition, §6 M11 ↔ M12 correspondence, §7 three-tier scalability (D7).
+
+## Obligations
+
+### 1. Two-Tier Reporting — Per-Sub-Phase + Phase Rollup
+
+#### 1.1 Per-Sub-Phase Report (Working Tier)
+
+Every sub-phase produces a report at the sub-phase folder's canonical filename (`REPORT.md` is the plan-suite convention; the host's discovered convention overrides per M1). This is the **working tier** — fine-grained, as-it-happens, capturing the sub-phase's substantive work.
+
+Canonical sections:
+
+- **Summary** — one-paragraph statement of what the sub-phase produced.
+- **Tasks executed** — enumeration of tasks completed, mapped to the sub-phase's `PHASE.md` task list.
+- **Outputs emitted** — every artifact produced, with path, line count or size, and a one-line description.
+- **Verification results** — every per-sub-phase verification item with its outcome.
+- **Disclosure ledger** — the sub-phase's amendments, extensions, refinements, deferrals, defaults, and inquiry outcomes per `rules/disclosure-ledger.md`.
+- **Pre-emission gate attestation** — the fifteen-bar attestation per `rules/pre-emission-gate.md`.
+- **Bindings (§0.j five-direction)** — reciprocal cross-references per `rules/bidirectional-binding.md`.
+
+#### 1.2 Phase-Level Rollup Report (Reviewing Tier)
+
+Every phase produces a rollup report aggregating across its sub-phases — the **reviewing tier**: derivative, condensed, cross-cutting.
+
+**The rollup is NOT a concatenation of sub-phase report links.** A document that lists the sub-phase reports as bullets and stops is non-conformant. The rollup carries five required behaviors:
+
+1. **Summarizes each sub-phase's outputs in a uniform template.** Each sub-phase gets the same shape — same headings, same fields, same reading order. Heterogeneous sub-phase summaries (one verbose, another a stub, a third in a different format) violate the uniform-template requirement.
+2. **Aggregates metrics across sub-phases.** Counts (artifacts emitted, lines authored, tests passed, verifications cleared), durations (sub-phase elapsed time, sprint velocity per `rules/agile-sprints.md` §1.7), trajectories (defect rate, churn, finding density) are aggregated and presented at the phase level.
+3. **Surfaces phase-level patterns invisible at any single sub-phase.** Patterns that emerge only across sub-phases — recurring failure modes, convergent decisions, drift between sub-phases — are surfaced explicitly. The phase-level pattern surface is the rollup's **unique** value over per-sub-phase concatenation.
+4. **Carries a phase-level self-check.** The rollup runs the pre-emission gate at the **phase level**, not just the per-sub-phase level. The phase's own bindings, the phase's own definitiveness, the phase's own production-readiness are inspected as a whole.
+5. **Advances the phase's outward declarations on behalf of the whole phase.** The rollup commits the phase's outputs to the phase's downstream consumers — the next phase's inputs, the parent suite's progress tracker, the host's index registries.
+
+The rollup's filename convention follows the host's discovery; the established plan-suite convention is `phases/NN-topic/REPORT.md` (the parent phase's `REPORT.md` at the parent folder), with sub-phases at `phases/NN-topic/NNL-subtopic/REPORT.md`. Single-sub-phase phases collapse the tier — the per-sub-phase report IS the rollup.
+
+### 2. Canonical Layout — Predictable Locations with Provenance
+
+Generated outputs sit at **predictable, canonical locations** with provenance and reciprocal cross-references. The exact form of "canonical" — directory naming, filename conventions, structural-marker prefixes, per-directory index conventions — is **delegated to the host's discovered conventions** per `rules/host-discovery.md`. Where the host is silent on layout, the choice surfaces as an inquiry per `rules/authority-inquiry.md` with apothem's recommendation per `rules/option-annotation.md`.
+
+**No artifact is laid as a flat file at an ad-hoc location.** Every emitted output has:
+
+- A **canonical directory** the host has ratified for outputs of its kind (e.g., test files under the host's tests directory; documentation pages under the host's docs directory; CI workflows under `.github/workflows/`; migration scripts under the host's migrations directory).
+- A **filename matching the host's sibling convention** (kebab-case / snake_case / PascalCase / etc. — whatever the siblings use).
+- A **provenance record** — either embedded in the artifact (frontmatter, header comment, docstring) or recorded in the producer's report. Every emitted artifact answers "where did this come from?" by inspection.
+- An **index entry** in the enclosing directory's index where the host maintains one (`__init__.py`, `index.md`, TOC, sidebar, package manifest).
+
+Cross-phase artifacts — synthesizing across phases — sit at the host's designated cross-phase deliverable location (whatever the host's convention is), indexed in the enclosing directory's index, with reciprocal back-references from every phase that contributed.
+
+### 2.1 Numeric-Prefix Discipline — Ordering Sequences Only
+
+Numeric prefixes on filesystem paths (`00-`, `01-`, `02-`, `NN-`) **convey ordering**. The discipline scopes them to artifacts whose **sequence is intrinsic to the contract**:
+
+- **Phase-ordering folders** under `phases/` (`phases/00-discovery/`, `phases/01-foo/`, `phases/02-bar/`) — the prefix carries the ordering the phase apparatus depends on. The `NN-` prefix is mandatory on every phase folder.
+- **Sub-phase folders** under a parent phase (`phases/02-foo/02A-subtopic/`, `02B-subtopic/`) — the prefix-plus-letter carries the sub-phase ordering. Mandatory.
+- **Migration scripts** where the host orders by numeric prefix (`migrations/0042_user_schema.sql`) — honor the host's ratified scheme.
+- **Any other artifact class where the host has ratified ordinal-prefix naming** as a convention — discovered per `rules/host-discovery.md` and honored.
+
+**Numeric prefixes are forbidden on artifacts that have no sibling sequence** — root-level singletons, lone configuration files, top-of-suite infrastructure files. Adding a prefix to a file that has no `01-` / `02-` siblings is **meaningless decoration that mis-signals an ordering relationship that does not exist**, and is a structural failure on the same axis as the orphan-output failure at §3.
+
+**Suite-root infrastructure files** at every plan-suite root (`<project-root>/.apothem/plans/{suite}/`) — the suite preamble, the master index, the progress tracker, the plan-notes ledger, the completion attestation, every other root-level singleton — carry **no numeric prefix**. They are siblings of one another, not items in an ordered sequence; the prefix would falsely imply an ordering the contract does not require. The same discipline extends to **any new root-level singleton class** the ecosystem admits in the future: the prefix appears only where ordering is intrinsic, never as decoration.
+
+**Failure tells.** A `00-FOO.md` at any root level where there is no `01-FOO.md` sibling is a finding. A renamed file gaining the prefix when its prior sibling-set never carried one is a finding. A new artifact class whose first instance is `00-X.md` ratifies a prefix the second instance (`01-X.md`?) would have to honor — preferable: drop the prefix on the first instance unless ordering is genuinely intrinsic.
+
+### 2.2 Plan-Suite `_outputs/` Emission Surface
+
+Every plan suite may carry a suite-local `_outputs/` sibling beside `_inputs/`, `_spec/`, and `phases/`. `_outputs/` is the canonical home for durable generated emissions that are useful after the session but too detailed for PROGRESS.md or PLAN-NOTES.md: audit reports, report mirrors, rollups, metrics, exports, and bounded operator-facing summaries.
+
+Placement discipline:
+
+- `/plan-audit` writes bounded audit reports to `<suite>/_outputs/audit-report-<YYYY-MM-DD>.md`.
+- `/plan-execute` writes phase implementation reports at `phases/NN-topic/REPORT.md` and may mirror operator-facing summaries at `<suite>/_outputs/<phase-slug>/REPORT.md`.
+- `/plan-review` keeps scorecards and concise findings state in PLAN-NOTES.md, but durable large review reports or revision-impact detail maps move to `_outputs/` with backlinks.
+- `/plan-status` remains read-only; if another orchestrator persists its prose output, that file belongs under `_outputs/report-<YYYY-MM-DD>.md` unless the host has a more specific documentation surface.
+
+Every `_outputs/` artifact must carry producer attribution and a consumer/index reference: the producer report's `Outputs emitted` section, PROGRESS.md Phase Output Registry, a local README/index if the suite maintains one, or the Handoff Manifest. `_outputs/` artifacts are evidence, not authoritative requirements; requirement traceability still resolves to the suite specification, MASTER-PLAN.md, PHASE.md, or operator-ratified decisions.
+
+### 2.3 Anti-Inflation Reporting Discipline
+
+PROGRESS.md and PLAN-NOTES.md are bounded state ledgers, not storage for every detail. They use index-first summaries and backlink to reports:
+
+- PROGRESS.md records current status, counters, blocker summaries, Phase Output Registry rows, Resumption Contract, next action, and critical file manifests. It does not accumulate long chronological narratives or paste full verification logs.
+- PLAN-NOTES.md records durable decisions, scorecard summaries, open questions, waivers, and rationale. It uses rolling summaries when a section grows beyond the current decision horizon.
+- REPORT.md and `_outputs/` hold detailed task logs, verification transcripts, audit reports, metrics, and long evidence tables.
+
+When a workflow produces detailed evidence, the same change-set writes the detail to REPORT.md or `_outputs/`, then writes a concise PROGRESS.md / PLAN-NOTES.md backlink. The backlink is the state surface; the report is the evidence surface.
+
+### 2.4 `*-maintenance` Suite Pattern
+
+Deferred, incomplete, or out-of-scope work that would inflate the active suite routes to a sibling maintenance suite named `<suite>-maintenance`. Maintenance routing is for work that the originating suite should not execute now, not for hiding open findings required by the current gate.
+
+Each maintenance item carries:
+
+- Source suite path and source artifact anchor.
+- Finding or task ID.
+- Rationale for maintenance routing.
+- Expected downstream command or phase.
+- Current status and owner, if known.
+
+The originating suite records only a concise maintenance backlink in PLAN-NOTES.md or PROGRESS.md. The maintenance suite carries the expanded backlog and its own `_spec/`, `_inputs/`, `_outputs/`, and `phases/` surfaces when it becomes executable.
+
+### 3. Orphan Output Prevention
+
+An **orphan output** is a generated artifact that satisfies any of:
+
+- **No consumer.** Nothing in the host's reference graph reads, imports, executes, links to, or references the artifact.
+- **No index entry.** The artifact is not listed in its enclosing directory's index where the host maintains one.
+- **No producer attribution.** The artifact carries no provenance — no frontmatter `provenance:` field, no header comment naming the producer, no record in the producer's report.
+
+Orphan outputs are **structural failures**. The `orphan-output-grep` mechanical matcher at `conformity/orphan_output_grep.py` scans every emitted artifact's enclosing directory for index-entry presence and the producer's report for attribution presence. Orphan findings are HIGH-severity at the pre-emission gate per `rules/pre-emission-gate.md` row 12.
+
+**Orphan recovery.** When an orphan is detected:
+
+- **Add the consumer.** If the artifact is genuinely needed but no consumer exists, surface the gap as a finding for the user's decision (the artifact's existence is justifiable but its consumer is missing).
+- **Add the index entry.** Update the enclosing directory's index in the same change-set. The index update is part of the artifact's emission, not a follow-up.
+- **Add the producer attribution.** Update the producer's report to record the artifact's emission. Update the artifact's frontmatter / header to cite the producer.
+- **Retire the artifact.** When investigation reveals the artifact has no genuine consumer, it is retired in the same change-set rather than left as an orphan. Retirement routes through the destructive-op confirmation surface at `rules/interactive-questions.md` §6.4 (the canonical Delete option set).
+
+### 4. Reciprocal Producer / Consumer Cross-References
+
+Every emitted output carries reciprocal cross-references on both ends of every producer / consumer edge:
+
+- **Producer side.** The phase's report (per-sub-phase or rollup) lists the artifact in its `Outputs emitted` section with the artifact's path, the consumer(s) that depend on it, and the binding direction (`Drives → <consumer>`).
+- **Consumer side.** Every artifact that consumes the output references it explicitly. For code, this is an import / require / link. For documentation, this is a Markdown link or include. For configuration, this is a path reference. The consumer's reference IS the reciprocal back-pointer per `rules/bidirectional-binding.md`.
+
+When an output's consumer changes (added, removed, renamed), the producer's report is updated in the same change-set. Stale producer reports (claiming a consumer that no longer exists, omitting a new consumer) are findings.
+
+### 5. Surface Imposition — Where the Layout Discipline Lands
+
+| Surface | Layout obligation |
+|---|---|
+| `CLAUDE.md` | Carries the standing directive that non-trivial multi-step work lays outputs under the canonical layout with two-tier reporting (M12 row in §8 fifteen-mandate registry). |
+| `skills/*/SKILL.md` | Procedures spanning sub-phases specify the sub-phase partitioning and the expected reports; per-sub-phase report shape is declared in the procedure. |
+| `agents/*.md` | Agents with multi-artifact remits return a work-root path with the canonical layout populated. The return format includes the per-sub-phase reports and the rollup. |
+| `commands/*.md` | Commands declare their place in the host's pipeline conventions. Each command's outputs section names the canonical layout the command honors. |
+| Multi-phase plans at `<project-root>/.apothem/plans/*/` | Each phase folder follows `phases/NN-topic/{REPORT.md, NNL-subtopic/}` shape. Sub-phase folders follow `phases/NN-topic/NNL-subtopic/{PHASE.md, REPORT.md, …}` shape. Cross-phase synthesis sits at the suite-root level (`MASTER-PLAN.md`, `PREAMBLE.md`, `PROGRESS.md`, `PLAN-NOTES.md`); durable generated emissions sit under `_outputs/`. |
+| Hook scripts at `conformity/` | The `orphan-output-grep` and the `non-canonical-location-grep` matchers operationalize §3 and §2 respectively at the pre-emission gate. |
+
+### 6. The M11 ↔ M12 Correspondence
+
+The sprint apparatus per `rules/agile-sprints.md` and the layout / reporting discipline here are **mutually-reinforcing**. The correspondence:
+
+| Sprint apparatus element (M11) | Layout / reporting surface (M12) |
+|---|---|
+| Sprint Goal | The phase / sub-phase folder's `PHASE.md` Goal section |
+| Sprint Backlog | The phase / sub-phase folder's Tasks section |
+| Definition of Ready | Pre-conditions checklist in the per-sub-phase report's preamble |
+| Definition of Done | Verification section in the per-sub-phase report |
+| Sprint Review | The rollup report's per-sub-phase summaries with approve / reject / carry-forward outcomes |
+| Sprint Retrospective | The rollup report's pattern-surfacing section + retrospective subsection |
+| Velocity tracking | Aggregated metrics in the rollup report (artifacts emitted, items completed per sub-phase) |
+
+The mapping is the operational form of the M11 Agile-process discipline materialized at the M12 layout / reporting surface. A non-trivial multi-step work session that satisfies M11 without populating the corresponding M12 surface is non-conformant; a session that satisfies M12 without the M11 apparatus is equally non-conformant.
+
+### 7. Three-Tier Scalability Framework (D7)
+
+The two-tier reporting discipline at §1 governs intra-phase / intra-suite reporting; this section governs inter-suite scalability — how the layout, validation cadence, indexing, and decomposition heuristics shift as a plan suite grows from a few dozen phases to thousands.
+
+#### 7.1 Tier Table
+
+| Tier | Phase count | Spec count | Validation cadence | Indexing | Decomposition |
+|---|---|---|---|---|---|
+| `small` | <50 | <100 | Full-suite each pass — `/plan-review` audits every phase, every spec section, every constraint per cycle | In-line refs (PLAN-NOTES.md narrative trace tables) | Monolithic — single suite at `<project-root>/.apothem/plans/{suite}/` |
+| `medium` | 50–500 | 100–1000 | Incremental + sampled-rollup — per-phase validation continues, plus phase-group rollups (5–20 phases each) sampled per cycle | Suite-root `MASTER-INDEX.md` per `src/apothem/templates/master-index-template.md` | Phase-grouped — `phases/NN-group/NNL-phase/` two-level shape, groups of 5–20 phases |
+| `large` | ≥500 | ≥1000 | Index-driven + on-demand drilldown — `MASTER-INDEX.md` is queried first, sub-suite REPORTs read on demand | `MASTER-INDEX.md` per sub-suite + suite-of-suites parent index | Sub-suite federation — multiple plan suites with parent-child relationship; each child suite is small or medium |
+
+#### 7.2 Drift-Prevention Mechanisms
+
+| Mechanism | Tier applicability | Description |
+|---|---|---|
+| Trace matrix | All tiers | Every spec requirement maps to one or more phases; every phase maps to one or more spec requirements. Bidirectional. At small tier, narrative trace tables inside the plan suite's notes file substitute for the formal trace-matrix file; at medium+ tier, `src/apothem/templates/trace-matrix-template.md` is materialized at the suite root. |
+| Stable IDs | medium+ | Cross-references use stable IDs (`R-NNNN` for requirements; `P-NN` for phases) so renames do not break refs. |
+| `MASTER-INDEX.md` | medium+ | Suite-root index of every phase + every spec section + every constraint + every named decision per `src/apothem/templates/master-index-template.md`. |
+| Sub-suite federation | large | Plan decomposes into multiple plan suites with parent-child relationship; each child suite is small or medium; the parent index aggregates. |
+| Per-phase verification | All tiers | Every phase emits a per-phase REPORT.md per §1.1. |
+| Phase-rollup verification | medium+ | Every group of 5–20 phases emits a rollup REPORT per §1.2. |
+| Suite-rollup verification | large | Every child suite emits a final rollup; federation aggregates child-suite rollups at the parent. |
+
+#### 7.3 Borderline-Tier Inquiry
+
+When a plan suite's phase count sits within ±10% of a tier boundary (45–55 phases for the small/medium boundary; 450–550 phases for the medium/large boundary), the agent MUST surface a tier-classification choice through the structured-inquiry channel per `rules/authority-inquiry.md` (preference category) rather than silent-pick. Question shape: `Plan suite phase count is within ±10% of a tier boundary; which scalability tier should govern this suite?`; header `Tier`; options `Small / Medium / Large` each with three-segment body citing the boundary thresholds and any host-discoverable prior-suite tier conventions per `rules/host-discovery.md`; `default-pointer:` `no-default: user decision required` (long-lived ratification per the §7.2 stable-ID convention; silent default would commit the suite to a tier without the operator's awareness of boundary proximity).
+
+#### 7.4 Small-Tier Worked Example
+
+The `sample-overhaul` plan suite at `<project-root>/.apothem/plans/sample-overhaul/` is a worked small-tier example: 24 PHASE.md files (well under the 50-phase boundary) governed by full-suite validation per cycle, in-line cross-references inside `PLAN-NOTES.md`, and a monolithic single-suite layout at the suite root. No `MASTER-INDEX.md` is materialized; no formal trace-matrix file is produced; the narrative trace tables inside `PLAN-NOTES.md` carry the all-tier trace-matrix obligation at the small-tier alternative form.
+
+#### 7.5 Tier Transition
+
+When a small-tier suite grows past the 50-phase boundary (or a medium-tier suite past 500), the transition is a deliberate operator decision routed through `/plan-review` plus a tier-classification structured inquiry. The transition emits the medium-tier (or large-tier) infrastructure in the same change-set: `MASTER-INDEX.md` materialized, stable IDs assigned to existing phases / requirements, trace-matrix file produced per `src/apothem/templates/trace-matrix-template.md`, sub-suite federation laid out (large only). Silent transitions are non-conformant — a 51-phase suite with no `MASTER-INDEX.md` is a structural failure on the same axis as a missing per-phase REPORT.md.
+
+## Enforcement
+
+Path-filtered (the eight glob patterns in this rule's `pathFilter` field — `**/.apothem/plans/**`, `**/.plans/**`, `**/phases/**`, `**/REPORT.md`, `**/PHASE.md`, `**/MASTER-PLAN.md`, `**/PROGRESS.md`, `**/migrations/**`), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/canonical-layout.md`: the parent owns the M12 standing directive and per-section summaries; this companion owns the operational bodies for §1 two-tier reporting, §2 / §2.1 layout and numeric-prefix discipline, §2.2 `_outputs/`, §2.3 anti-inflation, §2.4 maintenance suites, §3 orphan-output recovery, §4 reciprocal cross-references, §5 surface imposition, §6 M11 ↔ M12 correspondence, and §7 three-tier scalability (D7).
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every sub-phase `REPORT.md` body across every plan suite (§1.1 canonical-sections list). ● Every phase rollup `REPORT.md`'s five required behaviors (§1.2 — uniform template, aggregate metrics, surface patterns, phase-level self-check, advance outward declarations). ● Every phase folder's `NN-` prefix and every sub-phase folder's `NNL-` suffix (§2 numeric-prefix discipline). ● Every `_outputs/` durable emission and anti-inflation backlink (§2.2-§2.3). ● Every `*-maintenance` suite routing (§2.4). ● Every orphan-recovery action (§3 — add consumer / add index entry / add producer attribution / retire). ● Every producer-side / consumer-side reciprocal cross-reference closure (§4). ◐ The `orphan-output-grep` mechanical matcher at `conformity/orphan_output_grep.py`.
+- **Satisfies →** ● the fifteen-mandate registry row **M12 — Phase Reporting & Canonical Layout** (operational depth tier; standing-directive tier is the parent rule). ● `rules/canonical-layout.md` per-section anchors (each anchor's `(Companion Sub-Rule Anchor)` pointer line resolves to a section here).
+- **Established by ↑** ● `rules/canonical-layout.md` (parent rule; this companion carries the operational depth the parent's anchors point to). ● the fifteen-mandate registry (ratifies M12). ● the Pre-Emission Gate row 12.
+- **Gated by ←** ● The path-filter (the seven glob patterns) — this rule demand-loads only on plan-suite / phase / migration artifact touches. ● `rules/canonical-layout.md` always-on baseline (parent rule must be live for the per-section anchors to surface and resolve here). ● The trivial-vs-non-trivial threshold (trivial-scope work bypasses the two-tier requirement; this rule's body never engages).
+- **Cross-bound with ↔** ↔ `rules/canonical-layout.md` (parent rule; per-section anchors bind this companion). ↔ `rules/agile-sprints.md` (M11 — the §6 M11 ↔ M12 correspondence table is the mutual-reinforcement surface; sprint apparatus and layout / reporting surface bind both ways). ↔ `rules/bidirectional-binding.md` (M10 — §4 reciprocal producer / consumer cross-references operationalize M10 reciprocity at the artifact layer). ↔ `rules/host-discovery.md` (M1 — §1.1 / §1.2 / §2 honor host-discovered conventions for filenames and prefix schemes). ↔ `rules/pre-emission-gate.md` (M4 — bar 12 enforces this rule's two-tier + canonical-layout + orphan-prevention invariants). ↔ `rules/disclosure-ledger.md` (M2 — output / report / orphan-resolution emissions are recorded in the parent's ledger). ↔ `rules/interactive-questions.md` (§6.4 destructive-op canonical option set governs §3's orphan-retirement path; §7.3 borderline-tier inquiry routes through the canonical channel). ↔ `src/apothem/templates/master-index-template.md` (medium+ tier suite-root index per §7.2). ↔ `src/apothem/templates/trace-matrix-template.md` (all-tier trace-matrix surface per §7.2; small tier substitutes a narrative trace table in the plan suite's notes file).