Keep agent guidance in one root AGENTS.md (closes #31)

The canonical REPO_POLICIES.md now says that guidance for coding agents lives in one AGENTS.md at the repository root, including anything an agent should remember between sessions, and is never committed under a file or directory named after one agent tool or split into separate memory files. This retires the in-repo memory rule that older vendored copies still carry.

AGENTS.md is added to the list of files allowed in the root, which would otherwise contradict the new rule. Both checklists carry the matching item.

Model: opus-5-5

.dockerignore

@@ -18,16 +18,9 @@
 # does not need .git/config; that file can hold a credential, such as a
 # password in a remote URL or the token the CI checkout step stores there.
 # Each submodule keeps a config with the same exposure in its git directory
-# under .git/modules/, nested again for a submodule's own submodules, or in
-# its own .git directory when it keeps one.
-# KNOWN GAP: a submodule whose name has a `config` segment (`config`,
-# `deploy/config`, `config/lib`) loses its whole git directory, because
-# `**/.git/modules/**/config` also matches that segment's directory
-# under .git/modules/. Go's version stamping then fails the build;
-# nothing leaks. Name such a submodule without that segment:
-# `git submodule add --name`.
-**/.git/config
-**/.git/modules/**/config
+# under .git/modules/, nested again for a submodule's own submodules.
+.git/config
+.git/modules/**/config
 
 # Agent scratch: one full checkout of the repo per in-flight agent.
 # Anchored because it occurs once where agents run at the repo root.
@@ -51,9 +44,7 @@
 **/[iI][dD]_[rR][sS][aA]
 **/[iI][dD]_[dD][sS][aA]
 **/[iI][dD]_[eE][cC][dD][sS][aA]
-**/[iI][dD]_[eE][cC][dD][sS][aA]_[sS][kK]
 **/[iI][dD]_[eE][dD]25519
-**/[iI][dD]_[eE][dD]25519_[sS][kK]
 
 # Dependencies: restored inside the image, never copied in.
 **/node_modules

.gitattributes

@@ -1,4 +0,0 @@
-# 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.
-TODO.md merge=union

.gitignore

@@ -42,6 +42,4 @@ node_modules/
 [iI][dD]_[rR][sS][aA]
 [iI][dD]_[dD][sS][aA]
 [iI][dD]_[eE][cC][dD][sS][aA]
-[iI][dD]_[eE][cC][dD][sS][aA]_[sS][kK]
 [iI][dD]_[eE][dD]25519
-[iI][dD]_[eE][dD]25519_[sS][kK]

TODO.md

@@ -21,79 +21,12 @@ 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
-  `TODO.md`: a real conflict elsewhere keeps both versions of the line, and when
-  two new entries share an identical line, one is inserted into the middle of
-  the other, which a rebase can do to an entry already on `next`. Read the
-  merged entries after every merge or rebase. This applies to this repository
-  only; no canonical file changed.
-- 2026-10-04: The canonical `.dockerignore` now also keeps out the git `config`
-  of a submodule that keeps its own `.git` directory, which still reached the
-  image (issue 88): both git patterns now carry the `**/` prefix. A submodule
-  whose name has a `config` segment (`config`, `deploy/config`, `config/lib`)
-  still loses its whole git directory, so Go's version stamping fails the build;
-  the file records this as a `KNOWN GAP:` with the remedy,
-  `git submodule add --name`. Closing it would take a wildcard re-include, which
-  makes BuildKit walk every excluded directory, such as `node_modules`, on every
-  build. `REPO_POLICIES.md` and both checklists say so in the same words.
-- 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`
-  image is Debian-based and has no `apk`, so the old `apk add` instruction
-  failed as written. Nothing is pinned or unpinned; that is still open on
-  issue 72.
-- 2026-10-04: Fixed the server lifecycle example in
-  `prompts/GO_HTTP_SERVER_CONVENTIONS.md` (issue 86). Only fx handles SIGINT and
-  SIGTERM, and `Run()` in `main` exits with the shutdown's exit code. A listen
-  error asks fx to shut down with exit code 1 through `fx.Shutdowner`; a Sentry
-  start failure is returned from the server's start hook instead of calling
-  `os.Exit` from a goroutine, so the stop hooks of what had started still run.
-  The server's stop hook shuts the HTTP server down within 5 seconds and fails
-  when requests are still running. A new paragraph says who owns signals and the
-  exit code.
-- 2026-10-04: `REPO_POLICIES.md` now says how a Go tool a repo needs on the host
-  is pinned (issue 37): installed with `go install` pinned to a commit hash,
-  never tracked as a `go.mod` tool dependency or through a `tools.go` file.
-  golangci-lint is unaffected, since no repo installs it on the host.
-- 2026-10-04: The canonical `.gitignore` and `.dockerignore` now also keep out
-  `id_ecdsa_sk` and `id_ed25519_sk`, the private key files `ssh-keygen` writes
-  for keys backed by a hardware security key (issue 81). Their `.pub` halves
-  stay trackable.
-- 2026-10-04: `package.json` now has `"license": "MIT"`, matching `LICENSE`, so
-  yarn no longer prints "No license field" when `script/bootstrap` runs it
-  inside the Docker phases (issue 76). That was the only yarn warning there.
 - 2026-10-04: `REPO_POLICIES.md` now states that guidance for coding agents
   lives in one `AGENTS.md` at the repository root, never under a file or
   directory named after one agent tool and never in separate memory files (issue
   31). This retires the rule, still present in older vendored copies, that kept
   agent memory as committed files under `.claude/memory/`. `AGENTS.md` joins the
   list of files allowed in the root, and both checklists say so.
-- 2026-10-04: Rewrote the note under the canonical Go `make test` example in
-  `REPO_POLICIES.md` (issue 77), which still named the cache-busting build
-  argument that `--no-cache` replaced. It now says where Go's test result cache
-  can replay a pass: on a developer's machine, where the Makefile target runs,
-  and not in the `test` phase of the `Dockerfile`, whose base image and earlier
-  steps hold no result for the repo's tests.
 - 2026-10-04: The Makefile examples in the Go styleguide and the HTTP server
   conventions now fall back to `dev` when `git describe` prints nothing (outside
   a git checkout, or where git is missing or refuses the checkout), instead of

package.json

@@ -1,5 +1,4 @@
 {
-  "license": "MIT",
   "devDependencies": {
     "prettier": "3.8.1"
   }

prompts/EXISTING_REPO_CHECKLIST.md

@@ -63,15 +63,10 @@ with your task.
       here run anywhere other than the repo root, the anchored entry misses
       `services/api/.claude/`: add anchored entries for those directories.
 - [ ] If the repo embeds a version in a binary: `.dockerignore` lets `.git` into
-      the build context. It keeps out every git `config` at any depth
-      (`**/.git/config`, `**/.git/modules/**/config`): the repository's own,
-      each submodule's under `.git/modules/`, and that of a submodule keeping
-      its own `.git` directory. `git describe` does not need them, and each can
-      hold a credential: a password in a remote URL, or the token the CI
-      checkout step stores there. A submodule whose name has a `config` segment
-      (`config`, `deploy/config`, `config/lib`) loses its whole git directory to
-      `**/.git/modules/**/config`, and Go's version stamping then fails the
-      build: give it a name without that segment (`git submodule add --name`).
+      the build context. It keeps out `.git/config` and each submodule's
+      `config` under `.git/modules/` at any depth (`.git/modules/**/config`),
+      which `git describe` does not need and which can hold a credential: a
+      password in a remote URL, or the token the CI checkout step stores there.
       The stage that compiles has `git` (the Debian Go image has it; an alpine
       one needs `apk add --no-cache git`) and takes the version from the
       `VERSION` build argument when one is given, otherwise from

prompts/GO_HTTP_SERVER_CONVENTIONS.md

@@ -106,9 +106,6 @@ project-root/
 package main
 
 import (
-    "os/signal"
-    "syscall"
-
     "yourproject/internal/config"
     "yourproject/internal/database"
     "yourproject/internal/globals"
@@ -129,9 +126,6 @@ func main() {
     globals.Appname = Appname
     globals.Version = Version
 
-    // A write to a closed stdout or stderr must not end the process.
-    signal.Ignore(syscall.SIGPIPE)
-
     fx.New(
         fx.Provide(
             config.New,
@@ -204,8 +198,7 @@ Providers are resolved automatically by fx, but conceptually follow this order:
    Database)
 6. `middleware.New` - Middleware (depends on Logger, Globals, Config)
 7. `handlers.New` - Handlers (depends on Logger, Globals, Database, Healthcheck)
-8. `server.New` - Server (depends on all above, and on `fx.Shutdowner`, which fx
-   provides itself)
+8. `server.New` - Server (depends on all above)
 
 ---
 
@@ -224,14 +217,16 @@ type ServerParams struct {
     Config     *config.Config
     Middleware *middleware.Middleware
     Handlers   *handlers.Handlers
-    Shutdowner fx.Shutdowner
 }
 
 type Server struct {
     startupTime   time.Time
     port          int
+    exitCode      int
     sentryEnabled bool
     log           *slog.Logger
+    ctx           context.Context
+    cancelFunc    context.CancelFunc
     httpServer    *http.Server
     router        *chi.Mux
     params        ServerParams
@@ -253,15 +248,13 @@ func New(lc fx.Lifecycle, params ServerParams) (*Server, error) {
     lc.Append(fx.Hook{
         OnStart: func(ctx context.Context) error {
             s.startupTime = time.Now()
-            if err := s.enableSentry(); err != nil {
-                return err
-            }
-            s.SetupRoutes()
-            s.httpServer = s.newHTTPServer()
-            go s.serveUntilShutdown()
+            go s.Run()
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            // Server shutdown logic
             return nil
         },
-        OnStop: s.cleanShutdown,
     })
     return s, nil
 }
@@ -271,25 +264,23 @@ func New(lc fx.Lifecycle, params ServerParams) (*Server, error) {
 
 ```go
 // internal/server/http.go
-func (s *Server) newHTTPServer() *http.Server {
-    return &http.Server{
-        Addr:           fmt.Sprintf(":%d", s.params.Config.Port),
+func (s *Server) serveUntilShutdown() {
+    listenAddr := fmt.Sprintf(":%d", s.params.Config.Port)
+    s.httpServer = &http.Server{
+        Addr:           listenAddr,
         ReadTimeout:    10 * time.Second,
         WriteTimeout:   10 * time.Second,
         MaxHeaderBytes: 1 << 20,
         Handler:        s,
     }
-}
 
-// serveUntilShutdown returns when the stop hook shuts the HTTP server down.
-// If it stops for any other reason, such as its port being taken, it asks fx
-// to shut down with exit code 1.
-func (s *Server) serveUntilShutdown() {
-    s.log.Info("http begin listen", "listenaddr", s.httpServer.Addr)
+    s.SetupRoutes()
+
+    s.log.Info("http begin listen", "listenaddr", listenAddr)
     if err := s.httpServer.ListenAndServe(); err != nil && err != http.ErrServerClosed {
         s.log.Error("listen error", "error", err)
-        if err := s.params.Shutdowner.Shutdown(fx.ExitCode(1)); err != nil {
-            s.log.Error("shutdown request failed", "error", err)
+        if s.cancelFunc != nil {
+            s.cancelFunc()
         }
     }
 }
@@ -301,30 +292,43 @@ func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 
 ## Signal Handling and Graceful Shutdown
 
-fx owns SIGINT, SIGTERM and the exit code. `Run()` in `main` waits for one of
-those signals or for a call to `Shutdown()` on `fx.Shutdowner`, runs the stop
-hooks, and exits 0 after a signal, or with the code the call gave in
-`fx.ExitCode`. It exits 1 instead when a start hook or a stop hook returns an
-error; when a start hook fails, fx first runs the stop hooks of everything
-already started. No other code calls `signal.Notify` or `os.Exit`: the listen
-error above asks fx to shut down with `fx.ExitCode(1)`, and a Sentry start
-failure is returned from the start hook. Each component releases its own
-resources in its own stop hook, which fx runs in the reverse order of start.
-
 ```go
-// cleanShutdown is the server's stop hook. It fails when requests are still
-// running after 5 seconds.
-func (s *Server) cleanShutdown(ctx context.Context) error {
-    ctxShutdown, shutdownCancel := context.WithTimeout(ctx, 5*time.Second)
-    defer shutdownCancel()
-    err := s.httpServer.Shutdown(ctxShutdown)
+func (s *Server) serve() int {
+    s.ctx, s.cancelFunc = context.WithCancel(context.Background())
+
+    // Signal watcher
+    go func() {
+        c := make(chan os.Signal, 1)
+        signal.Ignore(syscall.SIGPIPE)
+        signal.Notify(c, os.Interrupt, syscall.SIGTERM)
+        sig := <-c
+        s.log.Info("signal received", "signal", sig)
+        if s.cancelFunc != nil {
+            s.cancelFunc()
+        }
+    }()
+
+    go s.serveUntilShutdown()
+
+    for range s.ctx.Done() {
+    }
+    s.cleanShutdown()
+    return s.exitCode
+}
+
+func (s *Server) cleanShutdown() {
+    s.exitCode = 0
+    ctxShutdown, shutdownCancel := context.WithTimeout(context.Background(), 5*time.Second)
+    if err := s.httpServer.Shutdown(ctxShutdown); err != nil {
+        s.log.Error("server clean shutdown failed", "error", err)
+    }
+    if shutdownCancel != nil {
+        shutdownCancel()
+    }
+    s.cleanupForExit()
     if s.sentryEnabled {
         sentry.Flush(2 * time.Second)
     }
-    if err != nil {
-        return fmt.Errorf("http server shutdown: %w", err)
-    }
-    return nil
 }
 ```
 
@@ -1156,11 +1160,11 @@ s.router.Get("/.well-known/healthcheck", s.h.HandleHealthCheck())
 Sentry is conditionally enabled based on `SENTRY_DSN` environment variable:
 
 ```go
-func (s *Server) enableSentry() error {
+func (s *Server) enableSentry() {
     s.sentryEnabled = false
 
     if s.params.Config.SentryDSN == "" {
-        return nil
+        return
     }
 
     err := sentry.Init(sentry.ClientOptions{
@@ -1168,17 +1172,15 @@ func (s *Server) enableSentry() error {
         Release: fmt.Sprintf("%s-%s", s.params.Globals.Appname, s.params.Globals.Version),
     })
     if err != nil {
-        return fmt.Errorf("sentry init failure: %w", err)
+        s.log.Error("sentry init failure", "error", err)
+        os.Exit(1)
+        return
     }
     s.log.Info("sentry error reporting activated")
     s.sentryEnabled = true
-    return nil
 }
 ```
 
-The server's start hook calls `enableSentry()` and returns its error, so a DSN
-Sentry rejects stops startup and fx exits 1.
-
 Sentry middleware with repanic (bubbles panics to chi's Recoverer):
 
 ```go
@@ -1190,7 +1192,7 @@ if s.sentryEnabled {
 }
 ```
 
-Flush Sentry in the server's stop hook, `cleanShutdown()`:
+Flush Sentry on shutdown:
 
 ```go
 if s.sentryEnabled {

prompts/NEW_REPO_CHECKLIST.md

@@ -71,15 +71,10 @@ Template files can be fetched from:
       will run them in subdirectories, `services/api/.claude/` needs its own
       anchored entry.
     - If the image embeds a version in a binary: `.dockerignore` lets `.git`
-      into the build context. It keeps out every git `config` at any depth
-      (`**/.git/config`, `**/.git/modules/**/config`): the repository's own,
-      each submodule's under `.git/modules/`, and that of a submodule keeping
-      its own `.git` directory. `git describe` does not need them, and each can
-      hold a credential: a password in a remote URL, or the token the CI
-      checkout step stores there. A submodule whose name has a `config` segment
-      (`config`, `deploy/config`, `config/lib`) loses its whole git directory to
-      `**/.git/modules/**/config`, and Go's version stamping then fails the
-      build: give it a name without that segment (`git submodule add --name`).
+      into the build context. It keeps out `.git/config` and each submodule's
+      `config` under `.git/modules/` at any depth (`.git/modules/**/config`),
+      which `git describe` does not need and which can hold a credential: a
+      password in a remote URL, or the token the CI checkout step stores there.
       The stage that compiles has `git` (the Debian Go image has it; an alpine
       one needs `apk add --no-cache git`) and takes the version from the
       `VERSION` build argument when one is given, otherwise from
@@ -124,10 +119,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
@@ -243,28 +236,13 @@ style conventions are in separate documents:
       (e.g. a web frontend compiled in a separate stage), the lint phase must
       create placeholder files so the embed directives resolve. Example:
       `RUN mkdir -p web/dist && touch web/dist/index.html web/dist/style.css`.
-    - If the project requires CGO or system libraries for linting, install them
-      in the lint phase. The `golangci/golangci-lint` image is Debian-based and
-      has no `apk`, so install with `apt-get` under the Debian package name
-      (`libvips-dev`, where alpine says `vips-dev`), and delete the package
-      lists in the same `RUN`, so the layer does not keep them:
-
-        ```dockerfile
-        RUN apt-get update \
-            && apt-get install -y --no-install-recommends libvips-dev \
-            && rm -rf /var/lib/apt/lists/*
-        ```
-
-    - `.dockerignore` lets `.git` into the build context. It keeps out every git
-      `config` at any depth (`**/.git/config`, `**/.git/modules/**/config`): the
-      repository's own, each submodule's under `.git/modules/`, and that of a
-      submodule keeping its own `.git` directory. `git describe` does not need
-      them, and each can hold a credential: a password in a remote URL, or the
-      token the CI checkout step stores there. A submodule whose name has a
-      `config` segment (`config`, `deploy/config`, `config/lib`) loses its whole
-      git directory to `**/.git/modules/**/config`, and Go's version stamping
-      then fails the build: give it a name without that segment
-      (`git submodule add --name`). The stage that compiles has `git` (the
+    - If the project requires CGO or system libraries for linting (e.g.
+      `vips-dev`), install them in the lint phase with `apk add`.
+    - `.dockerignore` lets `.git` into the build context. It keeps out
+      `.git/config` and each submodule's `config` under `.git/modules/` at any
+      depth (`.git/modules/**/config`), which `git describe` does not need and
+      which can hold a credential: a password in a remote URL, or the token the
+      CI checkout step stores there. The stage that compiles has `git` (the
       Debian Go image has it; an alpine one needs `apk add --no-cache git`) and
       takes the version from the `VERSION` build argument when one is given,
       otherwise from `git describe --tags --always`. That gives the tag on a
@@ -286,12 +264,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
@@ -344,19 +317,17 @@ style conventions are in separate documents:
     ```
 
     `-count=1` is required on both invocations: it defeats Go's test _result_
-    cache, so neither run can report a stored pass in place of running the
-    tests. It leaves the build cache alone, so it costs the runtime of the suite
-    and no recompilation.
+    cache, so the target cannot report a pass it did not earn, and the rerun
+    reproduces a failure instead of replaying it. It leaves the build cache
+    alone, so it costs the runtime of the suite and no recompilation.
 
-    That cache is Go's own, separate from Docker's layer cache. Go stores a
-    passing result in its cache directory (`GOCACHE`), and when the same tests
-    run again on unchanged code it prints that result, marked `(cached)`,
-    without running them. That matters on a developer's machine, where this
-    target runs and the directory lasts from one run to the next. The `test`
-    phase of the `Dockerfile` needs no `-count=1`: its base image holds no
-    result for this repo's tests and nothing before its `go test` step runs a
-    test, so there is nothing to replay. `--no-cache` (above) is what makes that
-    step run on an unchanged tree.
+    Note that this is a second, independent cache, stacked below the Docker
+    layer cache that [issue #26](https://git.eeqj.de/sneak/prompts/issues/26)
+    addresses. `CHECK_EPOCH` guarantees the `RUN make test` _step_ re-executes;
+    it does not guarantee `go test` inside that step does any work, because the
+    `GOCACHE` baked into earlier image layers survives into the re-executed
+    step. They are two separate defects requiring two separate fixes, and a fix
+    for one must not be recorded as covering the other.
 
     Python example:
 
@@ -522,11 +493,6 @@ style conventions are in separate documents:
 
     Keep it POSIX sh: no arrays, no `[[`, no `grep -P`.
 
-    A Go tool a repo needs on the host is installed with `go install` pinned to
-    a commit hash (`go install <package>@<commit hash>`). It is never tracked as
-    a `go.mod` tool dependency or through a `tools.go` file, either of which
-    pulls the tool's own dependencies into the repo's `go.mod` and `go.sum`.
-
 - When pinning images or packages by hash, add a comment above the reference
   with the version and date (YYYY-MM-DD).
 
@@ -674,6 +640,8 @@ style conventions are in separate documents:
     - JS: `package.json`, `yarn.lock`, `.prettierrc`, `.prettierignore`
     - Python: `pyproject.toml`
 
-- Guidance for coding agents lives in one `AGENTS.md` at the repository root. It
-  is never committed under a file or directory named after one agent tool, such
-  as `CLAUDE.md` or `.claude/`, and never split into separate memory files.
+- Guidance for coding agents lives in one `AGENTS.md` at the repository root,
+  including anything an agent should remember about the repo from one session to
+  the next. It is never committed under a file or directory named after one
+  agent tool, such as `CLAUDE.md` or `.claude/`, and never split into separate
+  memory files.