@ahmed-g-gad/apothem 0.1.1

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

@@ -0,0 +1,60 @@
+---
+name: "canonical-layout"
+description: "Non-trivial multi-step work emits two-tier reporting (per-sub-phase report + phase-level rollup that aggregates rather than concatenates) and lays generated outputs at the host's discovered canonical layout with reciprocal producer / consumer cross-references and provenance. Orphan outputs (generated artifacts with no consumer / no index entry / no producer attribution) are structural failures."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Phase / Sub-Phase Reporting & Canonical Layout of Generated Outputs
+
+## What this rule enforces
+
+Binds **M12 — Phase / Sub-Phase Reporting & Canonical Layout of Generated Outputs**. Non-trivial multi-step work MUST emit two-tier reporting (working + reviewing tiers) and MUST lay every generated output at a host-discovered canonical location with reciprocal producer / consumer cross-references and provenance. An orphan output — no consumer, OR no index entry, OR no producer attribution — is a structural failure, not a deferral candidate.
+
+## Pre-conditions
+
+Applies whenever the agent undertakes non-trivial multi-step work per the trivial-vs-non-trivial threshold. Trivial-scope work skips two-tier reporting. Single-sub-phase work collapses the tier (the sub-phase report IS the rollup) but still honors the canonical-layout discipline.
+
+## Required behavior
+
+Operational bodies live at the (Companion Sub-Rule Anchor) sibling rule, demand-loaded on plan-suite / phase / REPORT.md / PHASE.md / MASTER-PLAN.md / PROGRESS.md / migrations touches.
+
+(Companion Sub-Rule Anchor) §1 — two-tier reporting) Working tier (per-sub-phase REPORT.md with Summary / Tasks / Outputs / Verification / Disclosure ledger / gate attestation / Bindings) plus reviewing tier (rollup REPORT.md aggregating rather than concatenating — uniform template, aggregated metrics, pattern surfacing, phase self-check, outward declarations); single-sub-phase phases collapse the tier. See `rules/canonical-layout-reporting-tiers.md` §1.
+
+(Companion Sub-Rule Anchor) §2 — canonical layout) Outputs sit at predictable host-discovered locations per `rules/host-discovery.md`; every output carries canonical directory + sibling-convention filename + provenance record + index entry. Cross-phase artifacts sit at the host's cross-phase deliverable location with reciprocal back-references. See `rules/canonical-layout-reporting-tiers.md` §2.
+
+(Companion Sub-Rule Anchor) §2.1 — numeric-prefix discipline) Numeric prefixes (`NN-`, `NNL-`) convey ordering and apply only where sequence is intrinsic — phase folders, sub-phase folders, host-ratified migration scripts. Forbidden on root-level singletons and any class without a sibling sequence; decorative prefixes are structural failures. See `rules/canonical-layout-reporting-tiers.md` §2.1.
+
+(Companion Sub-Rule Anchor) §2.2 — plan-suite `_outputs/` surface) Durable generated emissions from plan workflows sit under each suite's `_outputs/` sibling, not in inflated PROGRESS.md / PLAN-NOTES.md narrative and not in ad-hoc root files. See `rules/canonical-layout-reporting-tiers.md` §2.2.
+
+(Companion Sub-Rule Anchor) §2.3 — anti-inflation reporting discipline) PROGRESS.md and PLAN-NOTES.md remain bounded, index-first state ledgers; detailed reports, audit traces, metrics, and bulky evidence move to REPORT.md or `_outputs/` with backlinks. See `rules/canonical-layout-reporting-tiers.md` §2.3.
+
+(Companion Sub-Rule Anchor) §2.4 — `*-maintenance` suite pattern) Deferred or out-of-scope plan work is routed to a sibling maintenance suite with source-suite anchors and rationale; it is not buried in the originating suite's progress narrative. See `rules/canonical-layout-reporting-tiers.md` §2.4.
+
+(Companion Sub-Rule Anchor) §3 — orphan-output prevention) Orphan = no consumer OR no index entry OR no producer attribution; HIGH-severity at pre-emission gate row 12; mechanical matcher at `conformity/orphan_output_grep.py`; recovery via add-consumer / add-index / add-attribution / retire — all in the same change-set. See `rules/canonical-layout-reporting-tiers.md` §3.
+
+(Companion Sub-Rule Anchor) §4 — reciprocal producer / consumer cross-references) Producer-side declares artifact + consumer(s) + binding direction in `Outputs emitted`; consumer-side references the output explicitly per `rules/bidirectional-binding.md`; stale producer reports are findings. See `rules/canonical-layout-reporting-tiers.md` §4.
+
+(Companion Sub-Rule Anchor) §5 — surface imposition) Discipline lands across CLAUDE.md, skills, agents, commands, .apothem/plans/, and tools/conformity. See `rules/canonical-layout-reporting-tiers.md` §5 for the per-surface obligation table.
+
+(Companion Sub-Rule Anchor) §6 — M11 ↔ M12 correspondence) Sprint apparatus per `rules/agile-sprints.md` and layout / reporting discipline are mutually reinforcing — Goal / Backlog / DoR / DoD / Review / Retrospective / Velocity each ↔ a layout-tier surface. See `rules/canonical-layout-reporting-tiers.md` §6 for the full table.
+
+(Companion Sub-Rule Anchor) §7 — three-tier scalability (D7)) `small` (<50 phases / <100 specs) — full-suite validation each pass, in-line refs, monolithic single suite. `medium` (50–500 / 100–1000) — incremental + sampled-rollup validation, suite-root `MASTER-INDEX.md`, phase-grouped decomposition (groups of 5–20). `large` (≥500 / ≥1000) — index-driven + on-demand drilldown validation, queryable index, sub-suite federation. Drift-prevention mechanisms (trace matrix all-tier; stable IDs / MASTER-INDEX.md / phase-rollup verification at medium+; sub-suite federation / suite-rollup at large) per the templates at `src/apothem/templates/master-index-template.md` and `src/apothem/templates/trace-matrix-template.md`. Borderline-tier (±10% of a boundary) routes through the structured-inquiry channel per `rules/authority-inquiry.md` rather than silent-pick. See `rules/canonical-layout-reporting-tiers.md` §7 for tier table, drift-prevention table, and small-tier worked example.
+
+## Disclosure surface
+
+Every layout / reporting emission lands in the disclosure ledger per `rules/disclosure-ledger.md` — `[Output — emitted: …]`, `[Report — sub-phase: …]`, `[Report — rollup: …]`, `[Output — orphan-resolved: …]`. Full marker schemas live at the (Companion Sub-Rule Anchor) sibling rule's Disclosure surface.
+
+## Failure tells
+
+Flat `report1.md` / `report2.md` at ad-hoc paths. A rollup that merely concatenates sub-phase report links instead of aggregating. Cross-phase synthesis buried inside one phase folder. Missing producer attribution. Tests at the project root; docs inlined into README; a CI workflow with no CONTRIBUTING entry. Heterogeneous rollups. A stale producer report claiming a vanished consumer. An emission with no `orphan-output-grep` clearance recorded.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every non-trivial multi-step work surface in every host project (the two-tier reporting discipline + canonical-layout discipline are the output-shape floor). ● The `orphan-output-grep` mechanical matcher at `conformity/orphan_output_grep.py` — operationalizes the §3 orphan-prevention invariant. ● Every multi-phase plan's `phases/NN-topic/{REPORT.md, NNL-subtopic/}` shape. ● Every multi-artifact agent return format. ● The pre-emission gate's row 12 enforcement per `rules/pre-emission-gate.md`.
+- **Satisfies →** ● the fifteen-mandate registry row **M12 — Phase Reporting & Canonical Layout**. ● the Pre-Emission Gate row 12 (M12 phase-layout check).
+- **Established by ↑** ● the fifteen-mandate registry (ratifies M12). ● the Pre-Emission Gate row 12. ● The plan-suite's existing two-tier convention at `<project-root>/.apothem/plans/*/phases/NN-topic/{PHASE.md, REPORT.md}` — this rule canonicalizes the existing practice and extends it to host-project work.
+- **Gated by ←** ● The trivial-threshold (trivial-scope work bypasses the two-tier requirement). ● `CLAUDE.md` always-loaded preamble. ● `rules/host-discovery.md` (the layout's "canonical" is host-discovered; this rule's §2 delegates the exact form to M1 discovery).
+- **Cross-bound with ↔** ↔ `rules/canonical-layout-reporting-tiers.md` (path-filtered companion sub-rule carrying the operational depth for §1 two-tier reporting, §2.1 numeric-prefix discipline, §3 orphan-output prevention, §4 reciprocal cross-references, §5 surface imposition, and §6 M11 ↔ M12 correspondence). ↔ `rules/agile-sprints.md` (M11 — the §6 M11 ↔ M12 correspondence is the operational form binding the two rules; sprint apparatus and layout surface are mutually reinforcing). ↔ `rules/bidirectional-binding.md` (M10 — reciprocal producer / consumer cross-references at §4 operationalize M10 reciprocity at the artifact layer). ↔ `rules/host-discovery.md` (M1 — canonical layout's exact form is host-discovered). ↔ `rules/visual-leverage.md` (M9 — diagrams of phase / sub-phase structure live at the canonical layout per §2). ↔ `rules/pre-emission-gate.md` (M4 — bar 12 of the gate 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 ledger). ↔ `rules/recommend-next-step.md` (M12 — the Recommended Next Step block is the reporting tier's forward-move surface). ↔ `rules/harness-adapter-shape.md` (M12 — adapter sub-packages and STANDARD-CONVENTION-PIN.md sit at the canonical layout per the §1 directory shape). ↔ `rules/propagation.md` (orphan prevention is one tier of the same-change-set reference-graph sync).

package/src/apothem/rules/clean-architecture-layers.md

@@ -0,0 +1,186 @@
+---
+name: "clean-architecture-layers"
+description: "Clean architecture layer discipline — Domain / Application / Infrastructure / Presentation separation under the inward-only dependency rule (Domain depends on nothing; outer layers implement inner-layer interfaces injected at the composition root; no inner layer imports a concrete outer class). Mandatory at 3+ modules or SHARED+; relaxed for throwaway scripts and trivial scopes. Path-filtered to src / lib / app / packages source trees."
+pathFilter: "**/src/**, **/lib/**, **/app/**, **/packages/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Clean Architecture Layer Discipline
+
+## Purpose
+
+Enforce strict separation between the Domain, Application, Infrastructure, and Presentation layers — protecting the domain core from external concerns to guarantee testability, scalability, and maintainability.
+
+## Obligations
+
+### 1. The Four Canonical Layers
+
+Every non-trivial project MUST be organized into four distinct layers under strict dependency rules:
+
+| Layer | Contains | Depends On | Never Depends On |
+| ----- | -------- | ---------- | ---------------- |
+| **Domain** | Entities, value objects, domain events, repository interfaces, domain services, business rules, validation logic | Nothing (pure, self-contained) | Application, Infrastructure, Presentation |
+| **Application** | Use cases, application services, DTOs, command/query handlers, orchestration logic, ports (interfaces) | Domain only | Infrastructure, Presentation |
+| **Infrastructure** | Database adapters, API clients, file system, message queues, cache implementations, ORM configurations, external service integrations | Domain, Application (implements their interfaces) | Presentation |
+| **Presentation** | Controllers, views, API endpoints, CLI handlers, serializers, middleware, request/response mapping | Application (via ports/interfaces) | Domain directly, Infrastructure directly |
+
+**The Dependency Rule.** Dependencies point inward only. Domain is innermost; Presentation outermost. Infrastructure sits beside Presentation — neither depends on the other.
+
+### 2. Layer Boundary Enforcement
+
+**2.1 — Import Discipline:**
+
+- Domain files MUST NOT import from Application, Infrastructure, or Presentation.
+- Application files MUST NOT import from Infrastructure or Presentation.
+- Cross-layer communication flows through interfaces (ports) defined in inner layers and implemented by outer layers.
+
+**2.2 — Interface Segregation at Boundaries:**
+
+- Every cross-layer dependency MUST be mediated by an interface / protocol / abstract class defined in the consuming (inner) layer.
+- Infrastructure implements Domain repository interfaces and Application port interfaces.
+- Presentation consumes Application services through defined ports — never reaching into Domain or Infrastructure directly. **Exception:** Domain value objects (e.g., `Money`, `UserId`) received through Application DTOs MAY be referenced in Presentation for display / serialization — but Presentation MUST NOT invoke Domain services or business logic.
+
+**2.3 — Dependency Injection:**
+
+- Outer-layer implementations are injected into inner-layer interfaces at the composition root (application startup).
+- No inner layer constructs or references a concrete outer-layer implementation.
+- Injection configuration is the composition root's responsibility, not the individual layers'.
+- For the Python materialization (`Protocol`, `ABC`, composition-root patterns), see `rules/code-craft-python.md` §1 DIP.
+
+### 3. Directory Structure Patterns
+
+Recommended directory layouts (adapt to language/framework conventions):
+
+**Flat Module Pattern (small-medium projects):**
+
+```mermaid
+%%{ init: { "theme": "neutral" } }%%
+%% verified: 2026-04-27 %%
+%% provenance: rules/clean-architecture-layers.md §1 (four canonical layers) %%
+%% cross-reference: rules/clean-architecture-layers.md §2 (layer boundary enforcement) %%
+graph TD
+    SRC["src/"]
+    SRC --> DOM["domain/<br/>(entities · value objects · interfaces)"]
+    SRC --> APP["application/<br/>(use cases · services · DTOs)"]
+    SRC --> INF["infrastructure/<br/>(database · APIs · external services)"]
+    SRC --> PRES["presentation/<br/>(controllers · CLI · API endpoints)"]
+```
+
+**Domain-Driven Module Pattern (large projects):**
+
+```mermaid
+%%{ init: { "theme": "neutral" } }%%
+%% verified: 2026-04-27 %%
+%% provenance: rules/clean-architecture-layers.md §1 (four canonical layers) + §6.1 (mandatory full layer separation) %%
+%% cross-reference: rules/clean-architecture-layers.md §2.1 (import discipline) %%
+graph TD
+    SRC["src/"]
+    SRC --> MODS["modules/"]
+    MODS --> USERS["users/"]
+    USERS --> U_DOM["domain/"]
+    USERS --> U_APP["application/"]
+    USERS --> U_INF["infrastructure/"]
+    USERS --> U_PRES["presentation/"]
+    MODS --> ORDERS["orders/"]
+    ORDERS --> O_DOM["domain/"]
+    ORDERS --> O_APP["application/"]
+    ORDERS --> O_INF["infrastructure/"]
+    ORDERS --> O_PRES["presentation/"]
+    SRC --> SHARED["shared/"]
+    SHARED --> S_DOM["domain/<br/>(shared value objects · cross-cutting domain logic)"]
+    SHARED --> S_INF["infrastructure/<br/>(shared infrastructure · logging · config)"]
+```
+
+### 4. Language-Specific Layer Materializations
+
+The universal layer patterns materialize through language-native idioms. Use the appropriate abstraction mechanism for your language (Python: `Protocol`; TypeScript/Java/Go: `interface`; Rust: `trait`; Swift: `protocol`) and data modeling tools (Python: `dataclasses`/Pydantic; TypeScript: Zod/classes; Java: records/Jackson; Go: structs/tags; Rust: `serde`/structs; Swift: Codable/structs).
+
+**4.1 — Dependency Inversion:**
+
+Domain and Application layers define interfaces using the language's abstraction mechanism. Infrastructure provides concrete implementations. The composition root wires implementations to interface-typed parameters. No inner layer ever imports a concrete outer class.
+
+**4.2 — Domain Purity:**
+
+- Zero external dependencies in Domain — no ORM imports, no framework imports, no I/O. Pure data structures, value objects, and business logic.
+- Domain entities MUST NOT use persistence-layer models directly.
+- Domain exceptions inherit from a domain-level base, never from a framework exception.
+
+**4.3 — Application as Orchestrator:**
+
+- Application services accept and return DTOs, never persistence entities.
+- Use cases call domain logic plus repository interfaces — no direct database or HTTP calls.
+- Application defines the ports (interfaces) Infrastructure implements.
+
+**4.4 — Infrastructure Adapters:**
+
+- Every external dependency (database, API, message queue, cache) is wrapped in an adapter implementing a Domain or Application interface.
+- Adapters are the sole location for library-specific code, and are independently testable via integration tests.
+
+**4.5 — Thin Presentation:**
+
+- Controllers / handlers translate transport requests into Application DTOs and responses back to transport format — zero business logic.
+- Validation and serialization happen at the boundary.
+
+### 5. Testing Implications
+
+Layer separation directly enables testability:
+
+- **Domain tests:** Pure unit tests — no mocking needed, no I/O, no framework dependencies.
+- **Application tests:** Unit tests with mocked interfaces. Test use case orchestration, not infrastructure details.
+- **Infrastructure tests:** Integration tests against real external systems. Test adapter correctness.
+- **Presentation tests:** Transport-layer tests (HTTP, CLI, gRPC). Test request-response mapping, not business logic.
+- **End-to-End tests:** Full stack through Presentation to Infrastructure. Verify integration.
+
+### 6. When to Apply
+
+**6.1 — Full Layer Separation (Mandatory):**
+
+- Projects with 3+ modules or bounded contexts.
+- Projects at SHARED+ seriousness level.
+- Projects involving database access, external APIs, or multiple presentation channels.
+- Projects expected to grow beyond initial scope.
+
+**6.2 — Simplified Separation (Acceptable):**
+
+- Small, single-purpose scripts or utilities (EXPLORING seriousness).
+- Domain + Infrastructure two-layer split when Application layer would be trivially pass-through.
+- Microservices where the bounded context is small enough that a flat structure suffices.
+
+**6.3 — When NOT to Force Layers:**
+
+- Throwaway scripts, one-off data transformations, proof-of-concept prototypes.
+- Projects where the overhead of layer separation exceeds the project's expected lifetime.
+- When the user explicitly requests a simpler structure — document the trade-off and proceed.
+
+## Seriousness Scaling
+
+| Level | Layer Discipline |
+| ----- | ---------------- |
+| EXPLORING | Awareness only — suggest separation when beneficial, do not enforce |
+| PERSONAL_USE | Recommend separation for non-trivial projects. Verify dependency direction on code review |
+| SHARED | Mandatory for projects with 3+ modules. Layer violations are findings in `/plan-review`. Import discipline enforced |
+| PUBLIC_LAUNCH | Full enforcement. Layer violations block execution. Architecture verification in quality gates. Lint rules for import boundaries recommended |
+
+## Anti-Patterns
+
+- **DON'T** let Domain depend on Infrastructure — **BECAUSE** the domain becomes untestable without spinning up databases, APIs, and external services.
+- **DON'T** put business logic in controllers/handlers — **BECAUSE** it couples domain rules to the presentation channel and makes them unreusable across CLI, API, and event-driven interfaces.
+- **DON'T** use ORM entities as domain entities — **BECAUSE** ORM concerns (lazy loading, column mapping, migration) leak into the domain and corrupt its purity.
+- **DON'T** skip the Application layer and call Infrastructure from Presentation — **BECAUSE** it scatters orchestration logic and makes use cases invisible.
+- **DON'T** create god services that span multiple layers — **BECAUSE** they violate the dependency rule and create tight coupling that resists change.
+- **DON'T** enforce layers on trivial projects — **BECAUSE** premature architecture adds complexity without proportional benefit.
+- **DON'T** import concrete Infrastructure classes inside Domain or Application layers — **BECAUSE** it inverts the dependency rule. Use interfaces/protocols and inject at the composition root.
+
+## Enforcement
+
+Path-filtered (`**/src/**`, `**/lib/**`, `**/app/**`, `**/packages/**`), scaling per the table above. Implements CM-27. Canonical specification for clean architecture layer discipline.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every non-trivial multi-module project's directory layout (§3 Directory Structure Patterns — flat-module vs. domain-driven-module). ● Every cross-layer dependency check (§2.1 Import Discipline; §2.2 Interface Segregation at Boundaries). ● Every composition-root pattern in dependency injection (§2.3). ◐ The Senior Software Architect role's language-agnostic layer discipline declared at `rules/cognitive-identity.md` §1 (Python-language materialization routes through `rules/code-craft-python.md`).
+- **Satisfies →** ● CM-27 (Clean Architecture Layers — rule-delegated mandate). ● the rules registry row "Clean Architecture".
+- **Established by ↑** ● CM-27. ● `rules/cognitive-identity.md` (the Senior Software Architect role declares clean-architecture as structural law, not guideline).
+- **Gated by ←** ● The path-filter (`**/src/**`, `**/lib/**`, `**/app/**`, `**/packages/**`) — this rule activates only on matching artifact touches. ● `rules/cognitive-identity.md` Senior Software Architect role declaration.
+- **Cross-bound with ↔** ↔ `rules/code-craft-python.md` (Python-language materialization of the layer discipline; §1 DIP cross-references this rule's §2.3 dependency-injection discussion). ↔ `rules/cognitive-identity.md` (the cognitive-identity rule declares the Senior Software Architect role this rule operationalizes). ↔ `rules/clean-room-generation.md` (clean-room generation produces layer-correct artifacts; §2 Writing Protocol respects layer boundaries).

package/src/apothem/rules/clean-room-generation-protocols.md

@@ -0,0 +1,124 @@
+---
+name: "clean-room-generation-protocols"
+description: "Path-filtered companion rule carrying the full Writing Protocol (§2), Re-Writing Protocol (§3), Code Generation (§4), Prose and Documentation (§5), Plan and Artifact Generation (§6), Decision Tree, and Anti-Patterns specifications anchored at the parent `rules/clean-room-generation.md` rule's pointer sections; demand-loaded when the assistant edits any code, prose, plan, or artifact surface."
+pathFilter: "**/src/**, **/lib/**, **/tools/**, **/scripts/**, **/tests/**, **/docs/**, **/*.py, **/*.md, **/CLAUDE.md, **/rules/**, **/commands/**, **/skills/**, **/agents/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Clean-Room Generation Protocols (Companion Sub-Rule)
+
+## Purpose
+
+Carry the full executable protocols for clean-room generation that `rules/clean-room-generation.md` pointer sections declare. Path-filtered: loads on any code, prose, plan, or artifact surface. The parent owns the Clean-Room Invariant (§1) and the CM-4 four-outcome routing (§1.1); this companion owns the Writing Protocol (§2), Re-Writing Protocol (§3), Code Generation (§4), Prose and Documentation (§5), Plan and Artifact Generation (§6), the CM-4 Decision Tree, and the Anti-Patterns.
+
+## Obligations
+
+### 2. Writing Protocol (New Content)
+
+**2.1 — Specification Extraction:** Before generating, extract: (a) purpose — what the output must accomplish, (b) audience — who consumes it, (c) constraints — format, length, style, technical requirements, (d) quality bar — seriousness level and domain standards.
+
+**2.2 — Intent-First Derivation:** Generate from understood intent, never from pattern matching. The question is never "what does content like this usually look like?" but always "what does THIS specific content need to be?"
+
+**2.3 — Structural Originality:** Choose structure from the content's inherent needs. A function's shape comes from its behavioral requirements. A document's shape comes from its communication goals. Import structure from convention only when the content genuinely demands it — and state why.
+
+**2.4 — Contextual Precision:** Every element calibrated to context. Variable names reflect the domain. Prose vocabulary matches the audience. Abstraction levels match the problem's complexity. Nothing generic when specific is possible.
+
+**2.5 — Completeness Gate:** Before delivering: every specification requirement addressed, no extraneous elements the specification did not require, every element earns its presence through traceability to inputs.
+
+### 3. Re-Writing Protocol (Transforming Existing Content)
+
+**3.1 — Behavioral Extraction:** Understand what the original DOES — observable behavior, contracts, invariants, side effects, edge cases. This extracted behavior IS the specification for the re-write.
+
+**3.2 — Intent Archaeology:** Identify WHY the original was written as it was. Surface implicit requirements, historical constraints, and embedded design decisions. Distinguish deliberate choices from accidental complexity.
+
+**3.3 — The Clean-Room Barrier:** After extraction, treat the extracted specification as the sole input for re-derivation — do not transform or edit the original's implementation in place. Re-derive from the extracted specification. The re-write is a fresh creation that happens to preserve behavior — not an edited copy. The re-write scope matches the change scope: if modifying a single function, extract and re-derive that function; if restructuring a module, extract and re-derive the module. Unchanged code in the same artifact is not subject to the clean-room barrier.
+
+**3.4 — Quality Elevation Mandate:** Every re-write that targets refactoring or improvement must demonstrably improve on the original in at least one dimension: clarity, correctness, performance, maintainability, testability, security, or expressiveness. Demonstration requires naming the specific deficiency in the original and how the re-write addresses it. Re-writes that merely rephrase violate the clean-room principle. Exception: faithful ports, migrations, and format conversions where the original is sound — the quality dimension is "fidelity to specification in the target format."
+
+**3.5 — Regression Gate:** After re-writing, verify all behavioral contracts from 3.1 are preserved. New defects introduced during re-writing are the primary risk — explicit verification is mandatory, not assumed.
+
+### 4. Code Generation
+
+**4.1 — Contract-Driven:** Generate from interfaces, protocols, type signatures, and behavioral contracts. The contract is the specification; the implementation is derived, not remembered.
+
+**4.2 — Test-Behavioral Derivation:** When tests exist, they define the behavioral specification. When absent, write behavioral assertions (input→output contracts) before generating the implementation.
+
+**4.3 — Pattern Adaptation:** Design patterns are structural principles, not code templates. Adapt the principle to the specific problem. A Strategy pattern for payment processing shares the principle with a Strategy for rendering — never the code.
+
+**4.4 — Domain-Native Expression:** Code speaks the domain's language. Financial code uses financial terms. Network code uses network terms. Generic names (`data`, `handler`, `process`, `manager`) indicate domain understanding failure.
+
+**4.5 — Minimal Sufficiency:** Generate exactly what the specification requires — no speculative features, no defensive code against impossible states, no premature abstractions. The output reads as written by someone who understood the requirements perfectly and nothing else. Aesthetic demand (cognitive-identity Filter 5) governs *form*, not *scope*: elegance expresses the specification with conceptual clarity, it does not add features. Filters 2-4 operate at the design phase — producing structurally novel ways to satisfy the spec — not at generation. A novel approach to the same requirement is scope-compliant; an unrequested capability the approach suggests is scope-violating. Example: a novel internal data structure that self-documents the code is form; an unrequested caching layer is scope.
+
+### 5. Prose and Documentation
+
+**5.1 — Purpose-Driven Structure:** Every document has a communication purpose. Structure follows purpose: tutorials guide sequentially, references enable random access, explanations build understanding progressively. Never impose sections because "documents like this usually have them."
+
+**5.2 — Sentence-Level Justification:** Every sentence advances the purpose. Removable sentences should not exist. Filler ("In this section, we will discuss..."), throat-clearing ("It is important to note that..."), and meta-commentary about the document itself are structural failures.
+
+**5.3 — Precision Over Politeness:** Exact words. "The function returns null when the key is missing" — not "The function may return null in certain cases." Hedge words weaken precision. Content-free qualifiers ("very", "quite", "somewhat") are noise.
+
+**5.4 — Active Construction:** Active voice, concrete subjects, specific verbs. "The scheduler assigns tasks to workers" — not "Tasks are assigned to workers by the scheduler." Passive voice removes the actor from the sentence; when the actor is removed, ambiguity about who performs the action cannot be diagnosed by the reader.
+
+**5.5 — Re-Writing Prose:** Extract information content (facts, relationships, procedures). Discard original expression entirely. Re-express from extracted content, optimized for target audience. The re-written version preserves 100% information content with zero stylistic inheritance.
+
+### 6. Plan and Artifact Generation
+
+**6.1 — Fresh Derivation Per Artifact:** Each artifact freshly derived from its inputs. No copy-paste between artifacts. Shared content in two artifacts means both independently justify its presence.
+
+**6.2 — Specification Traceability:** Every element in a generated artifact traces to a specific input requirement. Untraceable elements indicate drift or unnecessary additions — remove them.
+
+**6.3 — Re-Planning as Clean-Room:** Plan revisions treat the trigger (new info, failed assumption, changed requirement) as a new input. Re-derive affected sections from the updated specification rather than patching existing text.
+
+## Decision Tree
+
+```mermaid
+%%{ init: { "theme": "neutral" } }%%
+%% verified: 2026-04-27 %%
+%% provenance: rules/clean-room-generation.md §1.1 (interaction with CM-4 search) %%
+%% cross-reference: rules/operational-mandates.md (CM-4 Search Before Implement) %%
+flowchart TD
+    Start[Generation request received] --> Search[CM-4 search the codebase first]
+    Search --> Q{Existing code coverage?}
+    Q -->|fully covers| Reuse[Reuse as-is · no generation]
+    Q -->|partially covers| Mixed[Reuse covered portion · treat uncovered as fresh-write spec]
+    Q -->|needs integration changes| ReWrite[Re-Writing Protocol §3]
+    Q -->|fundamentally unsuitable| Fresh[Writing Protocol §2 · document why reuse rejected]
+    Mixed --> WriteUncovered[Apply §2 to uncovered portion]
+    ReWrite --> Extract[§3.1 Behavioral extraction]
+    Extract --> Archeology[§3.2 Intent archaeology]
+    Archeology --> Barrier[§3.3 Clean-room barrier · re-derive from spec]
+    Barrier --> Quality[§3.4 Quality elevation · name the deficiency]
+    Quality --> Regression[§3.5 Regression gate · verify behavioral preservation]
+    Fresh --> SpecExtract[§2.1 Specification extraction]
+    SpecExtract --> Derive[§2.2 Intent-first derivation]
+    Derive --> Original[§2.3 Structural originality]
+    Original --> Precise[§2.4 Contextual precision]
+    Precise --> Complete[§2.5 Completeness gate]
+    WriteUncovered --> Complete
+    Regression --> Done[Output ratified]
+    Reuse --> Done
+    Complete --> Done
+```
+
+## Anti-Patterns
+
+- **DON'T** import structure from templates without contextual justification — **BECAUSE** template-driven generation produces generic output that fails the specific problem.
+- **DON'T** re-write by cosmetic editing (synonym substitution, sentence reordering) — **BECAUSE** paraphrasing preserves structural weaknesses and violates the clean-room barrier.
+- **DON'T** generate from memorized examples — **BECAUSE** example-driven generation inherits context assumptions that rarely match the current problem.
+- **DON'T** include elements "because they are usually there" — **BECAUSE** convention-driven additions bloat output and dilute precision.
+- **DON'T** use generic names when domain-specific alternatives exist — **BECAUSE** generic names expose domain understanding failure.
+- **DON'T** hedge with qualifiers carrying no information — **BECAUSE** imprecision in output reveals imprecision in understanding.
+
+## Enforcement
+
+Path-filtered (the glob patterns in this rule's `pathFilter` field), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/clean-room-generation.md`: the parent owns the Clean-Room Invariant (§1) and CM-4 four-outcome routing (§1.1) at the always-on tier; this companion owns §2 Writing, §3 Re-Writing, §4 Code Generation, §5 Prose and Documentation, §6 Plan and Artifact Generation, the Decision Tree, and the Anti-Patterns.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every code, prose, plan, and artifact emission across the path-filter scope (the §2 Writing Protocol + §3 Re-Writing Protocol are the generation-method floor when in scope). ● Every refactor-class touch (§3 quality-elevation mandate gates the re-write). ● Every plan-suite emission (§6 fresh-derivation discipline). ◐ The Decision Tree's CM-4 four-outcome materialization.
+- **Satisfies →** ● CM-5 / CM-7 / CM-21 (rule-delegated mandates; this companion is the path-filtered protocol subset). ● the rules registry row "Clean-Room Generation" (companion sub-rule). ● `rules/clean-room-generation.md` pointer sections (the parent rule's anchors to this companion's full specification).
+- **Established by ↑** ● `rules/clean-room-generation.md` (parent-rule anchors). ● CM-5 + CM-7 + CM-21 inline definitions. ● `rules/cognitive-identity.md`.
+- **Gated by ←** ● The path-filter — this rule demand-loads only on code, prose, plan, or artifact-surface touches. ● `rules/clean-room-generation.md` always-on baseline (parent rule's Clean-Room Invariant and CM-4 routing must be live for the companion to demand-load coherently).
+- **Cross-bound with ↔** ↔ `rules/clean-room-generation.md` (parent rule; pointer sections bind this companion). ↔ `rules/cognitive-identity.md` (Filter 5 aesthetic-demand ↔ §3.4 quality elevation; both implement CM-21's facets). ↔ `rules/operational-mandates.md` (CM-4 search-before-implement gates the Decision Tree's entry; CM-5/CM-7 inline definitions). ↔ `rules/planning-techniques.md` (third co-implementer of CM-21; planning-technique facet there, generation-methodology facet here).

package/src/apothem/rules/clean-room-generation.md

@@ -0,0 +1,59 @@
+---
+name: "clean-room-generation"
+description: "Clean-room generation methodology for every output — code, prose, plans, artifacts: each is a fresh derivation from an understood specification (independently re-derivable from its inputs), never a memorized template nor a cosmetic edit of existing content. Routes CM-4 search outcomes into the Writing vs. Re-Writing protocols and gates every re-write on quality elevation against a named deficiency. Implements CM-5 / CM-7 / CM-21."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Clean-Room Generation
+
+## Purpose
+
+Govern the generation methodology for every output — code, prose, documentation, plans, artifacts. Each output MUST be a fresh derivation from an understood specification, never a reproduction of memorized patterns nor a cosmetic transformation of existing content.
+
+## Obligations
+
+### 1. The Clean-Room Invariant
+
+**Every output MUST be independently derivable from its inputs.** Given the specification, context, and constraints, a competent professional with zero access to prior implementations produces substantially the same output.
+
+Corollaries:
+
+- No output relies on memorized templates or boilerplate for its structure.
+- Every structural choice is justifiable from the current context.
+- Re-generating from the same specification MAY differ in expression while solving the same problem.
+- Convention is a starting point for evaluation, never an autopilot for structure.
+
+**1.1 — Interaction with CM-4 (Search Before Implement).** CM-4 search determines *what* to build; clean-room governs *how*. After CM-4 search, route by coverage:
+
+- **(a) Existing code fully satisfies** — reuse as-is; no generation or re-writing.
+- **(b) Existing code partially satisfies** — reuse the covered portion as-is; treat the uncovered portion as the Writing-Protocol (§2) specification.
+- **(c) Existing code needs integration changes** — Re-Writing Protocol (§3) on the modified portion only, scoped to the changed behavioral contracts.
+- **(d) Existing code fundamentally unsuitable** — Writing Protocol (§2) for the full requirement; document why reuse was rejected.
+
+### 2-6. Protocols (Companion Sub-Rule Anchor)
+
+Full protocols — §2 Writing, §3 Re-Writing, §4 Code Generation, §5 Prose and Documentation, §6 Plan and Artifact Generation — plus the CM-4 Decision Tree and six Anti-Patterns live at `rules/clean-room-generation-protocols.md`. The companion demand-loads on code, prose, plan, or artifact-surface touches.
+
+## Seriousness Scaling
+
+| Level | Clean-Room Discipline |
+| ----- | --------------------- |
+| EXPLORING | Intent-first derivation (2.2) and contextual precision (2.4). Quality elevation on explicit re-write requests |
+| PERSONAL_USE | Full Writing Protocol (Section 2) + Code Generation (Section 4). Re-Writing Protocol on re-write/refactor requests |
+| SHARED | Full Sections 2–6. Quality elevation mandatory on all re-writes. Sentence-level justification on documentation |
+| PUBLIC_LAUNCH | Full enforcement. Re-writing requires documented behavioral extraction (written to scratch/notes, not just mental). Structural choices annotated with rationale on all non-trivial artifacts. Completeness Gate (2.5) verified with explicit checklist |
+
+## Enforcement
+
+Always-on at every seriousness level, scaling per the table above. Implements CM-5 (Best Solution), CM-7 (Coherent Product), CM-21 (Creative Quality). Canonical specification for generation methodology, re-writing discipline, and output originality.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every code, prose, plan, and artifact emission across the ecosystem (the Writing Protocol §2 + Re-Writing Protocol §3 are the generation-method floor). ● Every `/plan` stage's artifact production (plan-suite emissions adopt the §6 fresh-derivation discipline). ● Every refactor-class agent task (Re-Writing Protocol §3 quality-elevation mandate gates the re-write). ◐ The CM-7 plan-internal isolation invariant on every codebase artifact (the §1 clean-room invariant operationalizes CM-7's natural-domain-language requirement). ◐ The CM-4 search-before-implement four-outcome routing (§1.1 mirrors CM-4's outcomes).
+- **Satisfies →** ● CM-5 / CM-7 / CM-21 (rule-delegated mandates). ● the rules registry row "Clean-Room Generation".
+- **Established by ↑** ● `rules/cognitive-identity.md` (clean-room generation is the methodology arm of the cognitive-identity declaration). ● CM-5 + CM-7 + CM-21 inline definitions. ● `rules/cognitive-identity.md` §1 seven-axs-of-breadth taxonomy (re-writing protocol's quality-elevation mandate cites that taxonomy).
+- **Gated by ←** ● `rules/operational-mandates.md` (CM-4 search-before-implement gate fires before §1.1 routes to a Writing/Re-Writing path). ● `rules/cognitive-identity.md` Filter 1 + Filter 5 always-on baseline.
+- **Cross-bound with ↔** ↔ `rules/clean-room-generation-protocols.md` (path-filtered companion sub-rule carrying the §2-§6 protocols, Decision Tree, and Anti-Patterns specifications). ↔ `rules/cognitive-identity.md` (Filter 5 aesthetic-demand ↔ §3.4 quality elevation; both implement CM-21's facets). ↔ `rules/operational-mandates.md` (CM-4/CM-5/CM-7 are inline-defined there; this rule is the methodology specification). ↔ `rules/planning-techniques.md` (third co-implementer of CM-21; planning-technique facet over there, generation-methodology facet here). ↔ `rules/persistent-conventions-vigilance.md` (clean-room generation produces ecosystem-coherent artifacts; convention vigilance maintains ecosystem coherence). ↔ `rules/plain-language.md` (Writing Protocol §2 produces narrative honoring plain-language; plain-language is the post-emission scan). ↔ `rules/token-efficiency-rewrite.md` (token-efficiency specialisation of §3 re-writing protocol with L2/L3 tiers made explicit). ↔ `rules/large-file-reading.md` (CM-4 Search Before Implement uses Grep/Glob first; large-file-reading canonicalizes locate-before-read). ↔ `rules/refactoring-discipline.md` (gates when and how the §3 re-writing protocol runs for a behaviour-preserving refactor).

package/src/apothem/rules/code-craft-conventions.md

@@ -0,0 +1,101 @@
+---
+name: "code-craft-conventions"
+description: "Universal code-craft delegation stub for languages without a dedicated per-language rule. Discovers the host's ratified formatter / linter / type-checker / test framework / per-language idioms and honors them per M1; surfaces silence as inquiry per M5; defers to a per-language sibling rule (code-craft-python, code-craft-shell, code-craft-markdown) when one matches the artifact's path."
+pathFilter: "**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Universal Code-Craft Delegation — Discover, Honor, Defer
+
+## What this rule enforces
+
+This rule binds **M13 — Code Craft Conventions** at the **universal-delegation** tier: it applies where a code artifact's language has no dedicated `rules/code-craft-<language>.md`. The discipline is **delegation**. The host's ratified code-craft conventions — formatter, linter, type-checker, test framework, build configuration, per-language idioms — MUST be **discovered** from the host's source-of-truth (manifest files, config files, sibling source files of the same language) per `rules/host-discovery.md` and **honored uniformly**. Where the host is silent on a convention the agent must adopt to act, the silence surfaces as an inquiry per `rules/authority-inquiry.md` with a recommended option per `rules/option-annotation.md`.
+
+This stub does not duplicate the canonical M13 sub-element list (M13.1 why-not-what commenting · M13.2 naming · M13.3 error handling · M13.4 function & module design · M13.5 logging · M13.6 testing · M13.7 formatter / linter / type-checker · M13.8 security-conscious code · M13.9 concurrency · M13.10 magic number discipline · M13.11 documentation surface). Per-language siblings carry the language-specific materialization; this stub carries the **delegation contract** routing every code-craft decision through host discovery and per-language sibling-rule precedence.
+
+## Pre-conditions
+
+Applies whenever a code artifact is authored, modified, or reviewed AND its language matches no per-language sibling rule's `pathFilter`. The current per-language siblings at `rules/`:
+
+| Sibling rule | Path-filter scope | When this stub yields |
+|---|---|---|
+| `code-craft-python.md` | `**/*.py`, `**/pyproject.toml`, `**/setup.cfg`, `**/requirements*.txt`, `**/Pipfile`, `**/tox.ini`, `**/pytest.ini`, `**/conftest.py`, `**/*.python-version`, `**/mypy.ini`, `**/ruff.toml`, `**/.ruff.toml`, `**/uv.toml`, `**/uv.lock`, `**/pyrightconfig.json` | Python artifacts |
+| `code-craft-shell.md` | `**/*.sh`, `**/*.bash`, `**/*.ps1` | Shell artifacts (POSIX bash + PowerShell) |
+| `code-craft-markdown.md` | `**/*.md`, `**/*.markdown` | Markdown / prose artifacts |
+
+When a sibling's `pathFilter` matches the artifact path, the sibling applies and this stub yields. When no sibling matches (e.g., TypeScript, Go, Rust, Java, C++, Ruby), this stub is the active code-craft authority.
+
+## Required behavior
+
+### 1. Host Discovery — The Per-Language Walk
+
+Before authoring code in any language without a dedicated sibling rule, the agent MUST walk the host's ratified source-of-truth files for that language:
+
+| Language | Discovery surfaces |
+|---|---|
+| **TypeScript / JavaScript** | `package.json`, `tsconfig.json`, `.eslintrc*`, `.prettierrc*`, `pnpm-lock.yaml` / `yarn.lock` / `package-lock.json`, sibling `*.ts` / `*.js` files |
+| **Rust** | `Cargo.toml`, `Cargo.lock`, `rustfmt.toml`, `clippy.toml`, sibling `*.rs` files |
+| **Go** | `go.mod`, `go.sum`, `.golangci.yml`, sibling `*.go` files |
+| **Java / Kotlin** | `pom.xml`, `build.gradle{,.kts}`, `checkstyle.xml`, `spotbugs-exclude.xml`, sibling `*.java` / `*.kt` files |
+| **C / C++** | `CMakeLists.txt`, `.clang-format`, `.clang-tidy`, sibling `*.c` / `*.cpp` / `*.h` files |
+| **Ruby** | `Gemfile`, `Gemfile.lock`, `.rubocop.yml`, sibling `*.rb` files |
+| **Other languages** | Walk the language's package manager manifest, the language's lint / format configuration, and at least three sibling source files |
+
+The agent MUST record every discovered convention with provenance (source file path, value, discovery date) per `rules/host-discovery.md` §4. The discovery output is the per-language ratified convention set the artifact MUST honor.
+
+### 2. Honor Discoveries — The Sibling Convergence
+
+The artifact MUST be **indistinguishable from one a long-tenured contributor would have written in that language**. When editing existing files, the agent MUST preserve the surrounding idioms even where it would idiomatically choose otherwise. The host's own `lint` / `format` / `test` / `type-check` commands MUST pass the artifact unmodified.
+
+Sibling-source convergence: when the host has no explicit lint / format config but does have sibling source files of the same language, those files' observable idioms (indentation, quote style, naming, import ordering, error-handling pattern) are the ratified convention by majority observation. A new file diverging from the sibling convention is non-conformant per M14 systemic participation (`rules/systemic-participation.md`).
+
+### 3. Surface Silence — Inquiry-Routed Choices
+
+Where the host is silent on a code-craft convention the agent must adopt to proceed (a brand-new project with no formatter; a new language entering a polyglot host with no precedent), the agent MUST surface the choice as an inquiry per `rules/authority-inquiry.md` with the recommended option annotated per `rules/option-annotation.md`. The recommended option's rationale cites at least one concrete-driver class — community-default tooling, vendor-recommended idioms, or a host-discovered analog from a related language already in the project.
+
+### 4. Per-Language Sibling Precedence
+
+When the artifact path matches a per-language sibling's `pathFilter`, that sibling's specific guardrails take precedence over this stub's general delegation. The sibling carries the language-specific materialization of M13.1–M13.11; this stub neither duplicates nor contradicts it.
+
+When a host carries a language with no per-language sibling AND that language recurs across multiple work sessions, the recurrence signals that a new sibling may be warranted per `rules/persistent-conventions-vigilance.md` §4 Ecosystem Gap Detection. The trigger is recurrence count plus convention-citation density; the gap-closure action is authoring a new `code-craft-<language>.md` sibling.
+
+### 5. Code-Craft Sub-Element Coverage — Universal Floor
+
+Even at the universal-delegation tier, the M13 sub-element catalog is the floor every emitted artifact MUST meet. Host-discovered conventions populate the per-language specifics; the universal floor remains:
+
+- **M13.1 Why-not-what commenting.** Comments state intent / rationale / reference / invariant — never paraphrase what the code lexically does. No commented-out code; source control is the canonical archive.
+- **M13.2 Naming.** Identifiers reveal intent. Booleans read as predicates. Single-letter names only in conventional roles.
+- **M13.3 Error handling.** Caught exceptions are typed and handled or re-raised with context. No silent failure.
+- **M13.4 Function & module design.** Pure-function bias where reasonable; explicit dependency injection over implicit state; one responsibility per function.
+- **M13.5 Logging.** Levels are deliberate (DEBUG / INFO / WARNING / ERROR / CRITICAL); no secrets ever logged.
+- **M13.6 Testing.** Behavior-descriptive test names; AAA shape (Arrange / Act / Assert); no test depends on test ordering.
+- **M13.7 Formatter / linter / type-checker.** The host's ratified tools are honored; the artifact passes them clean.
+- **M13.8 Security-conscious code.** No hardcoded secrets; no shell execution on unvalidated input; no SQL injection; no eval / exec on untrusted input.
+- **M13.9 Concurrency.** Where applicable: no shared mutable state without documented synchronization; race conditions named when they exist.
+- **M13.10 Magic number discipline.** Numeric literals appearing in logic become named constants with intent.
+- **M13.11 Documentation surface.** Public functions / classes / modules carry docstrings stating preconditions, postconditions, invariants, exceptions raised.
+
+The per-language sibling refines each sub-element with language-specific idioms; this stub enforces the floor when no sibling applies.
+
+## Disclosure surface
+
+Every host-discovery outcome and every silence-routed inquiry is recorded in the disclosure ledger per `rules/disclosure-ledger.md`:
+
+- `[Discovery — source: <manifest-path>; language: <name>; convention: <formatter | linter | type-checker | test-framework | idiom>; value: <discovered-value>; honored]` for every honored discovery.
+- `[Inquiry — id: <inquiry-id>; category: preference; outcome: <user-choice | fallback-to-recommended>]` for every silence-routed convention choice.
+- `[Default — applied: <auto-decision>; class: pure-formatting-normalization]` for the carve-out cases (host has ratified style, artifact diverges, normalization applied per `rules/authority-inquiry.md` §10.1).
+- `[Refinement — improvement: maintainability; per-language gap detected: <language>; recurrence: <count>; tracking: <gap-closure inquiry-or-task>]` when the recurrence count surfaces a new per-language-sibling-rule candidate.
+
+## Failure tells
+
+A TypeScript file in a project standardized on `prettier` + `eslint` that uses a different formatter or quote style than every sibling file (sibling-convergence violation). A Rust file with `unsafe` blocks lacking a `// SAFETY: <invariant>` comment in a project where every other `unsafe` block carries one (idiom drift). A Go file using `panic` as control flow in a project where every other Go file uses error returns (M13.3 error-handling drift). A Ruby file silently introducing a new RuboCop violation in a project with `.rubocop.yml` ratified (M13.7 formatter / linter drift). A new language introduced into a polyglot project without a code-craft sibling rule and without the recurrence-tracking surface (the rule's gap-detection signal is suppressed). A new language file authored without the host-discovery walk (the agent invented conventions where the host has them). A change-set that touches a per-language sibling-rule-covered path AND a stub-covered path, where the stub-covered language drifts while the sibling-covered language remains conformant (asymmetric attention to the per-language sibling vs. the stub's general delegation).
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every code artifact authoring session in a language without a dedicated per-language sibling rule (every TypeScript, Go, Rust, Java, C++, Ruby, Kotlin, Swift, etc. artifact). ● Per-language host-discovery walks for every code-touched language. ● The recurrence-tracking surface that signals new per-language-sibling-rule candidates. ◐ The sibling-convergence enforcement at `rules/systemic-participation.md` (M14).
+- **Satisfies →** ● the fifteen-mandate registry row **M13 — Code Craft** (universal-delegation tier; per-language tier is the per-language sibling rules).
+- **Established by ↑** ● the fifteen-mandate registry (ratifies M13). ● The user-scope ecosystem's mandate to carry a universal code-craft floor for every language regardless of per-language sibling presence.
+- **Gated by ←** ● the trivial-vs-non-trivial threshold (trivial-scope code edits run an abbreviated check covering M13.1 why-not-what + M13.7 formatter / linter only). ● `CLAUDE.md` always-loaded preamble. ● Per-language sibling rule pathFilter precedence (this stub yields when a sibling matches).
+- **Cross-bound with ↔** ↔ `rules/code-craft-python.md` (Python sibling — takes precedence on Python paths). ↔ `rules/code-craft-shell.md` (Shell sibling — takes precedence on shell paths). ↔ `rules/code-craft-markdown.md` (Markdown sibling — takes precedence on Markdown paths). ↔ `rules/host-discovery.md` (M1 — per-language discovery is the M1 walk for code-craft conventions). ↔ `rules/authority-inquiry.md` (M5 — silence-routed choices). ↔ `rules/option-annotation.md` (M7 — recommended-option annotation on inquired conventions). ↔ `rules/systemic-participation.md` (M14 — sibling convergence is the M14 silo-prevention surface for code). ↔ `rules/persistent-conventions-vigilance.md` (CM-22 §4 — recurrence-driven gap detection signals new per-language-sibling-rule candidates).