From 8313a48ee354d72905c1a0546ae69d03c9d996a6 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 7 Oct 2026 14:19:38 -0700 Subject: [PATCH 1/5] Spend Hardening Effort Where a Failure Can Actually Occur Add a GOVERNANCE.md "Trust Boundaries and Hardening Effort" section: trusted against untrusted input, likelihood times consequence for robustness hardening too, and a decline for a review finding asking for hardening the section rules out. fleet-code-review "Review the Change" carries it as a generated include, local-strict-review asks after races, coercions, and platform differences only where the deployment can produce one, and pr-review-conduct's decline outcome cites it. Fixes #2501 Co-Authored-By: Claude Opus 5.5 --- .agents/skills/drive-pr/SKILL.md | 5 ++++- .agents/skills/fleet-code-review/SKILL.md | 17 +++++++++++++++++ .agents/skills/local-strict-review/SKILL.md | 4 ++-- .agents/skills/pr-review-conduct/SKILL.md | 5 ++++- .../fleet-skills/.source-digests/drive-pr | 2 +- .../.source-digests/fleet-code-review | 2 +- .../.source-digests/local-strict-review | 2 +- .../.source-digests/pr-review-conduct | 2 +- .../fleet-skills/skills/drive-pr/SKILL.md | 5 ++++- .../skills/fleet-code-review/SKILL.md | 17 +++++++++++++++++ .../skills/local-strict-review/SKILL.md | 4 ++-- .../skills/pr-review-conduct/SKILL.md | 5 ++++- .github/skills/drive-pr/SKILL.md | 5 ++++- .github/skills/fleet-code-review/SKILL.md | 17 +++++++++++++++++ .github/skills/local-strict-review/SKILL.md | 4 ++-- .github/skills/pr-review-conduct/SKILL.md | 5 ++++- AGENTS.md | 1 + GOVERNANCE.md | 13 +++++++++++++ spec/files.json | 2 +- spec/section-model.md | 1 + 20 files changed, 101 insertions(+), 17 deletions(-) diff --git a/.agents/skills/drive-pr/SKILL.md b/.agents/skills/drive-pr/SKILL.md index 7a4bddb79..aa658fb69 100644 --- a/.agents/skills/drive-pr/SKILL.md +++ b/.agents/skills/drive-pr/SKILL.md @@ -165,7 +165,10 @@ 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 + sits elsewhere) declines the same way: name the boundary and cite what proves it. A finding + asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines + declines the same way too, citing that section and the input or deployment that rules the + case out. Any of these shapes 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 diff --git a/.agents/skills/fleet-code-review/SKILL.md b/.agents/skills/fleet-code-review/SKILL.md index 42d3cda9d..402e4a25f 100644 --- a/.agents/skills/fleet-code-review/SKILL.md +++ b/.agents/skills/fleet-code-review/SKILL.md @@ -41,6 +41,23 @@ 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. + + + +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. 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. +- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. +- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. 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. + + 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 diff --git a/.agents/skills/local-strict-review/SKILL.md b/.agents/skills/local-strict-review/SKILL.md index 3b4f9e9d8..f7390f6ac 100644 --- a/.agents/skills/local-strict-review/SKILL.md +++ b/.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 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,7 +55,7 @@ Paths: the files `git diff --name-only "$(git merge-base refs/remotes/origin/ 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. 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. +- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. +- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. 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. + + 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 diff --git a/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md b/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md index 3b4f9e9d8..f7390f6ac 100644 --- a/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md +++ b/.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 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,7 +55,7 @@ Paths: the files `git diff --name-only "$(git merge-base refs/remotes/origin/ 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. 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. +- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. +- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. 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. + + 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 diff --git a/.github/skills/local-strict-review/SKILL.md b/.github/skills/local-strict-review/SKILL.md index 3b4f9e9d8..f7390f6ac 100644 --- a/.github/skills/local-strict-review/SKILL.md +++ b/.github/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 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,7 +55,7 @@ Paths: the files `git diff --name-only "$(git merge-base refs/remotes/origin/ Date: Wed, 7 Oct 2026 14:24:10 -0700 Subject: [PATCH 2/5] Classify Input by Origin and Close the Likelihood Gap in the Hardening Rule Address the local review: trust follows where data originates, every case short of realistic and silent or destructive is declined, the contradicting host-tool example is gone, the boundary list lives in OPERATIONS.md, and the decline sentences are shortened. Co-Authored-By: Claude Opus 5.5 --- .agents/skills/drive-pr/SKILL.md | 11 +++++------ .agents/skills/fleet-code-review/SKILL.md | 11 ++++++----- .agents/skills/local-strict-review/SKILL.md | 7 ++++--- .agents/skills/pr-review-conduct/SKILL.md | 11 +++++------ .claude-plugin/fleet-skills/.source-digests/drive-pr | 2 +- .../fleet-skills/.source-digests/fleet-code-review | 2 +- .../fleet-skills/.source-digests/local-strict-review | 2 +- .../fleet-skills/.source-digests/pr-review-conduct | 2 +- .claude-plugin/fleet-skills/skills/drive-pr/SKILL.md | 11 +++++------ .../fleet-skills/skills/fleet-code-review/SKILL.md | 11 ++++++----- .../fleet-skills/skills/local-strict-review/SKILL.md | 7 ++++--- .../fleet-skills/skills/pr-review-conduct/SKILL.md | 11 +++++------ .github/skills/drive-pr/SKILL.md | 11 +++++------ .github/skills/fleet-code-review/SKILL.md | 11 ++++++----- .github/skills/local-strict-review/SKILL.md | 7 ++++--- .github/skills/pr-review-conduct/SKILL.md | 11 +++++------ GOVERNANCE.md | 11 ++++++----- 17 files changed, 70 insertions(+), 69 deletions(-) diff --git a/.agents/skills/drive-pr/SKILL.md b/.agents/skills/drive-pr/SKILL.md index aa658fb69..1370c5943 100644 --- a/.agents/skills/drive-pr/SKILL.md +++ b/.agents/skills/drive-pr/SKILL.md @@ -165,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/.agents/skills/fleet-code-review/SKILL.md b/.agents/skills/fleet-code-review/SKILL.md index 402e4a25f..e9afe37c7 100644 --- a/.agents/skills/fleet-code-review/SKILL.md +++ b/.agents/skills/fleet-code-review/SKILL.md @@ -48,12 +48,13 @@ For each candidate finding: 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. 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. -- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. -- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **A review finding asking for hardening this section declines 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. 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. diff --git a/.agents/skills/local-strict-review/SKILL.md b/.agents/skills/local-strict-review/SKILL.md index f7390f6ac..296809a51 100644 --- a/.agents/skills/local-strict-review/SKILL.md +++ b/.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, each 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. +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/ diff --git a/.agents/skills/pr-review-conduct/SKILL.md b/.agents/skills/pr-review-conduct/SKILL.md index c7aab4ce3..de51be0eb 100644 --- a/.agents/skills/pr-review-conduct/SKILL.md +++ b/.agents/skills/pr-review-conduct/SKILL.md @@ -244,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/.claude-plugin/fleet-skills/.source-digests/drive-pr b/.claude-plugin/fleet-skills/.source-digests/drive-pr index 0f6e54d51..aa1f34b9c 100644 --- a/.claude-plugin/fleet-skills/.source-digests/drive-pr +++ b/.claude-plugin/fleet-skills/.source-digests/drive-pr @@ -1 +1 @@ -69fbe7556baa8e1a +4fbde6878a3ce9e7 diff --git a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review index e58eea370..75a003dd3 100644 --- a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review +++ b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review @@ -1 +1 @@ -3c9bf067c74f6993 +5ec14b7f8fc96857 diff --git a/.claude-plugin/fleet-skills/.source-digests/local-strict-review b/.claude-plugin/fleet-skills/.source-digests/local-strict-review index d6d5f0be7..ce6572444 100644 --- a/.claude-plugin/fleet-skills/.source-digests/local-strict-review +++ b/.claude-plugin/fleet-skills/.source-digests/local-strict-review @@ -1 +1 @@ -f61abca944ad65c6 +cbd0582547eb3f52 diff --git a/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct b/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct index b2c36b6a4..e941434d7 100644 --- a/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct +++ b/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct @@ -1 +1 @@ -bac913368c410921 +062200718eafe1b3 diff --git a/.claude-plugin/fleet-skills/skills/drive-pr/SKILL.md b/.claude-plugin/fleet-skills/skills/drive-pr/SKILL.md index aa658fb69..1370c5943 100644 --- a/.claude-plugin/fleet-skills/skills/drive-pr/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/drive-pr/SKILL.md @@ -165,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md index 402e4a25f..e9afe37c7 100644 --- a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md @@ -48,12 +48,13 @@ For each candidate finding: 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. 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. -- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. -- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **A review finding asking for hardening this section declines 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. 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. diff --git a/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md b/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md index f7390f6ac..296809a51 100644 --- a/.claude-plugin/fleet-skills/skills/local-strict-review/SKILL.md +++ b/.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, each 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. +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/ diff --git a/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md b/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md index c7aab4ce3..de51be0eb 100644 --- a/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md @@ -244,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/.github/skills/drive-pr/SKILL.md b/.github/skills/drive-pr/SKILL.md index aa658fb69..1370c5943 100644 --- a/.github/skills/drive-pr/SKILL.md +++ b/.github/skills/drive-pr/SKILL.md @@ -165,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/.github/skills/fleet-code-review/SKILL.md b/.github/skills/fleet-code-review/SKILL.md index 402e4a25f..e9afe37c7 100644 --- a/.github/skills/fleet-code-review/SKILL.md +++ b/.github/skills/fleet-code-review/SKILL.md @@ -48,12 +48,13 @@ For each candidate finding: 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. 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. -- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. -- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **A review finding asking for hardening this section declines 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. 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. diff --git a/.github/skills/local-strict-review/SKILL.md b/.github/skills/local-strict-review/SKILL.md index f7390f6ac..296809a51 100644 --- a/.github/skills/local-strict-review/SKILL.md +++ b/.github/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, each 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. +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/ diff --git a/.github/skills/pr-review-conduct/SKILL.md b/.github/skills/pr-review-conduct/SKILL.md index c7aab4ce3..de51be0eb 100644 --- a/.github/skills/pr-review-conduct/SKILL.md +++ b/.github/skills/pr-review-conduct/SKILL.md @@ -244,12 +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. A finding - asking for hardening that `GOVERNANCE.md` "Trust Boundaries and Hardening Effort" declines - declines the same way too, citing that section and the input or deployment that rules the - case out. Any of these shapes - 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 diff --git a/GOVERNANCE.md b/GOVERNANCE.md index ccd8ee397..6ca07a97e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -214,12 +214,13 @@ The checks that separate work actually done from work that merely reports succes 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. 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. -- **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 filter text read back from the maintainer's own hosts, or file an issue for an attack on trusted input. +- **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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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.** A case earns a fix or an issue only where it can occur in the code's actual deployment. Its failure must also be silent or destructive. A case that cannot occur there, or an unlikely one that fails loudly, is declined with that reason, neither fixed nor filed. On a single-user host tool, that declines a concurrent writer and an interrupt landing between two cleanup steps. -- **A review finding asking for hardening this section declines is itself declined**, citing this section, with no fix and no issue. 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 own documentation lists which concrete inputs are trusted and which are not. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **A review finding asking for hardening this section declines 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. 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. From 7d510b259de62ed541142bc404be7fe5f06674e1 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 7 Oct 2026 14:26:42 -0700 Subject: [PATCH 3/5] Treat Outsider Data in Host Output and Outsider-Triggered Failures as Untrusted Address the second local review: a host log line recording an outside client's request is untrusted, a failure an outsider can trigger earns a fix, and the boundary list sits under OPERATIONS.md Configuration Layout. Co-Authored-By: Claude Opus 5.5 --- .agents/skills/fleet-code-review/SKILL.md | 8 ++++---- .../fleet-skills/.source-digests/fleet-code-review | 2 +- .../fleet-skills/skills/fleet-code-review/SKILL.md | 8 ++++---- .github/skills/fleet-code-review/SKILL.md | 8 ++++---- GOVERNANCE.md | 8 ++++---- 5 files changed, 17 insertions(+), 17 deletions(-) diff --git a/.agents/skills/fleet-code-review/SKILL.md b/.agents/skills/fleet-code-review/SKILL.md index e9afe37c7..6442b0c9a 100644 --- a/.agents/skills/fleet-code-review/SKILL.md +++ b/.agents/skills/fleet-code-review/SKILL.md @@ -49,12 +49,12 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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. +- **The class follows where data originates, not the channel carrying it.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. 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.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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 this section declines 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. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **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. diff --git a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review index 75a003dd3..c4a4a6e13 100644 --- a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review +++ b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review @@ -1 +1 @@ -5ec14b7f8fc96857 +5d746a5d73591489 diff --git a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md index e9afe37c7..6442b0c9a 100644 --- a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md @@ -49,12 +49,12 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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. +- **The class follows where data originates, not the channel carrying it.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. 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.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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 this section declines 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. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **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. diff --git a/.github/skills/fleet-code-review/SKILL.md b/.github/skills/fleet-code-review/SKILL.md index e9afe37c7..6442b0c9a 100644 --- a/.github/skills/fleet-code-review/SKILL.md +++ b/.github/skills/fleet-code-review/SKILL.md @@ -49,12 +49,12 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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. +- **The class follows where data originates, not the channel carrying it.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. 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.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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 this section declines 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. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **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. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 6ca07a97e..d58c94375 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -215,12 +215,12 @@ The checks that separate work actually done from work that merely reports succes 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. 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 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. +- **The class follows where data originates, not the channel carrying it.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. 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.** A 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. Every other case is declined with that reason, neither fixed nor filed. +- **Effort follows likelihood times consequence, for robustness as much as for trust.** A 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 this section declines 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. A session or a reviewer then applies this section without re-deriving it. A repository naming none uses the classes above. +- **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. From 02971e2c1a703d529fa34c9270b85e77162240c3 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 7 Oct 2026 14:30:01 -0700 Subject: [PATCH 4/5] Keep Plain Bugs Out of the Hardening Decline and Classify Every Channel by Origin Address the third local review: code failing on its ordinary path is a bug and is fixed, any channel holding outsider content is untrusted, and pr-review-conduct's triage list routes ruled-out hardening to outcome 2. Co-Authored-By: Claude Opus 5.5 --- .agents/skills/fleet-code-review/SKILL.md | 4 ++-- .agents/skills/pr-review-conduct/SKILL.md | 2 ++ .claude-plugin/fleet-skills/.source-digests/fleet-code-review | 2 +- .claude-plugin/fleet-skills/.source-digests/pr-review-conduct | 2 +- .claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md | 4 ++-- .claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md | 2 ++ .github/skills/fleet-code-review/SKILL.md | 4 ++-- .github/skills/pr-review-conduct/SKILL.md | 2 ++ GOVERNANCE.md | 4 ++-- 9 files changed, 16 insertions(+), 10 deletions(-) diff --git a/.agents/skills/fleet-code-review/SKILL.md b/.agents/skills/fleet-code-review/SKILL.md index 6442b0c9a..5aebbc5b9 100644 --- a/.agents/skills/fleet-code-review/SKILL.md +++ b/.agents/skills/fleet-code-review/SKILL.md @@ -49,10 +49,10 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. The same channel carrying the maintainer's input stays trusted. +- **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.** A 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. +- **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 this section declines 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. diff --git a/.agents/skills/pr-review-conduct/SKILL.md b/.agents/skills/pr-review-conduct/SKILL.md index de51be0eb..bb5f1c0fa 100644 --- a/.agents/skills/pr-review-conduct/SKILL.md +++ b/.agents/skills/pr-review-conduct/SKILL.md @@ -286,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. diff --git a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review index c4a4a6e13..fe6221e16 100644 --- a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review +++ b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review @@ -1 +1 @@ -5d746a5d73591489 +e3fab522ebff360b diff --git a/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct b/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct index e941434d7..40c066bf5 100644 --- a/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct +++ b/.claude-plugin/fleet-skills/.source-digests/pr-review-conduct @@ -1 +1 @@ -062200718eafe1b3 +92a8ca385cf20a5a diff --git a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md index 6442b0c9a..5aebbc5b9 100644 --- a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md @@ -49,10 +49,10 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. The same channel carrying the maintainer's input stays trusted. +- **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.** A 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. +- **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 this section declines 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. diff --git a/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md b/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md index de51be0eb..bb5f1c0fa 100644 --- a/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md @@ -286,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. diff --git a/.github/skills/fleet-code-review/SKILL.md b/.github/skills/fleet-code-review/SKILL.md index 6442b0c9a..5aebbc5b9 100644 --- a/.github/skills/fleet-code-review/SKILL.md +++ b/.github/skills/fleet-code-review/SKILL.md @@ -49,10 +49,10 @@ For each candidate finding: 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. The same channel carrying the maintainer's input stays trusted. +- **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.** A 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. +- **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 this section declines 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. diff --git a/.github/skills/pr-review-conduct/SKILL.md b/.github/skills/pr-review-conduct/SKILL.md index de51be0eb..bb5f1c0fa 100644 --- a/.github/skills/pr-review-conduct/SKILL.md +++ b/.github/skills/pr-review-conduct/SKILL.md @@ -286,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. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index d58c94375..17bab326d 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -215,10 +215,10 @@ The checks that separate work actually done from work that merely reports succes 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.** An argument, an environment variable, or a checked-out tree holding a pull request's content is untrusted. So is a host's log line recording what an outside client sent. The same channel carrying the maintainer's input stays trusted. +- **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.** A 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. +- **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 this section declines 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. From 3f7fb717855b94a34d7e04724c2e5817f7b4d06d Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 7 Oct 2026 14:36:51 -0700 Subject: [PATCH 5/5] Name the Declined Hardening Directly in the Review-Finding Bullet Co-Authored-By: Claude Opus 5.5 --- .agents/skills/fleet-code-review/SKILL.md | 2 +- .claude-plugin/fleet-skills/.source-digests/fleet-code-review | 2 +- .claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md | 2 +- .github/skills/fleet-code-review/SKILL.md | 2 +- GOVERNANCE.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/.agents/skills/fleet-code-review/SKILL.md b/.agents/skills/fleet-code-review/SKILL.md index 5aebbc5b9..b218bd7c9 100644 --- a/.agents/skills/fleet-code-review/SKILL.md +++ b/.agents/skills/fleet-code-review/SKILL.md @@ -53,7 +53,7 @@ Hardening is spent where a failure can actually occur. A defense against a case - **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 this section declines 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 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. diff --git a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review index fe6221e16..ab1fc3c6f 100644 --- a/.claude-plugin/fleet-skills/.source-digests/fleet-code-review +++ b/.claude-plugin/fleet-skills/.source-digests/fleet-code-review @@ -1 +1 @@ -e3fab522ebff360b +218937ec2fa571fd diff --git a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md index 5aebbc5b9..b218bd7c9 100644 --- a/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md +++ b/.claude-plugin/fleet-skills/skills/fleet-code-review/SKILL.md @@ -53,7 +53,7 @@ Hardening is spent where a failure can actually occur. A defense against a case - **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 this section declines 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 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. diff --git a/.github/skills/fleet-code-review/SKILL.md b/.github/skills/fleet-code-review/SKILL.md index 5aebbc5b9..b218bd7c9 100644 --- a/.github/skills/fleet-code-review/SKILL.md +++ b/.github/skills/fleet-code-review/SKILL.md @@ -53,7 +53,7 @@ Hardening is spent where a failure can actually occur. A defense against a case - **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 this section declines 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 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. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 17bab326d..625da237a 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -219,7 +219,7 @@ Hardening is spent where a failure can actually occur. A defense against a case - **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 this section declines 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 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.