Merge branch 'main' into style/constructor-naming-params

Only exception: stupidly obvious single args (featureflag.New(true)).
When in doubt, use Params.

prompts/CODE_STYLEGUIDE_GO.md

@@ -1,6 +1,6 @@
 ---
 title: Code Styleguide — Go
-last_modified: 2026-03-18
+last_modified: 2026-02-22
 ---
 
 1.  Try to hard wrap long lines at 77 characters or less.
@@ -138,13 +138,13 @@ last_modified: 2026-03-18
 
 1.  Constructors **must** be called `New()`. `modulename.New()` works great if
     you name the packages properly. If the constructor creates an instance from
-    an existing value or representation, `From<Something>()` (e.g.
-    `FromBytes()`, `FromConfig()`) is also acceptable. If the package contains
-    multiple types and `New()` is ambiguous, `NewThing()` is occasionally
-    acceptable — but prefer restructuring packages so each type gets its own
-    package and a plain `New()`. Do not invent creative constructor names like
-    `Create()`, `Make()`, `Build()`, `Open()` (unless wrapping an OS resource),
-    or `Init()`. If you see a constructor with a non-standard name, rename it.
+    an existing value or representation, `From<Something>()` (e.g. `FromBytes()`,
+    `FromConfig()`) is also acceptable. If the package contains multiple types
+    and `New()` is ambiguous, `NewThing()` is occasionally acceptable — but
+    prefer restructuring packages so each type gets its own package and a plain
+    `New()`. Do not invent creative constructor names like `Create()`, `Make()`,
+    `Build()`, `Open()` (unless wrapping an OS resource), or `Init()`. If you
+    see a constructor with a non-standard name, rename it.
 
 1.  Don't make packages too big. Break them up.
 

prompts/REPO_POLICIES.md

@@ -1,6 +1,6 @@
 ---
 title: Repository Policies
-last_modified: 2026-03-18
+last_modified: 2026-03-12
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -149,42 +149,6 @@ style conventions are in separate documents:
 - `make test` must complete in under 20 seconds. Add a 30-second timeout in the
   Makefile.
 
-- **`make test` should use the conditional verbose rerun pattern.** Run tests
-  without `-v` (verbose) first. If tests fail, automatically rerun with `-v` to
-  show full output. This keeps CI logs and `docker build` output clean on
-  success (just package/suite summaries) while providing full diagnostic detail
-  on failure (every test case, every assertion). The general shell pattern:
-
-    ```makefile
-    test:
-    	@<test-command> || \
-    		{ echo "--- Rerunning with -v for details ---"; \
-    		  <test-command-with-v>; exit 1; }
-    ```
-
-    Go example:
-
-    ```makefile
-    test:
-    	@go test -timeout 30s -race -cover ./... || \
-    		{ echo "--- Rerunning with -v for details ---"; \
-    		  go test -timeout 30s -race -v ./...; exit 1; }
-    ```
-
-    Python example:
-
-    ```makefile
-    test:
-    	@python -m pytest || \
-    		{ echo "--- Rerunning with -v for details ---"; \
-    		  python -m pytest -v; exit 1; }
-    ```
-
-    The `exit 1` ensures the target always fails after a rerun — the first run
-    already proved the tests are broken, so the build must not pass even if a
-    flaky test happens to succeed on the second attempt. The rerun exists solely
-    for diagnostic output.
-
 - Docker builds must complete in under 5 minutes.
 
 - `make check` must not modify any files in the repo. Tests may use temporary