Say that a build from a linked worktree needs the version passed in (closes #111)

A plain `docker build .` from a checkout whose `.git` is a file (a linked worktree, or a repository checked out as a submodule) stops at the version check of the canonical `Dockerfile`: that file points to a git directory outside the build context, so `git describe` prints nothing. The policy said a plain build must succeed and did not name this case.

`prompts/REPO_POLICIES.md` and both checklists now say, right after that rule, that such a checkout is the exception and is given its version with `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already do. The check is unchanged.

Model: opus-5-5

.golangci.yml

@@ -25,6 +25,8 @@ linters:
     # silenced by disabling that name, not by enabling the successor.
     - wsl              # Deprecated, replaced by wsl_v5
     - gomodguard       # Deprecated, replaced by gomodguard_v2
+    # Misses findings at random in v2.14.0; back once a pinned release fixes it
+    - canonicalheader
   settings:
     lll:
       line-length: 88

TODO.md

@@ -21,6 +21,19 @@ fmt-check, and commit.
 
 # Completed Steps
 
+- 2026-10-06: `REPO_POLICIES.md` and both checklists now say that a checkout
+  whose `.git` is a file, a linked worktree or a repository checked out as a
+  submodule, is the exception to a plain `docker build .` succeeding (issue
+  111): that file points to a git directory outside the build context, so the
+  build cannot read the version and the version check in the canonical
+  `Dockerfile` stops it. Such a build is given its version with
+  `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already do.
+  The check itself is unchanged.
+- 2026-10-06: The canonical `.golangci.yml` now disables `canonicalheader`
+  (issue 105). In golangci-lint v2.14.0 it misses findings at random in a
+  package that also calls `ResponseWriter.Header()`, so the same tree can fail
+  lint on one run and pass on the next. It comes back once a pinned
+  golangci-lint release fixes it.
 - 2026-10-06: The canonical `.gitignore` and `.editorconfig` now each end with a
   comment saying the repository's own entries go below it and a re-vendor keeps
   them (issue 103, which took in issue 104), as `.dockerignore`'s header already

prompts/EXISTING_REPO_CHECKLIST.md

@@ -91,10 +91,14 @@ with your task.
       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.
+      A checkout whose `.git` is a file (a linked worktree, or a repository
+      checked out as a submodule) is the exception: that file points to a git
+      directory outside the build context, so the build cannot read the version
+      and a plain `docker build .` fails; pass the version with
+      `--build-arg VERSION=...`. `script/docker` and `script/cibuild` already
+      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`

prompts/NEW_REPO_CHECKLIST.md

@@ -97,6 +97,12 @@ Template files can be fetched from:
       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.
+      A checkout whose `.git` is a file (a linked worktree, or a repository
+      checked out as a submodule) is the exception: that file points to a git
+      directory outside the build context, so the build cannot read the version
+      and a plain `docker build .` fails; pass the version with
+      `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already
+      do.
     - The Dockerfile carries a `lint` phase and a `test` phase, each invoking
       its tool directly rather than through `make` or `script/`, and the final
       stage carries a `COPY --from=` of a harmless file from each so the image

prompts/REPO_POLICIES.md

@@ -281,6 +281,12 @@ style conventions are in separate documents:
       `.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.
+      A checkout whose `.git` is a file (a linked worktree, or a repository
+      checked out as a submodule) is the exception: that file points to a git
+      directory outside the build context, so the build cannot read the version
+      and a plain `docker build .` fails; pass the version with
+      `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already
+      do.
 
 - Every repo should have a Gitea Actions workflow (`.gitea/workflows/`) that
   runs `script/cibuild` on push, and checks out the repo as its only other step.