Craft Fleet

# Craft Fleet

> Ceiling-raising code-quality elevation sweep across the standing codebase — compose the eleven `-craft` skills into ranked `(scope, domain)` targets, confirm one batch in a single up-front round that carries a **taste-calibration sample of verbatim findings**, fan out worktree-isolated subagents that each run the **real** `harness-refactoring` pipeline over one target's cited findings, admit nothing that lacks a cited craft finding and that a re-critique cannot show as **net better**, and hand back a **tiered** batch of elevation PRs and filed roadmap items for one bulk review. The fleet never auto-merges and never trusts a subagent's self-report.

The harness has a complete **floor** and no way to harvest its **ceiling** at batch scale. `cleanup-fleet` works the rule-based entropy queue — dead code, drift, structural risk in high-churn areas. `bug-fleet` hunts latent defects behind a reproduction bar. `test-fleet` chases coverage gaps. Every one of them acts on findings a machine can prove. Meanwhile the eleven `-craft` skills — `naming-craft`, `code-craft`, `copy-craft`, `test-craft`, `spec-craft`, `docs-craft`, `knowledge-craft`, `api-craft`, `cli-ergonomics-craft`, `security-craft`, `harness-design-craft` — encode the taste that says whether working code is any _good_, and they are invoked one file at a time, by a human who already suspected something was mediocre. The judgment exists; nothing sweeps with it.

`craft-fleet` is the **ceiling twin of `cleanup-fleet`**: it sweeps with the craft skills, ranks what they find, and hands back a **tiered** batch — bounded, high-confidence polish as elevation PRs, larger structural quality debt filed as roadmap items for the normal pipeline to build later. The restraint in that split is the design, not a shortfall of it. Craft findings are advisory LLM judgment **by design**, so a fleet that autonomously rewrites subjective "low quality" across a codebase produces churn, style-thrash, and bulk PRs that are miserable to review — it would spend the human's attention rather than save it, which inverts the entire point of the family. This member therefore leans **file-don't-rewrite** for anything structural, reserves direct PRs for safe, bounded, high-confidence polish, and strengthens the human-taste gate beyond every sibling's. It is a **quality-queue** member of the `-fleet` family: it does not sit on the core intake → decide → build → land spine, but works the craft-finding queue alongside it, exactly as `cleanup-fleet` works the entropy queue it mirrors.

This skill builds on the shared `-fleet` spine documented in `docs/reference/fleet-family.md` — the five-phase SELECT → CONFIRM → DISPATCH → VERIFY → terminal skeleton, the concurrency governor, the artifact + all-OS-CI verification discipline, the worktree fan-out with its nested-path push caveat, the front-load / park-unforeseen interaction model, and the never-silent-merge invariant. The family ADRs cited there — _Subagent worktree fan-out (vs the Workflow primitive) for `-fleet` execution_ and _The front-load / park-unforeseen interaction model for the `-fleet` family_ — state that contract once for the family, and the craft skills' shared _3-axis (tier × impact × confidence) output model_ supplies the finding vocabulary this skill consumes without extending. This SKILL.md defines only what is `craft-fleet`'s own: its queue, its elevate-vs-file taxonomy, its cited-and-net-better verification, its tiered dual terminal act, and its domain-specific rationalizations.

## When to Use

- Sweeping a codebase with the craft skills at batch scale, where per-file critique does not scale and the human's attention is the bottleneck
- Turning an existing craft-skill inventory into **delivered** elevation, rather than a standing list of things that could be better
- When the targets are genuinely independent — each is one coherent scope paired with one craft domain, elevated in its own worktree, and one target's polish does not depend on another's merge
- When the output must be trustworthy enough to review in bulk: every item arrives carrying the cited craft finding that produced it, so the reviewer judges taste rather than re-deriving it
- NOT for critiquing a single file — invoke the craft skill directly; a fleet's overhead only pays off across a batch
- NOT for rule-based entropy, dead code, or structural drift — that queue is `cleanup-fleet`'s, and it is objective where this one is advisory
- NOT for latent correctness defects — that is `bug-fleet`; a craft finding that turns out to be a real bug is **routed**, never fixed here
- NOT for coverage gaps — closing them is `test-fleet`; `craft-fleet` critiques the quality of the tests that exist, it does not author the ones that are missing
- NOT for landing or merging PRs — that is `pr-fleet`; `craft-fleet` stops at reviewable and never merges
- NOT for applying a security fix — a `security-craft` finding is never elevated by this fleet, and a genuine vulnerability is routed privately to the human rather than patched
- NOT for converging one target to clean — iterating a single module until it is good is a **pipeline**, not a fleet (which fans out across many independent targets into many outcomes)

## Capability Roles

<!-- Capability seam: this skill participates in a real extension point whose three roles are named and concrete. A seam with only one role filled is accidental single-implementation lock-in. See harness-skill-authoring Phase 1C. -->

- **Defines (Service Definition):** the shared LLM-judgment-critique contract in `packages/cli/src/shared/craft/` — the `LlmProvider` interface (`llm/provider.ts` / `llm/contracts.ts`) plus the shared finding/axes schema (`findings/axes.ts`) and run store (`runs/store.ts`) — that every `*-craft` skill's critique phase conforms to. craft-fleet consumes this contract; it does not own it.
- **Provides (Provider):** the eleven craft skills — `naming-craft`, `spec-craft`, `code-craft`, `security-craft`, `test-craft`, `api-craft`, `cli-ergonomics-craft`, `copy-craft`, `docs-craft`, `harness-design-craft`, `knowledge-craft`.
- **Consumes (Consumer):** **this skill** — craft-fleet composes ranked (scope, domain) targets across all craft providers uniformly through the shared critique/finding shape, then verifies each item by critique provenance. It is itself a `-fleet` member and so is also a Provider to the `fleet-command` conductor.

## Flags

| Flag            | Effect                                                                                                                                                 |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `--concurrency` | Cap concurrent elevation subagents (default 2, max recommended 3 — the machine-storm limit)                                                            |
| `--domains`     | Restrict the sweep to a comma-separated subset of the craft domains; the enabled set is confirmed at CONFIRM either way                                |
| `--report-only` | Compose the critique, rank the targets, and present the batch with its taste-calibration sample; do not dispatch elevations or file items              |
| `--dry-run`     | Run SELECT and CONFIRM only; stop before fan-out — nothing is verified, filed, or opened as a PR                                                       |
| `--file-only`   | Open no elevation PR: every `elevate` target converts its budgeted elevation slot into a filed item carrying its cited finding, so the caps still hold |

## Process

### Iron Law

**CITED-AND-NET-BETTER — no line is rewritten without a cited craft finding (a `runId` + `rubricId` + location from an actual craft-skill run), and nothing is emitted that a re-critique does not show as net better. The fleet never auto-applies a structural, contract-touching, or cross-module change, never elevates a prose file or a published contract, never publishes a routed security vulnerability, and never accepts a subagent's self-report as proof its pipeline ran.**

The craft skills are advisory **by design** — they emit judgment carrying a visible confidence axis precisely because their findings are not binary — so a fleet built on them must not convert advice into authority. The cite is the ceiling analogue of a reproduction: it is the one piece of evidence that cannot be produced by asserting it. Confident prose explaining why a rewrite is better reads exactly like confident prose explaining why a rewrite that is worse is better; a `runId` and a `rubricId` either point at a real catalog run at a real location or they do not.

The second half of the law does the work the first cannot. A cite proves the location was worth looking at; it says nothing about whether the rewrite improved it. Only a re-critique of the changed code can distinguish elevation from style-thrash — swapping one finding for another is motion, not progress. And keeping the elevate boundary **mechanical** — high confidence, bounded, behavior-preserving, on an eligible surface — is what stops the whole thing degrading into "this rewrite felt safe," which is precisely how a taste-driven fleet becomes a churn engine.

The corollary matters as much as the law. **A quiet target is a valid, valuable result.** A target whose critique yields nothing above the noise floor tells the human where the ceiling has already been reached, and that is worth knowing. The pressure to manufacture an elevation so a sweep does not look wasted is the exact failure mode a subjective-judgment fleet must design against: there is no reproduction to fail here and no detector to stay red, so nothing but this rule stands between a thin batch and an invented one.

```
Phase 1: SELECT --> Phase 2: CONFIRM --> Phase 3: DISPATCH
                                                    |
                                                    v
             Phase 5: FILE-AND-REPORT <-- Phase 4: VERIFY
```

| Phase              | Purpose                                                                                                  | Exit Condition                                                                         |
| ------------------ | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| 1. SELECT          | Compose the craft skills into ranked `(scope, domain)` targets                                           | Ranked `Target[]` with routing verdicts, cross-check results, and floor/cap counts     |
| 2. CONFIRM         | One human round: domains, batch, taste sample, floor, caps, governor, pinned base SHA                    | Approved batch with a pinned base SHA and confirmed domains, floor, and caps           |
| 3. DISPATCH        | Subagents run the real `harness-refactoring` over one target's cited findings                            | Every elevate target returned a branch, downgraded, parked, or failed (all recorded)   |
| 4. VERIFY          | Elevations: critique + elevation provenance, two-run re-critique, all-OS CI; filings: cite + cross-check | Each item marked verified-elevation / verified-filing / routed / downgraded / rejected |
| 5. FILE-AND-REPORT | Tiered dual terminal act, batch summary                                                                  | Report delivered; nothing merged                                                       |

### Phase 1: SELECT — Compose the Craft Skills, Floor, Route, Rank

1. **Compose the enabled craft skills — reimplement no critique.** Run them over the repository. They already discover their own corpora and emit structured findings, each carrying a `cite.rubricId`, under a `runId` reported once per run in the run summary. A finding's cite is therefore **composed** — the run's `runId` paired with that finding's `rubricId` and location — rather than read off the finding alone. The fleet's job here is composition and ranking, not detection: it never re-derives a rubric, never invents a finding, and never restates a critique in its own words.

   A missing or erroring craft skill **degrades to the remaining ones and is recorded** in the batch summary, never aborting the batch. If no craft skill is available, stop and report — there is nothing to rank.

2. **Fold the findings into targets.** A **target** is one coherent scope — a module, a doc set, a spec set — paired with **exactly one craft domain**. That pairing is not bookkeeping: it is what makes the terminal act's one-PR-per-target rule mean "never two craft domains in one PR," which is the property that keeps bulk taste review tractable. Two domains over the same scope are two targets.

3. **Apply the noise floor.** Drop, count, and never file or elevate any finding whose `impact` is `small` **and** which is additionally either `tier: aspirational` **or** `confidence: low` — that is, `small` ∧ (`aspirational` ∨ `low`). The grouping is stated explicitly because the rule must not be read as (`small` ∧ `aspirational`) ∨ `low`: a `large`-impact, `low`-confidence finding is exactly the kind of observation worth filing, and the wrong reading would silently discard it. Dropped findings are **counted and reported**, never silently discarded.

4. **Cross-check every target.** Search open elevation PRs and already-filed quality items for one that already addresses this target. An already-addressed target is **dropped and annotated citing the resolving PR or item**, never re-elevated. A fleet whose output is half duplicates costs more attention than it saves, by exactly the route its noise floor was meant to close.

5. **Route every survivor mechanically** — on the finding's own axes plus a surface rule, never on how bad the finding feels:
   - **`elevate`** (a direct PR) requires **all** of: `confidence: high`; the change is confined to one target and is behavior-preserving; no public-API, observable-contract, or exported-identifier change; no cross-module reach; and the finding's surface is on the **elevation-eligible list** for its domain — see _Elevation Eligibility_ below.
   - **`file`** (a roadmap item) — everything else above the floor: any structural change, any contract-touching change, any `medium`- or `low`-confidence finding, and every finding in a file-only domain.
   - **`route`** — the finding is really a correctness defect or a genuine security vulnerability. Routing is **park-and-hand-back, not a new mechanism**: the item is neither elevated nor filed by this fleet, and it surfaces in the batch report for the human to place.

   **Route per finding, then re-form the targets by verdict.** The routing rules read a finding, not a target, so a `(scope, domain)` pair whose findings split across verdicts never becomes a mixed target. It yields **at most one `elevate` target and at most one `file` item** for that same scope and domain, each carrying **only its own findings**; routed findings leave the pair entirely and are parked. That re-forming is what makes every downstream unit unambiguous — DISPATCH runs over one `elevate` target's findings plural, and VERIFY assigns exactly one verdict per emitted item. It also fixes the accounting: **the caps count emitted items — elevation PRs and filed items — never findings.**

6. **Enforce the caps after ranking.** Default **20 filed items and 20 elevation PRs** per batch, hard — counted in **emitted items**, per the re-forming rule above. The cap keeps the highest tier × impact and drops the rest **as over-cap, reported with its count** — never silently. The caps bound **SELECT-time intake**, so a target that later downgrades from `elevate` to `file` **converts an already-budgeted elevation slot** rather than adding new intake; a batch therefore never hands back more than the two caps together allow, whatever happens downstream.

   **The cap, not the floor, is the real guard.** Filing opens a tracking issue per item, so an uncapped sweep is a tracker flood no five-cell floor rule can prevent: the surviving `medium`-confidence middle of the distribution is large and legitimately routes to `file`. The floor removes the obvious tail cheaply; claiming it prevents backlog spam would be overselling a five-cell rule against a twenty-seven-cell distribution.

7. **Score and order by tier × impact.** Reuse `harness-roadmap-pilot`-style impact scoring so the ordering is principled and reproducible rather than a matter of which finding read most sharply. `confidence` is the **routing** axis and is deliberately **not** folded into the score. The 3-axis output model exists precisely because collapsing these axes destroys the information a reviewer needs to prioritize — a fleet that invented a second severity vocabulary would be re-collapsing them, and would drift from the catalogs it consumes.

8. **Build the `Target` record** for each survivor:

   ```
   Target {
     domain,      // exactly one craft domain
     id,          // target slug
     scope,       // the files / docs / specs it covers
     findings,    // each: runId, rubricId, location, tier, impact, confidence
     score,       // composite tier x impact
     verdict,     // "elevate" | "file" — uniform, per the re-forming rule
     crossCheck,  // "novel" | "already-addressed" + resolving PR/item
     forks,       // detected decision forks to surface at CONFIRM (may be empty)
   }
   ```

   And the `Batch` record that scopes the whole run, settled once at CONFIRM:

   ```
   Batch {
     domains,     // the enabled craft domains
     baseSha,     // the pinned base SHA every target works against
     floor,       // the confirmed noise floor
     caps,        // the confirmed per-batch caps { elevate, file }
     governor,    // the confirmed concurrency (default 2, max ~3)
     targets,     // the confirmed targets, each with its verdict
   }
   ```

### Phase 2: CONFIRM — The Single Up-Front Human Gate `[checkpoint:human-verify]`

1. **Present the whole batch in one round.** This is the **only guaranteed human touchpoint before batch review** — everything downstream runs autonomously. Present, together, in a single surface:
   - The **enabled craft domains** — which of the eleven ran at all, so the human can switch a domain off before it costs a single elevation.
   - The **ranked targets**, highest score first, each with its `elevate` / `file` split and its score basis: the tier and impact that ranked it, and the routing call that split it.
   - The **taste-calibration sample** — a handful of **real, verbatim findings**, elevation and file alike, drawn from the actual critique run rather than paraphrased or summarized.
   - The **noise floor** with its drop count, and the **per-batch caps** with the over-cap count they shed. Both are re-tunable here, once.
   - The **proposed concurrency** (default 2, capped at ~3).
   - The **pinned base SHA** the whole batch works against. The SELECT critique run is pinned to it so VERIFY's branch re-critique is a like-for-like comparison rather than a moving target across a multi-hour batch, and so the green-baseline precondition the elevation pipeline requires is evaluated once for the batch instead of drifting per target.

2. **Why the sample, and why here.** Every sibling's CONFIRM presents a ranked batch; this one additionally presents verbatim findings, because **taste does not generalize**. Counts tell a human how much work is proposed; only a sample tells them whether this sweep's taste matches theirs, and that is the question on which the whole batch's value turns. It is also the cheapest possible place to discover a mismatch: disagreeing with the sample costs one conversation before fan-out, while discovering the same mismatch at review costs a batch of PRs plus all the machine time that produced them.

3. **The human approves, trims, disables domains, or re-tunes the floor — once.** Batch approval, domain selection, the floor, and the caps all settle in this same gate. Front-loading the genuinely-ambiguous calls is what keeps the autonomous stretch from producing work the human would have declined. A domain the human switches off runs nowhere downstream; a floor the human raises applies to the whole batch.

4. **From here it is autonomous.** After this gate the fleet does not pause per target. The only thing that re-surfaces before FILE-AND-REPORT is a target that hits a genuinely-unforeseen fork mid-flight, and that parks only that one target without blocking the batch. Under `--dry-run` the skill stops at the end of this phase; under `--report-only` it presents this surface and stops without dispatching, verifying, or filing.

### Phase 3: DISPATCH — Worktree Fan-Out With a Concurrency Governor

1. **One worktree-isolated subagent per confirmed `elevate` target.** `file` targets require no fan-out at all — their critique is already complete and their terminal act is a filing, so dispatching them would spend machine time to produce nothing new.

2. **Each subagent runs the real `harness-refactoring` pipeline** over its one target's cited findings: tests green before and after **every** change, `harness validate` plus `harness check-deps` per step, blast radius computed up front, **one small change per commit**, and that skill's own revert-if-the-refactoring-introduced-no-improvement rule. The subagent does not hand-edit and does not short-cut the pipeline — the step-granular commit trail the pipeline necessarily leaves behind is exactly what VERIFY checks for.

   The anti-churn discipline this fleet needs is therefore **already law inside the skill it composes**, rather than a policy layered on top of a free-hand editor. Composing that skill also inherits its precondition, which is broader than the suite alone: it refuses to run against a failing suite **and** requires a baseline `harness validate` and `harness check-deps` that both pass before the first step. Elevation therefore assumes a **clean baseline at the pinned base SHA** on all three.

3. **The subagent runs no re-critique.** That proof belongs to VERIFY and to VERIFY alone. The subagent's job ends at pushing a branch that carries its commit trail and its cited findings; anything it concluded about its own work is a claim, and a claim is not what the fleet's verdicts rest on.

4. **Downgrade rules.** A target whose elevation turns out to need a **structural** change — cross-module reach, a contract or exported-identifier change, a module split, an abstraction redesign — **downgrades itself to `file` and reports**, rather than applying it. A target whose **baseline is not clean** at the pinned base — a red suite, or a failing `harness validate`, or a failing `harness check-deps` — takes the same path, since those three checks together are the elevation pipeline's entire safety net. A downgrade is a **normal outcome, not a failure**: the critique remains valid and still reaches the human as a filed item; only the autonomous rewrite is withheld.

5. **Cap concurrency at the confirmed governor (default 2, max ~3)** and at the per-batch caps. This is the machine-storm limit: beyond roughly three concurrent elevation agents the compound load produces flaky failures indistinguishable from real ones — and in a fleet whose net-improvement proof is an already-noisy oracle, manufactured noise on top of it is uniquely corrosive. Never raise the cap to "go faster."

6. **Record an "assumptions made" note per target** — the ranking basis it worked from, the routing call it inherited, the elevation scope it actually took, and what it deliberately left un-elevated. Bulk taste review is only trustworthy when the reviewer can see what was assumed and what was consciously not touched.

7. **Park the unforeseen.** A target that hits a genuinely-unforeseen fork — the scope turns out to span two domains, a cited location no longer exists at the pinned base, the finding contradicts another the same run produced — **parks that one target and reports it**. The rest of the batch continues uninterrupted.

8. **Push-path caveat.** A worktree created under a nested agent-config path breaks the local pre-push documentation gate: it self-excludes and scans zero files. Subagents push via the GitHub API or from a non-nested throwaway worktree. **Never `--no-verify`** — bypassing the gate defeats the verification the fleet's guarantees rest on.

### Elevation Eligibility — Only a Surface the Test Suite Guards

The whole safety envelope of the elevation pipeline is the test suite plus `harness check-deps`: those are what make "behavior-preserving" a checkable claim rather than an assertion. That yields **one rule, not eleven judgment calls** — a surface is elevation-eligible only if it lives inside **source the test suite exercises**. The single exception is narrower, not looser: test files are the suite rather than exercised by it, so they qualify only under the assertion-freeze rule stated below the table.

| Craft domain           | Elevation-eligible surface                                                           | Otherwise    |
| ---------------------- | ------------------------------------------------------------------------------------ | ------------ |
| `naming-craft`         | Non-exported local identifiers only                                                  | file         |
| `code-craft`           | Within-unit simplification and control-flow honesty, signature unchanged             | file         |
| `copy-craft`           | **Internal-facing prose only** — code comments and internal log lines                | file         |
| `test-craft`           | Test names and test-body clarity, **every assertion expression byte-identical**      | file         |
| `docs-craft`           | Nothing — prose has no test suite to guard it                                        | file         |
| `knowledge-craft`      | Nothing — prose has no test suite to guard it                                        | file         |
| `spec-craft`           | Nothing — prose has no test suite to guard it; a ratified ADR is never edited at all | file         |
| `harness-design-craft` | Nothing — no craft-driven write path exists                                          | file         |
| `api-craft`            | Nothing — every surface it critiques is a published contract                         | file         |
| `cli-ergonomics-craft` | Nothing — every surface it critiques is a published contract                         | file         |
| `security-craft`       | Nothing — **never elevated**                                                         | file / route |

Four of eleven domains clear the bar. The other seven are file-only, and each for a stated reason rather than caution in general.

**The prose domains are cut deliberately** — `docs-craft`, `knowledge-craft`, and `spec-craft` are the tempting case, because prose looks like the safest thing in a repository to improve. It is the opposite. No skill in the toolset applies prose-quality edits under a safety envelope, so elevating prose would mean free-hand rewriting text with **no mechanical check that it did not make things worse** — which is precisely the churn this member exists to avoid, dressed as the easy win. A **ratified ADR is additionally out of bounds on its own terms**: it is a historical record of a decision, not a document to be improved, and editing one rewrites the past.

**Published contracts are never elevated.** `api-craft` and `cli-ergonomics-craft` critique published contracts by definition, so renaming a flag or an endpoint is a breaking change wearing a quality argument. **`security-craft` is never auto-applied**, because a wrong "improvement" to security posture is worse than the mediocrity it replaced, and posture is exactly the kind of judgment whose failure mode is silent. **`harness-design-craft` has no reachable write path** — its own polish phase emits before-and-after sketches and never modifies source, and the rule-based design-drift remediation path consumes drift findings that carry no craft `runId` or `rubricId`, so wiring it in would require inventing the finding translation the Iron Law exists to forbid.

**`copy-craft`'s narrowing establishes the general principle: routing follows the surface, not the skill that surfaced the finding.** An error message and a CLI output string are the same bytes on the user's screen whether `copy-craft` or `cli-ergonomics-craft` found them, so they get the same treatment — **filed**, because user-facing output is an observable contract and no contract-touching change is ever elevated regardless of which domain raised it. What stays eligible is genuinely internal: **code comments**, which cannot alter behavior at all and are therefore the safest edit in the repository, and **internal log lines**, which are diagnostic output no consumer depends on. This shrinks the elevation surface; that is the direction this member is designed to err in.

**`test-craft`'s narrowing breaks a circularity.** The elevation pipeline proves behavior preservation **with** the test suite, so elevating tests is circular unless the change provably cannot alter what the suite checks. The rule that breaks the circle is mechanical: every assertion expression must be **byte-identical** before and after, the **passing-test count must be unchanged**, and the set of passing test IDs may differ **only by the renames the elevation itself applied** — a rename changes a test's ID by construction, so freezing the ID set outright would forbid the very change this row exists to permit. Renaming a test or clarifying its arrange/act body qualifies. **Sharpening an assertion does not**: that changes what is asserted, which is a real improvement and a `file`, not an elevation.

**Worker handoff — return the canonical `FleetHandoffRecord`.** When a worker finishes its target it hands the orchestrator exactly one `FleetHandoffRecord` (from `@harness-engineering/types`) — the ONE bounded envelope every `-fleet` member emits, so `fleet-command` parses any fleet's worker output uniformly instead of special-casing an ad hoc per-worker report shape. The record carries `status` (`done | parked | blocked | failed`), `fleet`, `item`, a one-line `summary`, an `evidence[]` of verifiable pointers (branch, PR, artifact path, CI check — exactly the references VERIFY re-checks), `next_steps[]`, and, for any non-`done` status, a `blocker`. The orchestrator validates it with `validateFleetHandoffRecord`; a malformed or unknown-keyed record is rejected, never silently misread. See the canonical handoff record in `docs/reference/fleet-family.md`.

### Phase 4: VERIFY — Three Independent Proofs, Never Self-Report

1. **Why three proofs and not one.** No single artifact covers this fleet's two distinct risks. One risk is an agent applying **its own taste** — a change no critique asked for, which a clean commit trail and a green suite would both wave through. The other is an elevation that makes things **worse** — a change a real finding did ask for, applied so that it trades the cited problem for a new one, which a cite and a trail would in turn both wave through. Each proof closes what the others leave open, so VERIFY checks all three, independently, for **every elevation** — the `file` tier is verified here too, but to the narrower standard stated below, because it never produced a branch to check. **Never accept a subagent's self-report**: "cited it, elevated it, re-critiqued it clean" is a claim to be checked, not a result.

2. **Critique provenance — the change was asked for.** Every changed location maps to a cited finding from a real craft-skill run (`runId` + `rubricId` + location). A changed location that maps to no finding is **the orchestrator's own taste and is rejected, however good it looks**. That last clause is load-bearing: a taste-driven fleet's most attractive failure is the improvement nobody requested, and it is attractive precisely because it does look good.

3. **Elevation provenance — the real pipeline ran.** Confirm the step-granular `harness-refactoring` commit trail on the branch: one small change per commit, suite green throughout. **Absent trail = the real pipeline did not run = rejected**, however well the final diff reads. A hand-applied patch that happens to match a cited finding proves nothing about the safety envelope it skipped.

4. **Net-improvement evidence — the change helped.** Re-run **the same craft skill** over the changed scope on the branch and require both halves: the cited findings are **resolved**, _and_ **no new finding at equal-or-higher tier was introduced**. Tier ordering is the craft catalogs' own — `foundational` outranks `polish`, which outranks `aspirational` — so "equal-or-higher" is evaluated mechanically rather than by feel. **A re-critique that trades one finding for another is style-thrash, not elevation**, and it does not ship.

5. **The oracle is non-deterministic, and the protocol says so.** A re-critique is an LLM call: two runs over identical code can disagree, so a single run can both falsely reject a good elevation and falsely accept a bad one. The answer is a **two-run protocol biased conservative on both sides**:
   - A cited finding counts as **resolved only if it is absent from both runs**. Unanimity is required to credit an improvement.
   - A new equal-or-higher-tier finding **blocks if it appears in either run**. One sighting of a regression is enough to stop shipping the rewrite.
   - When the two runs **disagree**, the elevation is **not proven** — but the underlying critique is still valid, so the item **downgrades to `file`** rather than being discarded. Nothing is lost; only the autonomous rewrite is withheld.

   A re-critique that **cannot run at all** — no provider configured, a budget-exceeded prompt collection, an erroring skill — is a different case with a deliberately different outcome. It produces **no proof**, so by the same rule that rejects a missing commit trail the item is **rejected and retried once**, an unavailable provider usually being transient. The distinction is not fussiness: a re-critique that never ran leaves nothing to re-examine, while one that ran and split has already produced its reading — enough to justify filing the critique, never enough to justify shipping the rewrite.

   Two runs rather than three is a deliberate cost call — craft skills bill per LLM call and this fleet runs eleven of them across a repository — and downgrade-not-discard is what makes the cheaper protocol safe: **an inconclusive oracle costs the batch a filed item, never a bad merge.**

6. **VERIFY owns both runs; the DISPATCH subagent runs none.** A subagent that re-critiques its own branch and reports the outcome leaves the orchestrator reading a **claim** rather than checking a **proof** — exactly what the family's never-self-report invariant forbids. Having both the subagent and VERIFY re-run would satisfy the invariant at four runs per item. Concentrating both runs here keeps the total at **two** _and_ makes them independent, so the cost argument and the invariant are satisfied by the same choice instead of traded against each other.

7. **Plus behavior preservation and CI.** The passing-test count does not decrease; no public-API or observable-contract change is present; CI is green on **all target operating systems** plus the project's required checks. Green on one OS is not green. **Base freshness (spine clause):** all-OS green is trusted as `verified` only when it ran against **current `main`** — the branch is up to date with `main`, or branch protection enforces strict / up-to-date-before-merge. Green gathered against a base that `main` has since moved past is **stale**: downgrade the elevation to **`degraded`**, not verified, and report the stale tested base SHA vs current `main` (`classifyBaseFreshness`; `docs/reference/fleet-family.md` § _Base freshness_). These, like the three proofs above, are **elevation** checks.

8. **The `file` tier is verified too — to its own, narrower standard.** A `file` item never enters DISPATCH, so it has no branch, no commit trail, no re-critique, and no CI: four of the checks above have nothing to read. `verified-filing` therefore requires exactly two things — **critique provenance**, the cite resolving to a real craft-skill run (`runId` + `rubricId` + location) exactly as an elevation's must, and the **cross-check**, confirming at verification time that the target is still not already addressed by an open elevation PR or an existing filed item. An item failing either is **rejected rather than filed**. Those are the only two claims a filing actually makes, and a stale cite or a duplicate filing costs the human precisely the attention this fleet exists to save.

9. **Assign exactly one verdict per item:** `verified-elevation`, `verified-filing`, `routed`, `downgraded`, or `rejected`. A rejected item is **retried once**; still failing, it is reported as rejected with its reason and the batch continues. **Degradation never reaches VERIFY.** A missing craft skill degrades in SELECT and a structural discovery downgrades in DISPATCH, but a proof that this phase's standard for **that item's tier** demands and that cannot be produced is a **rejection**, not a graceful skip. The asymmetry is the point: the earlier phases can afford to lose coverage, and this one cannot afford to lose rigor.

### Phase 5: FILE-AND-REPORT — Tiered Dual Terminal Act, Never Merge

1. **One elevation PR per verified `(target, craft domain)`** — never one per finding, never mixed across domains — each carrying its cited findings and its assumptions-made note. **Never merged.** The granularity is chosen, not inherited: one-PR-per-item is right when each item is a distinct defect, but forty naming fixes as forty PRs is a denial-of-service on review, and forty mixed fixes in one PR forces the reviewer to switch judgment modes line by line. Homogeneous batching gives the reviewer **one kind of taste question at a time over one coherent scope**, which is the only shape in which bulk taste review is actually tractable. Landing the batch is the human's call, optionally via `pr-fleet`.

2. **File each verified `file` item as a roadmap item** — including **every target downgraded from `elevate`**, whose critique remains valid even though its rewrite was withheld. Each filed item carries its **cite, rubric, and location**, so the eventual builder acts on the original judgment instead of re-deriving a critique that has already been paid for once. **The orchestrator writes each filed item's "assumptions made" note here**, from SELECT's routing basis: the ranking basis that ordered it, the routing call that split it, and why it was filed rather than elevated. A downgraded target arrives carrying the note its subagent already wrote in DISPATCH; a pure-`file` item never had a subagent, so this is the phase that produces its note.

3. **Park-and-hand-back the routed findings.** A correctness candidate is handed back as a **seed candidate for the correctness queue** — proving a defect requires a reproduction, and this member has no machinery for one. A genuine security vulnerability goes **privately to the human** and is **never opened as a public item**: filing a security finding publicly _is_ disclosure, and this fleet has no disclosure machinery, no severity rating, and no embargo. Ordinary `security-craft` posture findings that are not vulnerabilities take the `file` path like any other file-only domain.

4. **Emit a one-row-per-item batch summary** for bulk review:

   | Item | Target | Domain | Verdict | PR / Filed item | Cite | Assumptions made |
   | ---- | ------ | ------ | ------- | --------------- | ---- | ---------------- |

   Alongside the table, report every non-item outcome with its count and its reason: **dropped-by-noise-floor** findings, **over-cap** findings shed after ranking, **downgraded** targets with their downgrade reason, **cross-check drops** each citing its resolving PR or item, **routed** findings, and **quiet** targets. Quiet targets are reported **as quiet — a valid outcome, not a failure**.

5. **Under `--file-only`, every `elevate` target files instead.** No branch is pushed and no PR is opened: each `elevate`-routed target **converts its already-budgeted elevation slot** into a filed item, exactly as a downgrade does, so the combined total still never exceeds what the two caps allow. Because no branch exists, no commit trail, no re-critique, and no CI apply — those items are verified to the **`verified-filing` standard**, cite plus cross-check, like any other filing.

6. **Degrade gracefully in SELECT and DISPATCH only.** A missing or erroring craft skill, a target that downgraded, or one target's failed elevation is reported while the batch continues. One bad target never sinks the batch, and a batch of filings with no elevations is a perfectly good batch.

## Harness Integration

- **`harness skill run craft-fleet`** — Run the full five-phase batch pipeline.
- **The eleven `-craft` skills** — Composed in SELECT to build the queue, and re-run **by VERIFY** (twice, per the two-run protocol) for net-improvement evidence. Only `naming-craft`, `code-craft`, `copy-craft`, and `test-craft` carry an elevation-eligible surface; `docs-craft`, `knowledge-craft`, `spec-craft`, `api-craft`, `cli-ergonomics-craft`, `security-craft`, and `harness-design-craft` are **file-only** and never produce an elevation.
- **`harness-refactoring`** — The **single** bounded-elevation pipeline each DISPATCH subagent runs over its target's cited findings; the step-granular commit trail it necessarily leaves behind is the elevation provenance VERIFY checks.
- **`harness-roadmap-pilot`** — Its impact-scoring approach is reused in SELECT to order targets by composite tier × impact.
- **`harness validate`** / **`harness check-deps`** — The per-step gates inside the composed refactoring pipeline that make "behavior-preserving" a checkable claim rather than an assertion.
- **`manage_roadmap`** — The filing mechanism for the `file` tier in FILE-AND-REPORT. It opens a tracking issue per item, which is **why** the per-batch cap is hard rather than advisory.
- **`gh`** — Cross-check against open elevation PRs and already-filed quality items (SELECT), CI reads across all target operating systems (VERIFY), and elevation-PR creation (FILE-AND-REPORT).
- **`harness skill validate craft-fleet`** — The authoring-time gate for this skill's own structure and schema.
- **`docs/reference/fleet-family.md`** — The shared `-fleet` spine this skill builds on (the five-phase skeleton, the concurrency governor, the artifact + all-OS-CI verification discipline, the worktree fan-out and its push caveat, the front-load / park-unforeseen interaction model, and the never-silent-merge invariant), stated once for the family.

## Success Criteria

- Given a confirmed batch of N craft targets, the fleet produces a **tiered** batch — elevation PRs for verified bounded polish and filed roadmap items for verified structural quality debt — with **every** item carrying a cited craft finding (`runId` + `rubricId` + location).
- **No line is changed without a cited craft finding.** A changed location that maps to no finding from a real craft-skill run is rejected as the orchestrator's own taste.
- **Every elevation PR carries the step-granular `harness-refactoring` commit trail** (one small change per commit, suite green throughout); an item with no such trail is rejected as not having run the real pipeline.
- **Every elevation is confirmed net better by a two-run re-critique that VERIFY itself executes**, never by one the dispatch subagent ran and reported. Each cited finding is absent from **both** runs, and **no** run reports a new finding at equal-or-higher tier (`foundational` > `polish` > `aspirational`). A re-critique that trades one finding for another is style-thrash and does not ship; two runs that disagree leave the elevation unproven and the item **downgrades to `file`**; a re-critique that could not run at all is **rejected** for want of proof, never passed.
- Every elevation PR preserves behavior — the passing-test count does not decrease and no public-API or observable-contract change is present — and is green across all target operating systems plus the project's required checks.
- **No structural quality change is ever auto-applied.** Cross-module reach, contract change, exported-identifier change, module splits, and abstraction redesign are filed, always — including when a target discovers mid-flight that its elevation requires one, and including when the baseline is not clean at the pinned base SHA — a red suite, a failing `harness validate`, or a failing `harness check-deps`. Both cases downgrade to `file` and report.
- **Only `naming-craft`, `code-craft`, `copy-craft`, and `test-craft` ever produce an elevation**, and only on their eligible surfaces. The other seven domains are file-only: no prose file, no design token, no API or CLI contract surface, and no `security-craft` finding is ever rewritten by this fleet — and a ratified ADR is never edited at all.
- **User-facing output is never elevated, whichever domain surfaced it.** A `copy-craft` finding on an error message or a CLI output string is filed on the same terms as a `cli-ergonomics-craft` finding on the same bytes; only internal-facing prose — code comments and internal log lines — is elevation-eligible.
- **A `test-craft` elevation leaves every assertion expression byte-identical** and the passing-test count unchanged, with the passing test-ID set differing only by the renames the elevation itself applied; anything that changes what a test asserts is filed.
- Findings below the noise floor — `impact: small` **and** (`tier: aspirational` **or** `confidence: low`) — are **dropped and counted, never filed**; the per-batch caps (default 20 filed, 20 elevation PRs) are never exceeded, and everything the cap sheds is **reported as over-cap with its count**, never silently dropped.
- There is **exactly one** up-front human decision round, and it presents a **taste-calibration sample of verbatim findings** alongside the domain selection, the noise floor, and the caps — not counts alone.
- **Every emitted PR and filed item carries an "assumptions made" note** (ranking basis, routing call, elevation scope, and what was deliberately left un-elevated).
- Elevation PRs are batched **one per target** — and since a target is by definition one scope paired with exactly one craft domain, that means **never one PR per finding, and never two craft domains in one PR**. Both failures are observable from the emitted PR set.
- Findings that are really correctness defects or security vulnerabilities are **routed** — parked, neither elevated nor filed by this fleet, and handed back in the batch report: correctness candidates as seed candidates for the correctness queue, security vulnerabilities privately to the human, never patched inline and never published to a public tracker.
- Already-addressed targets are **dropped and annotated citing the resolving PR or item, not re-elevated**.
- A target with nothing above the noise floor is reported as **quiet** — a valid outcome, not a failure.
- The skill **never auto-merges** an elevation PR.
- It **degrades gracefully in SELECT and DISPATCH**: a missing or erroring craft skill, a downgraded target, or a single target's failed elevation is reported while the batch continues, and a rejected item is retried at most once. **Degradation never reaches VERIFY** — a proof that phase's standard for the item's tier demands and cannot produce is a rejection, not a graceful skip.
- Concurrency never exceeds the confirmed governor (default 2, max ~3).
- **No item is marked verified on a subagent self-report.** Every **elevation** verdict is backed by independently-checked critique provenance, independently-checked elevation provenance, a re-critique VERIFY ran itself, and all-OS CI; every **filing** verdict — which has no branch to check — is backed by its cite resolving to a real craft-skill run and by a cross-check that the target is not already addressed.

## Gates

- **No rewrite without a cited craft finding** — a `runId`, a `rubricId`, and a location from a real craft-skill run. A changed location that maps to no finding is the orchestrator's own taste and the item is rejected, however good the diff looks.
- **No elevation without the step-granular refactoring commit trail.** Absent trail ⇒ the real pipeline did not run ⇒ rejected. A hand-applied patch that matches a finding is still a hand-applied patch.
- **No elevation without a two-run net-improvement proof.** A cited finding is resolved only if it is absent from **both** runs; a new equal-or-higher-tier finding in **either** run blocks the elevation.
- **A re-critique that could not run is a rejection, not a pass.** Retried once; if it still cannot run, the item is reported as unverifiable and never shipped.
- **Two runs that disagree downgrade the item to `file`.** Never ship the unproven rewrite; never discard the valid critique.
- **VERIFY executes both re-critique runs.** A re-critique the dispatch subagent ran and reported is never accepted as proof, no matter how detailed the report.
- **Never auto-apply a structural, contract-touching, cross-module, or exported-identifier change.** Filed, always — including when the discovery happens mid-flight and including when the baseline is not clean (red suite, or a failing `harness validate` or `check-deps`).
- **Only `naming-craft`, `code-craft`, `copy-craft`, and `test-craft` ever elevate**, and only on their eligible surfaces. No prose file, no design token, no API or CLI contract surface.
- **Never edit a ratified ADR.** It is a record of a decision, not a document to be improved.
- **Never elevate user-facing output**, whichever domain surfaced it. Error messages and CLI output strings are observable contracts and are filed.
- **A `test-craft` elevation that changes any assertion expression is a `file`.** Byte-identical assertions, unchanged passing-test count, and a passing test-ID set differing only by the applied renames — or it is not an elevation.
- **Never auto-apply a `security-craft` finding, and never publish a routed security vulnerability.** A wrong security "improvement" is worse than the mediocrity it replaced, and public filing is disclosure.
- **Never exceed the per-batch caps silently.** Everything the cap sheds is reported as over-cap with its count.
- **Never auto-merge an elevation PR.** The fleet stops at reviewable; the human lands the batch.
- **Never exceed the concurrency governor.** More than ~3 concurrent elevation agents is the machine-storm zone, and manufactured noise on top of a non-deterministic oracle is uniquely corrosive.
- **Never manufacture an elevation for a quiet target.** A quiet target is a valid result and is reported as quiet.
- **Never `--no-verify`.** A worktree whose push gate fails pushes via the GitHub API or a non-nested throwaway worktree instead.

## Escalation

- **A craft skill is missing or errors:** degrade to the remaining ones and record which one was unavailable in the batch summary. If no craft skill is available, stop and report — there is nothing to rank.
- **The re-critique provider is unavailable or the prompt budget is exceeded:** the item is rejected for want of proof and retried once. If it still cannot run, report the item as unverifiable rather than passing it — an unproven elevation is exactly what the Iron Law's second half forbids.
- **The baseline is not clean at the pinned base SHA** — a red suite, or a failing `harness validate` or `check-deps`: the affected targets do not elevate. They downgrade to `file` and report, because those three checks are the elevation pipeline's entire safety net and there is nothing to substitute for them.
- **A target discovers mid-flight that its elevation needs a structural change:** downgrade it to `file` and report the reason; do not apply it, and do not narrow the change until it fits. The critique still reaches the human.
- **A finding turns out to be a correctness defect:** park it and hand it back as a seed candidate for the correctness queue. Proving a defect requires a reproduction, and this member has no machinery for one.
- **A finding turns out to be a genuine security vulnerability:** hand it to the human privately. Never patch it, never open a public item, and do not continue pulling on the thread looking for adjacent findings.
- **The over-cap count is large:** report it with the batch and let the human re-tune the floor or the caps at the next CONFIRM. Do not quietly raise the cap — a cap raised in-flight is a tracker flood with a justification attached.
- **CI is red on a subset of operating systems:** report the item failed, naming the operating system and the check. Never average a mixed result into "mostly green," and never mark it verified.

## Rationalizations to Reject

| Rationalization                                                                             | Reality                                                                                                                                                                                                |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "The finding is obviously right — applying it without chasing down the cite is bookkeeping" | The cite is the whole bar. Without a `runId` + `rubricId` + location the change is the orchestrator's taste wearing a craft skill's name, and the cited-finding Gate rejects it however good it looks. |
| "This doc reads badly and a prose rewrite cannot break anything — elevate it"               | Prose has no test suite, so "did not make it worse" is unprovable here. No skill applies prose-quality edits under a safety envelope; prose domains are file-only, and a ratified ADR is never edited. |
| "The re-critique came back clean on the first run; a second run is a waste of budget"       | The oracle is an LLM call and a single run falsely accepts as readily as it falsely rejects. Resolved requires absence from **both** runs — one clean run is a reading, not a proof.                   |
| "The two runs disagreed, so throw the item out"                                             | Disagreement unproves the **rewrite**, not the **critique**. The item downgrades to `file` carrying its original cite; discarding it would throw away judgment that was already paid for.              |
| "The subagent already re-critiqued its own branch and reported it net better"               | That is a self-report, which the family invariant never accepts. VERIFY runs both re-critiques itself — that is what keeps the total at two runs and makes them independent at the same time.          |
| "It is only a flag name / an exported symbol, and the tests still pass"                     | A green suite does not make a contract change safe; it means the suite does not encode the contract. Exported identifiers and published surfaces are filed, always — never elevated.                   |
| "This craft finding is really a bug — while I am in the file I will fix it"                 | Proving a defect needs a reproduction, and this fleet has no machinery for one. It is **routed**: parked and handed back as a seed candidate for the correctness queue, never patched in passing.      |
| "Forty naming fixes in one PR is less work for the reviewer than forty PRs"                 | Both are wrong, which is why the rule is one PR per target. Forty PRs is a denial-of-service on review; one mixed PR makes the reviewer switch judgment modes line by line.                            |
| "The target came back quiet — find something so the sweep does not look wasted"             | A quiet target is a valid result: it says the ceiling is already reached there. With no repro to fail and no detector to stay red, the only thing preventing an invented batch is this rule.           |
| "I sharpened the assertion while renaming the test — it is strictly better now"             | Sharpening an assertion changes what the suite checks, which breaks the byte-identical-assertion rule that made test elevation non-circular. It is a genuine improvement and it is a `file`.           |

## Red Flags

| Flag                                                                         | Corrective Action                                                                                                                                     |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| "I will mark it verified from the subagent's net-better report"              | STOP. Run both re-critiques in VERIFY and check the cite and the commit trail yourself. A report is a claim; the fleet's verdicts rest on proofs.     |
| "The re-critique could not run, but the diff looks like a clear improvement" | STOP. No proof means rejection, retried once. "Looks like an improvement" is exactly the judgment the two-run protocol exists to replace.             |
| "This exported identifier rename is obviously better and the suite is green" | STOP. That is a contract change. File it with its cite; the elevate boundary is mechanical and a green suite is not a contract check.                 |
| "I have a clean `security-craft` finding — file it so it gets attention"     | STOP. Never auto-apply it, and never open it publicly if it is a real vulnerability — public filing is disclosure. Hand it to the human privately.    |
| "The pre-push gate is failing in this worktree — I will `--no-verify`"       | STOP. Never bypass. Push via the GitHub API or a non-nested throwaway worktree; that gate is part of the verification the fleet's guarantees rest on. |

## Examples

### Example: A thirty-eight-target ceiling sweep

```
$ harness skill run craft-fleet --concurrency 2

Phase 1: SELECT
  Craft domains enabled: 11 of 11 (all available, none errored)
  Composed findings: 214, each carrying runId + rubricId + location
  Noise floor  small AND (aspirational OR low)  -> 96 dropped and counted
  Folded 118 survivors into 38 (scope, domain) targets
  Cross-check vs open elevation PRs / filed items -> 3 already-addressed, dropped
                                                     with the resolving PR cited
  Routed 2 -> 1 correctness candidate, 1 security vulnerability
  Routing the remaining 33 -> 9 elevate, 24 file
  Ranked by tier x impact (roadmap-pilot scoring); caps applied after ranking
  Caps 20 elevate / 20 file -> 4 file items shed as over-cap, reported with count
  Quiet: 5 scopes critiqued with nothing above the floor

Phase 2: CONFIRM  [checkpoint:human-verify]
  Domains presented (11), ranked batch presented (9 elevate / 20 file).
  Taste-calibration sample: 6 verbatim findings, 3 elevate + 3 file.
  Noise floor and caps shown with their drop counts, both re-tunable here.
  Pinned base SHA: a71c3e0. Concurrency: 2.
  Human disables knowledge-craft (-2 filed) and trims 1 elevate target.
  Approved batch = 8 elevate + 18 file.

Phase 3: DISPATCH (governor = 2)
  auth-session-naming   naming-craft  -> branch pushed, 4-commit trail
  retry-control-flow    code-craft    -> branch pushed, 3-commit trail
  sync-comments         copy-craft    -> branch pushed, 2-commit trail
  export-test-names     test-craft    -> branch pushed, 5-commit trail
  parser-local-names    naming-craft  -> branch pushed, 2-commit trail
  queue-log-lines       copy-craft    -> branch pushed, 2-commit trail
  ledger-guard-clauses  code-craft    -> branch pushed, 3-commit trail
  billing-abstraction   code-craft    -> DOWNGRADED to file (needs a module split)
  No subagent ran a re-critique.

Phase 4: VERIFY (independent — both re-critique runs executed here)
  auth-session-naming   cites OK; trail OK; runs A+B both clean; suite green;
                        CI green 3 OS -> verified-elevation
  sync-comments         cites OK; trail OK; runs A+B both clean -> verified-elevation
  export-test-names     assertions byte-identical; passing count unchanged; IDs
                        differ only by the applied renames; A+B clean
                        -> verified-elevation
  parser-local-names    cites OK; trail OK; A+B clean -> verified-elevation
  queue-log-lines       cites OK; trail OK; A+B clean -> verified-elevation
  retry-control-flow    run A: cited finding resolved. run B: still reports it.
                        Runs disagree -> not proven -> DOWNGRADED to file
  ledger-guard-clauses  1 changed location maps to no cited finding
                        -> REJECTED (retried once, same) — orchestrator's own taste

Phase 5: FILE-AND-REPORT
  Batch summary — one row per item; excerpt shown:
  | Item                 | Target               | Domain       | Verdict            | PR / Filed item | Cite                | Assumptions made              |
  | -------------------- | -------------------- | ------------ | ------------------ | --------------- | ------------------- | ----------------------------- |
  | local name clarity   | auth-session-naming  | naming-craft | verified-elevation | PR link         | run + rubric + loc  | non-exported identifiers only |
  | comment accuracy     | sync-comments        | copy-craft   | verified-elevation | PR link         | run + rubric + loc  | internal prose only           |
  | test-name clarity    | export-test-names    | test-craft   | verified-elevation | PR link         | run + rubric + loc  | assertions frozen             |
  | endpoint naming      | billing-api-surface  | api-craft    | verified-filing    | filed item      | run + rubric + loc  | filed: published contract     |
  | control-flow honesty | retry-control-flow   | code-craft   | downgraded         | filed item      | run + rubric + loc  | runs split; rewrite withheld  |
  | abstraction redesign | billing-abstraction  | code-craft   | downgraded         | filed item      | run + rubric + loc  | module split -> structural    |
  | guard-clause tidy    | ledger-guard-clauses | code-craft   | rejected           | —               | (uncited location)  | no cite for 1 changed line    |
  5 elevation PRs opened, one per (target, domain). Never merged.
  20 filed items = 18 confirmed file + 2 downgrades (converted elevate slots).
  Routed 2: correctness candidate seeded to the correctness queue; security
  vulnerability handed to the human privately, not filed.
  Dropped by noise floor 96. Over-cap 4. Cross-check drops 3 (cited).
  Quiet targets 5 — reported as quiet, a valid outcome.
```

### Example: Two re-critique runs disagree

A subagent returns a `code-craft` elevation on `retry-control-flow` with a clean 3-commit trail and a green suite. VERIFY runs the re-critique twice over the changed scope on the branch: the first run reports the cited finding resolved, the second still sees it. Under the two-run protocol a finding counts as resolved only when it is absent from **both** runs, so the elevation is **not proven**.

It is not discarded either. The original critique is untouched by the disagreement — something was worth changing there, and the craft skill said so under a real `runId`. The item therefore **downgrades to `file`**, carrying its original cite, rubric, and location to the roadmap item so the eventual builder starts from the judgment rather than re-deriving it. The rewrite is withheld, the critique is preserved, and the reviewer's attention is spent on nothing at all — which is precisely the trade the cheaper two-run protocol was chosen to make.

## Test Scenarios

### Scenario 1: Gate — a change with no cited finding is applied because it "obviously improves" the code

A dispatch subagent tidies a guard clause adjacent to its target's cited findings. The diff is smaller, the suite is green, and the commit trail is clean, but that one changed location maps to no finding from any craft-skill run. Expected: the **no rewrite without a cited craft finding** Gate rejects the item as the orchestrator's own taste, however good the diff looks; it is retried once and then reported as rejected. The "the finding is obviously right — chasing the cite is bookkeeping" rationalization is the failure this scenario guards against, and note that the attractive diff is what makes it dangerous rather than what excuses it.

### Scenario 2: Gate — a single clean re-critique run is accepted as net-improvement proof

VERIFY runs the re-critique once, sees the cited findings gone, and marks the item verified to save budget. Expected: the **two-run net-improvement** Gate refuses it — a cited finding is resolved only if it is absent from **both** runs, because one LLM call falsely accepts as readily as it falsely rejects. Separately and distinctly: a re-critique that could **not run at all** (no provider, exhausted budget, erroring skill) is a **rejection retried once**, not a pass and not a downgrade — it produced no reading to re-examine, whereas two runs that split already produced theirs.

### Scenario 3: Gate — a `copy-craft` finding on a user-facing error message is elevated

`copy-craft` surfaces a genuinely poor error message with `confidence: high`, and the change is one line inside source the suite exercises. Expected: the **never elevate user-facing output** Gate files it instead. Routing follows the **surface**, not the skill that surfaced the finding: those bytes are an observable contract, so they are filed on exactly the same terms as a `cli-ergonomics-craft` finding on the same string. Only internal-facing prose — code comments and internal log lines — remains elevation-eligible under `copy-craft`.