@rune-kit/rune 2.29.0 → 2.30.0

package/skills/preflight/SKILL.md

@@ -103,7 +103,7 @@ const permissions = await fetchPermissions(id); // waits unnecessarily
 const [user, permissions] = await Promise.all([fetchUser(id), fetchPermissions(id)]);
 ```
 
-Flag each issue with: file path, line number, category (null-deref | missing-await | off-by-one | type-coerce), and a one-line description.
+Flag each issue with: file path, a **verbatim evidence snippet** copied from the file, category (null-deref | missing-await | off-by-one | type-coerce), and a one-line description. Record the snippet, not a line number — Step 6's Anchor Pass resolves the line with `Grep`.
 
 ### Step 2 — Error Handling
 For every changed file, verify:
@@ -132,7 +132,7 @@ app.use((err, req, res, next) => {
 });
 ```
 
-Flag each violation with: file path, line number, category (bare-catch | missing-status-check | raw-error-exposure), and description.
+Flag each violation with: file path, a **verbatim evidence snippet**, category (bare-catch | missing-status-check | raw-error-exposure), and description. Same rule as Step 1 — the snippet is what you produce; the line number comes from Step 6's Anchor Pass.
 
 ### Step 3 — Regression Check
 Use `rune:scout` to identify all files that import or depend on the changed files/functions.
@@ -337,7 +337,21 @@ Score is appended to the Preflight Report footer. Useful for tracking quality tr
 Invoke `rune:sentinel` on the changed files. Attach sentinel's output verbatim under the "Security" section of the preflight report. If sentinel returns BLOCK, preflight verdict is also BLOCK.
 
 ### Step 6 — Generate Verdict
-Aggregate all findings:
+
+**Falsification Pass first.** Before aggregating, filter findings by disproof, not by confidence — the same rule `review` applies (`../review/SKILL.md` → Step 6):
+
+- **DROP** a finding only when the code you read contains **direct counter-evidence** against its key claim (the null check exists, the `await` is present, the caller validates the input).
+- **KEEP** a finding that depends on context outside the diff which you did read via tools — that context is evidence.
+- **KEEP** a finding you can neither verify nor disprove. "Unsure" is not grounds to drop; only counter-evidence is.
+- Dropped findings are discarded silently, never listed as considered-and-dismissed.
+
+Type each surviving finding `OBSERVED | DERIVED | ASSUMED` per `../completion-gate/references/claim-discipline.md`. An `ASSUMED` finding — one resting on a premise you could not check — names that premise and **never escalates the verdict to BLOCK on its own**. It reports as WARN with the premise stated.
+
+**Anchor Pass second.** Every finding you collected in Steps 1-4 carries an evidence snippet, not a line number. Resolve each one now via the Anchor Ladder defined in `../review/SKILL.md` → Step 6: `Grep` the exact snippet, retry once whitespace-normalised with the outer lines dropped, and on a second miss mark the finding `UNANCHORED`.
+
+`UNANCHORED` behaves here exactly as it does in `review` — downgrade one level (BLOCK → WARN → INFO), report as `path (unanchored)` with the snippet inline, never drop. A finding that will not anchor **cannot carry the BLOCK verdict on its own**, for the same reason an `ASSUMED` one cannot: halting a pipeline on a claim nobody can locate spends the developer's trust faster than the bug would have.
+
+Then aggregate all surviving findings:
 - Any BLOCK from sentinel OR a logic issue that would cause data corruption or security bypass OR a dead interactive element (Step 4 cross-layer pairing / Step 4.5 dead-interactive check) OR a BLOCK from any domain hook → overall **BLOCK**
 - Any missing error handling, regression risk with no tests, or incomplete feature (other than the BLOCK cases above) → **WARN**
 - Only style or best-practice suggestions → **PASS**
@@ -346,18 +360,28 @@ Report PASS, WARN, or BLOCK. For WARN, list each item the developer must acknowl
 
 ## Output Format
 
-```
+````
 ## Preflight Report
 - **Status**: PASS | WARN | BLOCK
 - **Files Checked**: [count]
 - **Changes**: +[added] -[removed] lines across [files] files
+- **Unanchored**: [count — findings whose evidence did not resolve to a line]
 
 ### Logic Issues
-- `path/to/file.ts:42` — null-deref: `user.name` accessed without null check
-- `path/to/api.ts:85` — missing-await: async database call not awaited
+- `path/to/file.ts:42` — [OBSERVED] null-deref: `user.name` accessed without null check
+  ```ts
+  return user.name.trim();
+  ```
+- `path/to/api.ts (unanchored)` — [ASSUMED: caller in job.ts not read] missing-await: async database call not awaited
+  ```ts
+  db.orders.insert(row);
+  ```
 
 ### Error Handling
 - `path/to/handler.ts:20` — bare-catch: error swallowed silently
+  ```ts
+  } catch (e) {}
+  ```
 
 ### Regression Risk
 - `utils/format.ts` — changed function used by 5 modules, 2 have tests, 3 untested (WARN)
@@ -379,12 +403,14 @@ Report PASS, WARN, or BLOCK. For WARN, list each item the developer must acknowl
 
 ### Verdict
 WARN — 3 issues found (0 blocking, 3 must-acknowledge). Resolve before commit or explicitly acknowledge each WARN.
-```
+````
+
+Findings under Logic Issues and Error Handling show their evidence block; the Regression, Completeness, and Coherence sections describe file-level or structural gaps that have no single line to anchor, so they carry a path only.
 
 ## Constraints
 
 1. MUST check: logic errors, error handling, edge cases, type safety, naming conventions
-2. MUST reference specific file:line for every finding
+2. MUST anchor every line-level finding to a verbatim evidence snippet, resolving the line via the Anchor Pass rather than recall — unresolved findings report `(unanchored)`, downgraded one level, and cannot carry BLOCK alone
 3. MUST NOT skip edge case analysis — "happy path works" is insufficient
 4. MUST verify error messages are user-friendly and don't leak internal details
 5. MUST check that async operations have proper error handling and cleanup
@@ -424,7 +450,7 @@ WARN — 3 issues found (0 blocking, 3 must-acknowledge). Resolve before commit
 - Cross-layer pairing checked (Step 4): every new interactive component's handler chain reaches a real endpoint/service or has an explicit UI-only scope
 - Dead-interactive scan done (Step 4.5 UI hook) on all UI files in the diff
 - Sentinel invoked and its output attached in Security section
-- Structured report emitted with PASS / WARN / BLOCK verdict and file:line for every finding
+- Structured report emitted with PASS / WARN / BLOCK verdict, and every line-level finding anchored to a verbatim snippet (or reported `(unanchored)` and downgraded)
 
 ## Cost Profile
 

package/skills/rescue/SKILL.md

@@ -7,7 +7,7 @@ metadata:
   author: runedev
   version: "0.4.0"
   layer: L1
-  model: sonnet
+  model: opus
   group: orchestrator
   tools: "Read, Write, Edit, Bash, Glob, Grep"
 ---

package/skills/research/SKILL.md

@@ -5,7 +5,7 @@ metadata:
   author: runedev
   version: "0.4.0"
   layer: L3
-  model: haiku
+  model: sonnet
   group: knowledge
   tools: "Read, Glob, Grep, WebFetch, WebSearch"
 ---

package/skills/review/SKILL.md

@@ -68,6 +68,16 @@ Every review MUST cite at least one specific concern, suggestion, or explicit ap
 
 ## Execution
 
+### Review Policy
+
+Three rules govern every step below. When a later step seems to conflict with one of these, the policy wins.
+
+**1. Precision over recall.** A false alarm costs more reviewer trust than a missed LOW finding. One wrong CRITICAL teaches the developer to skim the next report; a missed style nit costs nothing. Optimise for a report where every line is worth reading — not for coverage.
+
+**2. Blocking split.** Correctness and security findings are blocking. Style and idiom findings are non-blocking and never gate a merge on their own. Report both; only the first kind may produce REQUEST CHANGES.
+
+**3. Never guess at missing context.** When the surrounding code, caller, or convention needed to judge a line is not in front of you, either go read it (`Read`, `Grep`, `rune:scout`) or stay silent. A finding invented to fill a gap in your own reading is the single most expensive kind of false alarm.
+
 ### Step 1: Scope
 
 Determine what to review.
@@ -77,6 +87,23 @@ Determine what to review.
 - If context is unclear: use `rune:scout` to identify all files touched by the change
 - List every file in scope before proceeding — do not review files outside the stated scope
 
+**Strict Focus Rule** — the scope list you just wrote is the only set of files this review may produce findings about.
+
+- Reads outside that list are for **understanding only**. Open any file you need to judge the diff correctly (callers, types, config, conventions) — that is encouraged, not scope creep.
+- A finding whose subject is a file outside scope is **dropped, not reported** — not downgraded to LOW, not filed under "while I was in there". Dropped.
+- If you spot a genuine issue elsewhere while gathering context, record it as a **one-line follow-up in the report footer**, never as a review finding. It carries no severity and does not affect the verdict.
+
+The reason is trust, not bureaucracy: a review that wanders produces findings the author cannot act on in this change, and trains them to skim the ones they can.
+
+**Rule Loading** — pick the checklists this diff actually needs, then stop.
+
+1. Collect the distinct file extensions across the scope list you just wrote.
+2. `Read` `references/rules/index.md` and follow its mapping to the matching rule files — at most one per language present in the diff.
+3. Always read `references/rules/default.md`. It carries the five dimensions every file is judged on.
+4. Read nothing further. **Never read all rule files** — a Go rule cannot produce a true finding about a diff with no Go in it, only a plausible-looking one, and that is the noise this split exists to remove.
+
+Every rule in those files ends with a `Do not report when…` clause. That clause is as binding as the rule above it: a rule that only says when to fire will fire on everything. Rules do not restate the Review Policy, the Evidence Contract, or the claim types — they inherit all three from this file, and a rule never invents a severity or a gate of its own.
+
 ### Step 1.5: Blast Radius Assessment
 
 For each modified function/class, estimate its blast radius before reviewing.
@@ -133,33 +160,35 @@ Read each changed file. Prioritize bugs that **pass CI but break production**
 - **Data loss paths**: write operations without confirmation, delete without soft-delete, truncation without backup
 - **Edge cases**: empty input, null/undefined, zero, negative numbers, empty arrays, Unicode, timezone boundaries
 - Check for: logic errors, off-by-one errors, incorrect conditionals, broken async/await patterns
-- Flag each finding with file path, line number, and severity
+- Flag each finding using the **Evidence Contract** below — a snippet you copied, not a line number you remembered
 
-**Common patterns to flag:**
+#### Evidence Contract
 
-```typescript
-// BAD — missing await causes race condition
-async function saveUser(data) {
-  db.users.create(data); // caller proceeds before save completes
-  return { success: true };
-}
-// GOOD
-async function saveUser(data) {
-  await db.users.create(data);
-  return { success: true };
-}
-```
+Every finding carries these five fields. The line number is the one field you do **not** produce yourself.
 
-```typescript
-// BAD — null deref crash
-function getUsername(user) {
-  return user.profile.name.toUpperCase(); // crashes if profile or name is null
-}
-// GOOD — safe access
-function getUsername(user) {
-  return user?.profile?.name?.toUpperCase() ?? 'Anonymous';
-}
-```
+| Field | Required | Source |
+|-------|----------|--------|
+| `path` | yes | the Step 1 scope list |
+| `evidence` | yes | verbatim snippet copied out of the file |
+| `line` | resolved | `Grep` on `evidence` at report time — never model recall |
+| `severity` | yes | your judgement |
+| `claim` | yes | `OBSERVED` / `DERIVED` / `ASSUMED` (Step 6) |
+
+A line number recalled from a long context drifts, and a correct finding pointing at the wrong line is unactionable — the reader looks, sees nothing, and stops trusting the report. A snippet can be checked against the file; a remembered number cannot. So produce what you can copy, and let a tool resolve the rest (Step 6, Anchor Pass).
+
+**Evidence rules:**
+
+- Copy the lines **verbatim** — no rewriting, reformatting, re-indenting, or tidying
+- Strip diff markers (`+`, `-`, and the leading space on context lines) before recording
+- Include only the lines directly involved — no surrounding context padding
+- Cap at **5 lines**. A finding that needs more than 5 lines to show is a design comment, not a defect — report it without evidence at MEDIUM or below
+- Multiple disjoint locations → pick the single most relevant one and file the rest as separate findings
+
+Evidence blocks are **substance, not shape**. Under `context-engine`'s `caveman` output mode the prose around a finding compresses; the evidence block does not (`../context-engine/references/output-modes.md` — "shape is negotiable, substance is not").
+
+**Strict Focus applies here** (restated from Step 1, because this is the step that breaks it): reading a caller or a helper outside the diff to decide whether a changed line is correct is *expected*. Reporting a bug you noticed in that caller is not — that finding is dropped, or goes to the report footer as a one-line follow-up. The question this step answers is only ever "is the **changed** code correct?"
+
+**Language-specific patterns** for the files in scope come from the rule files loaded in Step 1 — each carries the concrete triggers *and* the conditions under which they must not be reported.
 
 ### Step 3: Pattern Check
 
@@ -172,30 +201,7 @@ Check consistency with project conventions.
 - Check TypeScript: no `any`, full type coverage, no non-null assertions without justification
 - Flag inconsistencies as MEDIUM or LOW depending on impact
 
-**Common patterns to flag:**
-
-```typescript
-// BAD — mutation
-function addItem(cart, item) {
-  cart.items.push(item); // mutates in place
-  return cart;
-}
-// GOOD — immutable
-function addItem(cart, item) {
-  return { ...cart, items: [...cart.items, item] };
-}
-```
-
-```typescript
-// BAD — any defeats TypeScript's purpose
-function process(data: any): any {
-  return data.items.map((i: any) => i.value);
-}
-// GOOD — typed
-function process(data: { items: Array<{ value: string }> }): string[] {
-  return data.items.map(i => i.value);
-}
-```
+Mutation, type-escape, and idiom triggers are language-specific — take them from the Step 1 rule files rather than applying one language's conventions to another's.
 
 ### Step 4: Security Check
 
@@ -345,20 +351,59 @@ End with the only metric that matters: `net: -<N> lines, -<M> deps possible.` No
 
 Produce a structured severity-ranked report.
 
-**Before reporting, apply confidence filter:**
-- Only report findings with >80% confidence it is a real issue
+#### Falsification Pass (run before writing the report)
+
+**Falsify, not verify.** Do not ask "am I confident enough to report this?" — a model cannot calibrate its own confidence to a number, so that question filters nothing and quietly drops true findings. Ask the answerable question instead: **"did I read something that disproves this?"**
+
+| | Condition | Action |
+|---|---|---|
+| **DROP** | The code you read contains **direct counter-evidence** against the finding's key claim — the null check exists three lines up, the `await` is there, the input is validated by the caller you opened | Discard it |
+| **KEEP** | The finding depends on context **outside the diff** that you did read via tools — that context is evidence, not a disqualification | Report it |
+| **KEEP** | You can neither verify nor disprove it | Report it, typed honestly (below) |
+
+**"Unsure" is not grounds to drop.** Only counter-evidence is. A finding you could not confirm is still a finding — it is reported at the severity its claim type allows, not deleted to keep the report tidy.
+
+Dropped findings are **discarded silently** — never listed as "considered and dismissed". A disproven finding is noise whether or not you label it as such.
+
+**Type every surviving finding** with a claim type from `../completion-gate/references/claim-discipline.md`:
+
+| Type | Means | Ceiling |
+|------|-------|---------|
+| `OBSERVED` | You read the code path this session and saw the defect | Any severity |
+| `DERIVED` | Follows from what you read through a mechanism you can state in the finding | Any severity |
+| `ASSUMED` | Requires an unverified premise (a caller you did not open, a runtime condition you cannot see) | **Never CRITICAL** — state the premise in the finding |
+
+An `ASSUMED` finding capped below CRITICAL is the honest form of "this looks wrong but I could not confirm the call path". Promotion happens by reading the code, never by rephrasing the finding more confidently.
+
+#### Anchor Pass (run per surviving finding)
+
+Resolve every line number now, with a tool. Climb the ladder and stop at the first rung that hits:
+
+1. `Grep` the exact `evidence` string in `path`. A hit → the finding is **anchored**; use the line number `Grep` returned.
+2. No hit → retry once with whitespace normalised (collapse runs of spaces) and the first and last lines of the snippet dropped. A hit → anchored on the remaining core.
+3. Still no hit → the finding is **`UNANCHORED`**.
+
+**`UNANCHORED` handling** — advisory, never blocking:
+
+- Downgrade severity by one level: CRITICAL → HIGH → MEDIUM → LOW. LOW stays LOW.
+- Report as `path (unanchored)` in place of `path:line`, with the evidence snippet shown inline
+- **Never silently drop it.** A failed anchor means the snippet does not match the file as you recorded it — usually a transcription slip, occasionally a file that moved while you read. Both deserve the reader's attention; neither is counter-evidence, so neither disproves the finding.
+
+Anchoring resolves a finding; it does not filter one. Only the Falsification Pass drops findings — a survivor of that pass always reaches the report, anchored or not.
+
+**Then, before reporting:**
 - Consolidate similar issues: "8 functions missing error handling in src/services/" — not 8 separate findings
 - Skip stylistic preferences unless they violate conventions found in `.eslintrc`, `CLAUDE.md`, or `CONTRIBUTING.md`
 - Adapt to project type: a `console.log` in a CLI tool is fine; in a production API handler it is not
 
 - Group findings by severity: CRITICAL → HIGH → MEDIUM → LOW
-- Include file path and line number for every finding
+- Give every finding its `path:line` from the Anchor Pass — or `path (unanchored)` — plus the evidence block underneath
 - Include a Positive Notes section (good patterns observed)
 - Include a Verdict: APPROVE | REQUEST CHANGES | NEEDS DISCUSSION
 
 ### Step 6.5: Fix-First Triage
 
-> From gstack (garrytan/gstack, 50.9k★): "Reviews that produce 20 findings and delegate all to the user waste everyone's time."
+A review that produces 20 findings and delegates every one of them back to the user has moved work, not done it.
 
 Classify each finding as **AUTO-FIX** or **ASK** before reporting:
 
@@ -376,11 +421,13 @@ Classify each finding as **AUTO-FIX** or **ASK** before reporting:
 - Collect ASK findings into ONE `AskUserQuestion` — not 5 separate questions
 - Report both: "Auto-fixed 4 issues. 2 findings need your input: [...]"
 
-**Rationalization prevention**: "This looks fine" is NOT acceptable without evidence. If you can't cite a specific file:line or convention that justifies the code, flag it as UNVERIFIED — don't rationalize away uncertainty.
+**Rationalization prevention**: "This looks fine" is NOT acceptable without evidence. If you cannot cite a specific file:line or convention that justifies the code, do not wave it through — report it as an `ASSUMED` finding naming the premise you could not check.
+
+This is the same asymmetry as the Falsification Pass, applied in the other direction: uncertainty never justifies **dropping** a finding, and it never justifies **clearing** code either. Both resolve by reading, or by saying plainly what was not read.
 
 ### Step 6.6: Scope Drift Detection
 
-> From gstack (garrytan/gstack, 50.9k★): "Intent vs diff catches scope creep that plan-based guards miss."
+Comparing stated intent against the actual diff catches scope creep that plan-based guards miss — the plan was right, the diff simply grew past it.
 
 After reviewing code, compare **stated intent** vs **actual diff**:
 
@@ -403,26 +450,6 @@ After reporting:
 - If untested code: call `rune:test` with specific coverage gaps identified
 - Call `neural-memory` (Capture Mode) to save any novel code quality patterns or recurring issues found.
 
-## Framework-Specific Checks
-
-Apply **only** if the framework is detected in the changed files. Skip if not relevant.
-
-**React / Next.js** (detect: `import React` or `.tsx` files)
-- `useEffect` with missing dependencies (stale closure) → flag HIGH
-- List items using index as key on reorderable lists: `key={i}` → flag MEDIUM
-- Props drilled through 3+ levels without Context or composition → flag MEDIUM
-- Client-side hooks (`useState`, `useEffect`) in Server Components (Next.js App Router) → flag HIGH
-
-**Node.js / Express** (detect: `import express` or `require('express')`)
-- Missing rate limiting on public endpoints → flag MEDIUM
-- `req.body` passed directly to DB without validation schema → flag HIGH
-- Synchronous operations blocking the event loop inside async handlers → flag HIGH
-
-**Python** (detect: `.py` files with `django`, `flask`, or `fastapi` imports)
-- `except:` bare catch without specific exception type → flag MEDIUM
-- Mutable default arguments: `def func(items=[])` → flag HIGH
-- Missing type hints on public functions (if project uses mypy/pyright) → flag LOW
-
 ## UI/UX Anti-Pattern Checks
 
 Apply **only** when `.tsx`, `.jsx`, `.svelte`, `.vue`, or `.html` files are in the diff. Skip for backend-only changes.
@@ -622,25 +649,36 @@ LOW       — style inconsistency, naming suggestion, minor refactor opportunity
 
 ## Output Format
 
-```
+````
 ## Code Review Report
 - **Files Reviewed**: [count]
 - **Findings**: [count by severity]
 - **Review Commit**: [git hash at time of review]
 - **Council**: [not invoked | MULTI_FAMILY (N families) | NO_DECORRELATION — same-family subagents only]
+- **Unanchored**: [count — findings whose evidence did not resolve to a line]
 - **Overall**: APPROVE | REQUEST CHANGES | NEEDS DISCUSSION
 
 ### Spec Compliance
 - [PASS/FAIL]: [acceptance criteria coverage]
 
 ### CRITICAL
-- `path/to/file.ts:42` — [description of critical issue]
+- `src/auth/session.ts:42` — [OBSERVED] loose equality on the session token: a request with no token and a session with no token are both `undefined`, and `undefined == undefined` is true, so an anonymous caller is granted that session's user
+  ```ts
+  if (req.token == session.token) return grant(session.user);
+  ```
 
 ### HIGH
-- `path/to/file.ts:85` — [description of high-severity issue]
+- `src/db/users.ts:85` — [DERIVED] create is not awaited, so the handler returns success before the write lands; a failed insert is reported to the client as 201
+  ```ts
+  db.users.create(data);
+  return { success: true };
+  ```
 
 ### MEDIUM
-- `path/to/file.ts:120` — [description of medium issue]
+- `src/cache/store.ts (unanchored)` — [ASSUMED: caller in worker.ts not read] cache write has no TTL; if the worker path also writes this key the entry never expires
+  ```ts
+  cache.set(key, value)
+  ```
 
 ### Blast Radius
 - [High-impact symbols with caller counts]
@@ -650,7 +688,14 @@ LOW       — style inconsistency, naming suggestion, minor refactor opportunity
 
 ### Verdict
 [Summary and recommendation]
-```
+
+### Follow-ups (outside this scope)
+- `other/file.ts` — [one line, no severity, does not affect the verdict; omit section if none]
+````
+
+Read the MEDIUM entry above as the shape of an honest weak finding: unanchored (so `path (unanchored)`, already downgraded one level), `ASSUMED` with its unchecked premise named, and still reported — because none of that is counter-evidence.
+
+Every finding carries its claim type from the Falsification Pass and its evidence block from the Evidence Contract. `ASSUMED` findings name the premise that was not checked and never appear under CRITICAL. A finding over the 5-line evidence cap is a design comment — it ships without a block, at MEDIUM or below. The Follow-ups section is the only place an out-of-scope observation may appear.
 
 ### Review Staleness Detection
 
@@ -666,7 +711,7 @@ When `cook` or `ship` checks review status: compare review commit hash with curr
 ## Constraints
 
 1. MUST read the full diff — not just the files the user pointed at
-2. MUST reference specific file:line for every finding
+2. MUST give every finding a verbatim evidence snippet, and resolve its line via the Anchor Pass rather than recall — an unresolved finding is reported `(unanchored)` and downgraded, never renumbered by guess
 3. MUST NOT rubber-stamp with generic praise ("well-structured", "clean code") without evidence
 4. MUST check: correctness, security, performance, conventions, test coverage
 5. MUST categorize findings: CRITICAL (blocks commit) / HIGH / MEDIUM / LOW
@@ -697,7 +742,7 @@ chain_metadata:
   exports:
     findings_count: { critical: [N], high: [N], medium: [N], low: [N] }
     findings:
-      - { severity: "[level]", file: "[path]", line: [N], message: "[issue]" }
+      - { severity: "[level]", file: "[path]", line: [N or null when unanchored], anchored: [true | false], evidence: "[verbatim snippet, ≤5 lines]", message: "[issue]", claim_type: "[OBSERVED | DERIVED | ASSUMED]" }
     verdict: "[APPROVE | REQUEST_CHANGES | NEEDS_DISCUSSION]"
     quality_score: [0-100]  # when mode: "scored"
   suggested_next:
@@ -710,9 +755,14 @@ chain_metadata:
 
 | Failure Mode | Severity | Mitigation |
 |---|---|---|
-| Finding flood — 20+ findings overwhelm developer | MEDIUM | Confidence filter: only >80% confidence, consolidate similar issues per file |
+| Finding flood — 20+ findings overwhelm developer | MEDIUM | Falsification Pass drops disproven findings; consolidate similar issues per file |
 | "LGTM" without file:line evidence | HIGH | HARD-GATE blocks this — cite at least one specific item per changed file |
-| Expanding review scope beyond the diff | MEDIUM | Limit to `git diff` scope — do not creep into adjacent unchanged files |
+| Expanding review scope beyond the diff | MEDIUM | Strict Focus Rule (Step 1) — read anything for context, but findings about out-of-scope files are dropped or become footer follow-ups |
+| Dropping a true finding because it could not be confirmed | HIGH | Falsification Pass — only counter-evidence drops a finding; "unsure" reports it as `ASSUMED` |
+| Line number recalled from context instead of resolved — points at the wrong line, reader finds nothing, stops trusting the report | HIGH | Evidence Contract (Step 2) produces a copyable snippet; the Anchor Pass (Step 6) resolves the number with `Grep`. Never write a line number you did not get back from a tool |
+| Dropping a finding because its evidence would not anchor | MEDIUM | Anchoring resolves, it never filters — `UNANCHORED` downgrades one level and reports with the snippet inline. A failed `Grep` is not counter-evidence |
+| Reading every rule file regardless of the diff's languages | MEDIUM | Step 1 Rule Loading — load only the files matching extensions in scope, plus `default.md`. A rule for a language absent from the diff can only produce a plausible-looking false finding |
+| Applying a rule's trigger while ignoring its `Do not report when…` clause | HIGH | The negative clause is part of the rule, not commentary on it. A rule cited without checking its exclusion is the single most common source of confident false alarms |
 | Security finding without sentinel escalation | HIGH | Any auth/crypto/payment code touched → MUST call rune:sentinel |
 | Skipping UI anti-pattern checks for frontend changes | MEDIUM | Any .tsx/.jsx/.svelte/.vue in diff → MUST run UI/UX Anti-Pattern Checks section |
 | Skipping spec compliance check (Step 5.5 Stage 1) | HIGH | Code quality without spec check ships clean code that does the wrong thing — always load the plan/ticket before reviewing quality |
@@ -729,7 +779,8 @@ chain_metadata:
 ## Done When
 
 - All changed files in the diff read and analyzed
-- Every finding references specific file:line with severity label
+- Rule files matching the diff's extensions loaded (plus `default.md`), and no others
+- Every finding carries a verbatim evidence snippet and a severity label, with its line resolved by the Anchor Pass or marked `(unanchored)` and downgraded
 - Security-critical code escalated to sentinel (or confirmed not present)
 - Test coverage gaps identified and documented
 - UI anti-pattern checks ran for any frontend files in diff (or confirmed not applicable)

package/skills/review/references/rules/config.md

@@ -0,0 +1,63 @@
+# Config, CI, and infrastructure files
+
+Blocking here: credentials in the tree, a CI workflow that lets untrusted code reach a secret, and a
+production default that is wide open. Formatting, key order, and comment density are not findings —
+config files attract style opinions, and a report full of them buries the one line that matters.
+
+## Secrets
+
+- A token, key, password, or connection string with a literal value
+- A `.env` file committed with real values rather than placeholders
+- A secret passed as a build argument or baked into an image layer — it stays in history
+- A credential echoed into logs by a debug or verbose setting
+
+Do not report an obvious placeholder (`changeme`, `xxx`, `example.com`, a documented dummy) or a
+value in a file the repo's ignore rules already exclude — check before reporting.
+
+## CI workflow security
+
+- `pull_request_target` combined with a checkout of the PR's head — untrusted code runs with secrets
+- A third-party action pinned to a tag or branch rather than a commit SHA
+- A workflow token granted write scope where the job only reads
+- A secret referenced in a job that a fork's PR can trigger
+- User-controlled text (title, branch name, body) interpolated straight into a `run:` block
+
+Do not report an unpinned action published by the same organization as the repository, where the
+project's other workflows follow the same convention.
+
+## Runtime and container defaults
+
+- A container running as root, or with `privileged`, host network, or a docker socket mounted
+- An image tagged `latest` in anything that is deployed
+- A debug, verbose, or development flag set in a production-facing config
+- A health check or resource limit absent on a deployed service
+
+Do not report root or `latest` in a local development compose file, a test fixture, or a
+documentation example — the risk is a property of where it is deployed, not of the string.
+
+## Network exposure
+
+- An ingress, security group, or firewall rule open to `0.0.0.0/0` on a non-public port
+- CORS allowing `*` together with credentials — the browser rejects it, and the intent is unclear
+- TLS verification disabled, or a minimum protocol version below the project's stated baseline
+- A management, metrics, or admin endpoint bound to a public interface
+
+Do not report a wildcard CORS origin on an endpoint that serves only public, unauthenticated data.
+
+## File semantics
+
+- YAML where an unquoted `yes`, `no`, `on`, `off`, or a country code like `NO` is read as a boolean
+- Duplicate keys in YAML or JSON — the last one silently wins
+- A number that must stay a string (a version, a zip code, an account id) left unquoted
+- A tab character used for indentation in YAML — a parse error
+
+Do not report quoting style on values where no type coercion is possible.
+
+## Versions and dependencies
+
+- A floating range (`*`, `latest`, an unbounded caret) in a manifest with no lockfile committed
+- A lockfile changed with no corresponding manifest change, or the reverse
+- A pinned dependency with a known advisory where the fix is a patch release
+
+Do not report a floating range in a devDependency of a library whose lockfile is deliberately not
+committed — that is the standard convention for published packages.

package/skills/review/references/rules/default.md

@@ -0,0 +1,57 @@
+# Default rules
+
+Loaded for every review, alongside any language file that matches. These are the five dimensions
+every changed file is judged on, regardless of language. Deliberately small — a language rule file
+is more specific and therefore more trustworthy, so where the two overlap, prefer the language file.
+
+## Correctness
+
+- A condition inverted, off by one, or testing a different value than the one it guards
+- An edge case the change introduces and does not handle: empty input, zero, a negative number, a
+  single-element collection, a boundary date
+- A failure path that leaves state half-written, with no rollback or compensating action
+- A default or fallback that silently produces a plausible-but-wrong value
+
+Do not report an unhandled edge case when the caller you read already excludes it — and if you did
+not read the caller, that is an `ASSUMED` finding naming the caller, not an `OBSERVED` one.
+
+## Security
+
+- Input from outside the trust boundary reaching a query, path, command, template, or redirect
+- A new entry point with no authorization check where comparable entry points have one
+- A credential, token, or key with a literal value
+- An error message or log line carrying a secret, a token, or personally identifying data
+
+Do not report on code whose only inputs are internal constants or values already validated at a
+boundary you read. Auth, crypto, and payment code still escalates to `rune:sentinel` regardless of
+whether this rule fires.
+
+## Performance
+
+- Work inside a loop that does not depend on the loop: a repeated query, a re-read file, a
+  recompiled pattern
+- An operation whose cost grows with a collection that grows without bound
+- A synchronous or blocking call on a latency-sensitive path
+
+Do not report performance on a path that runs once at startup, in a script, or in a test — and do
+not report a complexity concern without naming the input that makes it matter. An unmeasured
+micro-optimization is a LOW finding at most.
+
+## Maintainability
+
+- A magic value repeated across call sites that should be a named constant
+- A function doing several unrelated things, where the change made it worse rather than found it so
+- Naming that contradicts what the code does — a `get` that writes, an `is` that returns a value
+- Copy-pasted logic that now has to be corrected in more than one place
+
+Do not report a maintainability concern that predates the diff. Pre-existing structure is a
+footer follow-up, never a finding against this change — the author cannot act on it here.
+
+## Test coverage
+
+- New branching logic with no test exercising the new branch
+- A bug fix with no test that fails without the fix
+- A test changed to match new behaviour where the behaviour change itself was not requested
+
+Do not report missing tests for pure config, generated files, or a change whose behaviour is
+already covered by an existing test you located.

package/skills/review/references/rules/go.md

@@ -0,0 +1,65 @@
+# Go
+
+Blocking here: discarded errors, goroutine and resource leaks, data races, and nil semantics that
+panic at runtime. Naming, comment style, and receiver conventions are non-blocking — `gofmt` and
+`go vet` already cover the ground a reviewer would otherwise spend the report on.
+
+## Error handling
+
+- An error assigned to `_`, or a call whose error return is dropped entirely
+- An error returned unwrapped where the caller needs to distinguish causes — no `%w`, no sentinel
+- `err` shadowed by `:=` in an inner scope, so the outer check tests a stale value
+- `panic` on a recoverable condition in library code
+
+Do not report a discarded error on a call that cannot meaningfully fail in context — `fmt.Fprintf`
+to a `strings.Builder`, a `Close` on a read-only handle already drained — provided the discard is
+deliberate and local.
+
+## Concurrency
+
+- A goroutine with no exit path: it blocks forever on a channel nobody closes or writes
+- `sync.WaitGroup` whose `Add` is inside the goroutine rather than before it starts
+- A map or slice written from multiple goroutines without a mutex or channel discipline
+- A mutex locked on a path that can `return` before `Unlock`, with no `defer`
+- Sending on a channel that another path may have closed
+
+Do not report loop-variable capture in a module whose `go.mod` declares `go 1.22` or later — the
+per-iteration variable semantics make the classic capture bug impossible there.
+
+## Context and timeouts
+
+- `context.Background()` or `context.TODO()` inside a request path that already has a context
+- An outbound HTTP, RPC, or DB call with no deadline and no context propagation
+- A context cancel function from `WithCancel` / `WithTimeout` not deferred — a leak
+- A context stored in a struct field rather than passed as the first parameter
+
+Do not report a missing deadline on a call inside `main`, an init path, or a long-running worker
+that is meant to run until cancelled.
+
+## Resource lifecycle
+
+- `defer resp.Body.Close()` missing after a successful HTTP call, or placed before the error check
+- `defer` inside a loop where the resource must be released each iteration, not at function exit
+- A file, rows handle, or connection opened on one branch and closed on only some of them
+- `rows.Err()` never checked after a `sql.Rows` iteration
+
+Do not report a missing `Close` when the value's lifetime is the process itself.
+
+## Nil and slice semantics
+
+- A write to a nil map — reads are fine, writes panic
+- A nil pointer dereference on a path where the constructor can return `(nil, err)`
+- `append` on a slice sharing a backing array with a caller's slice, silently overwriting
+- A typed nil returned as an `error` interface — non-nil interface holding a nil pointer
+
+Do not report slice aliasing when the source slice is built inside the same function and never
+escapes it.
+
+## Untrusted input
+
+- A query assembled with `fmt.Sprintf` rather than placeholders
+- `exec.Command` whose arguments derive from input, especially through a shell
+- A path joined from input without `filepath.Clean` plus a base-directory check
+
+Do not report `fmt.Sprintf` in a query when every interpolated value is a constant or comes from a
+fixed allowlist in the same file.