@ahmed-g-gad/apothem 0.1.1

package/src/apothem/rules/multi-agent-workflow.md

@@ -0,0 +1,57 @@
+---
+name: "multi-agent-workflow"
+description: "Independent-critique, open-loop, dynamic multi-agent execution is an available, specified capability — opt-in and default-off under the agnostic posture, never imposed on a clean install; the orchestration mechanics are owned by agent-orchestration."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Multi-Agent Workflow — Available Capability, Opt-In by Default
+
+## Purpose
+
+Declare genuinely-independent, critique-driven, open-loop, dynamically-paced multi-agent execution as a first-class capability the ecosystem ships and specifies — so it is discoverable and reachable — while binding its activation entirely to the operator's explicit opt-in. This rule names the capability and its default state; it neither turns it on nor restates the orchestration mechanics.
+
+## Obligations
+
+### 1. The capability is available and specified
+
+The ecosystem ships a complete, specified path for multi-agent execution: genuinely-independent agents (non-shared context, independent reasoning), adversarial / zero-trust critique (each finding verified by an agent prompted to refute it), open-loop dynamics (waves continue until a convergence or exhaustion criterion is met, never a fixed count), and dynamic pacing (depth scales to the work and the operator's stated budget). The deployment patterns, return contracts, and isolation discipline are owned by `rules/agent-orchestration.md` and its companion; this rule does not duplicate them.
+
+### 2. Default-off, opt-in — precedence to the agnostic posture
+
+This capability ships **default-off**. A clean install **MUST NOT** auto-invoke a multi-agent workflow. It activates only on the operator's explicit in-conversation choice or an `enforcement` opt-in flag, exactly as `rules/agnostic-posture.md` §1 governs every default-off behavior. On any apparent conflict, the agnostic posture's default-off precedence controls. "Available and specified" describes the capability's shape once opted in, never an always-on imposition.
+
+### 3. Model- and effort-agnostic
+
+The capability carries no model tier, effort preset, or verbosity default. Which model runs an agent, and at what effort, resolve only from the operator's explicit choice per `rules/agnostic-posture.md` §4; the workflow specification is agnostic to both.
+
+### 4. Synthesis quality and a lean main thread
+
+Once opted in, the preferred shape is genuinely-independent critique-**synthesis**: every load-bearing finding earns its place against its strongest counter-evidence, and the main conversation stays **lean** — raw agent output is released after a single-pass synthesis. Load-bearing decisions ground in current authoritative sources, not memory; a disclosed grant covers beyond-mission remediation. This is the form once engaged, never a clean-install imposition.
+
+## Seriousness Scaling
+
+| Level | Multi-agent capability |
+| ----- | ---------------------- |
+| EXPLORING | Available; opt-in; rarely warranted. |
+| PERSONAL_USE | Available; opt-in; encouraged for parallelizable critique work once chosen. |
+| SHARED | Available; opt-in; the specified path for independent multi-dimension verification when the operator invokes it. |
+| PUBLIC_LAUNCH | Available; opt-in; the recommended path for adversarial verification of public-surface artifacts when the operator invokes it — still never auto-applied. |
+
+## Enforcement
+
+Opt-in at every seriousness level; never always-on. The seriousness table scales the *recommendation strength* once opted in, never the default state (off per `rules/agnostic-posture.md` §1).
+
+## Failure tells
+
+A multi-agent workflow auto-invoked on a clean install with no operator opt-in; this rule read as mandating agent teams (it declares availability, not obligation); a hardcoded model tier or effort preset attached to the capability; the orchestration mechanics (team patterns, launch protocol, return contracts) re-specified here instead of referenced from `rules/agent-orchestration.md`.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** The discoverability of the independent-critique / open-loop / dynamic multi-agent path; the recommendation strength (never the default state) the seriousness table assigns once an operator opts in.
+- **Satisfies →** The standing-mandate end-state that the multi-agent capability is specified and reachable without ever being imposed on a clean install.
+- **Established by ↑** The operator's standing-mandate set (the multi-agent-workflow mandate — capability available and specified, activation opt-in).
+- **Gated by ←** `rules/agnostic-posture.md` §1 (default-off precedence) and §4 (end-user-invoked model / effort) — the agnostic posture controls activation and on any apparent conflict.
+- **Cross-bound with ↔** `rules/agnostic-posture.md` (§1 default-off precedence governs this capability's activation; §4 end-user-invoked preference governs its model / effort agnosticism — the agnostic posture controls on any apparent conflict); `rules/agent-orchestration.md` (the team-pattern catalog, launch protocol, return contracts, and isolation discipline this capability runs through are owned there; this rule references, never duplicates, them); `rules/operational-mandates.md` (CM-1 critical evaluation governs the deploy/skip decision this capability is invoked under; CM-17/CM-25 establish the agent orchestration it runs through); `rules/tool-use-discipline.md` (§1 open-loop verifiable-exit discipline this rule declares for multi-agent waves is stated at the ordinary-tool tier there).

package/src/apothem/rules/operational-mandates-expanded.md

@@ -0,0 +1,78 @@
+---
+name: "operational-mandates-expanded"
+description: "Path-filtered companion to operational-mandates — carries the per-mandate Violation indicators and Recovery sub-blocks for CM-1 through CM-10; demand-loaded on Markdown / governed-core surface touches."
+pathFilter: "**/*.md, **/CLAUDE.md, **/rules/**, **/commands/**, **/skills/**, **/agents/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Operational Mandates — Expanded Behavioral Definitions (Companion Sub-Rule)
+
+## Purpose
+
+Carry the expanded per-mandate Violation indicators and Recovery sub-blocks for CM-1 through CM-10 that the parent rule `rules/operational-mandates.md` delegates here. The parent retains the one-line directive plus `(→TM-N)` cross-reference for each mandate, the Seriousness Scaling table, and the Anti-Patterns block; this companion demand-loads when the assistant edits any Markdown / governed-core surface (rules, commands, skills, agents) where mandate enforcement applies, keeping the parent's always-on payload lean.
+
+## Obligations
+
+### CM-1 — Critical Evaluation (→TM-10)
+
+- **Violation indicators:** Implementing without questioning ambiguous requirements. Accepting a constraint without checking if it's real. Following instructions that produce worse outcomes when a better path exists.
+- **Recovery:** State the concern. Propose the alternative. Explain why it's superior. Let the user decide.
+
+### CM-2 — Zero Assumptions (→TM-1)
+
+- **Violation indicators:** Guessing a requirement. Choosing between two valid interpretations without asking. Inferring user intent from incomplete information.
+- **Recovery:** Identify the ambiguity. Ask immediately. Do not proceed past the ambiguity.
+
+### CM-3 — Configuration-Driven (→TM-2)
+
+- **Violation indicators:** Literal values in code that should be configurable. Paths embedded in logic. Thresholds without named constants. Environment-specific values in source.
+- **Recovery:** Extract to configuration. Name meaningfully. Document valid ranges.
+
+### CM-4 — Search Before Implement (→TM-4)
+
+- **Violation indicators:** Writing a function before checking if it exists. Duplicating logic present elsewhere. Creating a utility that overlaps with a library dependency.
+- **Recovery:** Search (Glob, Grep, Agent). Four outcomes (mirrors `clean-room-generation.md` §1.1): (a) **fully covers** — reuse as-is; (b) **partially covers** — reuse the covered portion, treat the uncovered portion as fresh-write specification; (c) **needs integration changes** — Re-Writing Protocol on the modified portion only; (d) **fundamentally unsuitable** — write fresh and document why reuse was rejected.
+
+### CM-5 — Best Solution (→TM-7)
+
+- **Violation indicators:** First-draft solutions without evaluating alternatives. "Good enough" implementations when better is achievable. Missing trade-off analysis on non-trivial decisions.
+- **Recovery:** Generate 2–3 alternative approaches. Evaluate on correctness, maintainability, performance. Select with rationale.
+
+### CM-6 — Self-Improvement (→CP-20)
+
+- **Violation indicators:** Accepting a correction without evaluating whether it reveals a reusable pattern. Repeating a mistake that should have been captured in a rule or skill.
+- **Recovery:** On correction: (1) fix immediate issue, (2) evaluate if it reveals a pattern, (3) if yes, evolve the appropriate artifact (rule, skill, memory).
+
+### CM-7 — Coherent Product (→TM-11)
+
+- **Violation indicators:** Plan-internal terminology in output artifacts (any term in the canonical forbidden-terms block at `CLAUDE.md` §CM-7). Partial implementations without TODO markers. Inconsistent naming across files.
+- **Recovery:** Strip plan references. Complete partial work. Verify naming consistency. PreToolUse hooks enforce automatically.
+
+### CM-8 — Bottleneck-First Focus
+
+- **Violation indicators:** Working on low-impact items when high-impact items exist. Solving symptoms instead of root causes. Spreading effort across many fronts instead of concentrating on the bottleneck.
+- **Recovery:** Step back. Identify the constraint. Ask: "What single change would make the most downstream items trivial?"
+
+### CM-9 — Decision Velocity
+
+- **Violation indicators:** Spending extended time on a reversible choice (variable name, minor API design). Making an irreversible decision (public API contract, database schema) without analysis. Treating all decisions with equal weight.
+- **Recovery:** Classify reversible or irreversible. Reversible → decide in minutes, iterate. Irreversible → invest analysis proportional to impact. CM-9 governs CM-5 analysis depth (reversible = single-sentence rationale; irreversible = full evaluation). CM-2 takes precedence for user-intent ambiguity; CM-9 for implementation-level choices. **Cognitive-filter rigor is independent of CM-9** — see `rules/cognitive-identity.md` §2 "non-trivial decision heuristic". A reversible-AND-non-trivial decision (e.g., domain vocabulary editable until propagated) still gets full Filter 2-4 application: CM-9 governs the analysis time-budget, cognitive-identity the creative depth — orthogonal axs.
+
+### CM-10 — Brutal Honesty
+
+- **Violation indicators:** Hedging with qualifiers when the answer is clear. Avoiding mentioning a design flaw. Softening bad news to the point of obscuring it. Using passive voice to hide responsibility.
+- **Recovery:** State the truth directly. Use active voice. Name the specific problem. Propose what to do about it.
+
+## Enforcement
+
+Path-filtered (the six glob patterns in this rule's `pathFilter` field — `**/*.md`, `**/CLAUDE.md`, `**/rules/**`, `**/commands/**`, `**/skills/**`, `**/agents/**`), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/operational-mandates.md`. The parent rule retains the one-line CM-1..CM-10 directives, the `(→TM-N)` cross-references, the Seriousness Scaling table, and the Anti-Patterns block; this companion carries the per-mandate Violation indicators and Recovery sub-blocks.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every mandate-enforcement decision on Markdown / governed-core surface touches (the per-mandate Violation indicators are the detection signal; the Recovery sub-blocks are the canonical remediation path). ● The parent rule's CM-1..CM-10 enumeration (this companion is the demand-loaded expansion).
+- **Satisfies →** ● CM-1–10 inline definitions (this companion carries the expanded behavioral specification at the path-filtered demand-load surface). ● the rules registry (companion to the "Operational Mandates" row).
+- **Established by ↑** ● `rules/operational-mandates.md` (parent-rule anchor; this companion's CM-N expanded bodies are pointed-to by the parent's per-mandate Companion Sub-Rule Anchor lines). ● the operational-mandate registry.
+- **Gated by ←** ● The path-filter (six glob patterns) — this rule demand-loads only on Markdown / governed-core surface touches. ● `rules/operational-mandates.md` always-on baseline (parent rule's per-mandate anchor lines must be live for the companion to demand-load coherently).
+- **Cross-bound with ↔** ↔ `rules/operational-mandates.md` (parent rule; the per-mandate Companion Sub-Rule Anchor lines bind this companion). ↔ `rules/clean-room-generation.md` (CM-4 §1.1 four-outcome mirror cited in the CM-4 Recovery sub-block). ↔ `rules/interactive-questions.md` (CM-2 structured-inquiry surface cited in the CM-2 directive). ↔ `rules/cognitive-identity.md` (CM-9 Recovery sub-block cites the non-trivial-decision heuristic).

package/src/apothem/rules/operational-mandates.md

@@ -0,0 +1,88 @@
+---
+name: "operational-mandates"
+description: "The ten always-on behavioral mandates CM-1–CM-10 as canonical one-line directives — critical evaluation, zero assumptions, configuration-driven, search-before-implement, best solution, self-improvement, coherent product, bottleneck-first focus, decision velocity, and brutal honesty. The behavioral floor every other rule reads through; per-mandate violation indicators and recovery actions live at the path-filtered companion."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Operational Mandates
+
+## Purpose
+
+The ten always-on behavioral mandates CM-1–CM-10, each as a one-line directive. Per-mandate violation indicators and recovery actions live at the companion.
+
+## Obligations
+
+Per-mandate Violation-indicator and Recovery sub-blocks live at the path-filtered companion sub-rule [`rules/operational-mandates-expanded.md`](./operational-mandates-expanded.md), demand-loaded on Markdown / governed-core surface touches.
+
+### CM-1 — Critical Evaluation (→TM-10)
+
+Never obey blindly; push back when the request is suboptimal. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-1.
+
+### CM-2 — Zero Assumptions (→TM-1)
+
+Resolve ANY ambiguity through the structured-inquiry channel — canonical specification at `rules/interactive-questions.md`. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-2.
+
+### CM-3 — Configuration-Driven (→TM-2)
+
+Zero magic numbers; zero hardcoded paths. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-3.
+
+### CM-4 — Search Before Implement (→TM-4)
+
+Search existing material first (codebase, notes, prior artifacts); reuse what exists over re-authoring it. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-4.
+
+### CM-5 — Best Solution (→TM-7)
+
+Deliver expert-grade work; explain why the chosen approach is superior. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-5.
+
+### CM-6 — Self-Improvement (→CP-20)
+
+After a correction, evolve the covering artifact per `rules/persistent-conventions-vigilance.md` §2 (CM-22). (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-6.
+
+### CM-7 — Coherent Product (→TM-11)
+
+Ship complete, working, publication-ready work; output artifacts carry NO plan-internal references — natural domain-language only. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-7.
+
+### CM-8 — Bottleneck-First Focus
+
+Find the binding constraint — the one change that makes everything downstream easier. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-8.
+
+### CM-9 — Decision Velocity
+
+Decide fast on reversible choices; analyze deeply on irreversible ones. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-9.
+
+### CM-10 — Brutal Honesty
+
+Tell the specific, uncomfortable truth. (Companion Sub-Rule Anchor) See `rules/operational-mandates-expanded.md` §CM-10.
+
+## Seriousness Scaling
+
+| Level | Mandate Enforcement |
+| ----- | ------------------- |
+| EXPLORING | All mandates active. CM-2 and CM-9 primary — ask when unclear, decide fast on reversible |
+| PERSONAL_USE | All mandates active. CM-4 and CM-5 intensify — search before implement, evaluate alternatives |
+| SHARED | All mandates at full intensity. CM-6 and CM-7 strictly enforced — artifacts evolve, products are coherent |
+| PUBLIC_LAUNCH | All mandates at full intensity. CM-5 multi-alternative evaluation mandatory on all non-trivial decisions. CM-10 violations (hedging, soft truths) block completion |
+
+## Anti-Patterns
+
+- **DON'T** downgrade a mandate to "nice-to-have" under time pressure — **BECAUSE** CM-4 skipped "just this once" duplicates code; CM-5 skipped ships first-draft work to production.
+- **DON'T** perform a mandate's action without its intent (a clarification question with the answer pre-baked, "searching" only the open file) — **BECAUSE** the value is genuine execution, not the appearance of compliance.
+- **DON'T** apply mandates selectively by task size — **BECAUSE** small violations compound into systemic failure.
+- **DON'T** resolve ambiguity by silently picking the likelier interpretation — **BECAUSE** CM-2 requires asking; a silent pick makes the user's intent unrecoverable and the after-the-fact audit trail impossible to close.
+- **DON'T** reach for the fix nearest where the symptom surfaced — **BECAUSE** CM-8 points to the binding constraint, not the loudest complaint; a cache over an O(n²) query mistakes comfort for cure and the constraint resurfaces elsewhere.
+- **DON'T** hedge a real problem to preserve momentum ("mostly works", "should be fine") — **BECAUSE** CM-10's honesty is an early-warning signal; softening it exports the defect to whoever trusts the reassurance next.
+
+## Enforcement
+
+Always-on at every seriousness level, scaling per the table above. Implements CM-1–10. Canonical specification for operational mandate behavioral definitions.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every other rule's behavioral floor (CM-1 critical evaluation, CM-2 zero assumptions, CM-4 search-before-implement, CM-5 best solution gate every artifact emission). ● Every command's pre-execution conformity check (`commands/plan-execute.md` Step 2 cites CM-11 / CM-1 explicitly). ● Every agent's deployment decision frame (CM-17/CM-25 routes through `rules/agent-orchestration.md`). ◐ The structured-inquiry channel (CM-2's structured-inquiry surface delegates to `rules/interactive-questions.md`).
+- **Satisfies →** ● CM-1–10 inline definitions (this rule is the expanded behavioral specification CLAUDE.md delegates to). ● the rules registry row "Operational Mandates" (the registry entry's "Implements" column points here).
+- **Established by ↑** ● the operational-mandate registry. ● the artifact directories (rules/*.md class declaration). ● the seriousness-scaling discipline Seriousness-Scaled Governance (the four-tier scaling lens this rule's table inherits).
+- **Gated by ←** ● `CLAUDE.md` always-loaded preamble (rules in this directory load before any task work). ● `rules/cognitive-identity.md` Filter 1 + Filter 5 always-on baseline (every substantive output passes both before mandate enforcement applies).
+- **Cross-bound with ↔** ↔ `rules/operational-mandates-expanded.md` (path-filtered companion sub-rule carrying the per-mandate Violation indicators and Recovery sub-blocks for CM-1..CM-10). ↔ `rules/clean-room-generation.md` (CM-5 best-solution mandate's generation discipline lives there; CM-4 search-before-implement's four-outcome mirror is documented at §1.1). ↔ `rules/persistent-conventions-vigilance.md` (CM-6 self-improvement's artifact-evolution arm is canonicalized there). ↔ `rules/context-management.md` (CM-12 context stewardship's full protocol lives there). ↔ `rules/auto-memory.md` (CM-26 memory lifecycle's full protocol lives there). ↔ `rules/interactive-questions.md` (CM-2 zero-assumptions's structured-inquiry surface lives there). ↔ `rules/clean-architecture-layers.md` (CM-27 layer discipline lives there). ↔ `rules/code-craft-python.md` (CM-28 Python discipline lives there). ↔ `rules/large-file-generation.md` (CM-23 large-file protocol lives there). ↔ `rules/agent-orchestration.md` (CM-17/CM-25 agent orchestration lives there). ↔ `rules/planning-techniques.md` (CM-20/CM-21 planning techniques live there). ↔ `rules/plain-language.md` (CM-7 codebase-coherence mandate's outward-projection — plain-language scans intercept plan-internal references on apothem-only surfaces). ↔ `rules/multi-agent-workflow.md` (CM-17/CM-25 — the independent-critique / open-loop / dynamic multi-agent capability is invoked under the CM-1 critical-evaluation deploy/skip decision this rule canonicalizes; opt-in per `rules/agnostic-posture.md`).

package/src/apothem/rules/option-annotation-form.md

@@ -0,0 +1,60 @@
+---
+name: "option-annotation-form"
+description: "Path-filtered companion rule carrying the prose-and-document annotation form, rationale-specificity citations, cross-channel consistency invariant, cardinality bounds, and failure-tells enumeration declared at the parent `option-annotation.md` rule's anchor lines; demand-loaded on prose-and-document artifact touches."
+pathFilter: "**/*.md, **/CLAUDE.md, **/rules/**, **/commands/**, **/skills/**, **/agents/**, **/docs/**, **/ADR/**, **/rfcs/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Option Annotation Form (Companion Sub-Rule)
+
+## Purpose
+
+Specify the executable details of the prose-and-document option-annotation discipline declared at the parent `rules/option-annotation.md`. This companion is path-filtered: it loads when the assistant edits any prose-and-document artifact (Markdown files, rules, commands, skills, agents, docs, ADRs, RFCs), keeping the parent's always-on payload lean while preserving full form fidelity at the demand-load surface. The parent rule remains the canonical home for the M7 standing directive and channel-routing summary; this companion carries the prose-and-document form, rationale specificity, cross-channel consistency, cardinality bounds, and failure tells.
+
+## Obligations
+
+### 1. The Prose-and-Document Annotation Form
+
+Every option set in a prose-and-document artifact carries the following structure:
+
+```text
+Option A — <name>
+  <one-paragraph statement of what the option means and its direct, observable consequence>
+Option B — <name> — **Recommended**
+  <one-paragraph statement of what the option means>
+  Rationale: <specific, principle-linked rationale citing a concrete driver — host-project sibling-file precedent, observed-state fact, named risk, named constraint, RFC or vendor documentation, or a rule citation with anchor>
+Option C — <name>
+  <one-paragraph statement of what the option means and why the rationale's pressure does not weigh as heavily>
+```
+
+A mutually exclusive option set carries at most one `**Recommended**` label, mirroring the single-select cardinality at `rules/interactive-questions.md` §3.1. A non-exclusive set MAY mark multiple options only when the prose states they can be selected together AND each recommended option carries its own concrete-driver rationale. A zero-recommended set is conformant only when no option dominates on the cited driver — the rationale section then names the underdetermined dimensions and routes the choice to the user via an inquiry per `rules/authority-inquiry.md`.
+
+### 2. Rationale Specificity
+
+The rationale meets the scholarly / technical bar declared at `rules/ten-dimension-check.md` dimension 9. Specifically, the rationale cites at least one concrete driver class — host-project sibling-file precedent, observed-state fact (measured metric, file contents, gate result, log entry, dependency-graph analysis with a reproducible evidence pointer), named risk, named constraint, RFC or vendor documentation, or a rule citation with anchor. Phrases on the vague-rationale forbid list at `rules/interactive-questions-canonical-shapes.md` §3.2.2 — "this is widely adopted" without a named source, "best practice", "industry standard", "more scalable", "cleaner", "more elegant", "generally speaking" — are non-conformant when they stand as the sole justification.
+
+### 3. Cross-Channel Consistency
+
+When the same decision is surfaced in both channels — e.g., a commit-message body documents the option set the structured-inquiry invocation resolved — the two surfaces carry consistent option labels, consistent recommended markers, and consistent rationales. The structured-inquiry record is the source of truth on shape and label set; the prose surface tracks it without divergence.
+
+### 4. Cardinality Bounds
+
+Floor: two options (a single option is a notification, not a question). Ceiling: four options (more than four degrades operator judgment per the choice-overload literature at `rules/interactive-questions.md` §9). A set exceeding four entries MUST be split into a hierarchical surface — a primary three-or-four-option choice on the dominant dimension, then a follow-up choice on the secondary dimension once the primary resolves.
+
+### 5. Failure Tells
+
+"Here are some options, let me know which" — annotation absent (un-annotated form). "I went with Black" — silent pick (no option set surfaced). "Recommended: X. (No rationale)" — annotation hollow (marker without principle-linked driver). Two options carry the `**Recommended**` label in the same option set (cardinality violation). The rationale is `"this is widely adopted"` with no named source (vague-rationale forbid list). The recommended option's body lacks the `Rationale:` line (annotation incomplete). An option set of five or more entries presented flat (cardinality-bound violation; the choice-overload threshold is exceeded). A commit-message body documents an option set with a different recommended option than the structured-inquiry record resolved (cross-channel divergence).
+
+## Enforcement
+
+Path-filtered (the nine glob patterns in this rule's `pathFilter` field), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/option-annotation.md`. The parent rule carries the M7 standing directive and channel-routing summary; this companion carries the prose-and-document form, rationale specificity, cross-channel consistency, cardinality bounds, and failure tells.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every prose-and-document option set's annotation shape (the §1 form is the floor). ● The rationale-specificity check at every `Rationale:` line (§2 cites the concrete-driver taxonomy and the vague-rationale forbid list). ● The cardinality check at every option set (§4 floor of 2 / ceiling of 4). ◐ The cross-channel consistency check between structured-inquiry records and prose surfaces (§3).
+- **Satisfies →** ● the fifteen-mandate registry row **M7 — Option Annotation** (the prose-and-document subset). ● `rules/option-annotation.md` companion-anchor lines (the parent rule's pointers to this companion's full specification).
+- **Established by ↑** ● `rules/option-annotation.md` (parent-rule anchor). ● the fifteen-mandate registry row M7.
+- **Gated by ←** ● The path-filter (the nine glob patterns) — this rule demand-loads only on prose-and-document artifact touches. ● `rules/option-annotation.md` always-on baseline (parent rule's anchor must be live for the companion to demand-load coherently).
+- **Cross-bound with ↔** ↔ `rules/option-annotation.md` (parent rule; companion-anchor lines bind this companion). ↔ `rules/interactive-questions-canonical-shapes.md` (§2.1 per-invocation cardinality, §3.2.2 vague-rationale forbid list). ↔ `rules/interactive-questions-detail.md` (choice-overload bound, authoring discipline). ↔ `rules/ten-dimension-check.md` (M3 dimension 9 scholarly / technical referencing — rationale specificity meets it). ↔ `rules/authority-inquiry.md` (M5 — zero-recommended option sets route through the inquiry surface). ↔ `rules/disclosure-ledger.md` (M2 — annotation outcomes recorded in the ledger).

package/src/apothem/rules/option-annotation.md

@@ -0,0 +1,45 @@
+---
+name: "option-annotation"
+description: "Every multi-option choice carries a Recommended marker plus principle-linked rationale — silent picks and un-annotated option lists are forbidden in authoritative territory. The structured-inquiry subset delegates to the canonical structured inquiry schema; this rule extends the discipline to prose-and-document option sets."
+pathFilter: ""
+alwaysApply: true
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Option Annotation Discipline
+
+## What this rule enforces
+
+Binds **M7 — Option Annotation Discipline**. Whenever the agent surfaces an option set in any host-project artifact — prose response, ADR, README, PR description, design document, runbook step, code comment, commit-message body, RFC — every option MUST be enumerated, the agent's recommended option(s) MUST carry the canonical `**Recommended**` label, and the rationale MUST be specific and principle-linked. Silent picks and un-annotated option sets are both forbidden in authoritative territory.
+
+The structured-inquiry subset (invocation schema, three-segment option body, closed recommendation taxonomy, harness fallback, per-file destructive-op confirmation, default-pointer convention) is canonicalized at `rules/interactive-questions.md` §2–§7. This rule extends the same discipline to the prose-and-document option sets that channel does not cover.
+
+## Pre-conditions
+
+Applies to every option set surfaced in a host-project artifact of meaningful scope per the trivial-vs-non-trivial threshold. The canonical annotation collapses to a single-line confirmation only when the option set is binary AND the work is trivial-scope AND the user has already implied the answer. Option sets of three or more entries always carry the canonical annotation.
+
+## Required behavior
+
+### Channel routing
+
+Every option-set surface routes through one of two canonical channels:
+
+- **structured-inquiry channel.** When the option set is a decision the user must resolve, the channel is structured inquiry per `rules/interactive-questions.md` §1; the three-segment annotation, recommendation taxonomy, label-postfix bidirectional bind, and destructive-op default floor are owned there.
+- **prose-and-document channel.** When the option set surfaces inside an emitted artifact (prose response, ADR, README, PR description, design document, runbook), the annotation is the inline `**Recommended**` marker on the recommended option's heading — canonical example `Option B — <name> — **Recommended**`, followed by a `Rationale:` line citing a concrete driver.
+
+### Companion Sub-Rule Anchor
+
+The full prose-and-document specification — Option A / B / C example block + at-most-one-recommended cardinality + zero-recommended fallback (§1); concrete-driver classes + dimension-9 scholarly bar + vague-rationale forbid list (§2); cross-channel consistency invariant (§3); two-option floor + four-option ceiling + hierarchical split (§4); failure-tells enumeration (§5) — lives at the path-filtered companion [`rules/option-annotation-form.md`](./option-annotation-form.md), demand-loaded on prose-and-document artifact touches.
+
+## Disclosure surface
+
+The annotated option set IS the disclosure surface. When apothem falls back to the recommended option (the user declined to pick, or the option set was an optional inquiry per `rules/authority-inquiry.md`), the fallback is recorded in the disclosure ledger per `rules/disclosure-ledger.md` as `[Inquiry — id: <id>; outcome: fallback-to-recommended]`.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** Every option set in every emitted host-project artifact (prose, document, commit body, PR description). The `**Recommended**` marker presence at every multi-option choice surfaced inline. The mechanical option-annotation grep at `conformity/option_annotation_grep.py` (the prose-and-document scope of the matcher; the structured-inquiry scope routes through `rules/interactive-questions-sweep-matchers.md` H4–H7).
+- **Satisfies →** the fifteen-mandate registry row **M7 — Option Annotation**.
+- **Established by ↑** the fifteen-mandate registry (ratifies M7). `rules/interactive-questions.md` (the canonical-channel rule this rule extends; the structured-inquiry subset is canonicalized there, not duplicated here).
+- **Gated by ←** `CLAUDE.md` always-loaded preamble. The §8.1 trivial-vs-non-trivial threshold (binary collapsed-confirmation choices on trivial-scope work skip the canonical annotation; option sets of three or more entries always carry it).
+- **Cross-bound with ↔** `rules/option-annotation-form.md` (path-filtered companion sub-rule carrying the prose-and-document form, rationale specificity, cross-channel consistency, cardinality bounds, and failure tells). `rules/interactive-questions.md` (the structured-inquiry subset is canonicalized there; this rule extends to prose-and-document option sets without duplicating the schema). `rules/interactive-questions-sweep-matchers.md` (the H4–H7 annotation-compliance heuristics enforce this rule's prose-and-document scope at the pre-emission gate). `rules/disclosure-ledger.md` (M2 — fallback-to-recommended is recorded in the ledger). `rules/ten-dimension-check.md` (M3 — rationale specificity meets dimension 9 scholarly / technical referencing). `rules/authority-inquiry.md` (M5 — optional inquiries fall back to the recommended option per the carved-out catalog). `rules/operational-mandates.md` §CM-2 Zero Assumptions (M7 is the prose-and-document outward-projection form of CM-2's structured-inquiry discipline). `rules/sota-elevation.md` (every recommended-option rationale cites a concrete-exemplar concrete-driver class 6). `rules/recommend-next-step.md` (M7 — multi-action Next Steps blocks carry the Recommended marker plus concrete-driver rationale). `rules/i18n-discipline.md` (M7 — amendment inquiries carry Recommended + driver). `rules/determinism.md` (option-set annotations are rendered deterministically — same inputs yield the same recommended marker and rationale).

package/src/apothem/rules/own-voice-reimplementation.md

@@ -0,0 +1,86 @@
+---
+name: "own-voice-reimplementation"
+description: "Every reference-derived feature is reauthored in apothem's own voice with zero verbatim code/text/branding, is demonstrably more elegant and effective than the reference, and cites the relevant harness's own latest official documentation (a convention-pin snapshot dated within the prior 90 days)."
+pathFilter: "**/rules/**/*.md, **/commands/**/*.md, **/skills/**/*.md, **/agents/**/*.md, **/site/**/*.md*, **/assets/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Own-Voice Reimplementation — Zero Inheritance, Elevated Beyond, Harness-Doc-Aligned
+
+## What this rule enforces
+
+Every feature, structure, or convention apothem derives from observing a reference platform is **reauthored** in apothem's own voice. Zero verbatim code, text, marketing copy, or branding crosses the boundary — the reimplementation is an independent derivation from understood intent, not a transcription. The reimplementation **MUST** be more elegant, more sophisticated, and more effective than the reference; "as good as" is non-conformant where "better" is reachable. Every reimplemented surface that derives a convention from a harness **MUST** cite that harness's own latest official documentation through its `STANDARD-CONVENTION-PIN.md` — a convention-pin snapshot dated within the prior 90 days.
+
+## Pre-conditions
+
+Applies whenever any apothem surface reimplements a feature, structure, layout, naming scheme, design element, or convention observed in a reference platform. Surfaces authored without reference to any external platform carry no reimplementation obligation — only the standing plain-language and code-craft floors.
+
+## Required behavior
+
+### 1. No-Verbatim Rule
+
+The reimplementation **MUST NOT** copy any byte of the reference's code, prose, marketing copy, branding, color palette, slug, route name, file name, identifier, or naming convention. Every artifact **MUST** be independently derivable from the feature's understood intent — never from the reference's expression of it. Because nothing is copied, **no attribution is triggered**: no inherited authorship to credit, no license obligation, no origin to cite. A reimplementation that would require an attribution line to be lawful has copied something and **MUST** be reauthored from intent.
+
+### 2. Elevation Requirement
+
+The reimplementation **MUST** be demonstrably more elegant, more sophisticated, or more effective than the reference. The author **MUST** name the dimension of improvement — clarity, structural novelty, robustness, performance, accessibility, maintainability, or expressiveness — and state how the apothem surface realizes it. A reimplementation that merely matches the reference on every dimension **SHOULD** be reworked until at least one dimension is elevated; one that paraphrases without elevation is non-conformant.
+
+### 3. Harness-Documentation Pin
+
+Every reimplemented surface that derives a convention from a harness **MUST** cite that harness's `STANDARD-CONVENTION-PIN.md` at `src/apothem/harnesses/<name>/STANDARD-CONVENTION-PIN.md`, and the cited pin's `snapshot-date` **MUST** fall within the prior 90 days. The citing surface **MUST** state the verification recipe: compute the day-delta between today and the pin's `snapshot-date`, confirm `delta <= 90`. A pin older than 90 days **MUST** be refreshed against the harness's latest official documentation before the surface ships; a stale pin surfaces as an advisory finding with the refresh as its next step, and the phase's Definition of Done is not met until the pin is refreshed (CI's `--strict` opt-in enforces the freshness floor mechanically, per the agnostic-posture advisory discipline).
+
+### 4. Worked Before/After Example — Own-Voice Reauthoring
+
+The transformation below demonstrates own-voice reauthoring on a neutral, invented feature concept — a per-session continuous-learning loop. The "reference" column is a paraphrase of *intent only*, carrying none of any real platform's wording or structure; the "apothem own-voice" column is a structurally novel, elevated reimplementation.
+
+| Aspect | Reference (paraphrased intent) | apothem own-voice reimplementation |
+|---|---|---|
+| **Feature concept** | After each session, the tool records what it learned and reuses it next time. | A **convention-promotion ledger**: confirmed patterns graduate from session-local scratch to a durable, indexed memory tier through an explicit four-field promotion record (`source` / `target` / `date` / `rationale`). |
+| **Trigger** | "It learns as you go." | Promotion fires only on a **recurrence threshold** (a pattern observed across distinct sessions), never on a single observation — the threshold is the contract, not an implicit heuristic. |
+| **Structure** | A flat log of notes. | A **two-tier topology** (project-scoped + global) with a directional promotion invariant and an auditable ledger, so the learning surface is itself inspectable and reversible. |
+| **Elevation dimension** | — | **Structural novelty + auditability**: the apothem version replaces an opaque "it learns" black box with an explicit, reviewable promotion contract — a different mechanism, not a rephrasing of the reference's. |
+
+The apothem column shares **no wording, no data shape, and no naming** with the reference; it solves the same intent (carry forward what proved useful) through an independently-derived mechanism that is more inspectable than the paraphrased reference. This is reauthoring, not paraphrase.
+
+### 5. Standing Definition-of-Done Gate
+
+The mechanical reference-token sweep — gate name **`reference-token-grep`**, anchored at this rule — is a **standing per-phase Definition-of-Done gate**. Every later phase's exit gate **MUST** run it; **zero in-scope hits** is the preserved baseline at every phase boundary. The gate sweeps in-scope authored surfaces (per this rule's `pathFilter`) for any reference brand, slug, author name, or other reference-identifying token. A non-zero in-scope hit count surfaces as an advisory finding with reauthoring as its next step; the phase's Definition of Done is not met until the leaking token is reauthored away, and CI's `--strict` opt-in enforces the zero baseline mechanically. The zero baseline **MUST NOT** be silently relaxed for "just this phase".
+
+### 6. Resolved Placeholders
+
+Two former reference-internal placeholders are **RESOLVED as NOT-NEEDED** under the no-copy discipline; neither **MUST** be silently reconstructed:
+
+- **Exact reference-site palette / typography / logo.** NOT-NEEDED. The project authors an **original design system** — its own palette, type scale, and mark — from its own brand intent, never sampled from a reference site. Capturing the reference's visual tokens would violate §1.
+- **Reference config-file bodies.** NOT-NEEDED. Apothem **derives config conventions from each harness's own latest official documentation** (per §3's pin discipline), never from a reference platform's config files. The authoritative source is the harness vendor's documentation, not any reference platform.
+
+Re-introducing either placeholder under a renamed heading is a §1 violation surfaced at the §5 gate.
+
+## Mechanical enforcement
+
+`conformity/reference_token_grep.py` — the reference-token sweep anchored at this rule — enforces the §5 zero-in-scope-hits baseline across this rule's `pathFilter` surfaces. `conformity/plain_language_grep.py` — the sibling user-facing plain-language sweep — enforces the adjacent closed-set forbidden-vocabulary discipline on the same user-facing surfaces. The two matchers run together at every phase exit gate.
+
+## Disclosure surface
+
+Every reimplementation outcome is recorded in the disclosure ledger per `rules/disclosure-ledger.md`:
+
+- `[Reimplementation — surface: <name>; elevation: <dimension>; harness-pin: <snapshot-date>]` for every reauthored surface, naming the elevated dimension and the cited pin's snapshot date.
+- `[Reimplementation — placeholder-resolved: <palette-typography-logo | config-bodies>; resolution: not-needed]` for each of the two §6 placeholder resolutions.
+- `[Reimplementation — gate: reference-token-grep; in-scope-hits: 0]` for every phase-exit gate run that preserves the baseline.
+
+## Failure tells
+
+A block of code or copy carried verbatim from a reference platform. A reimplementation that restates the reference's feature in fresh words but reuses its structure, naming, or data shape (paraphrase, not reauthoring). A reference brand, slug, or author name leaking into a shipped in-scope surface. A harness-documentation pin whose `snapshot-date` exceeds 90 days cited as current. A design token (palette / type / logo) sampled from a reference site rather than authored originally. A config convention reproduced from a reference platform's config file rather than derived from the harness's own documentation. A silently reconstructed §6 placeholder under a renamed heading.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** The per-phase zero-leak Definition-of-Done gate (`reference-token-grep`) that every later phase's exit gate runs. The mechanical matcher at `conformity/reference_token_grep.py`. Every reauthored in-scope authored surface under this rule's `pathFilter`.
+- **Satisfies →** The own-voice reimplementation mandate (zero verbatim inheritance, mandatory elevation, harness-doc alignment). The product-artifact boundary that keeps shipped surfaces free of reference branding.
+- **Established by ↑** The no-copy reimplementation directive. The harness convention-pin discipline at `src/apothem/harnesses/<name>/STANDARD-CONVENTION-PIN.md`.
+- **Gated by ←** The `pathFilter` (in-scope authored surfaces only; non-derived surfaces are exempt). The `reference-token-grep` zero-hit baseline at every phase boundary.
+- **Cross-bound with ↔** `rules/plain-language.md` (sibling user-facing-vocabulary sweep on the same shipped surfaces). `rules/agnostic-posture.md` (host-agnostic posture; reimplementations derive conventions from each harness's own documentation, not from a single reference). `rules/recommend-next-step.md` (terminal-surface forward-move discipline this rule's tail honors).
+
+## Recommended Next Step
+
+**Proceed to Phase 00D — the `rules/` → `skills/` investigation** to map which reimplementation disciplines belong in path-filtered rules versus detectable-technique skills, per `rules/recommend-next-step.md`.

package/src/apothem/rules/performance-discipline.md

@@ -0,0 +1,91 @@
+---
+name: "performance-discipline"
+description: "Per-class runtime performance budgets with quantitative pass/fail gates — each artifact class (hook handlers, the conformity sweep, the test suite, agent spawn, install resolution) carries a runtime ceiling, a measurement boundary, and a benchmark verifier that exits zero on compliance; budget exceedances surface as findings routed to the expertise-gap log. Closes the Performance axis of the seven-axs-of-breadth taxonomy."
+pathFilter: "**/hooks/**, **/tools/**, **/tests/**, **/agents/**"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Performance Discipline
+
+## Purpose
+
+Establish per-class performance budgets and quantitative gates; close the Performance gap of the seven-axs-of-breadth taxonomy at `rules/cognitive-identity.md` §1.
+
+## Obligations
+
+### 1. Per-Class Performance Budgets
+
+Per-class runtime budgets; operator-editorial at apply time; baselines align with the hooks pipeline hook-timeout values. Every row's verifier exits 0 on budget compliance.
+
+| Class | Budget | Measurement boundary | Verifier |
+|-------|-------:|---------------------|----------|
+| Hook handler — `PreToolUse` / `PostToolUse` / `UserPromptSubmit` / `Notification` | 10s | hook-fire to dispatcher-return | `python src/apothem/benchmarks/bench_hooks.py --event=<name>` |
+| Hook handler — `SessionStart` / `PreCompact` / `PostCompact` | 30s | hook-fire to dispatcher-return | `python src/apothem/benchmarks/bench_hooks.py --event=<name>` |
+| Hook handler — `Stop` | 60s | hook-fire to dispatcher-return | `python src/apothem/benchmarks/bench_hooks.py --event=Stop` |
+| Verify-ecosystem sweep — composite | 30s | tool-invocation to exit | `python src/apothem/benchmarks/bench_validate_ecosystem.py` |
+| Verify-ecosystem sweep — per-check | 5s | per-subcommand invocation to exit | `python src/apothem/benchmarks/bench_validate_ecosystem.py --check=<name>` |
+| Conformity-gate orchestrator — single-file dispatch | 1s | `python -m apothem.conformity.gate <file>` invocation to exit | `time python -m apothem.conformity.gate <file>` |
+| Test-suite — full (post-pytest-xdist) | 60s | `pytest -n auto` start to exit | `time pytest -n auto` |
+| Test-suite — per-test-module | 10s | per-module collection to exit | `python src/apothem/benchmarks/bench_tests.py --module=<path>` |
+| Agent spawn — research / audit / quality / generation | 60s | spawn to result-collection | `python src/apothem/benchmarks/bench_agents.py --pattern=<name>` |
+| Install-all — resolution sweep (manifest rules + capability projection, all adapters) | 0.25s | dry-run install-all rule + capability resolution across every adapter, no filesystem mutation | `python src/apothem/benchmarks/bench_install.py` |
+
+### 1.0.1 Measurement-Gate Outcome (Budget Revision History)
+
+The measurement gate (per `rules/planning-techniques.md` §1 Iteration Loop Safety) measured the conformity-gate orchestrator's per-matcher work at **0.67ms mean** (sum across 20 matchers: 13.3ms; slowest `file-header-grep` at 4.70ms) against an interpreter-startup-dominated wall-clock of ~465ms per single-file dispatch. ProcessPoolExecutor spawn overhead on Windows hosts is ~50–300ms per worker; fanning out 20 matchers would add 2–6s of pure overhead — **slowing the gate 150–450×, not speeding it up**. Three revisions resolved: the composite-sweep revision (30s → 10s) was **rejected** by measurement (composite stays 30s; the new 1s per-dispatch rows reflect reality); the test-suite revision (120s → 60s) was **accepted** because pytest-xdist's per-test-file work is substantial and parallel execution wins; multi-agent dispatch budget stays **per-agent** (not per-wave) because agent-spawn cost is fixed regardless of parallelism shape.
+
+### 1.1 Shell-Execution Sub-Budgets
+
+Hook bootstrap stubs run synchronously on the critical path between hook-fire and dispatcher-handoff. Their startup cost lives inside the §1 hook-handler budget but is itself bounded so the dispatcher gets its full budget for the actual work. The shell-linter ratification (`shellcheck` + `Invoke-ScriptAnalyzer`) carries the same per-class discipline as `ruff check` for Python artifacts.
+
+| Class | Budget | Measurement boundary | Verifier |
+|-------|-------:|---------------------|----------|
+| Bootstrap stub — `hooks/lib/bootstrap.sh` (POSIX bash; Linux / macOS / WSL) | 500ms | stub invocation to `exec` of `dispatch.py` | `time bash hooks/lib/bootstrap.sh SessionStart </dev/null` |
+| Bootstrap stub — `hooks/lib/bootstrap.sh` (Windows Git Bash / mingw64) | 1500ms | stub invocation to `exec` of `dispatch.py` | `time bash hooks/lib/bootstrap.sh SessionStart </dev/null` |
+| Bootstrap stub — `hooks/lib/bootstrap.ps1` | 1500ms | stub invocation to dispatcher exit | `Measure-Command { pwsh -NoProfile -File hooks/lib/bootstrap.ps1 -Event SessionStart }` |
+| Interpreter locator — `find-python.{sh,ps1}` | 200ms | dot-source to first PATH probe success | included in the bootstrap-stub measurements above |
+| Shell linter — `shellcheck` over `hooks/lib/*.sh` | 5s | `shellcheck` invocation to exit | `shellcheck hooks/lib/*.sh` |
+| Shell linter — `Invoke-ScriptAnalyzer` over `hooks/lib/*.ps1` | 10s | analyzer invocation to exit | `pwsh -NoProfile -Command "Invoke-ScriptAnalyzer -Path hooks/lib -Severity Error,Warning"` |
+| Python linter — `ruff check` over the ecosystem | 5s | `ruff` invocation to exit | `ruff check hooks/ tools/ tests/` |
+
+The PowerShell budget is wider than POSIX-bash because PowerShell's startup cost dominates on Windows hosts; the dispatcher accommodates this by running its work asynchronously after the stub's `exec` boundary. The Windows Git Bash / mingw64 row carries the same 1500ms budget as PowerShell for the same reason: on Windows, `bash` is the mingw64 port and pays a per-invocation `fork()`-emulation cost that lifts baseline bash startup from ~50ms (POSIX) to ~800ms (mingw64). The POSIX-bash row remains the canonical 500ms budget for Linux / macOS / WSL hosts; the per-platform classification is enforced at audit time by the bench driver's host-detection logic. Empirical evidence: a 5-run mean of 1004ms (min 960ms, max 1042ms) on a Windows Git Bash mingw64 host against the prior 500ms uniform budget.
+
+### 2. Quantitative Gates
+
+Every code change touching an artifact class above runs the relevant verifier; exit code 0 attests budget compliance. A budget exceedance surfaces as a high-priority finding under the Performance axis and routes to `memory/expertise-gap-log.md` for closure tracking.
+
+### 3. Benchmark Suite
+
+`src/apothem/benchmarks/` carries per-class entry-point scripts. Each script runs the artifact class's representative invocations, measures runtime (optionally peak memory), compares against the §1 budget, and exits 0 on PASS / non-zero on FAIL with a measured-vs-budget delta line.
+
+### 4. Operator Override
+
+An operator MAY amend a per-class budget at the §1 table; each amendment cites a concrete-driver class (measured workload increase, infrastructure change, dependency upgrade, or rule citation) per the Proactive Expertise Incorporation discipline's concrete-driver requirement.
+
+## Seriousness Scaling
+
+| Level | Performance Discipline |
+|-------|------------------------|
+| Awareness | Measurements logged in `memory/expertise-gap-log.md`; budgets advisory only |
+| Daily use | Per-class budgets enforced at the verifier level; budget exceedances surface as high-priority findings |
+| Release-tier | Full enforcement + benchmark-suite gating in the CI pipeline |
+
+## Anti-Patterns
+
+- **DON'T** measure runtime without a budget — **BECAUSE** observation without a gate doesn't prevent regression.
+- **DON'T** set budgets without measurement — **BECAUSE** speculative budgets either over-approve or block valid work.
+- **DON'T** suppress budget exceedances without a recorded rationale — **BECAUSE** silent suppression compounds technical debt invisibly.
+
+## Enforcement
+
+Path-filtered (the four glob entries in this rule's `pathFilter` field), scaling per the table above. Canonical specification for per-class performance budgets and quantitative gates across the Performance axis of the seven-axs-of-breadth taxonomy.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every artifact-class touch under the four path-filter entries (`**/hooks/**`, `**/tools/**`, `**/tests/**`, `**/agents/**`) — the per-class budget table at §1 enforces a quantitative ceiling. ● Every benchmark-suite invocation under `src/apothem/benchmarks/` (the four scripts `bench_hooks.py` + `bench_validate_ecosystem.py` + `bench_tests.py` + `bench_agents.py` realize the §3 verifier specification). ● Every budget-exceedance routing to `memory/expertise-gap-log.md` for closure tracking. ◐ The CI pipeline's release-tier benchmark gating.
+- **Satisfies →** ● the rules registry row "Performance Discipline" (W19-BIS extension). ● The Performance axis declared in `rules/cognitive-identity.md` §1's seven-axs-of-breadth taxonomy. ● the hooks pipeline timeout cliffs (the per-class budgets at §1 align with the canonical hook-event timeout values).
+- **Established by ↑** ● `rules/cognitive-identity.md` §1 (the seven-axs-of-breadth taxonomy declares the Performance axis this rule operationalizes). ● the hooks pipeline (the timeout-value canonical block this rule's §1 budgets align with).
+- **Gated by ←** ● The path-filter (the four glob entries: hooks/, tools/, tests/, agents/) — this rule activates only on matching artifact touches. ● `rules/cognitive-identity.md` Senior Software Architect role declaration.
+- **Cross-bound with ↔** ↔ `rules/cognitive-identity.md` (the seven-axs-of-breadth declaration this rule closes). ↔ `src/apothem/benchmarks/` (the per-class benchmark scripts the §3 verifier specification operationalizes). ↔ `memory/expertise-gap-log.md` (per-axis amendment ledger; budget exceedances route here per §2). ↔ `scripts/dev/validate_ecosystem.py` (the `--check perf-budgets` subcommand operationalizes the §1 budgets).

package/src/apothem/rules/persistent-conventions-vigilance-checklist.md

@@ -0,0 +1,54 @@
+---
+name: "persistent-conventions-vigilance-checklist"
+description: "Path-filtered companion sub-rule carrying the Convention Awareness checklist (§1) and the Ecosystem Gap Detection artifact-class triggers (§4) for the parent `persistent-conventions-vigilance.md` rule; demand-loaded on touches of governed-core surfaces."
+pathFilter: "**/CLAUDE.md, **/rules/**, **/skills/**, **/commands/**, **/agents/**, **/hooks/**, **/settings.json"
+alwaysApply: false
+---
+
+<!-- SPDX-License-Identifier: MIT -->
+
+# Rule: Persistent Conventions Vigilance — Checklist (Companion Sub-Rule)
+
+## Purpose
+
+Carry the full Convention Awareness checklist and the full Ecosystem Gap Detection artifact-class trigger catalog that the parent rule `rules/persistent-conventions-vigilance.md` declares at its §1 and §4 anchors. This companion is path-filtered: it loads when the assistant edits any governed-core surface (CLAUDE.md, rules/, skills/, commands/, agents/, hooks/, settings.json) so the parent rule's always-on payload stays lean while preserving full checklist fidelity at the demand-load surface. The parent remains the canonical home for the standing directives, Proactive Evolution, Ecosystem Coherence, Anti-Patterns, and Seriousness Scaling; this companion carries the §1 checklist and the §4 trigger catalog.
+
+## Obligations
+
+### 1. Convention Awareness — Full Checklist
+
+Before any non-trivial action, verify alignment with the current harness ecosystem on each artifact class:
+
+- **File/folder naming:** kebab-case for rules, skills, commands, plan artifacts. PascalCase or UPPER_SNAKE_CASE only where harness convention requires (e.g., `CLAUDE.md`, `SKILL.md`, `PROGRESS.md`).
+- **Directory structure:** `rules/`, `commands/`, `skills/`, `.apothem/plans/`, `projects/` — each carries a defined purpose; never conflate them.
+- **Skill:** one folder per skill in `skills/`; entry point is always `SKILL.md` with YAML frontmatter.
+- **Rule:** flat `.md` file in `rules/`; self-contained with Purpose, Obligations, Seriousness Scaling, Anti-Patterns, Enforcement.
+- **Command:** flat `.md` file in `commands/`; each defines one slash command (`/command-name`).
+- **Hook:** defined in `settings.json`, triggers prompts on tool events. Timeout values (seconds) bound execution — a hook exceeding its timeout is silently skipped. Per-event timeouts live in the canonical hook-events table at the hooks pipeline; new events take their timeout from that same column.
+- **Agent:** prompts carry mission, deliverable, constraints, context, return contract; deployment patterns per CM-25.
+- **Plan:** suites at `<project-root>/.apothem/plans/[REPO]-[CONTEXT]-[MISSION]/` with preamble, master plan, progress, notes, and a `phases/` directory of per-phase folders (each holding `PHASE.md` and `REPORT.md`).
+- **Other:** `CLAUDE.md` (root config, always-loaded), `settings.json` (hooks, permissions, MCP), memory (per CM-26), MCP tools (`mcp__server__tool` naming), narration (GFM; no emojis unless requested).
+
+### 2. Ecosystem Gap Detection — Artifact-Class Triggers
+
+Beyond refining existing artifacts (parent §2 Proactive Evolution), identify when the ecosystem is MISSING an artifact that would add value. **Common trigger:** a pattern recurs 2+ times in-session with similar structure, or is noted in memory as recurring. Route the gap to the matching artifact class:
+
+- **Agent:** recurring agent pattern → persistent `agents/{name}.md` with tool restrictions + system prompt.
+- **Hook:** repeatedly violated/forgotten mandate → enforcement hook in `settings.json`.
+- **Rule:** repeatedly corrected behavior uncovered by existing rules → new `.md` rule.
+- **Plugin:** repeatedly referenced missing tool/MCP server → install or create.
+- **Config freshness:** `CLAUDE.md` or `settings.json` references that no longer match ecosystem state → update the stale references.
+- **Skill:** reusable detectable technique (actionable, falsifiable) with no existing skill → `skills/{name}/SKILL.md`. See also `rules/persistent-conventions-vigilance.md`.
+- **Command:** recurring multi-step workflow → `commands/{name}.md` with proper frontmatter.
+
+## Enforcement
+
+Path-filtered (the eight glob patterns in this rule's `pathFilter` field), always-on at every seriousness level when in scope. Demand-loaded companion to `rules/persistent-conventions-vigilance.md` §1 and §4. The parent rule carries the standing directive, Proactive Evolution (§2), Ecosystem Coherence (§3), Anti-Patterns, and Seriousness Scaling; this companion carries the §1 Convention Awareness checklist and the §4 Ecosystem Gap Detection trigger catalog.
+
+## Bindings (§0.j five-direction)
+
+- **Drives →** ● Every governed-core surface touch's pre-flight convention check (§1 checklist applied per artifact class). ● Every gap-detection sweep's artifact-class routing (§2 trigger catalog maps recurrence patterns to agent / hook / rule / plugin / config / skill / command classes).
+- **Satisfies →** ● CM-22 (rule-delegated companion sub-rule). ● `rules/persistent-conventions-vigilance.md` §1 + §4 anchors (the parent rule's pointers to this companion's full checklist and trigger catalog).
+- **Established by ↑** ● `rules/persistent-conventions-vigilance.md` §1 + §4 (parent-rule anchors). ● CM-22.
+- **Gated by ←** ● The path-filter (the eight glob patterns) — this rule demand-loads only on governed-core surface touches. ● `rules/persistent-conventions-vigilance.md` always-on baseline (parent rule's §1 + §4 anchors must be live for the companion to demand-load coherently).
+- **Cross-bound with ↔** ↔ `rules/persistent-conventions-vigilance.md` (parent rule; §1 + §4 anchors bind this companion). ↔ `rules/auto-memory.md` (memory feeds gap-detection; gap-detection writes to memory per the parent's §2 evolution cycle). ↔ `rules/operational-mandates.md` (CM-6 self-improvement triggers gap-detection routing through §2 here).