Merge TODO.md with git's union merge (closes #98)

Every PR adds an entry at the top of Completed Steps in TODO.md, so each
merge to next left every other open PR conflicting there. A root
.gitattributes now marks TODO.md merge=union, so two branches inserting
at the same place merge without a conflict.

Git now never reports a conflict in TODO.md: a real conflict elsewhere
keeps both versions of the line, and two new entries that share an
identical line end up one inside the other. The .gitattributes comment
and the TODO.md entry say to read the merged entries after every merge
or rebase.

This applies to this repository only; nothing canonical changes.

Model: opus-5-5

.gitattributes

@@ -1,4 +1,3 @@
-# Every PR adds an entry at the top of TODO.md's Completed Steps; union keeps
-# both sides instead of conflicting. Git never reports a conflict here: read
-# the merged entries after every merge or rebase.
+# Git never reports a conflict in TODO.md: read the merged entries after every
+# merge or rebase, because an entry can land in the middle of another.
 TODO.md merge=union

TODO.md

@@ -21,24 +21,6 @@ fmt-check, and commit.
 
 # Completed Steps
 
-- 2026-10-04: Went through the fleet findings recorded on 2026-08-09 (issue 62)
-  and added the two rules `REPO_POLICIES.md` did not yet state: a new or changed
-  check is proven by planting a defect it must catch; and a change to a separate
-  workflow limited to `main` is first run from the feature branch, added to that
-  workflow's `branches` list and removed again before merging. The other
-  findings were already stated, replaced by `--no-cache`, about git worktrees,
-  or about how agents work together. The warning against
-  `golangci-lint config verify` is dropped because sneak ruled on
-  https://git.eeqj.de/sneak/prompts/issues/40 (2026-08-10) that there is no
-  config check step and the config is assumed valid; a vendored `.golangci.yml`
-  stays byte-identical to the canonical copy. The issue gives each reason.
-- 2026-10-04: `REPO_POLICIES.md` now says which `Dockerfile` stages run
-  `script/bootstrap` (issue 90). The gate phases and the build stage start from
-  their pinned base images and install what those images lack either inline, as
-  the canonical Go `Dockerfile` does for `git`, or by running
-  `script/bootstrap`, as this repo's own `Dockerfile` does for its yarn
-  packages. The development environment stage, the final stage of a non-server
-  repo, runs `script/bootstrap`. The new repo checklist says the same.
 - 2026-10-04: Added a root `.gitattributes` that merges `TODO.md` with git's
   union merge (issue 98), so two branches that each add an entry at the top of
   Completed Steps merge without a conflict. Git now never reports a conflict in

prompts/NEW_REPO_CHECKLIST.md

@@ -124,10 +124,8 @@ are thin shims calling them. Model scripts:
 - [ ] `script/bootstrap` / `make bootstrap` — installs all dependencies,
       idempotently, assuming nothing (pkg manager detection nix/apt/brew/apk;
       node used if present, else pinned version via nvm from a hash-verified
-      archive; pinned yarn via corepack); a non-server repo's development
-      environment stage runs it instead of inline installs; a gate phase or the
-      build stage installs what its base image lacks either inline or by running
-      it
+      archive; pinned yarn via corepack); Dockerfile runs it instead of inline
+      installs
 - [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`,
       then `install-precommit`, plus repo-specific init
 - [ ] `script/test` / `make test` — `docker build --no-cache --target test .`,

prompts/REPO_POLICIES.md

@@ -104,14 +104,10 @@ style conventions are in separate documents:
   `lint` phase and a `test` phase, with the final stage depending on both so the
   image cannot be built unless they pass. For non-server repos the final stage
   brings up a development environment; for server repos it is the runtime image.
-  The gate phases and the build stage start from their pinned base images and
-  install what those images lack either inline, as the canonical Go `Dockerfile`
-  below does for `git`, or by running `script/bootstrap`, as the `prompts`
-  repo's own `Dockerfile` does for its yarn packages. The development
-  environment stage installs development prerequisites by running
-  `script/bootstrap` rather than duplicating its installs inline. A stage that
-  runs `script/bootstrap` COPYs `script/` and the dependency manifests
-  (`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before running it.
+  Dockerfiles install development prerequisites by running `script/bootstrap`
+  rather than duplicating installs inline; COPY `script/` and the dependency
+  manifests (`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before
+  running it.
 
 - **Linting and testing run in Docker, as phases of the `Dockerfile`.** There is
   no separate lint file. `script/lint` and `script/test` each build one phase
@@ -160,9 +156,6 @@ 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
@@ -286,12 +279,7 @@ 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. A separate
-  workflow limited to `main` by a `branches` list under `on: push` cannot be
-  checked by review: to try a change to it, add the feature branch to that list
-  and push, then remove the branch from the list again before merging. Keep any
-  job in it that publishes behind `if: github.ref_name == 'main'`, so the run
-  from the feature branch publishes nothing.
+  from a run of its own gates rather than from a cache entry.
 
 - Use platform-standard formatters: `black` for Python, `prettier` for
   JS/CSS/Markdown/HTML, `go fmt` for Go. Always use default configuration with