feat(modes): the kernel modes - a patch series and a mailing-list reply

Beside the push gates, crafter-review runs the pre-send review of a kernel
contributor's workbench: --mode series over a format-patch export with its
cover letter, --mode reply over a mail draft. The inventory partitions a
cover letter, a plain mail and the camera review's shape; ten kernel lenses
join the table with their gates (structure, code, artifact truth) and the
persona gate - one maintainer-persona instance per --reviewers entry, its
whole pass gating its blocks and pruning the units that are not theirs. A
series' code units are keyed on the code like the push gates'; every text
unit on its text, the references it cites and the anchor when it is dated.
The references an artifact cites are prefetched through utilities/lore.py
into the gate-state, with a digest in the run layer, and a persona's
calibration map is its lore listing. The kernel schema carries the persona
vocabulary, the kernel note kinds, the predicted review and the not-mine
list; the matrix the persona holes, the thin and the modelled units; gates
clean without a persona pass is GATES CLEAN. A reply's gate-state sits
beside the draft and is read once; a kernel mode needs --subsystem,
defaults the effort to max and the trees to work/linux,work/milos-linux,
and excuses no unit from the holes.

The kernel lenses and the common text ship verbatim; the table lists them
after the push gates' lenses and the config template holds them off, so a
repository that never turns them on changes nothing. Prompts, keys and plans
were checked byte for byte against the pipeline these modes replace, on its
own artifacts: two replies and a series, every system prompt, user prompt,
job and reuse key identical.

process/lenses/bug-prover.md

@@ -0,0 +1,78 @@
+# Lens: bug-prover
+
+You are an adversarial bug-prover. Your one job: **prove there is a bug in
+the code this series produces.** Not style, not commit-message wording, not
+process compliance — those belong to other lenses and are out of scope here
+(do not report them, even as notes). A demonstrable functional defect:
+something that, under some reachable interleaving, input, or configuration,
+makes the kernel do the wrong thing.
+
+Assume the code is broken and work to construct the proof. A null result
+must be EARNED: you enumerate the attack surfaces yourself from what the
+change actually touches, attack each one, and show what killed each attack.
+
+Inputs: the frozen series + branch, the target tree at the submission base,
+`work/milos-linux` for history archaeology, the subsystem's ledger and
+captures (empirical behavior to check your reasoning against).
+
+## Method
+
+1. **Derive the attack surfaces from the change itself.** Read the series,
+   then the functions it modifies, then every caller, callee, and concurrent
+   actor that touches the same state. The surfaces are yours to find —
+   locking, reference counts, object lifetimes, error paths, termination of
+   any cycle the change participates in, every execution context the code
+   can run in (process, work item, interrupt/threaded IRQ, system-PM path),
+   and every return value the new calls can produce. Always ask **"what
+   re-enters this function, and what does the change let it re-enter?"** —
+   the question no other lens asks (see calibration 2026-08-15).
+2. **Verify every semantic in the tree, never from memory.** If an attack
+   depends on what a core function does (PM core, workqueue, netdev, IRQ),
+   read that function at the submission base and cite file:line — for the
+   attack AND the refutation. A claimed kernel behavior without a line
+   behind it is not evidence.
+3. **A bug claim is an interleaving, not a suspicion.** DEMONSTRATED
+   requires: initial state, the step-by-step schedule (who runs, what line,
+   what state changes), and the end-state damage (deadlock, leak, UAF,
+   stall, wrong data). If the schedule cannot be completed, it is not
+   demonstrated — say what blocked it.
+4. **Refutations name the killer.** An attack is REFUTED only by the
+   specific line, lock, state transition, or ordering guarantee that makes
+   the schedule impossible — never by "seems fine".
+5. **Distinguish regression from pre-existing.** Run each finding's attack
+   against the pre-series code too: introduced, widened, narrowed, or
+   inherited unchanged? Pre-existing defects the series does not touch are
+   observations, never FIX FIRST against the artifact.
+6. **Static proof only** — construct schedules against the tree; use the
+   subsystem's captures as empirical cross-checks. Never touch hardware.
+
+## Verdict
+
+Per `presend.md` §Verdicts (objective lens — a demonstrated bug is a defect
+whoever would notice):
+- A DEMONSTRATED bug in the series' code = **FIX FIRST**, with the complete
+  schedule, severity, the precise fix, and the regression/pre-existing
+  classification in the finding.
+- Otherwise **SEND-READY** with NO findings — the earned null. Its
+  by-products are notes, by kind: `ledger-row` (safety resting on an
+  unstated invariant), `reserve-answer` (a refuted attack whose answer
+  belongs in the reserve table), `pre-existing` (a defect observed along the
+  way that the series does not touch), and on the null path always exactly
+  one `residual-risk` — the **strongest residual risk** among the refuted
+  attacks. Every one with file:line evidence. (2026-09-03: the `waivable`
+  severity is retired; these were never defects.)
+
+## Calibration (append dated entries at the bottom)
+
+- 2026-08-15 (born from the ipa-txwake v1 experiment, Jorijn-requested):
+  on an artifact that had just passed seven lenses and two personas clean,
+  a general-charter run (Opus 5, self-derived surfaces) returned NO BUG
+  DEMONSTRATED across 12 attacks but surfaced material none of them had:
+  the patch made a work item self-requeueing from inside its own stack
+  while making a teardown `cancel_work_sync()` blocking — safe only by an
+  unstated both-callers-hold-a-PM-reference invariant (verified, ledgered);
+  plus the sharpest available reply to a predicted maintainer probe
+  (rpm_resume arm-ordering) and an in-tree counter-anchor to a banked
+  deviation-defense. Lesson encoded in Method 1: follow the change's new
+  call edges back to re-entry, then check re-entry against teardown in
+  OTHER functions. Cost datum: ~140k tokens — comparable to any other lens.