style: strengthen constructor naming and Params struct rules (#19)

Per sneak's instruction:

- Constructors **must** be `New()`, `From<Something>()`, or `NewThing()` (multi-type packages only)
- Strongly discourage creative names (`Create`, `Make`, `Build`, `Init`)
- Constructors **must** use a `Params` struct (or `ThingParams`) for 2+ arguments — no exceptions
- Single obvious argument (`ctx`, bytes) is the only exception
- `context.Context` does not count against the argument limit (already documented)

Co-authored-by: user <user@Mac.lan guest wan>
Co-authored-by: clawbot <clawbot@noreply.git.eeqj.de>
Reviewed-on: #19
Co-authored-by: clawbot <clawbot@noreply.example.org>
Co-committed-by: clawbot <clawbot@noreply.example.org>

prompts/CODE_STYLEGUIDE_GO.md

@@ -1,6 +1,6 @@
 ---
 title: Code Styleguide — Go
-last_modified: 2026-02-22
+last_modified: 2026-03-18
 ---
 
 1.  Try to hard wrap long lines at 77 characters or less.
@@ -138,13 +138,13 @@ last_modified: 2026-02-22
 
 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()`,
+    an existing value or representation, `From<Something>()` (e.g.
-    `FromConfig()`) is also acceptable. If the package contains multiple types
+    `FromBytes()`, `FromConfig()`) is also acceptable. If the package contains
-    and `New()` is ambiguous, `NewThing()` is occasionally acceptable — but
+    multiple types and `New()` is ambiguous, `NewThing()` is occasionally
-    prefer restructuring packages so each type gets its own package and a plain
+    acceptable — but prefer restructuring packages so each type gets its own
-    `New()`. Do not invent creative constructor names like `Create()`, `Make()`,
+    package and a plain `New()`. Do not invent creative constructor names like
-    `Build()`, `Open()` (unless wrapping an OS resource), or `Init()`. If you
+    `Create()`, `Make()`, `Build()`, `Open()` (unless wrapping an OS resource),
-    see a constructor with a non-standard name, rename it.
+    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-12
+last_modified: 2026-03-18
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -149,6 +149,42 @@ 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