Fold the August fleet findings into the policies, or drop them (closes #62)

Three findings from 2026-08-09 were rules a repository must follow that
`prompts/REPO_POLICIES.md` did not yet state, and are now added where a
reader would look: `golangci-lint config verify` is never run from
`make lint`, the lint phase or CI, since it fetches its schema over the
network; a new or changed check is proven by planting a defect it must
catch; and a workflow step that runs only on `main` is first run from
the feature branch. The issue records why every other finding was
dropped.

Model: opus-5-5

TODO.md

@@ -21,6 +21,13 @@ fmt-check, and commit.
 
 # Completed Steps
 
+- 2026-10-04: Went through the fleet findings recorded on 2026-08-09 (issue 62)
+  and added the three rules `REPO_POLICIES.md` did not yet state:
+  `golangci-lint config verify` is never run from `make lint`, the lint phase or
+  CI; a new or changed check is proven by planting a defect it must catch; and a
+  workflow step that runs only on `main` is first run from the feature branch.
+  The other findings were already stated, replaced by `--no-cache`, about git
+  worktrees, or about how agents work together; the issue gives each reason.
 - 2026-10-04: The note under the canonical Go `Dockerfile` example in
   `REPO_POLICIES.md` now installs lint-phase system libraries with `apt-get`
   under their Debian package names (issue 83). The `golangci/golangci-lint`

prompts/REPO_POLICIES.md

@@ -156,6 +156,9 @@ style conventions are in separate documents:
   not evidence that anything ran: a sub-second build reporting success is a
   cache hit, not a result. Never invalidate by pruning — `docker builder prune`
   and friends destroy a build cache shared with every other build on the host.
+  When a check is added or changed, prove it works by planting a defect it must
+  catch and watching the run fail on it, then revert the defect. A green run
+  alone shows neither that the check ran nor that it covers what it should.
 
 - **The gate phases are separate stages, and the build stage depends on both.**
   The lint phase is based on the `golangci/golangci-lint` image (pinned by
@@ -274,7 +277,10 @@ style conventions are in separate documents:
   carry the same guarantee, because its gate phases may come from the cache. The
   image build is uncached and so runs the gate phases a second time. That is the
   price of the rule above, and it is worth paying: the image that ships is built
-  from a run of its own gates rather than from a cache entry.
+  from a run of its own gates rather than from a cache entry. A workflow step
+  that runs only on `main` cannot be checked by review. Before merging it,
+  temporarily add the feature branch to its trigger and push, keeping any job
+  that publishes behind `if: github.ref_name == 'main'`.
 
 - Use platform-standard formatters: `black` for Python, `prettier` for
   JS/CSS/Markdown/HTML, `go fmt` for Go. Always use default configuration with
@@ -482,6 +488,9 @@ style conventions are in separate documents:
   the two prompted the change: the canonical copy can name linters that an older
   golangci-lint rejects, and a newer golangci-lint can add linters that
   `default: all` switches on until the canonical copy disables them.
+  `golangci-lint config verify` is never run from `make lint`, the lint phase or
+  CI: it fetches the schema it checks against over the network, unpinned, on
+  every run.
 
 - **`script/bootstrap` installs a pinned tool by comparing versions, never by
   testing presence.** An `if ! command -v <tool>; then install; fi` guard tests