V9.14.008.2026.06.04

Signed-off-by: Marc S. Weidner <msw@coresecret.dev>

code_review.md

@@ -1,49 +1,78 @@
 # code_review.md
 
-Review priorities, in order:
+Use this file for explicit review tasks and final self-review after implementation.
+Do not treat it as a mandate for an unlimited audit unless the user asks for one.
+
+## Review priorities
+
+Review findings in this order:
 
 1. Correctness
 2. Security regressions
 3. Boot/build reproducibility
 4. Data loss risk
 5. Error handling
-6. Test coverage
+6. Test or validation coverage
 7. Maintainability
 8. Minimality of diff
 9. Style consistency
 
-Finding classes:
-- BLOCKER: proven correctness bug, security regression, build break, boot break, or data loss risk that must be fixed before
-  merge
-- RISK: plausible issue or security concern that is not fully proven from the available context
-- CLEANUP: maintainability, readability, or consistency improvement that is not required for correctness
-- NOTE: observation only; no change requested
+## Finding classes
 
-Review output format:
-- List findings first, ordered by severity.
-- Cite file paths and line numbers where possible.
-- For each finding, explain the concrete impact, and the smallest reasonable fix.
-- Separate observations, inferences, and recommendations.
-- After findings, list missing checks or residual risks.
-- If there are no findings, say so explicitly and still mention relevant test gaps.
+- `BLOCKER`: proven correctness bug, security regression, build break, boot break, or data loss risk that must be fixed before merge.
+- `RISK`: plausible issue or security concern that is not fully proven from the available context.
+- `CLEANUP`: maintainability, readability, or consistency improvement that is not required for correctness.
+- `NOTE`: observation only; no change requested.
 
-Do not nitpick formatting if automated tooling exists.
-Do not invent requirements not present in the task, repository, or documentation.
+## Review output format
+
+List findings first, ordered by severity.
+
+For each finding include:
+
+- class
+- file path and line number where possible
+- observation
+- concrete impact
+- smallest reasonable fix
+
+Then include:
+
+- missing checks or validation gaps
+- residual risks
+- concise final recommendation
+
+If there are no findings, say so explicitly and still mention relevant validation gaps.
+
+## Scope control
+
+- Do not nitpick formatting when automated tooling exists.
+- Do not invent requirements not present in the task, repository, or documentation.
+- Do not expand a small implementation task into a broad quality-management audit.
+- Do not request a full live build unless the changed code path affects image generation in a way that cannot be checked narrowly.
+- Prefer a small actionable finding over a broad speculative warning.
+
+## Security-sensitive checklist
+
+Check whether the change affects:
 
-Security-sensitive review checklist:
 - boot trust
 - initramfs behavior
+- live-boot runtime behavior
 - cryptsetup/LUKS handling
 - encrypted SquashFS handling
 - key material
-- remotely unlock
-- TLS/mTLS verification
-- signature/hash verification
+- remote unlock
+- TLS or mTLS verification
+- signature, checksum, or provenance verification
+- package sources or remote downloads
 - network exposure
 - file permissions
 - persistence
 - logging of sensitive values
 
+For affected areas, separate observation, inference, and recommendation.
+
 ---
 **[no tracking | no logging | no advertising | no profiling | no bullshit](https://coresecret.eu/)**
 <!-- vim: set number et ts=2 sw=2 sts=2 ai tw=128 ft=markdown -->