@@ -59,7 +59,7 @@ The checks that separate work actually done from work that merely reports succes
 - **A launched process is not a result, and a cause nobody observed is not a diagnosis.** "The watcher is armed" names a process rather than a finding, so what gets reported is the output that process produced, and where it produced none, that absence is the report. The failure it prevents is an agent standing still on a condition that was met half an hour earlier, having announced the wait and never read it. Naming an external cause for such a stall afterwards, a throttle or a quota that appears nowhere in the record, turns a local defect into a story about someone else and closes the investigation on the wrong party, so read the record for the cause before naming one, and where the record does not carry it, report the cause as unknown.
 - **A workflow change is only fully exercised by CI.** Extracting a `run:` block and executing it locally validates the script and nothing else, because `secrets: inherit`, `permissions:`, `needs:` wiring, and reusable-workflow inputs resolve only in a real run.
 - **Platform-specific code is "verified" only on the platform it runs on.** PowerShell on Windows, a macOS-only `mktemp`/`ssh-agent` behavior, a WSL-specific path quirk: an agent reasoning about such code from a different host, however carefully, has not executed it, and reasoning by structural analogy to an already-tested equivalent on another platform ("the POSIX version works, so the PowerShell version should too") is a plausible first pass, not verification. State it as exactly that, an unverified structural match, and never in the same words used for a tested fact. When no agent in the loop has access to the target platform, say so, and either defer the platform-specific portion to a human or an agent that has that access, or ship it clearly labeled unverified.
-- **A review flags an instance, so a fix covers the class, bounded to what this change touched or broke.** When a reviewer cites one stale claim, one silent-narrowing pattern, or one mis-worded contract, and the finding is being fixed, sweep for its siblings before replying, since reviewers sample rather than enumerate, and fix each sibling that sits in a file the diff already touches. A sibling the change itself put in disagreement is this change's to fix wherever it sits, because the change made it wrong. A sibling that was wrong before the change and sits in a file the diff does not touch is filed rather than folded in, because every file the diff grows into is one more that each round reads again, so a sweep that widens the diff widens the loop it was meant to close.
+- **A review flags an instance, so a fix covers the class, bounded to what this change touched or broke.** When a reviewer cites one stale claim, one silent-narrowing pattern, or one mis-worded contract, and the finding is being fixed, sweep for its siblings before replying, since reviewers sample rather than enumerate, and fix each sibling that sits in a file the diff already touches. A sibling the change itself put in disagreement is this change's to fix wherever it sits, because the change made it wrong. A sibling that was wrong before the change and sits in a file the diff does not touch stays out of the diff, because every file the diff grows into is one more that each round reads again, so a sweep that widens the diff widens the loop it was meant to close. Such a sibling takes the outcome a `pre-existing` finding takes under the `pr-review-conduct` Skill's "Every finding ends in a listed outcome" item 4.
 
 `GOVERNANCE.md` "Verification Discipline" keeps the full rules, and the `agent-conduct` Skill at `.agents/skills/agent-conduct/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo, carries it whole as a generated include and surfaces it at its decision moment.
 
 
@@ -97,7 +97,11 @@ promotion PR once the fix lands, is the early exit this skill exists to prevent.
    obstacle to route around, and that
    skill's refusal table says what each refusal means and what clears it.
 3. Drive pr-review-conduct's review loop on it to the Merge Gate, disposing of every finding per
-   "Disposing of Every Finding" below.
+   "Disposing of Every Finding" below. Request no Copilot round on this feature PR. Its `wait` reads
+   step 2's attestation as `coverage=local` and requests none, unless a partial round or a truncated
+   review history is on record. Exit `49` means the head carries no attestation, so run and record a
+   pass over it, push, and attest. A promotion re-reviews content its feature PRs already carried,
+   so the hosted review runs once per change, at the promotion in step 6.
 4. Merge the feature PR into
    develop, `gh pr merge <number> --squash --repo <owner>/<repo>`. Never `--delete-branch` on this
    call, it is run from inside the task's own worktree per step 1, where the feature branch is
@@ -153,8 +157,8 @@ maintainer when".
 
 1. **Real, so fix it, and fix the class rather than the instance.** A reviewer samples rather
    than enumerates, so sweep for the finding's siblings before replying and fix each one sitting
-   in a file the diff already touches or that this change itself made wrong, filing the rest, per
-   `GOVERNANCE.md` "Verification Discipline". That sweep is owed the first time the finding is
+   in a file the diff already touches or that this change itself made wrong. Each of the rest takes
+   the outcome a `pre-existing` finding takes under outcome 4, per `GOVERNANCE.md` "Verification Discipline". That sweep is owed the first time the finding is
    raised, not once it recurs. Take the fix through `local-strict-review` the same way the push
    that opened the pull request went, per `pr-review-conduct` "Expected review loop", then reply
    with the fixing commit SHA. A branch already reviewed once has not been reviewed for the fix, which
@@ -183,11 +187,40 @@ maintainer when".
    turn, before moving to other work. A plan to ask later is resolution by silence the moment
    attention moves elsewhere. If the maintainer is not reachable right now, leave the thread open
    and say so, rather than treating the intention to ask as the asking.
-4. **Real and worth doing later, so file the issue first, then reply with its link.** A deferral
-   noted only in a thread is lost the moment the PR merges. File it in the repository where the
-   fix has to land, which for a finding against carried content is the repository that authors
-   that content rather than the one carrying it, since an issue filed where nobody may make the
-   fix is a deferral nobody can close.
+4. **Deferred past this pull request, or on text it did not touch, so record it by its class.**
+   An `introduced` finding fixable here and deliberately left as is takes outcome 3 instead.
+   The class is the one `local-strict-review` "Disposing of Findings" defines, and the first
+   bullet that fits decides:
+   - A `pre-existing` finding on a canonical Markdown unit keeps the per-unit tracker
+     `pr-review-conduct` "Merge Gate" item 3 describes, since that already costs one link per unit.
+   - A `pre-existing` correctness defect with a stated failure is filed once as its own issue,
+     labeled `pre-existing`. Such a finding names an input or a state and the wrong output or the
+     crash it produces. Its body line goes under a `Pre-existing findings, filed` heading and
+     links that issue. A thread raising it is answered with that issue's link and resolved.
+   - A `style`, wording, consolidation, or restatement finding on text this change did not touch
+     is dropped. It gets one line under a `Dropped findings` heading and nothing else. It gets no
+     decline text, no issue, and no reply beyond a pointer to that line, which resolves any
+     thread.
+   - Any other `pre-existing` finding, from a local pass or a PR-hosted review, is listed in the
+     pull request body with its location and its class. No issue is filed for it. The body line
+     is its outcome, and a thread raising it is answered with a pointer to that line and resolved.
+   - Any other deferral is filed as an issue first, and the reply carries its link. A deferral
+     noted only in a thread is lost the moment the PR merges.
+
+   The body keeps every other unfiled `pre-existing` line, the fourth bullet's, under one
+   heading, `Pre-existing findings, not filed`. Each line under these headings carries its
+   location and its class. The headings stay apart from the open `introduced` findings a spent
+   edit budget puts in the body, per `local-strict-review` "Disposing of Findings". A reviewer's
+   suppressed finding has no thread, so its pointer is an answer per `pr-review-conduct`
+   "Answering a suppressed finding". That answer is `Listed in the body` for a listed or dropped
+   finding, and `Deferred to <issue>` for a filed one. A local-pass finding owes no pointer
+   beyond its body line. A sibling that outcome 1's class sweep leaves unfixed takes the
+   bullet a `pre-existing` finding would take. An issue goes in the repository where
+   the fix has to land. For a finding against carried content, that is the repository authoring
+   the content rather than the one carrying it. An issue filed where nobody may make the fix is
+   a deferral nobody can close. Filing every `pre-existing` finding is the expensive path. From
+   2026-10-16 to 2026-10-23, 108 of 329 non-handoff issues filed across four fleet repositories
+   carried `pre-existing`. Each one costs a lane, a pull request, and a review once worked.
 5. **Keeps recurring although the class was swept, so the rule is what needs fixing.** A finding
    raised repeatedly against correct code means the code is not communicating something: add the
    comment, sharpen the name, narrow the interface, or fix the rule if the rule is wrong.
 
@@ -148,7 +148,7 @@ Each bullet is a rule down to its `Why:` line, which is rationale rather than ru
   - `Why:` a local finding and a PR-hosted one deserve the same dispositions, and one home for the list is what stops two copies of it drifting apart.
 - **The agent disposing of a pass's findings classes each one `style`, `introduced`, or `pre-existing`, in that order.** `style` is a preference between defensible forms. `introduced` is any other finding on text this change wrote, rewrote, or removed, on text this change should have written, on a precondition this change left false elsewhere, or load-bearing for a decision this change puts to the maintainer. `pre-existing` is every other finding.
   - `Why:` the reviewer is asked to omit preferences and returns some anyway, and `style` is classed first so that a preference on text this change wrote is not owed a fix.
-- **Another round is owed only while an `introduced` finding is open.** Unless evidence disproves it, an `introduced` finding is fixed within the budget below, handed to the pull request once that budget is spent, or escalated where `pr-review-conduct` "Escalate to the maintainer when" says so. A `pre-existing` one is filed once and blocks nothing, and a `style` one is declined with evidence, per `pr-review-conduct` "Every finding ends in a listed outcome", the evidence being `fleet-code-review` "Review the Change"'s own rule to omit preferences.
+- **Another round is owed only while an `introduced` finding is open.** Unless evidence disproves it, an `introduced` finding is fixed within the budget below, handed to the pull request once that budget is spent, or escalated where `pr-review-conduct` "Escalate to the maintainer when" says so. A `pre-existing` one blocks nothing, and neither does a `style` one on text this change did not touch. `pr-review-conduct` "Every finding ends in a listed outcome" outcome 4 says how each is recorded. A `style` one on text this change wrote is declined with evidence per that section. The evidence is `fleet-code-review` "Review the Change"'s own rule to omit preferences.
   - `Why:` a finding count over prose never reaches zero, so a loop closing on "did it find anything" does not close, where one closing on the false claim, the unfollowable instruction, or the wrong behavior this change put there does.
 - **Two rounds of edits answer a pass, one budget per push and one per sweep issue.** Where an `introduced` finding is still open after the second round, editing stops. The pull request's body lists each remaining finding with its class. Its review loop then gives each one an outcome under `pr-review-conduct` before it merges, whether or not a hosted reviewer raises it again. A spent budget is not an escalation. A remaining finding goes to the maintainer only where `pr-review-conduct` "Escalate to the maintainer when" names its case.
   - `Why:` past the second round nearly every finding is against text the previous round's fix wrote, so the rounds are producing the defects they find rather than removing them.