Commit yarn 4 in the tree and install with --immutable (closes #149)

Follows sneak's ruling at
#149 (comment). This
repository now carries yarn 4.18.1 under .yarn/releases. The
distribution's yarn only starts that file, and that file does the work.
yarn.lock is converted once, and script/bootstrap installs with
--immutable instead of stopping on yarn's major version. Node is the
distribution's newest Node package: nodejs-current on Alpine and
nodejs_latest on nix. Every Dockerfile stage that needs yarn also copies
.yarnrc.yml and .yarn/releases/. The policies and both checklists say
so, with the steps for converting and for a new repository.

Model: opus-5-5

TODO.md

@@ -21,11 +21,6 @@ fmt-check, and commit.
 
 # Completed Steps
 
-- 2026-11-06: The pinning rule in `prompts/REPO_POLICIES.md` now opens with its
-  scope: what we download and install ourselves in scripts and Dockerfiles
-  (https://git.eeqj.de/sneak/prompts/issues/154). Distribution packages are
-  outside the rule, and updating and upgrading them is allowed. Both checklists
-  say the same.
 - 2026-11-04: Each repository now commits yarn 4 and installs with
   `yarn install --immutable` (https://git.eeqj.de/sneak/prompts/issues/149), on
   sneak's ruling at

prompts/EXISTING_REPO_CHECKLIST.md

@@ -1,6 +1,6 @@
 ---
 title: Existing Repo Checklist
-last_modified: 2026-11-06
+last_modified: 2026-11-04
 ---
 
 Use this checklist when beginning work in a repo that may not yet conform to our
@@ -169,12 +169,12 @@ with your task.
           from `https://git.eeqj.de/sneak/prompts/raw/branch/main/.prettierrc`
           and
           `https://git.eeqj.de/sneak/prompts/raw/branch/main/.prettierignore`).
-    - [ ] Any repository with `yarn.lock`: that file is in yarn 4's format. If
-          its second line says `yarn lockfile v1`, convert it with the steps
-          below. Do them in one commit with the re-vendored scripts, because
-          yarn 1 ignores `--immutable` and exits 0 on a tree with no
-          `.yarnrc.yml`. Run them with any distribution's node and yarn, and use
-          `yarnpkg` on Debian and Ubuntu.
+    - [ ] JS: `yarn.lock` is in yarn 4's format. If its second line says
+          `yarn lockfile v1`, convert it with the steps below. Do them in one
+          commit with the re-vendored scripts, because yarn 1 ignores
+          `--immutable` and exits 0 on a tree with no `.yarnrc.yml`. Run them
+          with any distribution's node and yarn, and use `yarnpkg` on Debian and
+          Ubuntu.
         1. Read the version from `yarnPath` in
            `https://git.eeqj.de/sneak/prompts/raw/branch/main/.yarnrc.yml`.
         2. Run `yarn set version <version>`. It writes
@@ -188,7 +188,7 @@ with your task.
            `npmMinimalAgeGate` from `.yarnrc.yml`. The conversion wrote them.
            They allow install scripts, any git repository and packages of any
            age, which yarn otherwise refuses.
-        6. In `package.json`, name any package that must run its install script,
+        6. Name any package that must run its install script in `package.json`,
            as `"dependenciesMeta": { "<name>": { "built": true } }`, and run
            `yarn install` again.
         7. Add `.yarn/*` and `!.yarn/releases` above the secret patterns in
@@ -267,21 +267,21 @@ with your task.
 
 - [ ] Pre-commit hook is installed (`make hooks`)
 - [ ] No secrets in the repo (`.env`, keys, credentials)
-- [ ] No mutable references (tags, `@latest`) to what the repo downloads and
-      installs itself in scripts and Dockerfiles — all pinned by cryptographic
-      hash with version/date comment. Distribution packages are outside this
-      rule. They need no version and no hash, and updating and upgrading them is
-      fine too. In a `Dockerfile`, the distribution is the pinned base image's.
-      On a host, it is the host's, and the host's package manager stands for it,
-      nix and brew included. A package source that a `Dockerfile` adds itself is
-      not the distribution's own, so its packages are pinned
+- [ ] No mutable references in Dockerfiles or scripts (tags, `@latest`) — all
+      pinned by cryptographic hash with version/date comment. The one exception
+      is a package from the distribution's own package index, which needs no
+      version and no hash. Pulling that index is also allowed. In a
+      `Dockerfile`, the distribution is the pinned base image's. On a host, it
+      is the host's, and the host's package manager stands for it, nix and brew
+      included. A package source that a `Dockerfile` adds itself does not get
+      this exception
 - [ ] node, yarn, npm, python, pip and venv come from the distribution wherever
       possible, never from nvm, pyenv, corepack or `npm install -g yarn`. If the
       distribution's version is too old, use a newer distribution. node means
       the distribution's newest Node package, such as `nodejs-current` on Alpine
       3.24
 - [ ] yarn's release file is in git under `.yarn/releases/`, written once by
-      `yarn set version` with an exact version (repositories with `yarn.lock`)
+      `yarn set version` with an exact version
 - [ ] Using `yarn`, not `npm` (JS projects)
 
 # Directory Structure

prompts/NEW_REPO_CHECKLIST.md

@@ -1,6 +1,6 @@
 ---
 title: New Repo Checklist
-last_modified: 2026-11-06
+last_modified: 2026-11-04
 ---
 
 Use this checklist when creating a new repository from scratch. Follow the steps
@@ -179,11 +179,10 @@ 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, or any repository that runs prettier through yarn: make the first
-          `yarn.lock` with the steps below. `script/bootstrap` installs no yarn
-          until `yarn.lock` exists, so run them with any distribution's node and
-          yarn, such as Alpine's (`apk add nodejs-current yarn`). Use `yarnpkg`
-          on Debian and Ubuntu.
+    - [ ] JS: make the first `yarn.lock` with the steps below.
+          `script/bootstrap` installs no yarn until `yarn.lock` exists, so run
+          them with any distribution's node and yarn, such as Alpine's
+          (`apk add nodejs-current yarn`). Use `yarnpkg` on Debian and Ubuntu.
         1. Read the version from `yarnPath` in
            `https://git.eeqj.de/sneak/prompts/raw/branch/main/.yarnrc.yml`.
         2. Run `yarn set version <version>`. It writes
@@ -285,20 +284,19 @@ are thin shims calling them. Model scripts:
       final stage is missing its `COPY --from=` edge to the gate phases.
 - [ ] No secrets in repo, and none in the build context: enumerate a probe image
       rather than reading `.dockerignore`
-- [ ] No mutable references to what the repo downloads and installs itself in
-      scripts and Dockerfiles. Distribution packages are outside this rule. They
-      need no version and no hash, and updating and upgrading them is fine too.
-      In a `Dockerfile`, the distribution is the pinned base image's. On a host,
-      it is the host's, and the host's package manager stands for it, nix and
-      brew included. A package source that a `Dockerfile` adds itself is not the
-      distribution's own, so its packages are pinned
+- [ ] No mutable image/package references. The one exception is a package from
+      the distribution's own package index, which needs no version and no hash.
+      Pulling that index is also allowed. In a `Dockerfile`, the distribution is
+      the pinned base image's. On a host, it is the host's, and the host's
+      package manager stands for it, nix and brew included. A package source
+      that a `Dockerfile` adds itself does not get this exception
 - [ ] node, yarn, npm, python, pip and venv come from the distribution wherever
       possible, never from nvm, pyenv, corepack or `npm install -g yarn`. If the
       distribution's version is too old, use a newer distribution. node means
       the distribution's newest Node package, such as `nodejs-current` on Alpine
       3.24
 - [ ] yarn's release file is in git under `.yarn/releases/`, written once by
-      `yarn set version` with an exact version (repositories with `yarn.lock`)
+      `yarn set version` with an exact version
 - [ ] No unnecessary files in repo root
 - [ ] All dates written as YYYY-MM-DD
 

prompts/REPO_POLICIES.md

@@ -1,6 +1,6 @@
 ---
 title: Repository Policies
-last_modified: 2026-11-06
+last_modified: 2026-11-04
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -21,28 +21,13 @@ style conventions are in separate documents:
   with the authoritative source as policies evolve.
 
 - **External references must be pinned by cryptographic hash.** This is the
-  single most important rule in this document. It covers what we download and
-  install ourselves in scripts and Dockerfiles:
+  single most important rule in this document. It covers everything fetched from
+  a remote source, including:
     - Docker base images
     - Go modules
-    - Python packages from PyPI
+    - Python packages
     - npm packages
     - GitHub Actions
-    - release archives fetched with `curl` or `wget`
-
-    Packages from the distribution's own package manager are outside this rule.
-    They need no version and no hash, because the distribution is trusted. In a
-    `Dockerfile`, it is the pinned base image's distribution. On a host, it is
-    the host's. The host's package manager stands for its distribution, and that
-    includes nix and brew. Updating the package index and upgrading installed
-    packages are fine too. This command, for example, is allowed:
-
-    ```sh
-    apt update && apt upgrade -y && apt install -y build-essential
-    ```
-
-    A package source that a `Dockerfile` adds itself is not the distribution's
-    own, so its packages are pinned like any other download.
 
     A version tag such as `@v4`, `@latest` or `:3.21` is server-mutable, and
     therefore a remote code execution vulnerability. Reference an external
@@ -59,6 +44,17 @@ style conventions are in separate documents:
     Unverified install scripts are arbitrary remote code execution. Double-check
     every external reference in every file before committing.
 
+    There is one exception: a package from the distribution's own package index
+    needs no version and no hash. Pulling that index is also allowed. The
+    distribution is trusted. In a `Dockerfile`, it is the pinned base image's
+    distribution. On a host, it is the host's. The host's package manager stands
+    for its distribution, and that includes nix and brew. These commands are
+    examples:
+    - `apt-get update`
+    - `apt-get install`
+    - `apk update`
+    - `apk add`
+
     These come from the distribution wherever possible:
     - node, meaning the distribution's newest Node package, such as
       `nodejs-current` on Alpine 3.24
@@ -83,6 +79,9 @@ style conventions are in separate documents:
     - the npm registry
     - `go get`
 
+    A package source that a `Dockerfile` adds itself is not the distribution's
+    own, so the exception does not cover it.
+
 - Every repo with software must have a root `Makefile` with these targets:
     - `make bootstrap`
     - `make setup`
@@ -200,15 +199,14 @@ style conventions are in separate documents:
     README must document the provided scripts in an **Entrypoints** section (see
     the README requirements below).
 
-- Run the repo's own entrypoints, never the underlying tools directly. The
-  `script/` scripts are the single source of truth for how each operation runs.
-  Calling them directly is fine, and so is calling the Makefile targets. The
-  Makefile targets must still exist, as the thin shims described above.
+- Always use Makefile targets (`make fmt`, `make test`, `make lint`, etc.)
+  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 the entrypoints. A run while iterating is not a gate, so the full
+    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