kami
3467826d4a
The reviewer prompt told the model to judge "the analysis requirements," but the reviewer stage only needed [patch, impl_plan] — it never actually received the analysis artifact, so the acceptance criteria it was meant to check against were never in its context. A reliability gate checking against criteria it can't see is theater. - reviewer now needs `analysis`, so the diff is judged against concrete, pre-stated acceptance criteria (§5 narrow question) rather than whole files against taste; the §3 minItems enforcement guarantees those criteria are non-empty. - reviewer.md operationalizes §5's two principles: evaluate the diff against each requirement (findings must map to a requirement/plan-step/defect), and don't re-report what deterministic tools already catch (compiler/detekt/tests — trust verification, point at failures, don't re-derive them). This is the workflow-level realization of §5. The full static-first infrastructure (running static tools as a pipeline step and mechanically excluding their findings from reviewer context) needs a static-findings event representation and is deferred. §6 critic calibration needs runtime history before it can say anything (spec ordering #5).