1 Commits
Author SHA1 Message Date
clawbot 4751b36672 Commit yarn 4 in the tree and install with --immutable (closes #149)
check / check (push) Successful in 23s
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
2026-11-04 19:53:23 +00:00
5 changed files with 49 additions and 92 deletions

No files matched your search

-10
View File
@@ -21,16 +21,6 @@ fmt-check, and commit.
# Completed Steps # Completed Steps
- 2026-11-07: Go code is now formatted with `gofmt` and then `golines -m 77`
(https://git.eeqj.de/sneak/prompts/issues/160). `prompts/REPO_POLICIES.md`
says how `script/fmt`, `script/fmt-check` and `script/bootstrap` do it and
pins `golines`. The Go style guide and both checklists say the same. `lll`
stays at 88, since `golines` leaves long strings and comments as they are.
- 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 - 2026-11-04: Each repository now commits yarn 4 and installs with
`yarn install --immutable` (https://git.eeqj.de/sneak/prompts/issues/149), on `yarn install --immutable` (https://git.eeqj.de/sneak/prompts/issues/149), on
sneak's ruling at sneak's ruling at
+5 -8
View File
@@ -1,16 +1,13 @@
--- ---
title: Code Styleguide — Go title: Code Styleguide — Go
last_modified: 2026-11-07 last_modified: 2026-10-18
--- ---
1. Format Go code with `gofmt` and then `golines -m 77`, through `make fmt`. 1. Try to hard wrap long lines at 77 characters or less.
Don't commit anything `make fmt` would change. The only exception is when
committing things that aren't yet syntactically valid, which should only
happen pre-v0.0.1 or on a non-`main` branch.
1. Hard wrap long lines at 77 characters or less. `golines` does this for code. 1. Don't commit anything that hasn't been `go fmt`'d. The only exception is
Wrap comments and long string literals by hand, since `golines` leaves them when committing things that aren't yet syntactically valid, which should
as they are. only happen pre-v0.0.1 or on a non-`main` branch.
1. Even if you are planning to deal with only positive integers, use 1. Even if you are planning to deal with only positive integers, use
`int`/`int64` types instead of `uint`/`uint64` types. This is for `int`/`int64` types instead of `uint`/`uint64` types. This is for
+11 -16
View File
@@ -1,6 +1,6 @@
--- ---
title: Existing Repo Checklist title: Existing Repo Checklist
last_modified: 2026-11-07 last_modified: 2026-11-04
--- ---
Use this checklist when beginning work in a repo that may not yet conform to our Use this checklist when beginning work in a repo that may not yet conform to our
@@ -259,27 +259,22 @@ with your task.
# Formatting # Formatting
- [ ] Platform-standard formatter is configured (`black`, `prettier`, and for Go - [ ] Platform-standard formatter is configured (`black`, `prettier`, `go fmt`)
`gofmt` then `golines -m 77`) - [ ] Default formatter config, only exception: four-space indents (except Go)
- [ ] Default formatter config, except four-space indents (not Go),
`proseWrap: always` for Markdown, and the Go 77-column limit
- [ ] Go: `script/bootstrap` installs `golines` with `go install` pinned to a
commit hash; `script/fmt-check` fails when `gofmt` or `golines -m 77`
would change a file
- [ ] All files pass `make fmt-check` - [ ] All files pass `make fmt-check`
# Git Hygiene # Git Hygiene
- [ ] Pre-commit hook is installed (`make hooks`) - [ ] Pre-commit hook is installed (`make hooks`)
- [ ] No secrets in the repo (`.env`, keys, credentials) - [ ] No secrets in the repo (`.env`, keys, credentials)
- [ ] No mutable references (tags, `@latest`) to what the repo downloads and - [ ] No mutable references in Dockerfiles or scripts (tags, `@latest`) — all
installs itself in scripts and Dockerfiles — all pinned by cryptographic pinned by cryptographic hash with version/date comment. The one exception
hash with version/date comment. Distribution packages are outside this is a package from the distribution's own package index, which needs no
rule. They need no version and no hash, and updating and upgrading them is version and no hash. Pulling that index is also allowed. In a
fine too. In a `Dockerfile`, the distribution is the pinned base image's. `Dockerfile`, the distribution is the pinned base image's. On a host, it
On a host, it is the host's, and the host's package manager stands for it, is the host's, and the host's package manager stands for it, nix and brew
nix and brew included. A package source that a `Dockerfile` adds itself is included. A package source that a `Dockerfile` adds itself does not get
not the distribution's own, so its packages are pinned this exception
- [ ] node, yarn, npm, python, pip and venv come from the distribution wherever - [ ] 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 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 distribution's version is too old, use a newer distribution. node means
+9 -12
View File
@@ -1,6 +1,6 @@
--- ---
title: New Repo Checklist title: New Repo Checklist
last_modified: 2026-11-07 last_modified: 2026-11-04
--- ---
Use this checklist when creating a new repository from scratch. Follow the steps Use this checklist when creating a new repository from scratch. Follow the steps
@@ -233,11 +233,9 @@ are thin shims calling them. Model scripts:
which writes no image. No lint verdict may come from a host invocation of which writes no image. No lint verdict may come from a host invocation of
the linter. the linter.
- [ ] `script/fmt` / `make fmt` — formats code (writes; native, never in a - [ ] `script/fmt` / `make fmt` — formats code (writes; native, never in a
container). Go code gets `gofmt`, then `golines -m 77`. container)
- [ ] `script/fmt-check` / `make fmt-check` — checks formatting (read-only; - [ ] `script/fmt-check` / `make fmt-check` — checks formatting (read-only;
native). Fails when `gofmt` or `golines -m 77` would change a Go file. native)
- [ ] Go: `script/bootstrap` installs `golines` with `go install` pinned to a
commit hash
- [ ] `script/check` / `make check` — runs `test`, `lint`, `fmt-check`; must not - [ ] `script/check` / `make check` — runs `test`, `lint`, `fmt-check`; must not
modify files modify files
- [ ] `script/projectname` — outputs the project name (used by `script/docker` - [ ] `script/projectname` — outputs the project name (used by `script/docker`
@@ -287,13 +285,12 @@ are thin shims calling them. Model scripts:
final stage is missing its `COPY --from=` edge to the gate phases. 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 - [ ] No secrets in repo, and none in the build context: enumerate a probe image
rather than reading `.dockerignore` rather than reading `.dockerignore`
- [ ] No mutable references to what the repo downloads and installs itself in - [ ] No mutable image/package references. The one exception is a package from
scripts and Dockerfiles. Distribution packages are outside this rule. They the distribution's own package index, which needs no version and no hash.
need no version and no hash, and updating and upgrading them is fine too. Pulling that index is also allowed. In a `Dockerfile`, the distribution is
In a `Dockerfile`, the distribution is the pinned base image's. On a host, the pinned base image's. On a host, it is the host's, and the host's
it is the host's, and the host's package manager stands for it, nix and package manager stands for it, nix and brew included. A package source
brew included. A package source that a `Dockerfile` adds itself is not the that a `Dockerfile` adds itself does not get this exception
distribution's own, so its packages are pinned
- [ ] node, yarn, npm, python, pip and venv come from the distribution wherever - [ ] 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 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 distribution's version is too old, use a newer distribution. node means
+24 -46
View File
@@ -1,6 +1,6 @@
--- ---
title: Repository Policies title: Repository Policies
last_modified: 2026-11-07 last_modified: 2026-11-04
--- ---
This document covers repository structure, tooling, and workflow standards. Code 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. with the authoritative source as policies evolve.
- **External references must be pinned by cryptographic hash.** This is the - **External references must be pinned by cryptographic hash.** This is the
single most important rule in this document. It covers what we download and single most important rule in this document. It covers everything fetched from
install ourselves in scripts and Dockerfiles: a remote source, including:
- Docker base images - Docker base images
- Go modules - Go modules
- Python packages from PyPI - Python packages
- npm packages - npm packages
- GitHub Actions - 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 A version tag such as `@v4`, `@latest` or `:3.21` is server-mutable, and
therefore a remote code execution vulnerability. Reference an external 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 Unverified install scripts are arbitrary remote code execution. Double-check
every external reference in every file before committing. 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: These come from the distribution wherever possible:
- node, meaning the distribution's newest Node package, such as - node, meaning the distribution's newest Node package, such as
`nodejs-current` on Alpine 3.24 `nodejs-current` on Alpine 3.24
@@ -83,6 +79,9 @@ style conventions are in separate documents:
- the npm registry - the npm registry
- `go get` - `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: - Every repo with software must have a root `Makefile` with these targets:
- `make bootstrap` - `make bootstrap`
- `make setup` - `make setup`
@@ -200,15 +199,14 @@ style conventions are in separate documents:
README must document the provided scripts in an **Entrypoints** section (see README must document the provided scripts in an **Entrypoints** section (see
the README requirements below). the README requirements below).
- Run the repo's own entrypoints, never the underlying tools directly. The - Always use Makefile targets (`make fmt`, `make test`, `make lint`, etc.)
`script/` scripts are the single source of truth for how each operation runs. instead of invoking the underlying tools directly. The Makefile is the single
Calling them directly is fine, and so is calling the Makefile targets. The source of truth for how these operations are run.
Makefile targets must still exist, as the thin shims described above.
An agent whose work is confined to one package may run `go test` directly on 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 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 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. `make check` is still required before every push.
- The Makefile is authoritative documentation for how the repo is used. Beyond - The Makefile is authoritative documentation for how the repo is used. Beyond
@@ -675,31 +673,11 @@ style conventions are in separate documents:
- Use platform-standard formatters: - Use platform-standard formatters:
- `black` for Python - `black` for Python
- `prettier` for JS/CSS/Markdown/HTML - `prettier` for JS/CSS/Markdown/HTML
- `gofmt`, then `golines -m 77`, for Go - `go fmt` for Go
Always use default configuration, with three exceptions: Always use default configuration, with two exceptions:
- four-space indents (except Go) - four-space indents (except Go)
- `proseWrap: always` for Markdown (hard-wrap at 80 columns) - `proseWrap: always` for Markdown (hard-wrap at 80 columns)
- a 77-column limit for Go, set by `golines -m 77`
`script/fmt` runs `gofmt` and then `golines -m 77` on Go code.
`script/fmt-check` fails when either of them would change a file. `golines`
comes from `github.com/segmentio/golines`. `script/bootstrap` installs it
with `go install`, pinned to a commit hash as below:
```sh
# golines v0.13.0, 2025-08-21
go install github.com/segmentio/golines@8f32f0f7e89c30f572c7f2cd3b2a48016b9d8bbf
```
`script/bootstrap` reads the installed version from the `mod` line of
`go version -m "$(command -v golines)"`, which reports `v0.13.0`. It does
not use `golines --version`, which prints `golines vdev` for a binary that
`go install` built.
`golines` cannot shorten every line: long string literals and comments stay
as they are. golangci-lint's `lll` limit therefore stays at 88 columns, so
it fails only lines far past the formatter's limit.
Documentation and writing repos (Markdown, HTML, CSS) should also have Documentation and writing repos (Markdown, HTML, CSS) should also have
`.prettierrc` and `.prettierignore`. `.prettierrc` and `.prettierignore`.