risk-review
code-review is Outpost's fast pass: one read, one verdict, the cheap checks left to the linter
and CI. Some changes deserve more than a read. risk-review runs code-review first, then
requires the claims the risky part depends on to actually be attacked, the way grill attacks a
design, before it will approve.
When to use it
- A change to
install.py, kit/installers/, or a kit/adapters/ write path: the code that
decides what gets written, kept, or deleted on a user's project.
- Any other change the author names as hard to reverse.
- Skip it for an ordinary change;
code-review alone is the right weight there.
Required inputs
- The diff or branch, same as
code-review.
- The specific risk: which files or behavior make this change worth the heavier pass, named
explicitly, not inferred.
Steps
- Run
code-review's own pass first: intent, contracts, data boundaries, portability, tests,
prose. Do not skip or shorten it.
- From the risky part only, name the specific claims this change depends on: what has to be true
for it not to delete, corrupt, or silently drop something it should not.
- Attack each claim with
grill's method: the strongest concrete counter-case, an input,
sequence, or missing precondition that breaks it. Mark each SURVIVED or BROKEN.
- A
BROKEN claim is a finding, not a note. Rank it with code-review's own severity.
Output format
- Verdict:
approve, comment, or request changes, same shape as code-review.
- Claims: the risky part's claim list, each marked
SURVIVED or BROKEN with its counter-case.
- Findings:
code-review's usual findings, plus any BROKEN claim, blocking ones first.
Stop conditions
- Do not approve while a claim tied to the named risk has not been attacked. A claim left
unattacked is an incomplete verdict, not a weaker one.
- Read-only, same as
code-review and grill. It produces the review; it does not apply fixes.
- Stop once every named-risk claim has a mark and the verdict is stated. Do not widen the attack
to parts of the diff outside the named risk; that is plain
code-review's job.
1---2name: risk-review3description: Use before merging a change to install.py, kit/installers/, or kit/adapters/ write paths, or anything the author names as hard to reverse. Gates the verdict on actually attacking the claims the risky part depends on, not just reading them. Distinct from code-review, which does not require that.4---56# risk-review78`code-review` is Outpost's fast pass: one read, one verdict, the cheap checks left to the linter9and CI. Some changes deserve more than a read. `risk-review` runs `code-review` first, then10requires the claims the risky part depends on to actually be attacked, the way `grill` attacks a11design, before it will approve.1213## When to use it1415- A change to `install.py`, `kit/installers/`, or a `kit/adapters/` write path: the code that16 decides what gets written, kept, or deleted on a user's project.17- Any other change the author names as hard to reverse.18- Skip it for an ordinary change; `code-review` alone is the right weight there.1920## Required inputs2122- The diff or branch, same as `code-review`.23- The specific risk: which files or behavior make this change worth the heavier pass, named24 explicitly, not inferred.2526## Steps27281. Run `code-review`'s own pass first: intent, contracts, data boundaries, portability, tests,29 prose. Do not skip or shorten it.302. From the risky part only, name the specific claims this change depends on: what has to be true31 for it not to delete, corrupt, or silently drop something it should not.323. Attack each claim with `grill`'s method: the strongest concrete counter-case, an input,33 sequence, or missing precondition that breaks it. Mark each `SURVIVED` or `BROKEN`.344. A `BROKEN` claim is a finding, not a note. Rank it with `code-review`'s own severity.3536## Output format3738- Verdict: `approve`, `comment`, or `request changes`, same shape as `code-review`.39- Claims: the risky part's claim list, each marked `SURVIVED` or `BROKEN` with its counter-case.40- Findings: `code-review`'s usual findings, plus any `BROKEN` claim, blocking ones first.4142## Stop conditions4344- Do not approve while a claim tied to the named risk has not been attacked. A claim left45 unattacked is an incomplete verdict, not a weaker one.46- Read-only, same as `code-review` and `grill`. It produces the review; it does not apply fixes.47- Stop once every named-risk claim has a mark and the verdict is stated. Do not widen the attack48 to parts of the diff outside the named risk; that is plain `code-review`'s job.
alawein