State That the Hub Commits Audit Reports and a Downstream Session Resyncs Itself

.agents/skills/check-this-repo/SKILL.md

@@ -19,8 +19,8 @@ description: >-
 
 ## Why this exists
 
-A downstream repo today only finds out it has drifted when someone runs a hub-driven resync
-against it by name. Nothing notices from the inside on its own. This skill is that inside check,
+A downstream repo today only finds out it has drifted when someone runs an audit or a resync
+against it. Nothing notices from the inside on its own. This skill is that inside check,
 run with no hub-side operator watching, so a stale Skills install or an out-of-date `AGENTS.md`
 pointer gets noticed and fixed without waiting for a fleet-wide sweep to reach this particular
 repo.
@@ -50,8 +50,8 @@ repo.
   needs a review.
 
 Nothing else. This skill never re-vendors a carried file, never deletes one, and never applies a
-setting or ruleset. Those are `resync-a-repo`'s job, driven from the hub with a named target,
-never a downstream repo acting on itself.
+setting or ruleset. Converging that drift is a resync, a separate change on its own branch, run
+per the hub's `RESYNC.md` by this repo's own session or by `resync-a-repo` from a hub checkout.
 
 ## Refresh cadence
 
@@ -67,12 +67,11 @@ refresh stays out of scope until the fleet has evidence the manual cadence fails
 
 - **A carried section that differs from the hub in a way that reads as a genuine local addition**
   rather than plain staleness, the exact case `carried-instruction-file-guard` exists to protect.
-  Report precisely what differs and stop there. Per AUDIT.md, a downstream repo does not write its
-  own audit report or resync itself against the hub, it names what it found and points at
-  `resync-a-repo`, run from a hub checkout, as the next step.
+  Report precisely what differs and stop there, naming a resync as the next step, where
+  `carried-instruction-file-guard` decides the merge.
 - **Anything the installer alone cannot resolve**, a broken `claude` CLI marketplace
   registration, a settings or ruleset drift, a workflow interface mismatch. Name it and hand it to
-  the maintainer or a hub-driven resync rather than patching around it locally.
+  the maintainer or a resync per the hub's `RESYNC.md` rather than patching around it locally.
 
 ## Answering "why isn't a fleet rule applying"
 

.agents/skills/resync-a-repo/SKILL.md

@@ -91,6 +91,7 @@ rather than leaving it standing.
 One focused pull request per drift class, branched from the target's `develop`, never a direct
 push to a protected branch and never a hand edit outside a pull request. Close the review loop,
 per the `pr-review-conduct` skill, before asking the maintainer for merge permission. The
-maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and
-commit the report once authorized, per `git-commit-conventions`, done means measured, not
-applied.
+maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and,
+from the hub checkout, commit the report under the hub's own `reports/` once authorized, per
+`AUDIT.md` section 8 and `git-commit-conventions`. A session resyncing its own repository
+leaves the report to a hub-side audit instead. Done means measured, not applied.

.claude-plugin/fleet-skills/.source-digests/check-this-repo

@@ -1 +1 @@
-7a6a5ddfebffe626
+f5075baedbd8a74f

.claude-plugin/fleet-skills/.source-digests/resync-a-repo

@@ -1 +1 @@
-2f7f3442e2a948d6
+179f4010403d2fa1

.claude-plugin/fleet-skills/skills/check-this-repo/SKILL.md

@@ -19,8 +19,8 @@ description: >-
 
 ## Why this exists
 
-A downstream repo today only finds out it has drifted when someone runs a hub-driven resync
-against it by name. Nothing notices from the inside on its own. This skill is that inside check,
+A downstream repo today only finds out it has drifted when someone runs an audit or a resync
+against it. Nothing notices from the inside on its own. This skill is that inside check,
 run with no hub-side operator watching, so a stale Skills install or an out-of-date `AGENTS.md`
 pointer gets noticed and fixed without waiting for a fleet-wide sweep to reach this particular
 repo.
@@ -50,8 +50,8 @@ repo.
   needs a review.
 
 Nothing else. This skill never re-vendors a carried file, never deletes one, and never applies a
-setting or ruleset. Those are `resync-a-repo`'s job, driven from the hub with a named target,
-never a downstream repo acting on itself.
+setting or ruleset. Converging that drift is a resync, a separate change on its own branch, run
+per the hub's `RESYNC.md` by this repo's own session or by `resync-a-repo` from a hub checkout.
 
 ## Refresh cadence
 
@@ -67,12 +67,11 @@ refresh stays out of scope until the fleet has evidence the manual cadence fails
 
 - **A carried section that differs from the hub in a way that reads as a genuine local addition**
   rather than plain staleness, the exact case `carried-instruction-file-guard` exists to protect.
-  Report precisely what differs and stop there. Per AUDIT.md, a downstream repo does not write its
-  own audit report or resync itself against the hub, it names what it found and points at
-  `resync-a-repo`, run from a hub checkout, as the next step.
+  Report precisely what differs and stop there, naming a resync as the next step, where
+  `carried-instruction-file-guard` decides the merge.
 - **Anything the installer alone cannot resolve**, a broken `claude` CLI marketplace
   registration, a settings or ruleset drift, a workflow interface mismatch. Name it and hand it to
-  the maintainer or a hub-driven resync rather than patching around it locally.
+  the maintainer or a resync per the hub's `RESYNC.md` rather than patching around it locally.
 
 ## Answering "why isn't a fleet rule applying"
 

.claude-plugin/fleet-skills/skills/resync-a-repo/SKILL.md

@@ -91,6 +91,7 @@ rather than leaving it standing.
 One focused pull request per drift class, branched from the target's `develop`, never a direct
 push to a protected branch and never a hand edit outside a pull request. Close the review loop,
 per the `pr-review-conduct` skill, before asking the maintainer for merge permission. The
-maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and
-commit the report once authorized, per `git-commit-conventions`, done means measured, not
-applied.
+maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and,
+from the hub checkout, commit the report under the hub's own `reports/` once authorized, per
+`AUDIT.md` section 8 and `git-commit-conventions`. A session resyncing its own repository
+leaves the report to a hub-side audit instead. Done means measured, not applied.

.github/skills/check-this-repo/SKILL.md

@@ -19,8 +19,8 @@ description: >-
 
 ## Why this exists
 
-A downstream repo today only finds out it has drifted when someone runs a hub-driven resync
-against it by name. Nothing notices from the inside on its own. This skill is that inside check,
+A downstream repo today only finds out it has drifted when someone runs an audit or a resync
+against it. Nothing notices from the inside on its own. This skill is that inside check,
 run with no hub-side operator watching, so a stale Skills install or an out-of-date `AGENTS.md`
 pointer gets noticed and fixed without waiting for a fleet-wide sweep to reach this particular
 repo.
@@ -50,8 +50,8 @@ repo.
   needs a review.
 
 Nothing else. This skill never re-vendors a carried file, never deletes one, and never applies a
-setting or ruleset. Those are `resync-a-repo`'s job, driven from the hub with a named target,
-never a downstream repo acting on itself.
+setting or ruleset. Converging that drift is a resync, a separate change on its own branch, run
+per the hub's `RESYNC.md` by this repo's own session or by `resync-a-repo` from a hub checkout.
 
 ## Refresh cadence
 
@@ -67,12 +67,11 @@ refresh stays out of scope until the fleet has evidence the manual cadence fails
 
 - **A carried section that differs from the hub in a way that reads as a genuine local addition**
   rather than plain staleness, the exact case `carried-instruction-file-guard` exists to protect.
-  Report precisely what differs and stop there. Per AUDIT.md, a downstream repo does not write its
-  own audit report or resync itself against the hub, it names what it found and points at
-  `resync-a-repo`, run from a hub checkout, as the next step.
+  Report precisely what differs and stop there, naming a resync as the next step, where
+  `carried-instruction-file-guard` decides the merge.
 - **Anything the installer alone cannot resolve**, a broken `claude` CLI marketplace
   registration, a settings or ruleset drift, a workflow interface mismatch. Name it and hand it to
-  the maintainer or a hub-driven resync rather than patching around it locally.
+  the maintainer or a resync per the hub's `RESYNC.md` rather than patching around it locally.
 
 ## Answering "why isn't a fleet rule applying"
 

.github/skills/resync-a-repo/SKILL.md

@@ -91,6 +91,7 @@ rather than leaving it standing.
 One focused pull request per drift class, branched from the target's `develop`, never a direct
 push to a protected branch and never a hand edit outside a pull request. Close the review loop,
 per the `pr-review-conduct` skill, before asking the maintainer for merge permission. The
-maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and
-commit the report once authorized, per `git-commit-conventions`, done means measured, not
-applied.
+maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and,
+from the hub checkout, commit the report under the hub's own `reports/` once authorized, per
+`AUDIT.md` section 8 and `git-commit-conventions`. A session resyncing its own repository
+leaves the report to a hub-side audit instead. Done means measured, not applied.

AGENTS.md

@@ -24,7 +24,7 @@ flowchart TD
 - **No repository yet, or a local tree with no remote.** Follow the hub's `STANDUP.md` from section 0. That file is hub-only and deliberately not carried, because a repository needing it cannot be relied on to hold a current copy. Note that nothing in it creates the GitHub repository, which is an outward-facing write requiring explicit permission, so section 0A is the list handed to the maintainer before anything else starts.
 - **A repository with no carried instruction set, or a partial one.** Carry the baseline per the hub's `STANDUP.md` sections 1A and 2, which resolve what this repository is owed from its declared types and workflow model. Absent files are not drift to re-vendor, they are a baseline that never arrived, and the two are fixed differently.
 - **A repository with the instruction set, current or stale.** Follow the hub's `RESYNC.md`, which runs `AUDIT.md` end to end for the findings and then applies each one in an order that matters, since the rules govern what comes after them, a deletion must precede the re-vendor that would otherwise refresh the file, and only some findings are mechanically detectable at all. An audit that reports drift and stops is half the procedure.
-- **A repository that believes it is conformant.** Run the audit anyway and commit the report, because conformance asserted without a report is conformance nobody can check. This is the same procedure as the case above and is listed separately only because it is the one most often skipped.
+- **A repository that believes it is conformant.** Run the audit anyway, because conformance asserted without a report is conformance nobody can check. The hub commits that report under its own `reports/`, since a report written by the repository it measures is a claim rather than evidence, so a session in the repository being audited fixes its own drift in its own repository, files its findings about the hub as issues, and leaves the report to a hub-side audit rather than opening a hub pull request to write its own. This is the same procedure as the case above and is listed separately only because it is the one most often skipped.
 
 Three rules bound every path above. **Read the hub's `main` branch as ground truth**, since that is the promoted and gated state, and read `develop` only to detect divergence. **Reach the hub as a checkout of your own and fetch it immediately before reading it**, because a clone is whatever it last fetched rather than the branch it names, and work only in that checkout rather than in one that another task is using, per [`GOVERNANCE.md`](./GOVERNANCE.md) "Repository Boundaries and Write Safety" and "Hub-Hosted Tooling". And **the audit is read-only**: it produces a report and never edits the repository it measures, so a fix is a separate, reviewable change.
 

AUDIT.md

@@ -214,7 +214,7 @@ flowchart LR
   finding -->|"one repo"| s10["10: Converge, branch + fix + PR"]
   s10 --> review["review loop to green"]
   review --> merge["maintainer merges"]
-  merge --> reaudit["re-audit, commit the report"]
+  merge --> reaudit["re-audit, the hub commits the report"]
   s9 --> reaudit
 ```
 

RESYNC.md

@@ -122,7 +122,7 @@ The other half is section 4 of [`AUDIT.md`][audit]: no check belonging to a proj
 - **The maintainer merges.** The agent drives to green and stops.
 - **Fix systemic drift in the hub instead.** Where many repositories share a drift, fix the rule or add a check here and let a re-audit re-flag it, rather than hand-patching each repository for a shared cause.
 
-**Done means measured, not applied.** Re-run the audit after the merge and commit the report, because a convergence asserted without a report is a convergence nobody can check.
+**Done means measured, not applied.** Re-run the audit after the merge, because a convergence asserted without a report is a convergence nobody can check. The hub commits that report under its own `reports/` per [`AUDIT.md`][audit] section 8, so a session resyncing its own repository leaves the report to a hub-side audit.
 
 <!-- Repo -->
 

host-setup/agent-safety/claude/claude-md-fleet.md

@@ -7,6 +7,6 @@ This section enables rather than restricts, so it is bounded by everything above
 
 - **Route by what the repository actually holds, not by what it should hold.** The two differ precisely when this matters. No repository yet means the hub's `STANDUP.md` from section 0, and note that nothing in that file creates the GitHub repository, which is an outward-facing write needing explicit permission. A missing or partial instruction set means carrying the baseline per that file's sections 1A and 2, since absent files are a baseline that never arrived rather than drift to re-vendor. An instruction set that is present, current or stale, means the hub's `RESYNC.md`, which runs `AUDIT.md` end to end for the findings and then applies each one in the order that file sets.
 - **Read the hub's `main` branch as ground truth**, since that is the promoted and gated state, and read `develop` only to detect divergence. The same holds for a repository being audited, for both workflow models.
-- **The audit is read-only and produces a report.** It never edits the repository it measures, so a fix is a separate and reviewable change. An audit that reports drift and stops is half the procedure, and a conformance claim carrying no committed report is a claim nobody can check.
+- **The audit is read-only and produces a report.** It never edits the repository it measures, so a fix is a separate and reviewable change. An audit that reports drift and stops is half the procedure, and a conformance claim carrying no committed report is a claim nobody can check. The hub commits that report under its own `reports/`.
 - **Reach the hub as a checkout of your own, fetched immediately before it is read.** A clone is whatever it last fetched rather than the branch it names, so a stale one answers confidently instead of failing, and a single file lifted out of the tree runs against whatever the caller happens to have. Work only in that checkout rather than in one that another task is using, since a blanket add, a hard reset, or a branch switch in a tree someone else is editing destroys work while every command is individually correct.
 <!-- fleet-bootstrap v1 end -->