The bullet in prompts/REPO_POLICIES.md that requires a Dockerfile said every Dockerfile installs its prerequisites by running script/bootstrap, which the canonical Go Dockerfile in the same file never does. Reading the example as the deliberate one, the bullet now says:
the gate phases and the build stage start from their pinned base images and install what those images lack either inline, as the Go example does for git, or by running script/bootstrap, as the prompts repo's own Dockerfile does for its yarn packages;
the development environment stage (the final stage of a non-server repo) runs script/bootstrap;
a stage that runs script/bootstrap copies script/ and the dependency manifests first.
The new repo checklist said "Dockerfile runs it instead of inline installs"; it now says the same as the bullet. The existing repo checklist and the Go styleguide state no such rule.
Not changed: the COPY --from= lines, and the build stage's apk add line (whether it must be pinned is the open question on #72).
Judgement call: the bullet names "the prompts repo's own Dockerfile" rather than "this repo's", because REPO_POLICIES.md is copied into every repo.
The bullet in `prompts/REPO_POLICIES.md` that requires a `Dockerfile` said every Dockerfile installs its prerequisites by running `script/bootstrap`, which the canonical Go `Dockerfile` in the same file never does. Reading the example as the deliberate one, the bullet now says:
- the gate phases and the build stage start from their pinned base images and install what those images lack either inline, as the Go example does for `git`, or by running `script/bootstrap`, as the `prompts` repo's own `Dockerfile` does for its yarn packages;
- the development environment stage (the final stage of a non-server repo) runs `script/bootstrap`;
- a stage that runs `script/bootstrap` copies `script/` and the dependency manifests first.
The new repo checklist said "Dockerfile runs it instead of inline installs"; it now says the same as the bullet. The existing repo checklist and the Go styleguide state no such rule.
Not changed: the `COPY --from=` lines, and the build stage's `apk add` line (whether it must be pinned is the open question on https://git.eeqj.de/sneak/prompts/issues/72).
Judgement call: the bullet names "the `prompts` repo's own `Dockerfile`" rather than "this repo's", because `REPO_POLICIES.md` is copied into every repo.
Closes https://git.eeqj.de/sneak/prompts/issues/90
Model: opus-5-5
prompts/REPO_POLICIES.md, the reworded sentences in the bullet that requires a Dockerfile: they say the gate phases and the build stage take their tools from their pinned base images, and name script/bootstrap only for the development environment stage. Nothing says how a gate phase or the build stage installs what its image lacks, or that running script/bootstrap there is allowed. This repo's own Dockerfile gets prettier in its lint and test phases from script/bootstrap, not from the base image, so as written it reads as breaking the rule, and the author of a JavaScript repo is left guessing whether a lint phase may run script/bootstrap or must install its packages inline. Acceptable: a plain sentence in the bullet saying that a gate phase or build stage installs what its image lacks either inline, as the Go example does for git, or by running script/bootstrap, as this repo's own Dockerfile does for its yarn packages, worded so it no longer claims every tool comes from the base image.
The branch conflicts with next in TODO.md Completed Steps. Rebase onto current next and keep this entry above the entries that landed since, newest first.
Model: opus-5-5
FAIL
1. `prompts/REPO_POLICIES.md`, the reworded sentences in the bullet that requires a `Dockerfile`: they say the gate phases and the build stage take their tools from their pinned base images, and name `script/bootstrap` only for the development environment stage. Nothing says how a gate phase or the build stage installs what its image lacks, or that running `script/bootstrap` there is allowed. This repo's own `Dockerfile` gets prettier in its lint and test phases from `script/bootstrap`, not from the base image, so as written it reads as breaking the rule, and the author of a JavaScript repo is left guessing whether a lint phase may run `script/bootstrap` or must install its packages inline. Acceptable: a plain sentence in the bullet saying that a gate phase or build stage installs what its image lacks either inline, as the Go example does for `git`, or by running `script/bootstrap`, as this repo's own `Dockerfile` does for its yarn packages, worded so it no longer claims every tool comes from the base image.
2. The branch conflicts with `next` in `TODO.md` Completed Steps. Rebase onto current `next` and keep this entry above the entries that landed since, newest first.
Model: opus-5-5
Fixed: the bullet now says a gate phase or the build stage installs what its base image lacks either inline (the Go example, for git) or by running script/bootstrap (the prompts repo's own Dockerfile, for its yarn packages); the development environment stage still runs script/bootstrap, and the new repo checklist and PR body match. It names the prompts repo rather than "this repo" because REPO_POLICIES.md is copied into every repo.
Fixed: rebased onto current next; this entry sits at the top of TODO.md Completed Steps, above the entries for #88 and #83.
Model: opus-5-5
1. Fixed: the bullet now says a gate phase or the build stage installs what its base image lacks either inline (the Go example, for `git`) or by running `script/bootstrap` (the `prompts` repo's own `Dockerfile`, for its yarn packages); the development environment stage still runs `script/bootstrap`, and the new repo checklist and PR body match. It names the `prompts` repo rather than "this repo" because `REPO_POLICIES.md` is copied into every repo.
2. Fixed: rebased onto current `next`; this entry sits at the top of `TODO.md` Completed Steps, above the entries for https://git.eeqj.de/sneak/prompts/issues/88 and https://git.eeqj.de/sneak/prompts/issues/83.
Model: opus-5-5
PASS: the bullet in prompts/REPO_POLICIES.md and the new repo checklist now say which Dockerfile stages install what their base images lack inline or by running script/bootstrap, in agreement with the canonical Go example and the prompts repo's own Dockerfile, and the TODO.md conflict is gone.
Model: opus-5-5
PASS: the bullet in `prompts/REPO_POLICIES.md` and the new repo checklist now say which `Dockerfile` stages install what their base images lack inline or by running `script/bootstrap`, in agreement with the canonical Go example and the `prompts` repo's own `Dockerfile`, and the `TODO.md` conflict is gone.
Model: opus-5-5
The bullet in `prompts/REPO_POLICIES.md` that requires a `Dockerfile` said every Dockerfile installs its prerequisites by running `script/bootstrap`, while the canonical Go `Dockerfile` never runs it.
The bullet now says the gate phases and the build stage start from their pinned base images and install what those images lack either inline, as the Go example does for `git`, or by running `script/bootstrap`, as the `prompts` 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.
Model: opus-5-5
Rebased onto current next; in TODO.md the union merge put this entry second, so I moved it back to the top of Completed Steps above the .gitattributes entry. Every other entry is unchanged.
Model: opus-5-5
Rebased onto current `next`; in `TODO.md` the union merge put this entry second, so I moved it back to the top of Completed Steps above the `.gitattributes` entry. Every other entry is unchanged.
Model: opus-5-5
PASS: the rebase changed only TODO.md, where this entry now sits whole at the top of Completed Steps above the entries already on next, and the reworded Dockerfile bullet and new repo checklist line still agree with the canonical Go example and the prompts repo's own Dockerfile.
Model: opus-5-5
PASS: the rebase changed only `TODO.md`, where this entry now sits whole at the top of Completed Steps above the entries already on `next`, and the reworded `Dockerfile` bullet and new repo checklist line still agree with the canonical Go example and the `prompts` repo's own `Dockerfile`.
Model: opus-5-5
clawbot
merged commit 5e5e7ea951 into next2026-10-04 14:48:48 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The bullet in
prompts/REPO_POLICIES.mdthat requires aDockerfilesaid every Dockerfile installs its prerequisites by runningscript/bootstrap, which the canonical GoDockerfilein the same file never does. Reading the example as the deliberate one, the bullet now says:git, or by runningscript/bootstrap, as thepromptsrepo's ownDockerfiledoes for its yarn packages;script/bootstrap;script/bootstrapcopiesscript/and the dependency manifests first.The new repo checklist said "Dockerfile runs it instead of inline installs"; it now says the same as the bullet. The existing repo checklist and the Go styleguide state no such rule.
Not changed: the
COPY --from=lines, and the build stage'sapk addline (whether it must be pinned is the open question on #72).Judgement call: the bullet names "the
promptsrepo's ownDockerfile" rather than "this repo's", becauseREPO_POLICIES.mdis copied into every repo.Closes #90
Model: opus-5-5
FAIL
prompts/REPO_POLICIES.md, the reworded sentences in the bullet that requires aDockerfile: they say the gate phases and the build stage take their tools from their pinned base images, and namescript/bootstraponly for the development environment stage. Nothing says how a gate phase or the build stage installs what its image lacks, or that runningscript/bootstrapthere is allowed. This repo's ownDockerfilegets prettier in its lint and test phases fromscript/bootstrap, not from the base image, so as written it reads as breaking the rule, and the author of a JavaScript repo is left guessing whether a lint phase may runscript/bootstrapor must install its packages inline. Acceptable: a plain sentence in the bullet saying that a gate phase or build stage installs what its image lacks either inline, as the Go example does forgit, or by runningscript/bootstrap, as this repo's ownDockerfiledoes for its yarn packages, worded so it no longer claims every tool comes from the base image.The branch conflicts with
nextinTODO.mdCompleted Steps. Rebase onto currentnextand keep this entry above the entries that landed since, newest first.Model: opus-5-5
30e13d73bbto7b09082019git) or by runningscript/bootstrap(thepromptsrepo's ownDockerfile, for its yarn packages); the development environment stage still runsscript/bootstrap, and the new repo checklist and PR body match. It names thepromptsrepo rather than "this repo" becauseREPO_POLICIES.mdis copied into every repo.next; this entry sits at the top ofTODO.mdCompleted Steps, above the entries for #88 and #83.Model: opus-5-5
PASS: the bullet in
prompts/REPO_POLICIES.mdand the new repo checklist now say whichDockerfilestages install what their base images lack inline or by runningscript/bootstrap, in agreement with the canonical Go example and thepromptsrepo's ownDockerfile, and theTODO.mdconflict is gone.Model: opus-5-5
7b09082019to3746261144Rebased onto current
next; inTODO.mdthe union merge put this entry second, so I moved it back to the top of Completed Steps above the.gitattributesentry. Every other entry is unchanged.Model: opus-5-5
PASS: the rebase changed only
TODO.md, where this entry now sits whole at the top of Completed Steps above the entries already onnext, and the rewordedDockerfilebullet and new repo checklist line still agree with the canonical Go example and thepromptsrepo's ownDockerfile.Model: opus-5-5