config: migrate gomodguard to gomodguard_v2 in canonical .golangci.yml

golangci-lint v2.12.0 deprecated `gomodguard` in favour of `gomodguard_v2`.
Because the canonical config uses `default: all`, the deprecated linter is
auto-enabled and every lint run in every consuming Go repo emits a
deprecation warning.

`gomodguard` and `gomodguard_v2` are two independently registered linters
in v2.12.2, so `gomodguard_v2` is already enabled by `default: all`; only
the deprecated one needs disabling. This mirrors the existing `wsl` entry,
which was disabled for the same reason when `wsl_v5` superseded it.

No settings migration was required: the canonical config configures no
gomodguard settings at all.

Refs: #25

.golangci.yml

@@ -13,8 +13,10 @@ linters:
   disable:
     # Genuinely incompatible with project patterns
     - exhaustruct      # Requires all struct fields
+    - depguard         # Dependency allow/block lists
     - godot            # Requires comments to end with periods
     - wsl              # Deprecated, replaced by wsl_v5
+    - gomodguard       # Deprecated, replaced by gomodguard_v2
     - wrapcheck        # Too verbose for internal packages
     - varnamelen       # Short names like db, id are idiomatic Go
   settings:
@@ -27,32 +29,6 @@ linters:
       max-complexity: 15
     dupl:
       threshold: 100
-    depguard:
-      # Test-support code must not be compiled into the shipped binary. A
-      # test-support package exists to hand a test privileges the program
-      # itself must never have, so a file that is not a test must not import
-      # one. Test files, and the files inside a package whose directory name
-      # ends in `test`, are where that code belongs, and are exempt.
-      #
-      # The deny list below is the one part of this file a repository is
-      # expected to extend, and the only part it may. depguard matches an
-      # import path against a list of prefixes, so it cannot be told "any path
-      # whose last segment ends in test"; a repository's own test-support
-      # packages have to be named here one at a time, by full import path,
-      # under a module path that differs from repository to repository. Add
-      # them; change nothing else.
-      rules:
-        test-support:
-          list-mode: lax
-          files:
-            - "$all"
-            - "!$test"
-            - "!**/*test/**"
-          deny:
-            - pkg: net/http/httptest
-              desc: >-
-                Test-support code belongs in test files and in packages whose
-                directory name ends in test, not in the shipped binary.
 
 issues:
   max-issues-per-linter: 0

prompts/CODE_STYLEGUIDE_GO.md

@@ -124,15 +124,10 @@ last_modified: 2026-03-18
 
 1.  Keep the `main()` function as small as possible.
 
-1.  Keep the `main` package as small as possible. Each `cmd/<name>/` directory
+1.  Keep the `main` package as small as possible. Move as much code as is
-    contains a single `main.go` whose body is one call into library code (for
+    feasible to a library package, even if it's an internal one. `main` is just
-    example `os.Exit(cli.Main())` calling `internal/cli`). All CLI logic — flag
+    an entrypoint to your code, not a place for implementations. Exception:
-    parsing, subcommand dispatch, argument handling, output formatting — lives
+    single-file scripts.
-    in `internal/` or `pkg/`, not in `cmd/`. `main` is just an entrypoint to
-    your code, not a place for implementations. Exception: single-file scripts.
-
-1.  No project logic outside `internal/` or `pkg/`. Anything in `cmd/` is a thin
-    entrypoint only.
 
 1.  HTTP HandleFuncs should be returned from methods or functions that need to
     handle HTTP requests. Don't use methods or your top level functions as

prompts/EXISTING_REPO_CHECKLIST.md

@@ -59,9 +59,7 @@ with your task.
 - [ ] README has an **Entrypoints** section documenting the `script/`
       entrypoints and linking the standard
 - [ ] `make check` does not modify any files in the repo
-- [ ] `make test` has a 90-second timeout and completes within the 60-second
+- [ ] `make test` has a 30-second timeout
-      hard cap (over 20 seconds is green but must be filed as an improvement
-      bug)
 - [ ] `make test` runs real tests, not a no-op (at minimum, import/compile
       check)
 - [ ] `make check` passes on current branch

prompts/NEW_REPO_CHECKLIST.md

@@ -80,8 +80,8 @@ are thin shims calling them. Model scripts:
       installs
 - [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`,
       then `install-precommit`, plus repo-specific init
-- [ ] `script/test` / `make test` — runs real tests, not a no-op (90-second
+- [ ] `script/test` / `make test` — runs real tests, not a no-op (30-second
-      timeout, 60-second hard cap on wall time)
+      timeout)
 - [ ] `script/lint` / `make lint` — runs linter
 - [ ] `script/fmt` / `make fmt` — formats code (writes)
 - [ ] `script/fmt-check` / `make fmt-check` — checks formatting (read-only)

prompts/REPO_POLICIES.md

@@ -1,6 +1,6 @@
 ---
 title: Repository Policies
-last_modified: 2026-08-19
+last_modified: 2026-08-07
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -189,13 +189,8 @@ style conventions are in separate documents:
   module under test to verify it compiles/parses. There is no excuse for
   `make test` to be a no-op.
 
-- `make test` must complete in under 60 seconds. That is the hard cap, and a
+- `make test` must complete in under 20 seconds. Add a 30-second timeout in the
-  suite that exceeds it fails. Under 20 seconds is the target. A suite between
+  Makefile.
-  20 and 60 seconds is still green, but the overage must be filed as an
-  improvement bug against that repo. Add a 90-second timeout to the test
-  invocation in the Makefile (`go test -timeout 90s`). The backstop deliberately
-  sits above the hard cap so that it catches a genuinely hung test rather than a
-  merely slow one.
 
 - **`make test` should use the conditional verbose rerun pattern.** Run tests
   without `-v` (verbose) first. If tests fail, automatically rerun with `-v` to
@@ -214,9 +209,9 @@ style conventions are in separate documents:
 
     ```makefile
     test:
-    	@go test -timeout 90s -race -cover ./... || \
+    	@go test -timeout 30s -race -cover ./... || \
     		{ echo "--- Rerunning with -v for details ---"; \
-    		  go test -timeout 90s -race -v ./...; exit 1; }
+    		  go test -timeout 30s -race -v ./...; exit 1; }
     ```
 
     Python example:
@@ -263,18 +258,11 @@ style conventions are in separate documents:
 - Make all changes on a feature branch. You can do whatever you want on a
   feature branch.
 
-- `.golangci.yml` is standardized. The vendored copy in a consuming repo must
+- `.golangci.yml` is standardized and must _NEVER_ be modified by an agent, only
-  _NEVER_ be modified by an agent: fetch it from
+  manually by the user. Fetch from
-  `https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml` and keep it
+  `https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml`. The
-  byte-identical, so that no repo can quietly loosen its own linting. Linter
+  canonical golangci-lint version is v2.12.2 (released 2026-05-06), installed
-  configuration changes are made to the canonical copy in the `prompts` repo and
+  commit-pinned via
-  reach consuming repos by re-vendoring; an agent may open a PR against
-  canonical, which only the user merges. One list is exempt from byte-identity,
-  because it cannot be written once for every repo: the `deny` list of the
-  `test-support` depguard rule, where a repo names its own test-support packages
-  by full import path. A repo adds entries there and changes nothing else, and a
-  re-vendor carries its entries forward. The canonical golangci-lint version is
-  v2.12.2 (released 2026-05-06), installed commit-pinned via
   `go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@c0d3ddc9cf3faa61a4e378e879ece580256d76e5`.
 
 - When pinning images or packages by hash, add a comment above the reference
@@ -394,9 +382,7 @@ style conventions are in separate documents:
   language-specific config). Everything else goes in a subdirectory. Canonical
   subdirectory names:
     - `bin/` — executable scripts and tools
-    - `cmd/` — Go command entrypoints; thin only: one `main.go` per binary whose
+    - `cmd/` — Go command entrypoints
-      body is a single call into `internal/` or `pkg/`, no project logic in
-      `cmd/`
     - `configs/` — configuration templates and examples
     - `deploy/` — deployment manifests (k8s, compose, terraform)
     - `docs/` — documentation and markdown (README.md stays in root)