Spend Hardening Effort Where a Failure Can Actually Occur

.agents/skills/drive-pr/SKILL.md

@@ -165,9 +165,11 @@ maintainer when".
    Disprove a wrong finding with the command and its output, the code path that makes it
    impossible, or the rule that governs it. A finding that is factually correct but not this
    repo's to fix (a verbatim-fidelity manifest entry byte-locking the section, ownership that
-   sits elsewhere) declines the same way: name the boundary and cite what proves it. Either shape
-   closes the thread on its own evidence, and the agent resolves such a thread itself rather than
-   leaving it for the maintainer. What makes that safe is the evidence being checkable by anyone,
+   sits elsewhere) declines the same way: name the boundary and cite what proves it. So does a
+   hardening finding that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" rules out,
+   citing that section and the input or deployment it turns on. Each shape closes the thread on
+   its own evidence, and the agent resolves such a thread itself rather than leaving it for the
+   maintainer. What makes that safe is the evidence being checkable by anyone,
    a command and its output, the code path, the quoted rule, a byte-identical diff, so a decline
    resting on anything weaker is not one of these. An assertion ("this is fine") does not close a
    finding, and outcome 3's value call is the maintainer's, so that thread stays open until they

.agents/skills/fleet-code-review/SKILL.md

@@ -41,6 +41,24 @@ For each candidate finding:
 3. Confirm that the repository does not already prevent it elsewhere.
 4. Prefer one root-cause finding over several symptoms of the same defect.
 5. Omit pure preferences that no repository rule or user-visible risk supports.
+6. Omit a hardening finding that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort",
+   carried below, declines.
+
+<!-- include: GOVERNANCE.md > Trust Boundaries and Hardening Effort -->
+
+Hardening is spent where a failure can actually occur. A defense against a case that cannot happen still costs a review round, a test, and the upkeep of both. So the effort an input gets is set by where it comes from and what its failure would do.
+
+- **Every input is trusted or untrusted, and the class sets the effort.** Trusted input is the maintainer's and what the maintainer controls. That covers files, images, and data handed to a session, settings and secrets files the maintainer writes, and command-line arguments the maintainer types. It covers this repository's content and the hub's, and the maintainer's own hosts with the output read back from them. It covers state files the repository's own scripts write. Untrusted input arrives from outside. That covers a request from an internet client and every field it controls, and upstream release metadata and downloads. It covers a third-party API response, content from an outside contributor, and a bot-authored pull request.
+- **The class follows where data originates, not the channel carrying it.** Any channel holding content an outsider supplied is untrusted, whatever the list above names. That covers an argument or a checked-out tree holding a pull request's content. It covers a host's log line recording an outside request, and a state file caching a third-party response. The same channel carrying the maintainer's input stays trusted.
+- **Against trusted input the only threat is a maintainer's mistake.** Guard a realistic mistake, such as a typo, CRLF line endings, a missing file, or a wrong unit. Guard it only where it would fail silently or destructively, with one check at the point of read that says what is wrong. Do not build a parser for adversarial shapes or test injection through a trusted file. Do not sanitize trusted text read back from the maintainer's own hosts against injection, or file an issue for an attack on trusted input. What agent-authored text may quote from those hosts is still "Representative Data in Agent-Authored Text"'s to decide.
+- **Untrusted input is validated once, at the boundary where it enters**, in proportion to what it can reach from there.
+- **Effort follows likelihood times consequence, for robustness as much as for trust.** Code that fails on its ordinary path in its deployment is a bug rather than a hardening case, and is fixed. A hardening case earns a fix or an issue only where it can realistically occur in the code's actual deployment. Its failure must also be silent or destructive, or be one an outsider can trigger. Every other case is declined with that reason, neither fixed nor filed.
+- **A review finding asking for hardening the bullets above rule out is itself declined**, with no fix and no issue. The decline cites this section and the input or deployment that rules the case out. This binds the reviewer as much as the author, so a reviewer does not raise such a finding. A review brief asks after races, coercions, and platform differences only where the code's deployment can produce one.
+- **A repository names its own boundaries where the classes above leave them unclear.** Its `OPERATIONS.md` lists which concrete inputs are trusted and which are not, under `Configuration Layout`. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above.
+
+`GOVERNANCE.md` "Trust Boundaries and Hardening Effort" keeps the full rules, and the `fleet-code-review` Skill at `.agents/skills/fleet-code-review/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 wherever a change is reviewed.
+
+<!-- /include -->
 
 Review carried fleet content by intent and fidelity. A byte-locked reference to a path that one
 downstream repository does not carry is not a broken link. A substantive defect in canonical

.agents/skills/local-strict-review/SKILL.md

@@ -33,7 +33,7 @@ Dispatches one read-only subagent against this branch's full diff since it forke
 
 The subagent reads the full content of every file the diff and the untracked-file list touch, not just the hunks, since cross-file and whole-file context is exactly what incremental review misses. It reports findings only. It never fixes, stages, or commits anything.
 
-Review criteria are `fleet-code-review`'s "Review the Change" section, reused rather than restated here, plus three traps worth calling out explicitly for a pass that runs before a human or a PR-hosted reviewer ever sees the diff: unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior differences. `fleet-code-review`'s separate "Publish Every Finding" section does not apply here: this skill has no PR to post a comment on and no coverage marker to close a review with, so its own report contract below replaces that section rather than extending it.
+Review criteria are `fleet-code-review`'s "Review the Change" section, reused rather than restated here, plus three traps worth calling out explicitly for a pass that runs before a human or a PR-hosted reviewer ever sees the diff: unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior differences. Each is called out only where the code's actual deployment can produce it, per `GOVERNANCE.md` "Trust Boundaries and Hardening Effort". `fleet-code-review`'s separate "Publish Every Finding" section does not apply here: this skill has no PR to post a comment on and no coverage marker to close a review with, so its own report contract below replaces that section rather than extending it.
 
 ## Running It
 
@@ -55,8 +55,9 @@ Paths: the files `git diff --name-only "$(git merge-base refs/remotes/origin/<ta
   edited lines" instruction below, never as an open-ended exploration.
 Rules that bind this task: quote `fleet-code-review`'s "Review the Change" section into the prompt,
   plus flag unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior
-  differences explicitly. Do not quote "Publish Every Finding", this task's report contract is
-  the Return line below, not a PR comment or a coverage marker.
+  differences explicitly, each only where the code's actual deployment can produce it.
+  Do not quote "Publish Every Finding", this task's report contract is the Return line below,
+  not a PR comment or a coverage marker.
 Return: one finding per line, file:line, the concrete failure scenario, no severity theater.
 Bounds: read-only. No edit, no stage, no commit, no push, no PR-hosted write of any kind.
 <AGENTS.md's own unresolved-rule closing line, quoted verbatim from "Context and Delegation Discipline", not restated here>

.agents/skills/pr-review-conduct/SKILL.md

@@ -244,9 +244,11 @@ After an authorized merge, run the `repo-worktree` post-merge cleanup procedure
    Disprove a wrong finding with the command and its output, the code path that makes it
    impossible, or the rule that governs it. A finding that is factually correct but not this
    repo's to fix (a verbatim-fidelity manifest entry byte-locking the section, ownership that
-   sits elsewhere) declines the same way: name the boundary and cite what proves it. Either shape
-   closes the thread on its own evidence, and the agent resolves such a thread itself rather than
-   leaving it for the maintainer. What makes that safe is the evidence being checkable by anyone,
+   sits elsewhere) declines the same way: name the boundary and cite what proves it. So does a
+   hardening finding that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" rules out,
+   citing that section and the input or deployment it turns on. Each shape closes the thread on
+   its own evidence, and the agent resolves such a thread itself rather than leaving it for the
+   maintainer. What makes that safe is the evidence being checkable by anyone,
    a command and its output, the code path, the quoted rule, a byte-identical diff, so a decline
    resting on anything weaker is not one of these. An assertion ("this is fine") does not close a
    finding, and outcome 3's value call is the maintainer's, so that thread stays open until they
@@ -284,6 +286,8 @@ instance's outcome is context for the new one, never a standing answer to reuse
 never against its confidence label. Classify before responding:
 
 - **Bug**, wrong behavior, missing coverage, a real code or doc divergence. Fix it.
+- **Hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" rules out**, including
+  a test it says not to write. Decline it under outcome 2, even where it reads as missing coverage.
 - **Style or convention**. If the cited rule matches the existing tree, fix the code. If the rule
   contradicts the tree or industry norm, **fix the rule, not the code**, and take it to the
   maintainer (outcome 5) rather than bouncing the same code across rounds.

.claude-plugin/fleet-skills/.source-digests/drive-pr

@@ -1 +1 @@
-03ce7ed14f270d13
+4fbde6878a3ce9e7

.claude-plugin/fleet-skills/.source-digests/fleet-code-review

@@ -1 +1 @@
-d23962efb51cbe7e
+218937ec2fa571fd

.claude-plugin/fleet-skills/.source-digests/local-strict-review

@@ -1 +1 @@
-3e0a74b0a99873ca
+cbd0582547eb3f52

.claude-plugin/fleet-skills/.source-digests/pr-review-conduct

@@ -1 +1 @@
-e3b78814c0099384
+92a8ca385cf20a5a

.claude-plugin/fleet-skills/skills/drive-pr/SKILL.md

@@ -165,9 +165,11 @@ maintainer when".
    Disprove a wrong finding with the command and its output, the code path that makes it
    impossible, or the rule that governs it. A finding that is factually correct but not this
    repo's to fix (a verbatim-fidelity manifest entry byte-locking the section, ownership that
-   sits elsewhere) declines the same way: name the boundary and cite what proves it. Either shape
-   closes the thread on its own evidence, and the agent resolves such a thread itself rather than
-   leaving it for the maintainer. What makes that safe is the evidence being checkable by anyone,
+   sits elsewhere) declines the same way: name the boundary and cite what proves it. So does a
+   hardening finding that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" rules out,
+   citing that section and the input or deployment it turns on. Each shape closes the thread on
+   its own evidence, and the agent resolves such a thread itself rather than leaving it for the
+   maintainer. What makes that safe is the evidence being checkable by anyone,
    a command and its output, the code path, the quoted rule, a byte-identical diff, so a decline
    resting on anything weaker is not one of these. An assertion ("this is fine") does not close a
    finding, and outcome 3's value call is the maintainer's, so that thread stays open until they

.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md

@@ -41,6 +41,24 @@ For each candidate finding:
 3. Confirm that the repository does not already prevent it elsewhere.
 4. Prefer one root-cause finding over several symptoms of the same defect.
 5. Omit pure preferences that no repository rule or user-visible risk supports.
+6. Omit a hardening finding that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort",
+   carried below, declines.
+
+<!-- include: GOVERNANCE.md > Trust Boundaries and Hardening Effort -->
+
+Hardening is spent where a failure can actually occur. A defense against a case that cannot happen still costs a review round, a test, and the upkeep of both. So the effort an input gets is set by where it comes from and what its failure would do.
+
+- **Every input is trusted or untrusted, and the class sets the effort.** Trusted input is the maintainer's and what the maintainer controls. That covers files, images, and data handed to a session, settings and secrets files the maintainer writes, and command-line arguments the maintainer types. It covers this repository's content and the hub's, and the maintainer's own hosts with the output read back from them. It covers state files the repository's own scripts write. Untrusted input arrives from outside. That covers a request from an internet client and every field it controls, and upstream release metadata and downloads. It covers a third-party API response, content from an outside contributor, and a bot-authored pull request.
+- **The class follows where data originates, not the channel carrying it.** Any channel holding content an outsider supplied is untrusted, whatever the list above names. That covers an argument or a checked-out tree holding a pull request's content. It covers a host's log line recording an outside request, and a state file caching a third-party response. The same channel carrying the maintainer's input stays trusted.
+- **Against trusted input the only threat is a maintainer's mistake.** Guard a realistic mistake, such as a typo, CRLF line endings, a missing file, or a wrong unit. Guard it only where it would fail silently or destructively, with one check at the point of read that says what is wrong. Do not build a parser for adversarial shapes or test injection through a trusted file. Do not sanitize trusted text read back from the maintainer's own hosts against injection, or file an issue for an attack on trusted input. What agent-authored text may quote from those hosts is still "Representative Data in Agent-Authored Text"'s to decide.
+- **Untrusted input is validated once, at the boundary where it enters**, in proportion to what it can reach from there.
+- **Effort follows likelihood times consequence, for robustness as much as for trust.** Code that fails on its ordinary path in its deployment is a bug rather than a hardening case, and is fixed. A hardening case earns a fix or an issue only where it can realistically occur in the code's actual deployment. Its failure must also be silent or destructive, or be one an outsider can trigger. Every other case is declined with that reason, neither fixed nor filed.
+- **A review finding asking for hardening the bullets above rule out is itself declined**, with no fix and no issue. The decline cites this section and the input or deployment that rules the case out. This binds the reviewer as much as the author, so a reviewer does not raise such a finding. A review brief asks after races, coercions, and platform differences only where the code's deployment can produce one.
+- **A repository names its own boundaries where the classes above leave them unclear.** Its `OPERATIONS.md` lists which concrete inputs are trusted and which are not, under `Configuration Layout`. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above.
+
+`GOVERNANCE.md` "Trust Boundaries and Hardening Effort" keeps the full rules, and the `fleet-code-review` Skill at `.agents/skills/fleet-code-review/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 wherever a change is reviewed.
+
+<!-- /include -->
 
 Review carried fleet content by intent and fidelity. A byte-locked reference to a path that one
 downstream repository does not carry is not a broken link. A substantive defect in canonical

.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md

@@ -33,7 +33,7 @@ Dispatches one read-only subagent against this branch's full diff since it forke
 
 The subagent reads the full content of every file the diff and the untracked-file list touch, not just the hunks, since cross-file and whole-file context is exactly what incremental review misses. It reports findings only. It never fixes, stages, or commits anything.
 
-Review criteria are `fleet-code-review`'s "Review the Change" section, reused rather than restated here, plus three traps worth calling out explicitly for a pass that runs before a human or a PR-hosted reviewer ever sees the diff: unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior differences. `fleet-code-review`'s separate "Publish Every Finding" section does not apply here: this skill has no PR to post a comment on and no coverage marker to close a review with, so its own report contract below replaces that section rather than extending it.
+Review criteria are `fleet-code-review`'s "Review the Change" section, reused rather than restated here, plus three traps worth calling out explicitly for a pass that runs before a human or a PR-hosted reviewer ever sees the diff: unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior differences. Each is called out only where the code's actual deployment can produce it, per `GOVERNANCE.md` "Trust Boundaries and Hardening Effort". `fleet-code-review`'s separate "Publish Every Finding" section does not apply here: this skill has no PR to post a comment on and no coverage marker to close a review with, so its own report contract below replaces that section rather than extending it.
 
 ## Running It
 
@@ -55,8 +55,9 @@ Paths: the files `git diff --name-only "$(git merge-base refs/remotes/origin/<ta
   edited lines" instruction below, never as an open-ended exploration.
 Rules that bind this task: quote `fleet-code-review`'s "Review the Change" section into the prompt,
   plus flag unguarded type coercions, TOCTOU/race conditions, and platform-specific behavior
-  differences explicitly. Do not quote "Publish Every Finding", this task's report contract is
-  the Return line below, not a PR comment or a coverage marker.
+  differences explicitly, each only where the code's actual deployment can produce it.
+  Do not quote "Publish Every Finding", this task's report contract is the Return line below,
+  not a PR comment or a coverage marker.
 Return: one finding per line, file:line, the concrete failure scenario, no severity theater.
 Bounds: read-only. No edit, no stage, no commit, no push, no PR-hosted write of any kind.
 <AGENTS.md's own unresolved-rule closing line, quoted verbatim from "Context and Delegation Discipline", not restated here>