# code_review.md

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. Data loss risk
4. Boot-chain integrity
5. Reproducibility and deterministic behavior
6. Error handling and cleanup
7. Test or validation coverage
8. Maintainability
9. Minimality of diff
10. Style consistency

## Finding classes

- `BLOCKER`: proven correctness bug, security regression, installer 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.

## 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

- Review the requested change, touched files, and directly affected code paths.
- Do not expand a small implementation task into a broad repository audit.
- Do not nitpick formatting when automated tooling exists.
- Do not invent requirements not present in the task, repository, or documentation.
- Do not request a full installer run, debootstrap run, destructive disk test, or network-heavy validation unless the changed
  path cannot be checked responsibly any other way.
- Prefer a small actionable finding over a broad speculative warning.
- Separate observation, inference, and recommendation when the evidence is incomplete.

## Installer-specific security checklist

Check whether the change affects:

- destructive disk operations, disk selection, partition table wiping, or formatting
- partition boundaries, GPT/MBR type codes, bootable flags, or firmware mode selection
- cryptsetup/LUKS2 parameters, passphrases, key files, key slots, LUKS UUIDs, header backups, or nuke behavior
- Btrfs filesystem creation, subvolumes, snapshots, labels, compression, or mount options
- `/etc/fstab`, `/etc/crypttab`, UUIDs, PARTUUIDs, mapper names, or initramfs flags
- initramfs-tools hooks, scripts, included binaries, early boot paths, or update-initramfs behavior
- Dropbear initramfs remote unlock, forced commands, host keys, firewalling, unlock-wrapper signatures, or hashes
- GRUB package selection, GRUB modules, encrypted `/boot`, UEFI fallback paths, BIOS install paths, or NVRAM behavior
- chroot command construction, `env -i` sanitization, target mount handling, or host/target path separation
- APT source generation, package authentication, Debian suite selection, signature verification, or hash verification
- remote downloads, TLS settings, bundled source archives, provenance, or checksum files
- key material, SSH keys, PGP keys, SOPS/AGE values, passphrase files, or secret cleanup
- logging, debug traces, trap output, and accidental disclosure of sensitive values
- file permissions, ownership, sudo policy, PAM, SSH policy, UFW, fail2ban, sysctl, modprobe, or hardening files
- recovery target behavior and consistency with the primary target
- reproducibility, deterministic ordering, and generated file stability
- direct or indirect data loss risk

---
**[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 -->