Re-vendor the canonical files from sneak/prompts at dd4027b (closes #213)

Linting and testing become the lint and test phases of the Dockerfile,
and the build stage depends on both. Dockerfile.lint, CHECK_EPOCH and
the tests that checked them are removed. Every docker build in script/
passes --no-cache, and script/cibuild runs script/bootstrap first. A
host without Go gets the go.mod version from script/install-go in
.tool/go, which bootstrap, the Makefile, fmt, fmt-check, precommit and
release add to PATH; fmt-check skips .tool. The image takes its version
from the VERSION build arg or git describe, dev without .git. This
repo's own entries follow the canonical content in .gitignore and
.editorconfig. The golangci-lint v2.14.0 findings are fixed. The rules
in CLAUDE.md move into AGENTS.md. IsDevVersion counts "unknown".

Model: opus-5-5

README.md

@@ -728,12 +728,11 @@ regardless of color setting (emoji are not color).
 ## requirements
 
 * Go 1.26 or later
-* Docker, with a reachable daemon, to lint, check, or commit:
-  `script/lint` lints by building `Dockerfile.lint`, which runs the
-  digest-pinned `golangci-lint` image as a build step, and `make check`
-  and the pre-commit hook both run it. A `golangci-lint` installed on
-  `PATH` is not a substitute and is never used on a host, whatever its
-  version.
+* Docker, with a reachable daemon, to test, lint, check, or commit:
+  `script/test` and `script/lint` build the `test` and `lint` phases of
+  the `Dockerfile`, and `make check` and the pre-commit hook both run
+  them. A `golangci-lint` installed on `PATH` is not a substitute and is
+  never used on a host, whatever its version.
 * S3-compatible object storage (or local filesystem, or rclone remote)
 
 ## development workflow
@@ -764,17 +763,20 @@ standard: normalized scripts in `script/` are the entrypoints for the
 development workflow, and the Makefile targets are thin shims that call
 them. We provide:
 
-* `script/bootstrap` — install all development dependencies (go, Go
-  module download). It deliberately does not install `golangci-lint`;
-  see `script/lint` below.
+* `script/bootstrap` — install all development dependencies (Go, Go
+  module download). A host without Go gets the `go.mod` version through
+  `script/install-go`, in `.tool/go`, which `script/bootstrap` itself,
+  the `Makefile`, `script/fmt`, `script/fmt-check`, `script/precommit`
+  and `script/release` add to their `PATH`. It
+  deliberately does not install `golangci-lint`; see `script/lint`
+  below.
 * `script/setup` — make a fresh clone ready for development: runs
   `script/bootstrap`, then `script/install-precommit`
 * `script/projectname` — print the project name (used for the Docker
   image tag)
 * `script/version` — print the version string to bake into the binary.
-  The `Makefile`'s `LDFLAGS` call this, and `script/docker` and
-  `script/cibuild` pass its output to the image build. See
-  [releasing](#releasing) for the rules.
+  The `Makefile`'s `LDFLAGS` call this. See [releasing](#releasing) for
+  the rules.
 * `script/install-goreleaser` — install the pinned `goreleaser` into
   `.tool/bin` from a sha256-verified release archive. Idempotent, and
   called by `script/bootstrap`; the release workflow calls it directly
@@ -782,102 +784,59 @@ them. We provide:
   `script/bootstrap` insists on.
 * `script/install-go` — install the Go toolchain named by `go.mod`'s
   `go` directive into `.tool/go` from a sha256-verified `go.dev`
-  archive, and put it on `PATH`. Idempotent. Called only by the release
-  workflow, which needs a host Go for `goreleaser` to shell out to;
-  nothing else on the release runner does. `actions/setup-go` is not
-  used because it verifies the downloaded toolchain against no value in
-  this repo. Bumping Go edits `go.mod`, the checksum in this script, and
-  the `Dockerfile` `golang` digest together.
+  archive, for Linux or macOS on amd64 or arm64. Idempotent. On a CI
+  runner it also puts `.tool/go/bin` on `PATH` for the steps that
+  follow. Called by the release workflow, which needs a host Go for
+  `goreleaser` to shell out to, and by `script/bootstrap` on a host
+  without Go. `actions/setup-go` is not used because it verifies the
+  downloaded toolchain against no value in this repo. Bumping Go edits
+  `go.mod`, the checksums in this script, and the two `golang` digests
+  in the `Dockerfile` together.
 * `script/release` — cross-compile and publish the release artifacts
   with the pinned `goreleaser`. Refuses a `goreleaser` on `PATH` whose
   version is not the pinned one, on the same reasoning as `script/lint`.
 * `script/release-snapshot` — the same build with no publishing and no
   tagging, into `./dist`
-* `script/test` — run the test suite (verbose rerun on failure). This
-  runs *everything*: there is no separate integration target and no
-  build-tagged subset held back, so the full round-trip tests in
-  `internal/vaultik/integration_test.go` run on every invocation. It
-  passes `-count=1`, which disables Go's test result cache. That is
-  deliberate and it is not free: on this repo's suite it costs about 11
-  seconds on every repeat run (measured, back to back: 0.4s cached
-  versus 11.6s with `-count=1`). That is the price of the run meaning
-  anything, because without it an unchanged package prints
-  `ok <pkg> (cached)`, which is indistinguishable from a package that
-  really ran, so the whole suite can report a full set of `ok` lines in
-  under half a second having executed nothing. The `-timeout` is a hang
-  backstop rather than a performance budget — it applies per test binary
-  to test execution only, not to compilation — and is set well above the
-  slowest package's measured runtime. Its 120s value deliberately
-  diverges from the 30s `REPO_POLICIES.md` mandates; the reasoning is in
-  the comment in the script, and issue #101 proposes amending the policy
-  text.
-* `script/lint` — lint by building `Dockerfile.lint`, which runs
-  `golangci-lint run --config .golangci.yml ./...` as a build step
-  inside the digest-pinned `golangci-lint` image, so a successful build
-  *is* a clean lint. Nothing lints on the host, at any version, ever;
-  the script requires Docker and fails loudly rather than falling back
-  to a `golangci-lint` on `PATH`. That `FROM` line is the single source
-  of truth for the linter version — bump it there and nowhere else.
-
-  It takes no arguments, because a build step has no command line to
-  pass flags to, and it passes a fresh `--build-arg CHECK_EPOCH` on
-  every invocation so the lint layer cannot be replayed from cache (see
-  `script/cibuild` below for what that mechanism defends against). To
-  watch the linter execute, run it as
-  `BUILDKIT_PROGRESS=plain script/lint` and check that the lint layer
-  says `RUN … golangci-lint` rather than `CACHED`.
-
-  One container per run means one lint cache and one `golangci-lint`
-  lock per run, both private to it and discarded with it, so concurrent
-  runs on one host cannot contaminate or block each other.
+* `script/test` — run the test suite by building the `test` phase of
+  the `Dockerfile` (verbose rerun on failure). This runs *everything*:
+  there is no separate integration target and no build-tagged subset
+  held back, so the full round-trip tests in
+  `internal/vaultik/integration_test.go` run on every invocation. The
+  90s `-timeout` is a hang backstop rather than a performance budget; it
+  applies per test binary, to test execution only.
+* `script/lint` — lint by building the `lint` phase of the
+  `Dockerfile`, which runs `golangci-lint config verify` and then
+  `golangci-lint run --config .golangci.yml ./...` as build steps in
+  the digest-pinned `golangci-lint` image. Nothing lints on the host.
+  That `FROM` line is the only pin of the linter version, and it changes
+  in the same commit as a re-vendored `.golangci.yml`.
 * `script/lint-fix` — apply the linter's autofixes (rewrites files),
-  using the same pinned image, parsed out of `Dockerfile.lint`. It
-  cannot be a build step, because fixes have to land in the worktree, so
-  it bind-mounts the tree into a `docker run` and therefore needs a
-  *local* daemon. It is a developer convenience and never a gate: no
-  gate reads its exit status. Run `make lint` afterwards to find out
-  whether the tree is clean.
+  using the same pinned image, parsed out of the `lint` phase's `FROM`
+  line. It cannot be a build step, because fixes have to land in the
+  worktree, so it bind-mounts the tree into a `docker run` and therefore
+  needs a *local* daemon. It is a developer convenience and never a
+  gate: no gate reads its exit status. Run `make lint` afterwards to
+  find out whether the tree is clean.
 * `script/fmt` — format all code (writes)
-* `script/fmt-check` — check formatting (read-only)
+* `script/fmt-check` — check formatting (read-only). It runs `gofmt` on
+  the host, over every Go file outside `.tool`.
 * `script/check` — run `script/test`, `script/lint`, and
-  `script/fmt-check`. This is authoritative *because* `script/lint`
-  builds `Dockerfile.lint`: a local `make check` and CI cannot disagree
-  about lint findings.
+  `script/fmt-check`.
 * `script/docker` — build the Docker image tagged via
-  `script/projectname`. Passes a fresh `--build-arg CHECK_EPOCH` for the
-  same reason `script/cibuild` does, so a local image build cannot be
-  green on checks it replayed from cache. It builds the *product* image
-  only, and the product `Dockerfile` has no lint stage, so it does not
-  lint: a green here means formatted, tested, and it compiles.
-* `script/cibuild` — CI entrypoint, and the full gate. Two builds, in
-  order: `Dockerfile.lint` (the linter, as a build step) and then
-  `Dockerfile` (`make fmt-check` and `make test` in its builder stage,
-  then the product image). Either failing fails the script. It runs the
-  checks in the same containers CI does, from a clean copy of the tree,
-  so it also catches anything that depends on host state.
-  `.gitea/workflows/check.yml` runs it on every push to `main` and
-  `next` and on every pull request against either.
+  `script/projectname`, stamped with the version
+  `git describe --tags --always --dirty` gives on the host, or `unknown`
+  outside a git checkout. The image's build stage depends on the `lint`
+  and `test` phases, so this lints and tests too.
+* `script/cibuild` — CI entrypoint: runs `script/bootstrap`,
+  `script/check`, and then the same image build as `script/docker`.
+  `.gitea/workflows/check.yml` runs it on every push.
 
-  It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per
-  invocation, which both files declare immediately above their check
-  `RUN`s and expand into each check command. Those layers are keyed on
-  that value, so a new value re-runs them even on a byte-identical tree,
-  and a green from this script means the checks executed. Dependency and
-  module layers sit above the `ARG` and still cache, so a build is not
-  cold.
-
-  A `docker build -f Dockerfile.lint .` that supplies no `CHECK_EPOCH`
-  fails rather than lying. An unset `ARG` is an empty string and an
-  empty string is a stable cache key, so without a guard such a build
-  would serve the lint layer from cache, execute nothing, and still exit
-  0. `Dockerfile.lint` therefore asserts the value is non-empty before
-  running anything, and because failed steps are never cached that
-  assertion fires on every invocation rather than once. The product
-  `Dockerfile` has no such guard, because a plain `docker build .` must
-  succeed: without `CHECK_EPOCH`, rebuilding an unchanged checkout
-  replays its check layers from cache. Use `script/lint`,
-  `script/docker` or `script/cibuild`, which pass the arg, when the
-  checks must run.
+  Every `docker build` in these scripts passes `--no-cache`, because on
+  an unchanged tree a cached check layer is replayed without running and
+  the build still exits 0. A plain `docker build .` is therefore no
+  evidence that the checks ran. The cost is that `script/cibuild` runs
+  the `lint` and `test` phases twice: once in `script/check` and again
+  in the image build.
 * `script/precommit` — pre-commit gate: `go mod tidy` + `go fmt` (must
   not change files), then `script/check`
 * `script/install-precommit` — install the git pre-commit hook that
@@ -889,8 +848,8 @@ them. We provide:
 
 The version a binary reports comes from git, not from a constant in a
 file. It is `git describe --tags --always --dirty`, which
-`script/version` runs for the `Makefile`, `script/docker` and
-`script/cibuild`:
+`script/version` runs for the `Makefile`, and `script/docker` and
+`script/cibuild` run themselves:
 
 * `HEAD` is exactly on a tag → that tag, such as `v1.0.0`.
 * a commit after a tag → `<tag>-<N>-g<short sha>`.
@@ -901,15 +860,17 @@ file. It is `git describe --tags --always --dirty`, which
 A `docker build .` of a clone, with no build arguments, runs the same
 `git describe` (without `--dirty`) on the `.git` in its build context,
 so it stamps the same value for a clean commit; the build fails if the
-context carries `.git` and no version comes out. A binary built without
-git metadata reports `dev`.
+context carries `.git` and no version, commit or commit date comes out.
+A binary built without
+git metadata reports `dev`, or `unknown` when `script/docker` or
+`script/cibuild` built it outside a git checkout.
 
 `goreleaser` stamps a release binary with the tag minus its leading
 `v`, so the tag `v1.0.0` produces `vaultik 1.0.0`, matching the archive
 name `vaultik_1.0.0_linux_amd64.tar.gz`. `goreleaser --snapshot` stamps
 `dev-<12 chars of the commit sha>` rather than inventing the next patch
 number. `vaultik version` calls a build a development build when its
-version is `dev`, `dev-<sha>`, the short commit sha or
+version is `dev`, `unknown`, `dev-<sha>`, the short commit sha or
 `<tag>-<N>-g<short sha>`, with or without `-dirty`; only a plain tag,
 such as `v1.0.0` or `1.0.0`, is a release. If `script/version` cannot
 be run at all, `make` stops with an error instead of building an