Promote the 3.23 Verify, Repair, and Delete Safety Fixes to Main

.editorconfig

@@ -13,9 +13,9 @@
 # Root config
 root = true
 
-# Defaults: LF is the default, and only the CRLF exception below is declared.
+# Defaults: LF is the default, and only the CRLF exceptions below are declared.
 # `.gitattributes` mirrors these two defaults as Git's normalization fallback.
-# CI verifies the committed bytes against this file.
+# CI verifies the checked-out files against this file.
 [*]
 charset = utf-8
 end_of_line = lf
@@ -36,7 +36,7 @@ indent_size = 2
 [*.{yml,yaml}]
 indent_size = 2
 
-# Windows batch and command scripts: the one CRLF exception to the `[*]` LF default above.
+# Windows batch and command scripts: a CRLF exception to the `[*]` LF default above.
 [*.{bat,cmd}]
 end_of_line = crlf
 

.gitattributes

@@ -1,5 +1,7 @@
-# Normalize every detected text file to LF in the index and on checkout.
-# `text=auto` leaves binary files byte-preserved.
+# Normalize a detected text file to LF in the index when it is first added or renormalized.
+# Check such a file out to LF except where a CRLF pin below applies.
+# `text=auto` byte-preserves only files Git's heuristic detects as binary.
+# A text-shaped file whose bytes have to be kept needs its own `-text` or `binary` pin.
 * text=auto eol=lf
 
 # Windows command scripts require CRLF.

.github/copilot-instructions.md

@@ -2,7 +2,7 @@
 
 Repository-wide instructions for GitHub Copilot.
 
-Read [AGENTS.md](../AGENTS.md) first. It routes every standing repository rule to its canonical document. When performing code review, load and follow the `fleet-code-review` skill in `.github/skills/fleet-code-review/SKILL.md`, then load every language, documentation, or workflow skill that it selects for the changed files. GitHub Copilot reads these files from the pull request's head branch, so review the instructions in that tree.
+Read [AGENTS.md](../AGENTS.md) first. It routes every standing repository rule to its canonical document. When performing code review, load and follow the `fleet-code-review` skill in `.github/skills/fleet-code-review/SKILL.md`. Then load every language, documentation, or workflow skill that it selects for the changed files. GitHub Copilot reads these files from the pull request's head branch, so review the instructions in that tree.
 
 Do not duplicate rules from `AGENTS.md`, `GOVERNANCE.md`, `CODESTYLE.md`, or `WORKFLOW.md` here. This file contains only Copilot-specific bootstrap and output requirements.
 
@@ -14,7 +14,7 @@ Use an imperative subject of at most 72 characters with no trailing period. Use
 
 Follow the fidelity declared for the file. A byte-locked reference to shared infrastructure that this repository does not carry is intentional, not a broken link. Raise substantive defects in canonical content, but locate the fix at its canonical source instead of proposing a local edit.
 
-`.github/skills/`, and in the hub `.claude-plugin/fleet-skills/`, are generated by the hub's `scripts/build_dist.py` from its `.agents/skills/`, so a defect in either is fixed in the source or the generator and never in the copy. A defect inside an include region, the text between the marker lines `<!-- include: <path> > <heading> -->` and `<!-- /include -->` that every copy carries as its authored source does, is fixed in the hub under the heading that key names, since the region is generated from that heading's body and the key's path resolves against the hub's root rather than this repository's copy of the same file. Where that heading's body is itself a region, the fix sits one hop further, under the heading its own key names. Post no review comment on a file under `.github/skills/` or, in the hub, `.claude-plugin/fleet-skills/`. When the pull request changes the file the fix belongs in, comment on that file instead, and otherwise state the finding in the review summary.
+`.github/skills/`, and in the hub `.claude-plugin/fleet-skills/`, are generated by the hub's `scripts/build_dist.py` from its `.agents/skills/`. So a defect in either is fixed in the source or the generator and never in the copy. An include region is the text between the marker lines `<!-- include: <path> > <heading> -->` and `<!-- /include -->` that every copy carries as its authored source does. A defect inside one is fixed in the hub under the heading that key names. That is because the region is generated from that heading's body. It is also because the key's path resolves against the hub's root rather than this repository's copy of the same file. Where that heading's body is itself a region, the fix sits one hop further, under the heading its own key names. Post no review comment on a file under `.github/skills/` or, in the hub, `.claude-plugin/fleet-skills/`. When the pull request changes the file the fix belongs in, comment on that file instead, and otherwise state the finding in the review summary.
 
 ## GitHub Copilot Review Runbook
 
@@ -26,21 +26,21 @@ For every review:
 4. Use an inline comment when a changed line can anchor the finding. Use the review body only when no valid inline anchor exists.
 5. End the review body with the exact machine-readable marker required by the `fleet-code-review` skill.
 
-The review automation is `scripts/pr_review.py`, run from a hub checkout. Use its `status`, `wait`, `comment`, and `reply --resolve` commands instead of reconstructing GraphQL queries or copying review identifiers by hand. Use `comment` for a suppressed-finding answer in the pull request conversation. Its status gate verifies the current head, diff coverage, output shape, inline threads, body-only findings, and required checks.
+The review automation is `scripts/pr_review.py`, run from a hub checkout. Use its `status`, `wait`, `attest`, `comment`, and `reply --resolve` commands instead of reconstructing GraphQL queries or copying review identifiers by hand. Use `comment` for a suppressed-finding answer in the pull request conversation. Its status gate verifies the current head, diff coverage, output shape, inline threads, body-only findings, and required checks.
 
-A formal review with no findings is complete only when it covers the current head and full diff coverage is stated for the change set that head has. The round covering the head states it, or the newest round that states it at all does and the pull request changes the same set of files at both commits, which is the only condition under which a statement carries forward. Only that newest round is consulted, so an older round whose change set does match carries nothing. A round reporting partial coverage of the diff blocks the merge, and so does a refusal, a coverage statement that does not reach this head, meaning absent from every round or carried by none because the change set moved or could not be compared, an unrecognized output shape, an unresolved thread, or a body-only finding. Re-run the loop after every fix push. Never infer review completion from `mergeStateStatus: CLEAN`.
+A formal review with no findings is complete only when it covers the current head. It also needs full diff coverage of the change set that head has, stated or read from a file table as below. A round covering the head states it. Where none does, a round covering the head whose own file table names exactly the changed files covers it. That is the reading a round at Balanced review effort gives. Where no round covering the head carries its own table, the newest round that does stands in where its table names exactly the changed files. A table stands in only where no Copilot round on the pull request, on any commit, states partial coverage. So a pull request that ever had a partial round goes to the maintainer. A round reporting partial coverage of the diff blocks the merge, and so does a refusal. So does a head that no coverage statement, file table, or attested local pass covers. So does an output shape the digest notes and nobody has read by hand, an unresolved thread, or a body-only finding. On a pull request into a branch other than the default, an attested local pass covers the head, `coverage=local` in the digest. A partial round, a truncated review history, or a refusal on the head still blocks that reading. A pull request into the default branch, a promotion among them, always carries a Copilot round on its head. Re-run the loop after every fix push. Never infer review completion from `mergeStateStatus: CLEAN`.
 
-Review effort is user-controlled. The automation observes `Lite`, `Balanced`, or `Max`, including an inherited `Default (<level>)`, and never selects or changes the setting. Effort does not determine coverage or completion. A request can complete without a `copilot_work_started` event, so absence of that event is not a stalled-review verdict. When `wait` returns `PENDING` with `requested=yes`, report the state and rerun `wait` for another bounded interval by default, reading that field as acceptance of the request rather than as delivery of a round. Do not clear the request on that first timeout, because it may still be active. Where a second bounded wait times out as well, read the pending set, clear it only where no human or team reviewer is requested alongside the bot, and rerun `wait`, which then has nothing outstanding to defer to and requests afresh, or polls and says so on its own auto-request line where it finds no reviewer node id to request with. The clear replaces that set rather than adding to it and nothing restores a request it drops, so a stall on a pull request that has a human or team reviewer requested goes to the maintainer, and so does one still pending after the wait that follows a clear. That clear is a recovery step the script does not implement, and `docs/pr-reviewer-reference.md`, in the hub checkout the script is run from, carries it. This recovery replaces only the review request and never changes the effort setting.
+Review effort is user-controlled. The automation observes `Lite`, `Balanced`, or `Max`, including an inherited `Default (<level>)`, and never selects or changes the setting. Effort does not determine coverage or completion. A request can complete without a `copilot_work_started` event, so absence of that event is not a stalled-review verdict. When `wait` returns `PENDING` with `requested=yes`, report the state and rerun `wait` for another bounded interval by default. Read that field as acceptance of the request rather than as delivery of a round. Do not clear the request on that first timeout, because it may still be active. Where a second bounded wait times out as well, read the pending set. In that case, clear it only where no human or team reviewer is requested alongside the bot, and rerun `wait`. That rerun then has nothing outstanding to defer to and requests afresh. Where it finds no reviewer node id to request with, it polls instead and says so on its own auto-request line. The clear replaces that set rather than adding to it, and nothing restores a request it drops. So a stall on a pull request that has a human or team reviewer requested goes to the maintainer. So does one still pending after the wait that follows a clear. That clear is a recovery step the script does not implement, and `docs/pr-reviewer-reference.md`, in the hub checkout the script is run from, carries it. This recovery replaces only the review request and never changes the effort setting. A `wait` ending `REQUEST_NOT_RECORDED`, exit 40, is a different state and takes none of this recovery. The request returned success and left neither a pending reviewer nor a review-request event. That is how an exhausted Copilot allowance has shown itself. So clearing and requesting again does not clear this state, and it goes to the maintainer.
 
 ### Disproved Claims
 
-**A disproof is proof about this repository, and the thread it was written in is not where the next round looks.** [GOVERNANCE.md "PR Review Etiquette"](../GOVERNANCE.md#pr-review-etiquette), which routes to the `pr-review-conduct` Skill, closes a false finding by disproving it in the thread, addressed to the reviewer so it does not raise the same thing again, and while the pull request is open that is the right place for it. Afterwards it is the wrong one. The pull request merges, the next round begins with no memory of the last, and the second occurrence reaches a maintainer with no way to tell it from a first. Each entry below is a claim that was tested against this repository and found false, kept so the proof is read rather than built twice.
+**A disproof is proof about this repository, and the thread it was written in is not where the next round looks.** [GOVERNANCE.md "PR Review Etiquette"](../GOVERNANCE.md#pr-review-etiquette), which routes to the `pr-review-conduct` Skill, closes a false finding by disproving it in the thread. The disproof is addressed to the reviewer so the reviewer does not raise the same thing again. While the pull request is open, the thread is the right place for it. Afterwards it is the wrong one. The pull request merges, and the next round begins with no memory of the last. The second occurrence then reaches a maintainer with no way to tell it from a first. Each entry below is a claim that was tested against this repository and found false, kept so the proof is read rather than built twice.
 
-**An entry names the claim, what was run or read to disprove it, the revision it was proved against, and what ends it.** A disproof is true of one tree at one revision, so an entry whose subject moves is deleted by the change that moves it rather than edited to look current, which is the same sweep the [GOVERNANCE.md "Documentation Style Conventions"](../GOVERNANCE.md#documentation-style-conventions) rule already requires of prose asserting a behavior that has changed underneath it. This is deliberately not a list to append to, since an entry outliving the code it was proved against becomes a reason not to check, and that is strictly worse than proving the claim a second time.
+**An entry names the claim, what was run or read to disprove it, the revision it was proved against, and what ends it.** A disproof is true of one tree at one revision. So an entry whose subject moves is deleted by the change that moves it rather than edited to look current. That is the same sweep the [GOVERNANCE.md "Documentation Style Conventions"](../GOVERNANCE.md#documentation-style-conventions) rule already requires of prose asserting a behavior that has changed underneath it. This is deliberately not a list to append to. That is because an entry outliving the code it was proved against becomes a reason not to check. That outcome is strictly worse than proving the claim a second time.
 
-**The record answers a repeated claim and never dismisses a new one.** An entry is cited only where the revision it names is still what the tree carries, and the reply carries the proof re-read rather than a pointer to the entry, since a reviewer that cannot open this file learns nothing from being pointed at it. Judge a finding on its merits first and match it against this record second, because reading it the other way round is how a real finding gets closed by a stale proof.
+**The record answers a repeated claim and never dismisses a new one.** An entry is cited only where the revision it names is still what the tree carries. The reply carries the proof re-read rather than a pointer to the entry. That is because a reviewer that cannot open this file learns nothing from being pointed at it. Judge a finding on its merits first and match it against this record second. The reason is that reading it the other way round is how a real finding gets closed by a stale proof.
 
-**The entries are this repository's own.** Each names a file and a revision, so a repository holding a copy of this file carries the shape and the rules above rather than these findings, deletes an entry whose subject it does not carry, and records what it has proved itself.
+**The entries are this repository's own.** Each names a file and a revision. A repository holding a copy of this file therefore carries the shape and the rules above rather than these findings. That repository deletes an entry whose subject it does not carry and records what it has proved itself. An entry is never about hub-hosted machinery, the tooling a repository reaches rather than carries per [GOVERNANCE.md "Hub-Hosted Tooling"](../GOVERNANCE.md#hub-hosted-tooling). A repository without that tooling has nothing to re-check such a claim against, so a constraint on that tooling is recorded in that tooling's code.
 
 ## When in Doubt