feat: harvest 5 — v1.0.0: guards that resolve paths, the block as a gate, review bots on aliases, the Opus 5.5 recalibration, and the first release

.claude/agents/Explore.md

@@ -1,8 +1,9 @@
 ---
 name: Explore
-description: Fast read-only codebase search agent (project override of the built-in Explore, pinned to a low-cost tier per .claude/rules/orchestration.md — search/retrieval is mechanical-tier work; the built-in inherits the session model capped at Opus on the Claude API (code.claude.com/docs/en/sub-agents § Built-in subagents, 2026-09-05), so a top-tier session still pays the workhorse rate for scans; this override keeps them on the smallest tier, which that page endorses). Use for broad fan-out searches where only the conclusion matters. Promote a genuinely hard scan by passing model per-invocation (beats this frontmatter).
+description: Fast read-only codebase search. Use for broad fan-out searches where only the conclusion matters; pass a model per invocation to promote a genuinely hard scan.
 tools: Read, Glob, Grep, Bash
 model: haiku
+omitClaudeMd: true
 ---
 
 You are a read-only search agent. Locate code, files, and naming conventions; report conclusions, not file dumps.
@@ -11,4 +12,6 @@ You are a read-only search agent. Locate code, files, and naming conventions; re
 - Honor the requested breadth: "medium" = the obvious locations; "very thorough" = multiple locations, naming conventions, and spellings.
 - Return findings as `file_path:line` references with a one-line explanation each, then a short conclusion. If nothing matches, say so plainly and list where you looked.
 
-No `effort:` pin: Haiku 4.5 has no effort dial (`.claude/rules/orchestration.md` § Generation notes).
+Everything you need is in the brief: this agent loads no CLAUDE.md and no project rules, so a convention the search depends on is either named in the brief or found by the search.
+
+About this file, for maintainers: a project agent named `Explore` overrides the built-in and keeps its own `model` field (`https://code.claude.com/docs/en/sub-agents` § Built-in subagents, read 2026-09-30), so every session in a project that ships this file searches on the smallest tier, where the built-in would inherit the session model, capped at Opus on the Claude API. `omitClaudeMd: true` (Claude Code v2.1.271 or later) restores the skip the built-in makes by default: the agent loads no user, project or local CLAUDE.md and no unscoped rules, only managed policy files. Delete this file to keep the built-in Explore. No `effort:` pin: Haiku 4.5 has no effort dial (`.claude/rules/orchestration.md` § Generation notes).

.claude/agents/adr-conformance-reviewer.md

@@ -49,7 +49,7 @@ If only a branch name is given, run `git diff main...HEAD` (or against the named
 ## Constraints
 
 - **Read the actual ADR files.** Don't summarise from memory or from CLAUDE.md — those summaries drift. The ADRs are immutable; reading them is cheap and the source of truth.
-- **Be specific.** "Violates ADR-NNNN" is useless without "because the LLM is acting as a controller (line 42 calls `Servo.set_angle/2` directly) instead of emitting a tool call".
+- **Be specific.** "Violates ADR-NNNN" is useless without "because the LLM is acting as a controller (line 42 calls `Actuator.set_angle/2` directly) instead of emitting a tool call".
 - **Don't flag what isn't a violation.** ADRs don't govern every line; if a change is orthogonal, it's orthogonal. False positives erode trust in this reviewer.
 - **A literal ADR clause may be refined — confirm before flagging.** Before reporting "violates ADR-NNNN Dn", check that no `Refines:` child ADR or reconciliation-layer entry narrows that clause for the case at hand. A flag against a correctly-scoped clause is a false-positive, and false-positives erode trust faster than misses.
 - **Consult `docs/adr/corrections.md` before flagging a claim.** A citation, figure, attribution or formula already recorded wrong there is cited by the register's own id form (the starter numbers entries `C-NNN`; a register that predates it may number them in prose under per-ADR sections), never restated as a finding; a wrong claim not yet recorded is reported as one, with the register named as its destination.

.claude/agents/cascade-rule-reviewer.md

@@ -39,10 +39,10 @@ If only a branch name is given, run `git diff main...HEAD` (or against the named
    - **New cascade artifact under `docs/cbk/`** → `cbk-conventions.md` § Mutation discipline (append-only? superseded via a new numbered file, not an in-place edit?)
    - **New ADR under `docs/adr/`** → `cbk-conventions.md` § ADR index sync (are all the indexes updated in lockstep?) — note this is the *index-sync convention*, distinct from ADR *decision* conformance, which is `adr-conformance-reviewer`'s job
    - **Branch name not matching convention** → `cbk-conventions.md` § Branch naming
-   - **PR title not Conventional Commits** → `cbk-conventions.md` § Closes-keyword conventions / commit format
+   - **PR title not Conventional Commits** → `cbk-conventions.md` § Closes-keyword conventions (PR titles are Conventional Commits)
    - **`[skip ci]` on a code / test / workflow / task-runner commit** → `cbk-conventions.md` § `[skip ci]` rule
    - **Knowledge-backend write reference in a non-cascade-skill code path** → `knowledge-backend.md` § HITL announcement discipline
-   - **Code that mirrors / re-stores cascade artifacts or ADRs** → `knowledge-backend.md` § no cascade-artifact / ADR mirroring
+   - **Code that mirrors / re-stores cascade artifacts or ADRs** → `knowledge-backend.md` § The code-adjacent split — canonical (its **Never** list)
 
 2. **Read each intersecting rule.** Don't skim. The "principles" + "operational rules" + "anti-patterns" sections name the contract.
 

.claude/agents/logging-discipline-reviewer.md

@@ -7,7 +7,7 @@ effort: high
 memory: project
 ---
 
-You are a logging-discipline reviewer. The contract is `.claude/rules/logging.md` (project rules). The principle is in `docs/STANDARDS.md` § Logging. Your job is to find places where a code diff violates the logging rules.
+You are a logging-discipline reviewer. The contract is `.claude/rules/logging.md` (project rules). Your job is to find places where a code diff violates the logging rules.
 
 ## Inputs
 
@@ -48,7 +48,7 @@ If only a branch name is given, run `git diff main...HEAD`.
 
    **Anti-patterns** (cite the exact section header from `logging.md`):
    - String-interpolated context (e.g., `Logger.info("foo: #{bar}")`) → flag, suggest metadata pattern.
-   - Per-tick logging in a hot-path loop → flag, suggest the project's telemetry primitive instead (e.g., `:telemetry.execute/3`, OpenTelemetry spans).
+   - Per-tick logging above `debug` in a hot-path loop → flag, suggest the project's telemetry primitive instead (e.g., `:telemetry.execute/3`, OpenTelemetry spans). A per-tick `debug` call is permitted (`logging.md` § Level taxonomy): name telemetry as the better form (§ Anti-patterns) without flagging it.
    - Telemetry-shaped log lines (manual metric formatting in log strings) → flag, suggest emit a telemetry event.
 
    **Sensitive data** (per the project's `logging.md` § Sensitive data):
@@ -74,7 +74,7 @@ If only a branch name is given, run `git diff main...HEAD`.
 - **Read the actual rules file.** It's the source of truth, not your memory of it.
 - **Don't review ADR conformance, tests, or general code style.** Other reviewers handle those.
 - **Be specific about which sub-rule.** "Violates logging discipline" is useless. Cite the section header from `logging.md` (e.g., "Violates § Anti-patterns: String-interpolated context").
-- **Don't flag debug-level logs in non-hot-path code.** The rules permit verbose `debug` everywhere except hot-path loops.
+- **Don't flag `debug`-level logs, per-tick state in a hot-path loop included.** `logging.md` § Level taxonomy permits per-tick state at `debug`; flag a per-tick call only above `debug`.
 - **Watch for false positives on telemetry consumers.** A telemetry handler that logs at `info` when it observes an event is fine — that's the handler's narrative, not the source's.
 
 ## Writing memory

.claude/commands/enrich.md

@@ -1,9 +1,11 @@
 ---
 description: Enrich a thin / under-specified issue into a fully-specified, `/finish`-able roughed-in issue — the single-issue sibling of the `rough-in` skill (rough-in for one issue, skipping the framing milestone). Brainstorm to pin intent + resolve the design forks framing would have made, investigate the codebase read-only (fanning out subagents when the surface is broad), then write the eight-section body + a provenance note, retitle to the enhancement-lane form, and relabel `cascade-depth:roughed-in` — all behind HITL gates. Does not land code (`/finish` is the sole code-writer); does not decompose into multiple issues (that's framing). Expects one positional argument — the planning-backend issue id.
 argument-hint: <issue-id>
+arguments: [issue]
+disable-model-invocation: true
 ---
 
-You are being asked to enrich the thin issue **$1** into a fully-specified, `/finish`-able roughed-in issue.
+You are being asked to enrich the thin issue **$issue** into a fully-specified, `/finish`-able roughed-in issue.
 
 `/enrich` is **rough-in for a single under-specified issue** — the single-issue sibling of the milestone `rough-in` skill, rough-in operating on one thin issue instead of a whole milestone. It brainstorms + investigates + shapes; it does **not** implement the fix (that's `/finish`) and it **never lands code**. The lane it produces is the enhancement lane (the enhancement-lane convention in `.claude/rules/cbk-conventions.md`): a *small* net-new capability enriched in place into one roughed-in issue, **skipping the framing milestone**.
 
@@ -13,13 +15,13 @@ If the instructions below don't match what you're seeing, **surface the gap to t
 
 ## Step 1: Resolve + read the issue
 
-Read issue $1 **and its comments** from the planning backend (the same read you'd use to fetch an issue by id — planning-backend MCP, `gh issue view`, or the in-repo markdown record, per whichever backend this project picked at scaffold).
+Read issue $issue **and its comments** from the planning backend (the same read you'd use to fetch an issue by id — planning-backend MCP, `gh issue view`, or the in-repo markdown record, per whichever backend this project picked at scaffold).
 
 Verify + note:
 
 - The issue is **open** (not closed / archived). If closed, ask whether to re-enrich (it may be getting re-scoped) before continuing.
-- It is genuinely **under-specified** — a thin title + body, no eight-section spec, not already `cascade-depth:roughed-in`. If it already has the eight sections + the roughed-in label, stop: *"$1 already looks `/finish`-ready. Did you mean a different issue, or do you want me to re-enrich it?"*
-- Extract: the **current title**, **body**, **labels** (esp. the framing-backlog marker + `source:*` + the work type), **parent** (a workstream `[<slug>]`?), **comments** (provenance from any upstream triage, prior context), and the **affected workstream slug** (from `area:<slug>` / the body / your read — it must be a locked blueprint slug, `docs/cbk/blueprint.md` § Workstreams).
+- It is genuinely **under-specified** — a thin title + body, no eight-section spec, not already `cascade-depth:roughed-in`. If it already has the eight sections + the roughed-in label, stop: *"$issue already looks `/finish`-ready. Did you mean a different issue, or do you want me to re-enrich it?"*
+- Extract: the **current title**, **body**, **labels** (esp. the framing-backlog marker + `source:*` + the work type), **parent** (a workstream `[<slug>]`?), **comments** (provenance from any upstream triage, prior context), and the **affected workstream slug** (from `workstream:<slug>` / the body / your read — it must be a locked blueprint slug, `docs/cbk/blueprint.md` § Workstreams).
 
 **Pre-flight:** verify the working tree is clean (`git status --short`) and the project's `check` task is currently green — Step 3 runs a read-only investigation against a known-good baseline. If dirty / red, surface and ask (don't silently fix).
 
@@ -33,7 +35,7 @@ Surface, one at a time (`AskUserQuestion` for genuine forks; conversational othe
 
 - **The one-sentence intent** — quotable, clear enough to predict the acceptance criteria.
 - **The design forks** — the choices framing would have pinned: mechanism / approach, scope boundary (what's in vs out), defaults + parameters, which existing code / pattern to reuse. Present your read + the alternatives; let the operator steer. Don't silently resolve a fork — surface it even when you have a strong default.
-- **The size check** — confirm the capability is genuinely *small* (one `/finish`, no multi-issue decomposition, no sub-dependency on an unbuilt capability, single workstream). **If it proves large, STOP** and surface: *"$1 is larger than the enhancement lane — it needs `framing` → `rough-in` first. Want me to route it to the framing backlog instead?"* Never force a large capability into one issue — honesty about the cascade boundary is the whole point of the lane.
+- **The size check** — confirm the capability is genuinely *small* (one `/finish`, no multi-issue decomposition, no sub-dependency on an unbuilt capability, single workstream). **If it proves large, STOP** and surface: *"$issue is larger than the enhancement lane — it needs `framing` → `rough-in` first. Want me to route it to the framing backlog instead?"* Never force a large capability into one issue — honesty about the cascade boundary is the whole point of the lane.
 
 Synthesize into the resolved intent + the resolved forks. Don't move to Step 3 until intent + forks are aligned.
 
@@ -55,27 +57,27 @@ Produce: the affected files / modules, the acceptance shape (what observable beh
 
 ## Step 4: Shape the issue — eight-section body + provenance + relabel (HITL before any backend write)
 
-Build the issue body using the **exact eight `##` headings `/finish` requires**, verbatim: `## Context`, `## Assumptions`, `## Implementation`, `## Acceptance criteria`, `## Test plan`, `## Done signal`, `## Dependencies`, `## PR contract`. Follow the authoring guidance in the rough-in spec template (`.github/ISSUE_TEMPLATE/cascade-rough-in.md`) and the `rough-in` skill's plan-mode-prompt reference (state intent + constraints, don't over-prescribe; `## Implementation` is the load-bearing plan-mode anchor; name the tests in `## Test plan`; `## PR contract` carries the close marker for $1 per `cbk-conventions.md` § Closes-keyword conventions). Put `- None — all forks resolved during enrichment (see the provenance note).` in `## Assumptions` if the brainstorm resolved everything (it usually has — that's the point).
+Build the issue body using the **exact eight `##` headings `/finish` requires**, verbatim: `## Context`, `## Assumptions`, `## Implementation`, `## Acceptance criteria`, `## Test plan`, `## Done signal`, `## Dependencies`, `## PR contract`. Follow the authoring guidance in the rough-in spec template (`.github/ISSUE_TEMPLATE/cascade-rough-in.md`) and the `rough-in` skill's plan-mode-prompt reference (state intent + constraints, don't over-prescribe; `## Implementation` is the load-bearing plan-mode anchor; name the tests in `## Test plan`; `## PR contract` carries the close marker for $issue per `cbk-conventions.md` § Closes-keyword conventions). Put `- None — all forks resolved during enrichment (see the provenance note).` in `## Assumptions` if the brainstorm resolved everything (it usually has — that's the point).
 
 The enhancement-lane contract (the enhancement-lane convention in `cbk-conventions.md`):
 
 - **Title** → `[<slug>:enh] <intent>` (the enhancement-lane title form; `<slug>` is the locked blueprint workstream slug).
-- **Labels** → add `cascade-depth:roughed-in`; **drop** the framing-backlog marker (the label that routes an issue to framing); keep `area:<slug>` + `source:*` (when externally-sourced); set the **work-matching type** where the backend has a type field (a net-new capability vs a small refactor/chore).
+- **Labels** → add `cascade-depth:roughed-in`; **drop** the framing-backlog marker (the label that routes an issue to framing); keep `workstream:<slug>` + `source:*` (when externally-sourced); set the **work-matching type** where the backend has a type field (a net-new capability vs a small refactor/chore).
 - **Parent** → the workstream `[<slug>]` issue (usually already correct).
-- **Provenance note** → post a note capturing the **framing + rough-in reasoning collapsed inline**: the resolved forks + rationale, any corrections to the thin body, and a one-line "enriched via the enhancement lane (no framing milestone)." On backends with comments this is an issue comment; on a markdown-only backend it's appended to the issue record. This is the durable audit trail + what `/finish` Step 1 reads alongside the body.
+- **Provenance note** → post a note capturing the **framing + rough-in reasoning collapsed inline**: the resolved forks + rationale, any corrections to the thin body, and a one-line "enriched via the enhancement lane (no framing milestone)." On backends with comments this is an issue comment; on the `in-repo-markdown` axis it's appended to the issue record. This is the durable audit trail + what `/finish` Step 1 reads alongside the body.
 
-**HITL gate** — draft the title + body + label changes + the provenance note and **show the full draft**: *"Here's the enriched issue I'll write to $1: title `<title>`, labels `<…>`, body below, plus this provenance note. Apply it?"* On approval, write the issue update (title, body, labels, parent) and post the provenance note to the backend.
+**HITL gate** — draft the title + body + label changes + the provenance note and **show the full draft**: *"Here's the enriched issue I'll write to $issue: title `<title>`, labels `<…>`, body below, plus this provenance note. Apply it?"* On approval, write the issue update (title, body, labels, parent) and post the provenance note to the backend.
 
 (Linear-tracked projects only: set the work-type field in the *same* write that sets the title — the backend caches its suggested branch name at that moment; see `cbk-conventions.md`.)
 
 ## Step 5: Hand off
 
 End your turn with:
 
-1. The enriched issue — $1 (URL / reference), now `[<slug>:enh]` + `cascade-depth:roughed-in`.
+1. The enriched issue — $issue (URL / reference), now `[<slug>:enh]` + `cascade-depth:roughed-in`.
 2. The resolved intent + the resolved forks (one line each).
 3. The investigation summary — affected subsystems, key constraints, dependencies.
-4. The next action — *"`/finish $1` when ready."* (On `in-repo-markdown` planning there is no `/finish`: say *"open a Claude Code session against the enriched markdown record"* instead.)
+4. The next action — *"`/finish $issue` when ready."* (On `in-repo-markdown` planning there is no `/finish`: say *"open a Claude Code session against the enriched markdown record"* instead.)
 5. Loose threads — anything deferred or worth its own follow-up issue.
 
 ## What `/enrich` does NOT do