Settle Three Carried Sentences Whose Hub Sources Disagreed

.agents/skills/agent-conduct/SKILL.md

@@ -38,7 +38,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`.** Patching the local copy leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.agents/skills/dotnet-codestyle/SKILL.md

@@ -49,8 +49,12 @@ All builds must complete without warnings, enforced three ways:
   surfaced as a warning fails the build and must be fixed or deliberately suppressed at the
   narrowest scope that fits (see Analyzer suppressions below), never left to accumulate.
 - **CI lint backstop.** CI runs the clean-compile checks on every PR as the authoritative gate.
-  The .NET mechanism for a local hook is Husky.Net, wired from the canonical
-  `catalog/snippets/husky/` config in the hub, hub-local and not carried into every fleet repo.
+  Husky.Net is wired from the canonical `catalog/snippets/husky/` config in the hub, hub-local
+  and not carried into every fleet repo. Its hook needs a host .NET toolchain, which a .NET
+  repo already has. The other canonical shape, `catalog/snippets/pre-commit/`, is for a repo
+  without one, and each shape carries whichever language checks its own repo keeps. A repo may
+  also wire an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`.
+  That path and `.pre-commit-config.yaml` are the two the audit reads.
   GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section
   carries the obligation itself, what the hook must cover, its audit treatment, and the
   per-clone enablement steps.
@@ -81,7 +85,7 @@ in place.
 ### Build tasks
 
 Run these from VS Code's task runner (Terminal -> Run Task) or an agent's task-running tool. The
-three clean-compile tasks are carried verbatim, and a repo adds its own convenience tasks (tool
+three clean-compile tasks are carried unchanged, and a repo adds its own convenience tasks (tool
 updates, dependency upgrades, benchmarks) on top:
 
 - `.NET Build`: build with diagnostic verbosity *(clean-compile)*

.agents/skills/python-codestyle/SKILL.md

@@ -96,9 +96,13 @@ those. These are documented commands, and the hub's `vscode-tasks-python.json` s
 VS Code tasks mirror that the fleet baseline expects. Every command-executing task in it is
 `type: process`, and every aggregator is `dependsOn`-only. Neither chains with `&&`, so the mirror
 runs the same on any task shell. CI runs the same clean-compile commands as the authoritative
-backstop. The Python mechanism for a local hook is the `pre-commit` framework, wired from the
-canonical `catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet
-repo. That directory's own README names the second file to copy alongside the config.
+backstop. A repo with no host .NET toolchain wires its local hook from the canonical
+`catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet repo, or
+wires an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`. That
+path and `.pre-commit-config.yaml` are the two the audit reads. The
+runner follows the host toolchain rather than the languages the hook checks, so a repo already
+building .NET may run these same Python checks from the Husky.Net snippet instead. The
+`pre-commit` directory's own README names the second file to copy alongside the config.
 GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section carries
 the obligation itself, what the hook must cover, its audit treatment, and the per-clone enablement
 steps.

.claude-plugin/fleet-skills/.source-digest

@@ -1 +1 @@
-fe834763b58313f7
+5278eece0d27f54b

.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md

@@ -38,7 +38,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`.** Patching the local copy leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.claude-plugin/fleet-skills/skills/dotnet-codestyle/SKILL.md

@@ -49,8 +49,12 @@ All builds must complete without warnings, enforced three ways:
   surfaced as a warning fails the build and must be fixed or deliberately suppressed at the
   narrowest scope that fits (see Analyzer suppressions below), never left to accumulate.
 - **CI lint backstop.** CI runs the clean-compile checks on every PR as the authoritative gate.
-  The .NET mechanism for a local hook is Husky.Net, wired from the canonical
-  `catalog/snippets/husky/` config in the hub, hub-local and not carried into every fleet repo.
+  Husky.Net is wired from the canonical `catalog/snippets/husky/` config in the hub, hub-local
+  and not carried into every fleet repo. Its hook needs a host .NET toolchain, which a .NET
+  repo already has. The other canonical shape, `catalog/snippets/pre-commit/`, is for a repo
+  without one, and each shape carries whichever language checks its own repo keeps. A repo may
+  also wire an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`.
+  That path and `.pre-commit-config.yaml` are the two the audit reads.
   GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section
   carries the obligation itself, what the hook must cover, its audit treatment, and the
   per-clone enablement steps.
@@ -81,7 +85,7 @@ in place.
 ### Build tasks
 
 Run these from VS Code's task runner (Terminal -> Run Task) or an agent's task-running tool. The
-three clean-compile tasks are carried verbatim, and a repo adds its own convenience tasks (tool
+three clean-compile tasks are carried unchanged, and a repo adds its own convenience tasks (tool
 updates, dependency upgrades, benchmarks) on top:
 
 - `.NET Build`: build with diagnostic verbosity *(clean-compile)*

.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md

@@ -96,9 +96,13 @@ those. These are documented commands, and the hub's `vscode-tasks-python.json` s
 VS Code tasks mirror that the fleet baseline expects. Every command-executing task in it is
 `type: process`, and every aggregator is `dependsOn`-only. Neither chains with `&&`, so the mirror
 runs the same on any task shell. CI runs the same clean-compile commands as the authoritative
-backstop. The Python mechanism for a local hook is the `pre-commit` framework, wired from the
-canonical `catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet
-repo. That directory's own README names the second file to copy alongside the config.
+backstop. A repo with no host .NET toolchain wires its local hook from the canonical
+`catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet repo, or
+wires an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`. That
+path and `.pre-commit-config.yaml` are the two the audit reads. The
+runner follows the host toolchain rather than the languages the hook checks, so a repo already
+building .NET may run these same Python checks from the Husky.Net snippet instead. The
+`pre-commit` directory's own README names the second file to copy alongside the config.
 GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section carries
 the obligation itself, what the hook must cover, its audit treatment, and the per-clone enablement
 steps.

.github/copilot-instructions.md

@@ -22,8 +22,10 @@ put a release-bump magnitude in the title. The full contract is in
 
 Follow the fidelity declared for the file. A byte-locked reference to shared infrastructure that
 this repository does not carry is intentional, not a broken link. Raise substantive defects in
-canonical content, but locate the fix at its canonical source instead of proposing a local edit
-that its fidelity rejects.
+canonical content, but locate the fix at its canonical source instead of proposing a local edit.
+An edit to a verbatim unit is reported, as modified content or as stale where it matches an
+earlier canonical revision, and one to an intent or presence unit is reported nowhere, so the
+audit is not what decides this.
 
 ## GitHub Copilot Review Runbook
 

.github/skills/agent-conduct/SKILL.md

@@ -38,7 +38,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`.** Patching the local copy leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.github/skills/dotnet-codestyle/SKILL.md

@@ -49,8 +49,12 @@ All builds must complete without warnings, enforced three ways:
   surfaced as a warning fails the build and must be fixed or deliberately suppressed at the
   narrowest scope that fits (see Analyzer suppressions below), never left to accumulate.
 - **CI lint backstop.** CI runs the clean-compile checks on every PR as the authoritative gate.
-  The .NET mechanism for a local hook is Husky.Net, wired from the canonical
-  `catalog/snippets/husky/` config in the hub, hub-local and not carried into every fleet repo.
+  Husky.Net is wired from the canonical `catalog/snippets/husky/` config in the hub, hub-local
+  and not carried into every fleet repo. Its hook needs a host .NET toolchain, which a .NET
+  repo already has. The other canonical shape, `catalog/snippets/pre-commit/`, is for a repo
+  without one, and each shape carries whichever language checks its own repo keeps. A repo may
+  also wire an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`.
+  That path and `.pre-commit-config.yaml` are the two the audit reads.
   GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section
   carries the obligation itself, what the hook must cover, its audit treatment, and the
   per-clone enablement steps.
@@ -81,7 +85,7 @@ in place.
 ### Build tasks
 
 Run these from VS Code's task runner (Terminal -> Run Task) or an agent's task-running tool. The
-three clean-compile tasks are carried verbatim, and a repo adds its own convenience tasks (tool
+three clean-compile tasks are carried unchanged, and a repo adds its own convenience tasks (tool
 updates, dependency upgrades, benchmarks) on top:
 
 - `.NET Build`: build with diagnostic verbosity *(clean-compile)*

.github/skills/python-codestyle/SKILL.md

@@ -96,9 +96,13 @@ those. These are documented commands, and the hub's `vscode-tasks-python.json` s
 VS Code tasks mirror that the fleet baseline expects. Every command-executing task in it is
 `type: process`, and every aggregator is `dependsOn`-only. Neither chains with `&&`, so the mirror
 runs the same on any task shell. CI runs the same clean-compile commands as the authoritative
-backstop. The Python mechanism for a local hook is the `pre-commit` framework, wired from the
-canonical `catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet
-repo. That directory's own README names the second file to copy alongside the config.
+backstop. A repo with no host .NET toolchain wires its local hook from the canonical
+`catalog/snippets/pre-commit/` directory, hub-local and not carried into every fleet repo, or
+wires an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`. That
+path and `.pre-commit-config.yaml` are the two the audit reads. The
+runner follows the host toolchain rather than the languages the hook checks, so a repo already
+building .NET may run these same Python checks from the Husky.Net snippet instead. The
+`pre-commit` directory's own README names the second file to copy alongside the config.
 GOVERNANCE.md's hub-only "Running the Linters Locally (Known-Working Invocations)" section carries
 the obligation itself, what the hook must cover, its audit treatment, and the per-clone enablement
 steps.

.github/workflows/deploy-site-task.yml

@@ -27,7 +27,7 @@ on:
         required: true
         type: string
     secrets:
-      # The one credential that crosses this reusable workflow's boundary as a named secret.
+      # The credentials that cross this reusable workflow's boundary as named secrets.
       # The host address, the user, and the known-hosts value are GitHub Environment variables instead, since they are integrity-critical but not confidential.
       # The deploy job below reads them directly through its own environment binding.
       DEPLOY_SSH_PRIVATE_KEY:

AGENTS.md

@@ -4,7 +4,7 @@
 
 This file is the entry point every coding agent reads first, and it holds only three things: the bootstrap that says where the canonical rules live and which procedure to follow for the state this repository is actually in, the rules for managing context and delegation, which apply to every task, and a map of where every other rule lives. The rule text itself is in [`GOVERNANCE.md`](./GOVERNANCE.md), one section per topic. Code style lives in [`CODESTYLE.md`](./CODESTYLE.md) (a General section plus per-language sections for .NET, Python, and Shell, the language sections packaged as the `dotnet-codestyle`, `python-codestyle`, and `shell-codestyle` Skills), and the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. A project's **project-specific conventions and public-API/behavioral contracts** (e.g. a "Library API Conventions" section) live in that project's own `AGENTS.md`, **not** in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md), because that file targets GitHub Copilot / VS Code specifically, while this file and `GOVERNANCE.md` are the agent-agnostic ones every coding agent is directed to read, so any rule a reviewer must honor has to live in one of those two files to be provider-independent.
+Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. A project's **project-specific conventions and public-API/behavioral contracts** live in that project's own topical docs. They do **not** go in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md), which targets GitHub Copilot and VS Code specifically. A rule a reviewer must honor therefore has to sit in an agent-agnostic file to be provider-independent. A section of its own in this file is not the alternative. An undeclared section here is drift to reconcile rather than a local liberty.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -18,7 +18,7 @@ Each language defines a **clean-compile** verification: the combination of build
 
 - **Run it after every code change, and it is not the whole gate.** The relevant language's clean-compile must pass before you commit. CI runs those same language checks as a backstop **plus everything else its validation workflow runs**, and all of it reports into the one required status, so a green clean-compile does not predict a green CI. That remainder is at least the doc-lint set (markdownlint, cspell, actionlint, `editorconfig-checker`) and whatever spec, config, and script gates the repo carries, so read the workflow for the full list rather than assuming this sentence enumerates it. What has to pass before a push is the repo's **whole** lint gate, per [GOVERNANCE.md "Verification Discipline"][governance-verification-discipline]. Each linter's known-working invocation is in `GOVERNANCE.md` "Running the Linters Locally (Known-Working Invocations)", a hub-only section read in a hub checkout rather than carried into every fleet repo.
 - **The named task definition is the canonical spec** - its exact command sequence, arguments, and strictness. You may run it through the VS Code task **or** by invoking the equivalent native commands directly, and either is fine **only if the sequence, arguments, and strictness match exactly**. No shortcuts and no more-lenient options (for example, never drop `--verify-no-changes` or loosen a `--severity`).
-- **A working local commit/pre-commit gate is strongly suggested, not the repo's free choice to skip.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so the *mechanism* stays the repo's choice: Husky.Net for .NET, `pre-commit` for Python, canonical configs for both in `catalog/snippets/` in the hub, not a repo-relative path since it is hub-local and not carried into every fleet repo. What that gate must cover, and what its absence means for the audit, is `GOVERNANCE.md` "Running the Linters Locally (Known-Working Invocations)", the same hub-only section, not restated here. Keeping a working gate is not drift.
+- **A working local commit/pre-commit gate is strongly suggested, not the repo's free choice to skip.** The *mechanism* is bounded by the host toolchain rather than by which languages its checks cover, and two canonical shapes carry it. Husky.Net needs a host .NET toolchain, so a repo without one uses `pre-commit`. Any repo may instead wire an equivalent hook of its own at `.husky/pre-commit`, enabled with `core.hooksPath`. Canonical shapes for both live in `catalog/snippets/` in the hub, not a repo-relative path since it is hub-local and not carried into every fleet repo. What that gate must cover, and what its absence means for the audit, is `GOVERNANCE.md` "Running the Linters Locally (Known-Working Invocations)", the same hub-only section, not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions