Converge Copilot Instructions and Remaining Intent Files with Hub

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.

AGENTS.md

@@ -2,9 +2,9 @@
 
 **PhotoCleaner** is a .NET 10 console application that prepares media files (photos and videos) for import into photo management systems such as Lightroom, Immich, and PhotoPrism. It analyzes and transforms files through validation, conversion, and verification phases, orchestrating external tools (ExifTool, FFmpeg) through CLI wrappers, with SQLite-backed deduplication and Immich trash integration. The repo also contains an xUnit test project (`PhotoCleanerTests/`) and a benchmark project (`PhotoCleanerBenchmarks/`).
 
-This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md).
+This file is the entry point every coding agent reads first, and it holds only two things: 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), the CI/CD workflow contract in [`WORKFLOW.md`](./WORKFLOW.md), and this project's architecture, processing pipeline, per-command details, and test layout in [`ARCHITECTURE.md`](./ARCHITECTURE.md).
 
-Treat this file and `GOVERNANCE.md` as authoritative for cross-cutting rules, and do not restate their rules elsewhere. This project's own conventionsand behavioral contracts live in [`CODESTYLE.md`](./CODESTYLE.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. This project's own **code-style** conventions, the formatting and language rules a reviewer enforces, live in [`CODESTYLE.md`](./CODESTYLE.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. This project's **design** conventions, its architecture, processing pipeline, and implementation patterns, are `ARCHITECTURE.md`'s own subject and are read there rather than restated here.
 
 ## Fleet Bootstrap
 

CODESTYLE.md

@@ -16,9 +16,9 @@ Use each tool's official casing in task labels, docs, and prose, per the `commen
 
 Each language defines a **clean-compile** verification: the combination of build, formatter, linter, and code-analysis tools that must report clean before a commit. It is exposed as one or more **named** VS Code tasks (or, where a language ships no tasks, documented commands), and those definitions are the same across the fleet. The concrete names live in each language section below.
 
-- **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"][governance-running-the-linters-locally].
+- **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 [OPERATIONS.md "Local Verification"][operations-local-verification].
 - **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 local commit/pre-commit gate is the repo's choice.** No single hook runner fits every language (a `dotnet`-tool runner like Husky.Net suits .NET but not Python), so none is mandated, but that is **not** a recommendation against commit gates. CI is the authoritative backstop regardless, and a local gate is an additive convenience a repo may wire and keep: Husky.Net (and `dotnet husky run` as a style step) for .NET, `pre-commit` for Python. 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.** 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 the hub's `catalog/snippets/` (not carried into this repo). What that gate must cover, and what its absence means for the audit, is [OPERATIONS.md "Local Verification"][operations-local-verification], not restated here. Keeping a working gate is not drift.
 
 ### Analyzer Diagnostics and Suppressions
 
@@ -59,13 +59,13 @@ This is packaged as the `python-codestyle` Skill at `.agents/skills/python-codes
 
 ## Shell
 
-Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, `shellcheck` cleanliness, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules.
+Bash, and only where a program cannot be Python: a bootstrap that installs the interpreter cannot be written in it, and a host tool that must run before a development toolchain exists cannot depend on one. Everything else is Python, with a test under the scripts tree's `tests/` directory. The mandatory `set -Eeuo pipefail` header, the pipefail-versus-early-reader pitfall, self-locating scripts, the `shellcheck`-plus-`shfmt` clean-compile, and the why-not-what comment rule are packaged as the `shell-codestyle` Skill at `.agents/skills/shell-codestyle/SKILL.md` in the hub, not a repo-relative link since that path is hub-local and not carried into every fleet repo. Read the skill for the full rules. Run the clean-compile check itself per [OPERATIONS.md "Local Verification"][operations-local-verification], not by probing `command -v shellcheck`.
 
 <!-- Repo -->
 
 [governance]: ./GOVERNANCE.md
-[governance-running-the-linters-locally]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [governance-verification-discipline]: ./GOVERNANCE.md#verification-discipline
+[operations-local-verification]: ./OPERATIONS.md#local-verification
 [readme]: ./README.md
 [root]: ./.editorconfig
 [vscode-tasks]: ./.vscode/tasks.json

GOVERNANCE.md

@@ -254,7 +254,7 @@ Every repo's GitHub repository details (the About panel) follow a fixed conventi
 
 - [`AGENTS.md`](./AGENTS.md): the agent entry point, carrying context and delegation rules plus the map to the sections above.
 - [`GOVERNANCE.md`](./GOVERNANCE.md), [`CODESTYLE.md`](./CODESTYLE.md), [`WORKFLOW.md`](./WORKFLOW.md), [`AUDIT.md`](./AUDIT.md): the governance and audit docs. This file is the cross-cutting-rules authority, `AUDIT.md` the self-audit of settings, rulesets, and secret names.
-- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot review runbook, plus this project's architecture, processing pipeline, per-command details, and test layout.
+- [`.github/copilot-instructions.md`](./.github/copilot-instructions.md): the Copilot bootstrap and review runbook. [`ARCHITECTURE.md`](./ARCHITECTURE.md): this project's architecture, processing pipeline, per-command implementation details, and test layout.
 - [`PhotoCleaner/`](./PhotoCleaner/): the console application. [`PhotoCleanerTests/`](./PhotoCleanerTests/): the xUnit test project. [`PhotoCleanerBenchmarks/`](./PhotoCleanerBenchmarks/): the BenchmarkDotNet project. [`PhotoCleaner.slnx`](./PhotoCleaner.slnx) is the solution.
 - [`Docker/`](./Docker/): the Dockerfile and the Docker Hub overview the release pipeline publishes.
 - [`.github/workflows/`](./.github/workflows/): the pull request gate, the reusable build tasks, and the publisher.