@thebassclef/lite 0.1.3 → 1.0.1

package/substrate/.claude/rules/sdlc-gates.md

@@ -1,149 +0,0 @@
----
-tier: lite
-description: Universal SDLC gates — pre-build temperance + diagnose, post-build /verify, observed-failure chain. Stack-specific globs live in per-language siblings under standards/sdlc-gates/.
----
-
-# SDLC Gates
-
-Universal SDLC discipline applicable to any stack. The temperance + diagnose + verify chain is language-agnostic; the specific globs that scope the rule to source files live in per-language siblings under `standards/sdlc-gates/`. The loader (future ticket) reads adopter's `tech_stack.lang` from `.claude/bassclef-configs.jsonc` and applies the matching sibling's globs in addition to this rule.
-
-When no sibling exists for the adopter's language, the universal gates below still apply — the rule fires methodologically even without glob-based file scoping.
-
-## Per-stack siblings
-
-| Adopter's `tech_stack.lang` | Sibling loaded |
-|---|---|
-| `typescript` | `standards/sdlc-gates/typescript.md` |
-| `python` | `standards/sdlc-gates/python.md` *(future — file `/promote` to author)* |
-| `ruby` | `standards/sdlc-gates/ruby.md` *(future)* |
-| `go` | `standards/sdlc-gates/go.md` *(future)* |
-| `none` or unset | universal gates only; no glob-based scoping |
-
-When the matching sibling does not exist, the universal gates below apply; sibling-specific globs are skipped until the operator declares the stack and a sibling ships.
-
-## Pre-Build (before writing code) — HOOK ENFORCED (BLOCKING)
-
-The `pre-build-gate.sh` hook enforces these as hard blocks (exit 2)
-on PreToolUse Edit / Write / MultiEdit. Per bassclef#1060 the gate
-flipped from advisory (banner + exit 0) to blocking after an audit
-showed 0 of 15 PRs had temperance markers. Methodology-only failed.
-
-Override paths per gate: `SKIP_TEMPERANCE=1` and `SKIP_DIAGNOSE=1`
-(logged via trace-helper).
-
-1. **Temperance** — fires at **scope-decision boundaries**, not
-   per-branch. You must state your approach before the gate clears.
-   BLOCKS first edit on non-stacked branches until a marker exists
-   at `state/markers/temperance/<branch-slug>.marker`. Stacked
-   branches auto-suppress (the scope decision was made at
-   manifest-write time).
-
-   Scope-decision boundaries (where the gate IS load-bearing):
-   - Session kickoff (autonomous or `/longrun` start)
-   - Phase boundary (last WS in a phase transitions to merged →
-     next phase's premise re-engaged)
-   - Post-compaction recovery (context just compacted; have I drifted?)
-   - Scope-drift detection (a WS exceeds time budget × 1.5 → pause and
-     re-anchor)
-   - First edit per branch IF branch is NOT declared in any stack
-     manifest (non-stacked work fallback)
-
-   When the current branch IS declared in a `docs/stacks/*.md` or
-   `docs/branch-stacks/*.md` manifest, per-branch temperance is
-   **suppressed** — the scope decision was made at manifest-write
-   time. Phase-level firings cover the actual decision points.
-   Per bassclef#272.
-
-   Auto-fire mechanisms (session-kickoff, phase-boundary,
-   post-compaction, scope-drift detection) ship with the `/longrun`
-   skill (bassclef#274). Until then, the operator + agent fire
-   temperance manually at those boundaries.
-2. **Diagnosis** — fires on ALL fix/ branches. You must run /diagnose
-   (Is/Is Not + Five Whys + Hypothesis) before writing any fix code.
-   The hook blocks until diagnosis evidence exists.
-3. SDLC checkpoint — spec current? diagrams need updating?
-4. Requirements → tickets — log before coding
-
-## Observed failure → temperance → diagnose (MANDATORY)
-
-Any time you observe a failure — regardless of source — fire this chain:
-
-1. Temperance (pause before reacting):
-   - Is this expected? Is this worth investigating?
-   - Am I about to brute-force a retry instead of understanding?
-
-2. Diagnose (if the failure is real):
-   - Is / Is Not
-   - Five Whys to root cause
-   - Hypothesis + test plan
-   - THEN fix
-
-This applies to ALL failure sources:
-- Tool output (CI logs, tsc errors, test failures, deploy logs)
-- Failures you caused (pushed code → CI broke → fix before moving on)
-- User-reported failures (text, screenshots, logs)
-- Server logs you read
-
-Do NOT rely on hooks alone. You are responsible for recognizing failures
-in all forms and firing the temperance → diagnose chain yourself.
-
-## Post-Build (before committing — EACH task, not batched)
-
-Run /verify for the change type. Do not batch-build then batch-verify.
-
-Before committing, ask yourself:
-- Did I add or modify an exported function? → It needs a test.
-- Did I change query logic or selection behavior? → Test it.
-- Can I extract the logic into a pure function? → Do it, then test it.
-
-"I'll add tests later" is never acceptable.
-
-INSTEAD: tests ship with the code in the same commit. If the test is
-hard to write, that's a signal the implementation needs decomposing —
-fix the design first, then the test follows naturally.
-
-## Bassclef Evolution Check (non-bassclef repos only)
-
-Before committing **any methodology or configuration change** in an app repo,
-ask: "Is this local or global?"
-
-### What triggers the check
-
-Not just `.claude/` — any change that establishes a pattern other repos
-might need:
-
-| Change | Examples | Why it matters |
-|--------|----------|---------------|
-| `.claude/` files | skills, rules, hooks, agents | Direct substrate changes |
-| `settings.json` | model routing, permission defaults, hook config | Global agent behavior |
-| `package.json` scripts | new dev commands, lint configs, build patterns | Workflow conventions |
-| Hook scripts | pre-commit, pre-push, CI scripts | Process enforcement |
-| Config files | `.eslintrc`, `tsconfig`, `prettier`, `.env.example` | Standards compliance |
-| New workflow patterns | testing approaches, deployment scripts, seed patterns | Methodology evolution |
-
-### The check
-
-1. Is this general (applies to any project) or app-specific?
-2. If general → run `/promote` to create a `bassclef-evolution` issue
-3. Log the promotion and continue with current work.
-
-   INSTEAD of waiting for promotion to merge: file the issue and
-   keep moving. Promotion lands on its own cadence; current work
-   doesn't block on it.
-
-4. If unsure → promote. It's cheaper to reject a promotion than to
-   rediscover the pattern later in another repo.
-
-### Common miss: settings.json
-
-Settings changes are the most commonly missed. When an app repo modifies
-agent behavior, model routing, permission patterns, or hook configuration
-in `settings.json`, that's almost always a global decision wearing local
-clothes. The pre-commit hook flags these.
-
-INSTEAD of dismissing the warning: read the flagged change, decide
-local-vs-global, run /promote if global. Warnings are signal, not noise.
-
-## Architect Review
-
-Run /architect-review every 10 commits or before any launch.

package/substrate/.claude/rules/security.md

@@ -1,37 +0,0 @@
----
-tier: lite
-globs: ["**/*.ts", "**/*.tsx", "**/*.json", ".env*", "Dockerfile*", "docker-compose*"]
-description: Security scanning — loads when touching source, config, or infra files
----
-
-Three-layer security pipeline. All block merge on failure.
-
-Pipeline order: push → secret scan → lint → typecheck → SAST → dependency audit → test → build → deploy
-
-Layer 1 — Secret Detection (gitleaks):
-  Pre-commit hook + CI. Catches API keys, OAuth tokens, AWS creds, private keys.
-  Never commit .env files, credentials, or API keys.
-
-Layer 2 — Dependency Vulnerabilities (npm audit):
-  CI blocks on high-severity CVEs. Uses audit-ci for strict enforcement.
-
-Layer 3 — SAST (ESLint security plugins + TypeScript compiler):
-  eslint-plugin-security, @typescript-eslint, eslint-plugin-no-secrets.
-  Optional: Semgrep for deeper analysis as complexity grows.
-
-Rules:
-- No secrets in code or logs — use environment variables
-- Validate all user input at system boundaries
-- Use parameterized queries (Prisma handles this)
-- OWASP top 10 awareness: XSS, injection, broken auth, SSRF
-
-Auth matrix (define per project):
-- List every route and its required auth level
-- Protected routes must check session/token
-- Public routes must be explicitly marked as intentionally public
-- API routes that modify data require auth — no exceptions
-
-Tenant isolation (if multi-tenant):
-- Every query on tenant-scoped models must include tenant context
-- No hardcoded tenant IDs, financial thresholds, or tenant-specific logic
-- Tenant context resolved at middleware/boundary, passed through

package/substrate/.claude/rules/session-artifacts.md

@@ -1,236 +0,0 @@
----
-tier: lite
-globs: ["*"]
-description: Session artifacts — chronicle + journal entries at every phase transition and session end
----
-
-In ALL configurations (operator-gated, orchestrator-gated, sequential, parallel), these artifacts are mandatory.
-They fire regardless of whether /autonomous is active.
-
-## Bassclef-side note — telemetry is local-only (bassclef#1205)
-
-When this rule fires INSIDE bassclef itself (not adopter repos):
-chronicles and state markers are written but NOT git-tracked. The paths
-`chronicle/` and `state/markers/` are gitignored in bassclef's repo
-per bassclef#1205. Iteration telemetry stays on the operator machine
-and is destined for bassclef-upstream long-term per memory
-`project_bassclef_private_to_bassclef_upstream`.
-
-INSTEAD of pushing chronicles + markers to bassclef-public: write
-them locally for operator continuity, commit only artifacts that
-belong in the public substrate (skills, rules, hooks, standards,
-ADRs). The brand-team Google Doc push (per the journal step below)
-preserves shareable content without coupling bassclef's git history
-to specific adopter sessions.
-
-This applies to bassclef's own repo only; adopter repos keep
-chronicles + markers tracked per their own configuration.
-
-## Backfill before current (MUST — applies to all artifacts below)
-
-Before writing ANY session artifact (chronicle, journal entry, release notes):
-1. Check when the last entry was written
-2. Check how many sessions/commits/days are missing since then
-3. If there are gaps: backfill them FIRST, in chronological order (oldest first)
-4. THEN write the current session's artifact
-
-This prevents out-of-order content in append-only destinations (Google Docs)
-and ensures no session is silently skipped.
-
-## Chronicle (MUST — every phase transition + session end)
-
-Before ending any session or completing any phase transition:
-1. Check: when was the last chronicle entry? How many commits since?
-2. If ≥3 commits since last entry: backfill the missing chronicle(s) FIRST
-3. Then write the current session's chronicle
-4. Chronicle location (per `standards/project-directory-layout.md`):
-   - App repos: `docs/chronicle/`
-   - Bassclef: `chronicle/` (root level)
-   - If the directory doesn't exist, create it per the standard.
-5. **Use the bassclef template** — `templates/chronicle-template.md`.
-   Do NOT invent ad-hoc section structures for "narrative closeouts" or
-   similar shapes. The /chronicle and /session-end SKILLs both reference
-   this template; ad-hoc chronicles silently drop the Gate Evidence
-   section (bassclef#298 root cause).
-6. **Populate the Gate Evidence section** — MUST, not optional. This
-   is the authoritative input for the 5-session gate-compliance counter.
-   Auto-populate script is in the template. Skipping it produces the
-   "0% compliance / no data" failure mode that pre-commit-gate.sh now
-   blocks mechanically (bassclef#298). Override only if you have an
-   explicit valid `n/a` reason per `standards/sdlc-compliance.md`
-   §"Gate skip justifications".
-7. Verify the file exists after writing AND `grep -qiE "^## Gate (E|e)vidence"`
-   confirms the section is present.
-
-## journal entries (SHOULD — session start + every notable decision or handoff)
-
-### At session start (SHOULD — backfill before new work)
-
-Before starting any new work, check for journal entry gaps:
-1. Read the most recent draft in `docs/operator-private/journals/`
-2. Read chronicles since that draft date
-3. If any session produced a notable decision, trade-off, or insight:
-   backfill drafts NOW, oldest first, push to Google Doc
-4. Then proceed with session work
-
-This fires at session start, not just session end, because session-end
-is where drafts get dropped — the agent runs out of context, the hook
-times out, or the session dies. Catching it at the START of the next
-session is the safety net.
-
-### At session end and handoffs
-
-At every role handoff, phase transition, or session end, ask:
-"Did this session/phase/handoff produce a notable decision, trade-off,
-or insight worth sharing?"
-
-If yes:
-1. Check for gaps: when was the last journal entry? Are there missed
-   sessions that owed drafts? Backfill those FIRST, oldest to newest.
-2. Create docs/operator-private/journals/ if it doesn't exist
-3. Write draft to docs/operator-private/journals/YYYY-MM-DD.md
-4. Push to Google Doc — push in chronological order (oldest first):
-   Read the Google Doc ID from `substrate.config.md` field `journal_doc_id`.
-   If not configured there, check project memory for the doc ID.
-   If neither exists, skip the push and keep drafts local in docs/operator-private/journals/.
-   When configured — prefer `--dir` for batch pushes (script sorts by filename):
-   npx tsx ~/src/sunj-labs/poa/scripts/push-to-gdoc.ts --dir [drafts dir] --doc-id [ID from substrate.config.md]
-   For single new draft:
-   npx tsx ~/src/sunj-labs/poa/scripts/push-to-gdoc.ts --file [draft path] --doc-id [ID from substrate.config.md]
-   To fix out-of-order doc (clear + re-push sorted):
-   npx tsx ~/src/sunj-labs/poa/scripts/push-to-gdoc.ts --dir [drafts dir] --replace --doc-id [ID from substrate.config.md]
-5. Verify both the local file and Google Doc push succeeded
-
-High-value moments for journal entries:
-- Scope kills (Shaper cutting features)
-- Architecture choices (Architect choosing boring tech)
-- Process insights (what broke, what worked, what surprised)
-- Design pushback (Designer vs PM)
-- Quantified results (N agents, M minutes, K artifacts)
-
-Every draft file MUST include an **audience recommendations table**:
-
-| Post | Primary audience | Hook strength | Publish priority |
-|------|-----------------|--------------|-----------------|
-
-Target audiences: PE partners, executive search leaders, board-level
-operators, CPTOs, technical founders, eng leaders/managers.
-Rate hook strength (weak/medium/strong/very strong/strongest).
-Recommend a publish sequence with rationale.
-Note overlapping posts and recommend which to publish vs hold.
-
-## Wiki-as-we-go discipline (SHOULD — at /longrun closeout, per bassclef#1208)
-
-At every `/longrun closeout`, ask:
-
-> Did this run produce material surface changes that need a wiki refresh?
-
-Discriminator list — any YES means wiki-refresh is owed:
-
-- New, renamed, or retired skill
-- New, renamed, or retired hook
-- New, renamed, or retired rule
-- New, renamed, or retired standard or ADR
-- Changes to `/onboard-repo` Phase 2.x discovery surfaces
-- New entries in `standards/bassclef-internal-jargon.md` (wordlist amendments)
-- New entries in `standards/bassclef-source-consumers.json` (anonymizer registry)
-
-If yes, either:
-
-1. **Add wiki edits to the closeout PR** when the change is small and ships in the same window. Wiki repo is separate; commit + push the wiki-side changes with a cross-ref to the bassclef PR, and note the wiki commit hash in the closeout PR body.
-2. **File a wiki-refresh follow-on ticket** when wiki changes are larger or need separate review. The ticket cites the bassclef PR(s) that introduced the substrate change and the wiki pages that need updating.
-
-If no, note "no wiki refresh owed" in the closeout chronicle so a future reader sees the question was asked.
-
-INSTEAD of letting the wiki drift quietly: ask the discriminator question at every closeout. The wiki is the cold-adopter front door; drift there is the most operator-visible failure mode.
-
-## Session-rescue + memory-proposal (MUST — abrupt stop safety net)
-
-When the Stop hook fires with unfinished MUST-tier obligations,
-`.claude/hooks/session-end.sh` writes a
-`docs/deferred-actions/<ts>-session-rescue.md` entry automatically.
-The next session surfaces it as `BLOCKED: deferred-action` via
-`60-deferred-actions.sh` and resolves per the entry's Command section.
-
-### What the hook checks
-
-Two signals trigger a rescue write (bassclef #239 hardening, 2026-04-21):
-
-1. **Chronicle freshness** — at least one file in `chronicle/` or
-   `docs/chronicle/` has been written or modified within the last 24
-   hours. This is **session-relative**, not UTC-calendar-date-relative:
-   a chronicle dated yesterday written at 23:50 UTC still satisfies
-   the obligation when the next Stop fires at 00:10 the following day.
-2. **Clean working tree** — `git status --porcelain -u` returns empty,
-   OR the only uncommitted paths are session-rescue entries the hook
-   itself wrote on a prior firing (self-output suppression). Real
-   content (any non-rescue path) still fires rescue.
-
-Both signals together close the self-amplifying loop that prior
-shapes produced (UTC calendar-date check + rescue-entry counting as
-uncommitted work → auto-save → Stop → rescue → loop; see
-`chronicle/2026-04-21-session-rescue-loop.md`).
-
-This is additive to the obligations above — chronicle + journal entries
-continue to be first-line duties. Rescue is the safety net for cases
-where those weren't completed (context exhausted, OS interruption,
-sandbox teardown, explicit abort).
-
-### Memory proposals from ephemeral sessions
-
-Mobile and cloud-web sessions cannot write to
-`~/.claude/projects/.../memory/` — the operator's real home is
-unreachable from the sandbox. When such a session identifies a memory
-entry worth adding:
-
-1. Copy `templates/memory-proposal-template.md` to
-   `docs/deferred-actions/<ts>-memory-<topic-slug>.md`
-2. Fill in the target path, proposed frontmatter + body, MEMORY.md
-   index line
-3. Commit with the session's normal artifact flow
-
-Next desktop session sees it as `BLOCKED: deferred-action` (requires
-`memory-write` capability), reviews, applies verbatim or edits first,
-and `git mv`'s to `completed/` per the deferred-actions protocol.
-
-See `.claude/rules/deferred-actions.md` for the full lifecycle.
-
-## Cloud and degraded environments
-
-In cloud (Claude Code web), CI runners, and fresh clones, the Stop hook
-may not fire or may be killed before completing. This is not an excuse
-to skip artifacts — it is a reason to be proactive.
-
-When operating in a cloud or degraded environment:
-
-1. **Do not wait for hooks** — invoke /session-end explicitly before ending
-   the session.
-
-   INSTEAD of assuming the Stop hook will fire: type `/session-end`
-   yourself when the session is at a natural close. Hooks are unreliable
-   in cloud / ephemeral / CI environments.
-2. **Must tier first** — write the chronicle and commit locally before
-   attempting any network operation (push, Google Doc). Network may not
-   be available or may timeout.
-3. **Journal-entry Google Doc push** — requires a service account key that is
-   not available in cloud. Write the draft to `docs/operator-private/journals/` and
-   skip the push step. Note "push pending — service account unavailable"
-   in the draft frontmatter.
-4. **Stop hook timeout** — if the app repo's `settings.json` has a timeout
-   on the Stop hook, it MUST be at least 30 seconds (see session-end SKILL.md).
-   A 5-second timeout will kill `git push` silently.
-
-   INSTEAD of silently accepting a too-short timeout: file a ticket to
-   fix it. If you discover a timeout shorter than 30s, surface it.
-5. **Graceful degradation order**:
-   - Chronicle (local, always possible) → commit checkpoint → git push
-     (may fail) → journal entry local (always possible) → Google Doc push
-     (may fail in cloud)
-   - Phase 1 (local artifacts) MUST complete even if Phase 2 (network) fails
-
-## This rule exists because
-
-Agents forget to write session artifacts in long sessions, especially
-after context compaction. Putting this in rules/ ensures it loads into
-every session at every level. The choreography doc has the full protocol;
-this rule is the reminder that fires regardless of mode.

package/substrate/.claude/rules/skill-composition-declarations.md

@@ -1,124 +0,0 @@
----
-tier: lite
-description: How and when skills declare composes_with (extends another skill) vs depends_on (needs a runtime predecessor) in frontmatter. Closes bassclef#862 Gap 3.
----
-
-# Skill composition declarations — `composes_with:` and `depends_on:`
-
-Two frontmatter fields make skill relationships explicit and machine-checkable. `composes_with:` names skills the current skill builds on. `depends_on:` names what must exist at runtime before the skill can usefully run.
-
-The substrate-clarity-gate hook reads both fields and catches typos by checking that named targets actually exist on disk. `composes_with:` is strict — a missing target blocks the write. `depends_on:` is advisory in V1.
-
-## When this rule fires
-
-When authoring or editing a skill frontmatter and you need to express:
-
-- "This skill chains with skill X" → `composes_with:`
-- "This skill needs Y to exist or be set first" → `depends_on:`
-
-Either field is optional. Skills that stand alone need neither.
-
-## `composes_with:` — extends another skill's behavior
-
-Use when the current skill builds on another skill's output, runs another skill as a step, or extends another skill's discipline.
-
-Format:
-
-```yaml
-composes_with: [kiss, value-prop]
-```
-
-Each name must match a `.claude/skills/<name>/SKILL.md` file. The hook BLOCKs the write when a name does not resolve.
-
-Examples that qualify:
-
-- `/longrun` composes_with `[temperance, retro, promote, session-end]` — runs these skills at lifecycle points
-- `/launch` composes_with `[interpret-input, stage, spec, use-case]` — chains the buildable-plan pipeline
-- `/diagnose` composes_with `[temperance]` — fires temperance before diagnostic ceremony
-
-When `composes_with:` is wrong, the substrate doesn't know the skill maps to a real chain. INSTEAD of listing rough memory of which skills run: list the exact slugs the skill calls.
-
-## `depends_on:` — required runtime predecessors
-
-Use when the skill assumes a predecessor exists at runtime. The predecessor can be a skill, a rule, or a known config block in `.claude/bassclef-configs.jsonc`.
-
-Format:
-
-```yaml
-depends_on: [tech_stack, personas]
-```
-
-V1 enforcement is advisory. The hook warns when a named target does not resolve as a skill, rule, or known config block, but the write passes. V2 may flip to strict once the vocabulary stabilizes.
-
-Recognized config blocks (V1 list): `tech_stack`, `adopter_defaults`, `plan_tier`, `prose_discipline`, `longrun`, `testing`.
-
-Examples that qualify:
-
-- A skill that reads adopter stack metadata depends_on `[tech_stack]`
-- A skill that requires persona definitions depends_on `[personas]` (the `/personas` skill must have run)
-- A skill that reads adopter overrides depends_on `[adopter_defaults]` (the bassclef-configs block)
-
-When `depends_on:` is wrong, the skill silently produces empty output instead of telling the operator what is missing. INSTEAD of letting the skill discover its preconditions at runtime: declare them up front.
-
-## composes_with vs depends_on — picking one
-
-| If the relationship is... | Use |
-|---|---|
-| The current skill runs the other skill as a step | `composes_with:` |
-| The current skill extends or chains the other skill's output | `composes_with:` |
-| The current skill needs prior session state from another skill | `depends_on:` |
-| The current skill reads a config block at runtime | `depends_on:` |
-| The current skill assumes a rule is in force | `depends_on:` |
-
-INSTEAD of listing the same name in both fields: pick the relationship that fires first. A skill that both runs `/value-prop` AND needs `/personas` from a prior session declares `composes_with: [value-prop]` plus `depends_on: [personas]`.
-
-## What this rule does NOT cover
-
-- Source code patterns and design pattern annotations — see `.claude/rules/pattern-annotation.md`
-- Frontmatter schema fields other than these two — see `standards/frontmatter-schema.md`
-- Adopter onboarding wiring (which adopter-config blocks ship by default) — see `.claude/skills/onboard-repo/SKILL.md`
-- Layer 3 traceability manifests that auto-populate from declared values — Phase 4 of bet 2026-06-18a (WU-17/WU-18/WU-19 deferred follow-on)
-
-## Mechanical enforcement
-
-- `composes_with:` value type must be a YAML list of strings. A non-list type or a non-string item BLOCKs the write.
-- Each name in `composes_with:` must resolve to `<repo>/.claude/skills/<name>/SKILL.md`. A missing target BLOCKs.
-- Each name in `depends_on:` resolves against skills, rules, or known config blocks. A miss emits an ADVISORY notice and passes.
-- Substrate root for path resolution is derived from the file being written (everything before `/.claude/`).
-
-Hook: `.claude/hooks/substrate-clarity-gate.sh` (added in bassclef#862 WU-15).
-Tests: `.claude/hooks/tests/substrate-clarity-gate.test.sh` Tests 27–36.
-
-## Override
-
-`SKIP_SUBSTRATE_CLARITY=1 <command>` bypasses the validation and logs the override via trace-helper. INSTEAD of overriding when a target is genuinely missing: file the missing skill first, then add the composes_with entry.
-
-Override is appropriate when:
-
-- A migration script edits many skills at once and the target skill ships in the same PR
-- Emergency rescue when the hook itself is broken
-
-## Composes with
-
-- `.claude/rules/skill-description-clarity.md` — sister discipline at the frontmatter description surface
-- `.claude/rules/state-schema-validation.md` — sister mechanical check at the state-spine surface
-- `standards/frontmatter-schema.md` — full frontmatter field catalog
-
-## Refs
-
-- bassclef#862 Gap 3 — declared composition fields
-- WU-15 of `docs/iteration-bets/2026-06-18a-public-adopter-leverage-longrun.md` — ships this rule + hook extension
-- WU-3 of same bet (bassclef PR #1167) — frontmatter schema validation that recognized these fields
-- bassclef#1127 — tech_stack vocabulary; the first recognized config block
-- WU-17 / WU-18 / WU-19 (deferred) — Phase 4 manifests that read declared values to build forward/reverse lookups
-
-## Sources read
-
-- `.claude/hooks/substrate-clarity-gate.sh` — current validation passes
-- `standards/frontmatter-schema.md` — recognized field catalog
-- bassclef#862 issue body — WU-3 + WU-15 framing
-- `docs/iteration-bets/2026-06-18a-public-adopter-leverage-longrun.md` — goal doc with WU-15 spec
-
-## Retirement condition
-
-This rule retires when declared composition fields are no longer in the substrate vocabulary. The fields may evolve (Layer 3 manifests may read them differently) but the discipline of declaring relationships at the frontmatter surface persists.