Derive the image version from git; send .git without its config (closes #69, closes #71)

The canonical documents told every repo to exclude .git from the build
context, default ARG VERSION to dev and never run git describe in a
build stage, so an image built from a clone with no build argument
reported dev. .dockerignore now sends .git but keeps out .git/config,
which can hold a credential. The Dockerfile example installs git, takes
the VERSION build argument when one is given and otherwise
git describe --tags --always, and fails when .git exists but the version
is empty, dev or unknown. The policy and both checklists state the rule
in the same words, including that a plain docker build . with no build
arguments must succeed.

Model: opus-5-5

prompts/EXISTING_REPO_CHECKLIST.md

@@ -1,6 +1,6 @@
 ---
 title: Existing Repo Checklist
-last_modified: 2026-09-08
+last_modified: 2026-10-02
 ---
 
 Use this checklist when beginning work in a repo that may not yet conform to our
@@ -44,7 +44,7 @@ with your task.
       `script/test` — those are themselves a `docker build` and would recurse
       inside a build step
 - [ ] Every depth-independent pattern in `.dockerignore` carries a `**/` prefix,
-      only genuinely root-anchored entries such as `.git` are unprefixed, and
+      only genuinely root-anchored entries such as `.claude` are unprefixed, and
       `.gitignore`'s patterns have not been transplanted unmodified — the
       transplanted form leaves `config/.env` and `certs/server.key` in the build
       context while reading as solved
@@ -58,11 +58,23 @@ with your task.
       can copy another session's unreviewed work into an image layer. If agents
       here run anywhere other than the repo root, the anchored entry misses
       `services/api/.claude/`: add anchored entries for those directories.
-- [ ] If the repo embeds a version in a binary, that version is computed on the
-      host and passed with `--build-arg VERSION=...` by `script/docker` and
-      `script/cibuild`, and no stage calls `git describe`. A tag-derived version
-      additionally needs `fetch-depth: 0` on the CI checkout step, which clones
-      shallow and fetches no tags by default.
+- [ ] If the repo embeds a version in a binary: `.dockerignore` lets `.git` into
+      the build context. It keeps out `.git/config`, which `git describe` does
+      not need and which can hold a credential: a password in a remote URL, or
+      the token the CI checkout step stores there. The stage that compiles has
+      `git` (the Debian Go image has it; an alpine one needs
+      `apk add --no-cache git`) and takes the version from the `VERSION` build
+      argument when one is given, otherwise from `git describe --tags --always`.
+      That gives the tag on a tagged commit; on a later commit, the tag, the
+      number of commits since it and the short commit (`v1.2.3-4-gabc1234`); and
+      the short commit when no tag is reachable. `ARG VERSION` has no default,
+      and the build fails if the context carries `.git` and the version still
+      comes out empty, `dev` or `unknown`. A plain `docker build .` with no
+      build arguments must succeed; a Dockerfile that refuses an empty build
+      argument drops that refusal and keeps the argument. `script/docker` and
+      `script/cibuild` pass the version they compute on the host; it takes
+      precedence. A tag-derived version additionally needs `fetch-depth: 0` on
+      the CI checkout step, which clones shallow and fetches no tags by default.
 - [ ] Gitea Actions workflow in `.gitea/workflows/` runs `script/cibuild` on
       push — reference
       `https://git.eeqj.de/sneak/prompts/raw/branch/main/.gitea/workflows/check.yml`