Allow go test on one package while iterating (closes #51)

Follows sneak's ruling at
#51 (comment). An agent
whose work is confined to one package may run `go test` directly on that
package's suite, or on individual tests in it, while iterating. `go build`,
`go vet` and the linter still go through make targets. The full `make check`
is still required before every push. The `Makefile` gains nothing.

The rule on Docker now says the lint and test gates run there, because a run
while iterating is not a gate.

Model: opus-5-5

TODO.md

@@ -21,6 +21,13 @@ fmt-check, and commit.
 
 # Completed Steps
 
+- 2026-11-04: An agent whose work is confined to one package may run `go test`
+  directly on that package's suite, or on individual tests in it, while
+  iterating (https://git.eeqj.de/sneak/prompts/issues/51), on sneak's ruling at
+  https://git.eeqj.de/sneak/prompts/issues/51#issuecomment-167600. The full
+  `make check` is still required before every push, and the `Makefile` gains
+  nothing. The rule on Docker now names the lint and test gates, because a run
+  while iterating is not one.
 - 2026-11-04: node, yarn, npm, python, pip and venv now come from the
   distribution with no version and no hash
   (https://git.eeqj.de/sneak/prompts/issues/146), on sneak's ruling at

prompts/CODE_STYLEGUIDE_JS.md

@@ -8,7 +8,8 @@ last_modified: 2026-11-04
 
 1. Use yarn for package management, avoid using npm.
 
-1. Install node from the distribution, in whatever version it packages.
+1. Install node from the distribution. If its version is too old, use a newer
+   distribution.
 
 1. Use `prettier` for code formatting, with four spaces for indentation.
 

prompts/EXISTING_REPO_CHECKLIST.md

@@ -88,12 +88,12 @@ with your task.
     `pip install --require-hashes`. It installs the packages from `Pipfile.lock`
     with `pipenv install --deploy`, plus `--dev` when the tests need the
     development packages. It sets `PIP_ONLY_BINARY=:all:` for both installs, so
-    a package with no wheel for the image stops the install. It installs no
-    Python there, because the tests use the distribution's, which a step above
-    it installs. `Pipfile` names no `python_version`, because `--deploy` stops
-    when the distribution's Python differs from it. The tests run after
-    `ARG CACHEBUST`, and every other stage installs its Python packages after
-    it, as in the Python `test` phase example in `REPO_POLICIES.md`
+    a package with no wheel for the image stops the install. In that step it
+    installs no Python, because a step above it already did. `Pipfile` names no
+    `python_version`, because `--deploy` stops when the distribution's Python
+    differs from it. The tests run after `ARG CACHEBUST`, and every other stage
+    installs its Python packages after it, as in the Python `test` phase example
+    in `REPO_POLICIES.md`
 
 - [ ] The gate phases invoke their tools directly, never through `make lint` or
       `script/test` — those are themselves a `docker build` and would recurse
@@ -167,7 +167,9 @@ with your task.
     - [ ] JS: `package.json`, `yarn.lock`, `.prettierrc`, `.prettierignore`
           (fetch from
           `https://git.eeqj.de/sneak/prompts/raw/branch/main/.prettierrc` and
-          `https://git.eeqj.de/sneak/prompts/raw/branch/main/.prettierignore`)
+          `https://git.eeqj.de/sneak/prompts/raw/branch/main/.prettierignore`).
+          Make the first `yarn.lock` with yarn 1, from a distribution that
+          packages it, such as Alpine (`apk add nodejs yarn`).
     - [ ] Python: `pyproject.toml`
     - [ ] Docs/writing: `.prettierrc`, `.prettierignore` (same URLs as above)
 
@@ -208,11 +210,11 @@ with your task.
       with a one-line message when yarn's major version is not 1.
 - [ ] A `Dockerfile` stage copies `yarn.lock` before it runs `script/bootstrap`
       only if that stage needs yarn. A stage that needs yarn starts from an
-      image whose distribution packages yarn 1, which today means Alpine.
+      image whose distribution packages yarn 1, such as Alpine.
 - [ ] `script/bootstrap`, `script/fmt` and `script/fmt-check` run yarn by
       whichever name is present: `yarn`, or `yarnpkg` on Debian and Ubuntu. With
-      neither name on `PATH`, they print one line saying to run
-      `script/bootstrap`, and exit 1.
+      neither name on `PATH`, `script/fmt` and `script/fmt-check` print one line
+      saying to run `script/bootstrap`, and exit 1.
 - [ ] `script/bootstrap` installs no linter of its own — delete the block, its
       version variables and its call site. A JS repo's `yarn install` stays; it
       brings a linter along with every other dependency, and no verdict is taken

prompts/NEW_REPO_CHECKLIST.md

@@ -156,12 +156,12 @@ Template files can be fetched from:
         the packages from `Pipfile.lock` with `pipenv install --deploy`, plus
         `--dev` when the tests need the development packages. It sets
         `PIP_ONLY_BINARY=:all:` for both installs, so a package with no wheel
-        for the image stops the install. It installs no Python there, because
-        the tests use the distribution's, which a step above it installs.
-        `Pipfile` names no `python_version`, because `--deploy` stops when the
-        distribution's Python differs from it. The tests run after
-        `ARG CACHEBUST`, and every other stage installs its Python packages
-        after it, as in the Python `test` phase example in `REPO_POLICIES.md`
+        for the image stops the install. In that step it installs no Python,
+        because a step above it already did. `Pipfile` names no
+        `python_version`, because `--deploy` stops when the distribution's
+        Python differs from it. The tests run after `ARG CACHEBUST`, and every
+        other stage installs its Python packages after it, as in the Python
+        `test` phase example in `REPO_POLICIES.md`
 
     - Server: the final stage builds and runs the application
     - Non-server: the final stage brings up the dev environment
@@ -179,7 +179,9 @@ Template files can be fetched from:
           `https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml` and,
           in the same commit, set the lint phase digest to the one named in the
           `.golangci.yml` paragraph of `REPO_POLICIES.md`)
-    - [ ] JS: `yarn init`, `yarn add --dev prettier`
+    - [ ] JS: `yarn init`, `yarn add --dev prettier`. `script/bootstrap`
+          installs no yarn until `yarn.lock` exists, so use yarn 1 from a
+          distribution that packages it, such as Alpine (`apk add nodejs yarn`).
     - [ ] Python: `pyproject.toml`
 
 ## Configure script/ Entrypoints and Makefile
@@ -204,7 +206,7 @@ are thin shims calling them. Model scripts:
       inline or by running it.
 - [ ] A `Dockerfile` stage copies `yarn.lock` before it runs `script/bootstrap`
       only if that stage needs yarn. A stage that needs yarn starts from an
-      image whose distribution packages yarn 1, which today means Alpine.
+      image whose distribution packages yarn 1, such as Alpine.
 - [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`,
       then `install-precommit`, plus repo-specific init
 - [ ] `script/test` / `make test` —
@@ -236,8 +238,8 @@ are thin shims calling them. Model scripts:
       `script/fmt-check` runs the formatter on the host.
 - [ ] `script/bootstrap`, `script/fmt` and `script/fmt-check` run yarn by
       whichever name is present: `yarn`, or `yarnpkg` on Debian and Ubuntu. With
-      neither name on `PATH`, they print one line saying to run
-      `script/bootstrap`, and exit 1.
+      neither name on `PATH`, `script/fmt` and `script/fmt-check` print one line
+      saying to run `script/bootstrap`, and exit 1.
 - [ ] No `docker build` in `script/` leaves a dangling image behind:
       `script/lint` and `script/test` write no image, and `script/docker` and
       `script/cibuild` tag theirs

prompts/REPO_POLICIES.md

@@ -123,25 +123,28 @@ style conventions are in separate documents:
 
     `script/bootstrap` installs node, yarn and the node packages only when
     `yarn.lock` is in the tree. With no `yarn.lock`, it installs no node and no
-    yarn, and it does not check yarn's version.
+    yarn, and it does not check yarn's version. Make a repository's first
+    `yarn.lock` with yarn 1, from a distribution that packages it, such as
+    Alpine (`apk add nodejs yarn`).
 
     Debian and Ubuntu name the yarn command `yarnpkg`. `script/bootstrap`,
     `script/fmt` and `script/fmt-check` each carry the same small function that
-    runs whichever name is present. With neither name on `PATH`, the function
-    prints one line saying to run `script/bootstrap`, and exits 1.
+    runs whichever name is present. With neither name on `PATH`, `script/fmt`
+    and `script/fmt-check` print one line saying to run `script/bootstrap`, and
+    exit 1.
 
     With `yarn.lock` in the tree, `script/bootstrap` stops with a one-line
     message when yarn's major version is not 1, before it installs any node
     packages. Debian 13 and Ubuntu 26.04 package yarn 4. With
     `--frozen-lockfile`, yarn 4 refuses a yarn 1 `yarn.lock`. Without that flag,
-    it rewrites the file in its own format, with its own hashes in place of
-    these. Alpine and Ubuntu 24.04 package yarn 1, so a host uses one of those.
+    it rewrites the file in its own format, with yarn 4 hashes in place of the
+    yarn 1 ones. A host whose distribution packages yarn 4 moves to one that
+    packages yarn 1, such as Alpine or Ubuntu 24.04.
 
     A `Dockerfile` stage copies `yarn.lock` before it runs `script/bootstrap`
     only if that stage needs yarn. A stage that needs yarn starts from an image
-    whose distribution packages yarn 1, which today means Alpine. The Python and
-    Go stages below need no yarn, so they copy no `yarn.lock` before that step
-    and never reach the stop.
+    whose distribution packages yarn 1, such as Alpine. The Python and Go stages
+    below need no yarn and copy no `yarn.lock`, so they never reach the stop.
 
     `script/cibuild` runs the CI build, and the Gitea workflow calls it. The
     script changes to the repo root, runs `script/bootstrap`, runs
@@ -173,6 +176,12 @@ style conventions are in separate documents:
   instead of invoking the underlying tools directly. The Makefile is the single
   source of truth for how these operations are run.
 
+    An agent whose work is confined to one package may run `go test` directly on
+    that package's suite, or on individual tests in it, while iterating. This is
+    the only exception to this rule. `go build`, `go vet` and the linter still
+    go through make targets. A run while iterating is not a gate, so the full
+    `make check` is still required before every push.
+
 - The Makefile is authoritative documentation for how the repo is used. Beyond
   the required targets above, it should have targets for every common operation:
     - running a local development server (`make run`, `make dev`)
@@ -204,9 +213,9 @@ style conventions are in separate documents:
     and the dependency manifests it needs (`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
-  and nothing else:
+- **The lint and test gates run in Docker, as phases of the `Dockerfile`.**
+  There is no separate lint file. `script/lint` and `script/test` each build one
+  phase and nothing else:
 
     ```sh
     docker build --build-arg CACHEBUST="$(date +%s)-$$" \
@@ -552,9 +561,9 @@ style conventions are in separate documents:
       A cache mount is shared by every build on the host, and nothing checks its
       files again.
 
-    A Python repository's `script/bootstrap` adds these lines. The `ensurepip`
-    test fails when python is missing, and also when Debian's venv package is
-    missing:
+    A Python repository's `script/bootstrap` adds these lines in `main`, above
+    the last `echo`. The `ensurepip` test fails when python is missing, and also
+    when Debian's venv package is missing:
 
     ```sh
     if [ ! -x "$HOME/.pipenv/bin/pip" ]; then
@@ -568,6 +577,13 @@ style conventions are in separate documents:
     "$HOME/.pipenv/bin/pipenv" install --dev --deploy
     ```
 
+    Make `script/requirements.txt` once, with
+    `echo pipenv | pip-compile --generate-hashes --allow-unsafe -o script/requirements.txt -`.
+    `pip-compile` comes from Alpine's `py3-pip-tools` package; Debian and Ubuntu
+    do not package `pip-tools`. Make the first `Pipfile.lock` with
+    `$HOME/.pipenv/bin/pipenv lock`, after the `pip install` line has installed
+    pipenv.
+
     In the example below, `script/bootstrap` finds `make`, `git`, python and
     venv already installed. The example copies no `yarn.lock`, so
     `script/bootstrap` installs no node and no yarn.
@@ -583,7 +599,7 @@ style conventions are in separate documents:
     # stay in their own layer when script/ changes.
     RUN apt-get update \
         && apt-get install -y --no-install-recommends ca-certificates make git \
-            python3 python3-pip python3-venv \
+            python3 python3-venv \
         && rm -rf /var/lib/apt/lists/*
     # script/bootstrap installs pipenv in a virtual environment at
     # $HOME/.pipenv, and the tests below run that pipenv.