euthyna 0.2.0 → 0.3.0

package/.agents/skills/euthyna-en/SKILL.md

@@ -0,0 +1,285 @@
+---
+name: euthyna-en
+description: 'The adjudication discipline and delivery gate for code security audits. Use when the user asks to audit the security of a piece of code, a pull request, a change, or to verify an existing vulnerability claim. It does three things: supply the deterministic facts a model cannot compute (callers, test coverage, git history origins), judge every claim against six gates, and downgrade any claim that cannot produce evidence to "observation" rather than a finding. Not for: asking about the details of a single CVE, running an existing scanner once, pure documentation or formatting changes, or when the user explicitly wants a quick summary and accepts the risk.'
+whenToUse: Use when the user asks to audit the security surface of code or a repository, verify whether a suspected vulnerability is real, decide whether a finding is exploitable, review whether a change introduces a security regression, or asks to "audit before delivery". For single-topic checks such as only searching for secrets or only checking dependency versions, use the dedicated specialist skill instead and do not trigger this one.
+disable-model-invocation: true
+user-invocable: true
+---
+
+# euthyna — the adjudication discipline for code security audits
+
+> εὔθυνα: the audit every Athenian official had to submit on leaving office; you did not
+> get to walk away without handing over your accounts. That is this skill's core
+> mechanism: **saying "the audit is done" does not count. Evidence is handed over and the
+> gates decide.**
+
+**This skill does not find bugs; it polices conclusions.** Finding bugs is the model's and
+the existing tools' job. This skill's job: every conclusion must pass the gates, and a
+conclusion that cannot pass is downgraded to "observation".
+
+---
+
+## When to use / when not to use
+
+**Use**:
+
+- The user asks to audit the security surface of code, a repository, or a change (PR / commit / diff)
+- The user brings a suspected vulnerability and asks "is this real" or "is it exploitable"
+- The user asks to review whether a change weakened an existing security control
+- The user asks to "verify before delivery"
+
+**Do not use** (refuse directly or route to another skill):
+
+- Only asking about a specific CVE or dependency detail → use a dependency audit tool
+- Only asking to run an existing scanner and paste its output → that is a tool call, not an audit
+- Pure documentation, formatting, or lint changes → no security surface
+- The user explicitly wants a quick summary and accepts the risk → state that this is
+  "non-audit mode" and do not apply this skill's adjudication format
+
+---
+
+## Three non-negotiable rules
+
+These three rules are the entire difference between this skill and "tell the model to be
+more careful". No stage, no path may skip them.
+
+### Rule 1: measurable quantities come from commands, the model only interprets
+
+Caller counts, test coverage, dependency versions, line numbers, commit hashes — **none of
+these may be answered from impression**. The model may say "not measurable" when a command
+is unavailable, but it must not estimate and then write the estimate into a conclusion as a
+fact.
+
+> This comes from a measured failure: a package showed "5+ maintainers" on the code hosting
+> platform while the package manager's actual permission list had 1 person; another package
+> with 160 million weekly downloads showed zero downloads in one data source. **Estimating
+> numbers by feel is always wrong.**
+
+### Rule 2: evidence is mandatory down to `file:line`; placeholders are banned
+
+- Every claim cites a concrete location in the form `path:L123`, and `path:L123 (commit abc1234)` when a version exists
+- `probably` / `likely` / "roughly" are banned — chase the real code, and if you cannot, say you cannot
+- PoCs must not contain `TODO`, `...`, or `// attacker does something here`
+- **Once a PoC is found to use an artificial bypass** (mock, stub, disabled check), that PoC is **invalid**
+
+### Rule 3: missing data is not clean
+
+Every criterion falls into exactly one of three states: **evaluated-clean / evaluated-flagged /
+not evaluable for a stated reason**.
+
+- A run that measured nothing produces "not evaluable", **not** "no problems found"
+- Before citing any "clean" conclusion, read the coverage table first
+- **Numbers must be quoted verbatim** — no re-deriving, rounding, or dressing up
+- Finding nothing is not an endorsement
+
+---
+
+## Entry decision tree
+
+```
+What did the user give?
+│
+├─ An existing suspected-vulnerability claim ──► Stage C: claim verification
+│   ("is this real", "is it exploitable")          read references/verification-gates.md
+│                                                 ★ if the conclusion depends on "was it tested" → run coverage
+│
+├─ A change (PR / diff / commit) ───────────────► Stage B: change audit
+│   ("is this PR safe")                            read references/change-audit.md
+│                                                 ★ deleted lines in the diff → run history first
+│                                                 ★ if test coverage matters   → run coverage first
+│
+├─ A repository / dependency surface ───────────► Stage A: dependency audit
+│   ("do the dependencies have problems")          read references/dependency-audit.md
+│
+└─ A full repository security audit ────────────► Stage B as the core, with A and C as sub-steps
+```
+
+★ = **run before reading code by hand**, not as a follow-up after reading. The deterministic
+facts from the producers decide where the manual reading must be directed.
+
+**Multiple stages may run, but stages must not substitute for each other.**
+In particular: every suspected finding reported by Stage B must go through Stage C one by
+one — never write it straight into the report as a conclusion.
+
+---
+
+## The two deterministic measurements this skill ships
+
+Callers, coverage, dependency vulnerabilities and secrets are **not re-built** (see the
+division of labor at the end). But two things nobody else does — and a model cannot compute
+reliably — are shipped by this skill as a zero-dependency CLI:
+
+| Measurement | Question it answers | When it is **mandatory** |
+|---|---|---|
+| `history` | Which commit does the code this change **deleted** come from? Was that commit a security fix? | when the diff has deleted lines (Stage B) |
+| `coverage` | Was this symbol **ever actually invoked** by a test run? | when the report claims "tested / not tested" (Stage B / C) |
+
+```powershell
+node <euthyna repo>/bin/euthyna.js history  --base <pre-change revision> --repo <audited repo>
+node <euthyna repo>/bin/euthyna.js coverage --coverage <absolute path to coverage file> --symbol <symbol name>
+```
+
+⚠️ **A relative `node bin/euthyna.js` always fails.** During an audit the current directory
+is the **audited project**, not the euthyna repo, and it will report `Cannot find module`.
+Use the euthyna repo's path and pass the audited repo explicitly with `--repo` (`--base` /
+`--head` resolve against it).
+
+**Exit codes** — the difference between `2` and `0` is the reason this whole thing exists:
+
+| Code | Meaning | What to do |
+|---|---|---|
+| `0` | measured, no security-related finding | continue, but **read the "criteria not evaluated" section** |
+| `10` | measured, at least one fact classified `security` | **raise priority**, run each through Stage C; do not treat as a conclusion |
+| `1` | usage error | fix the command. This is not a measurement result |
+| **`2`** | **could not measure at all** | **must not be read as clean**. Change the measurement approach, or mark the criterion "not evaluable" |
+
+When a command is unavailable (not installed, no checkout): **mark the criterion "not
+evaluable" — never fill the gap with a hand estimate.**
+
+Operations manual (commands, real output samples, failure modes): `references/fact-producers.md`.
+
+---
+
+## The fact contract (the interface between measurement and adjudication)
+
+This skill defines the interface between the measurement layer and the adjudication layer:
+`docs/fact-contract.md`.
+
+Key points:
+
+- The contract carries only **facts** — no scores, no severity levels, no remediation advice
+- Every fact must carry a **reproduce command** or **producing tool + version**
+- **Scores must not be used as gates** (learned from `dsh-trust-check`: its contract explicitly says "do not use `score` or `band` as a gate")
+- `approximate` facts **must not participate in gates**
+- **`unknown` is not "clean"** — it is the most misused of the three states
+
+How to read a fact (what it lets you infer, and **what it does not**): `references/fact-contract.md`.
+
+---
+
+## The adjudication format
+
+Whatever path was taken, the output must land in this shape:
+
+```
+BUG #N TRUE POSITIVE — [one-line claim]
+  All gates passed. Evidence: path:L123 (commit abc1234)
+  Reproduce: <re-runnable command or PoC location>
+  Exploitability: EASY / MEDIUM / HARD
+  Impact: specific to funds / elevated privilege / exposed data
+
+BUG #N FALSE POSITIVE — [reason for rejection]
+  Gate N (gate name) FAIL: <specific evidence>
+  e.g. line 98's check guarantees packet_size >= 16, so (packet_size - header_size) >= 8.
+       Underflow is mathematically impossible.
+
+BUG #N INCONCLUSIVE — [reason it cannot be decided]
+  Gate N (gate name) NOT EVALUATED: <why>
+```
+
+**The third state `INCONCLUSIVE` must exist.** Trail of Bits' original fp-check has only two
+states because it uses a Stop hook to force infinite continuation until completion;
+**DSH cannot do that** (the Stop hook must rate-limit itself or it loops forever, see
+`docs/dsh-stop-gate.md`). So this honest exit must exist — "not finished" must never be
+written as `FALSE POSITIVE`.
+
+---
+
+## The programmatic gate check (euthyna gate)
+
+The format above is not decoration: `euthyna gate <report file>` mechanically checks every
+finding —
+
+- **TRUE POSITIVE**: evidence must reach `path:L123`, a reproduce command is mandatory, impact
+  must be stated, and all six gates must pass;
+- **FALSE POSITIVE**: at least one gate FAIL with specific evidence;
+- **INCONCLUSIVE**: at least one gate not evaluated, and no FAIL.
+
+A finding that lacks evidence, lacks reproduction, or whose gates contradict its verdict
+(such as a TRUE POSITIVE carrying a FAIL gate) is **downgraded to "observation"** and
+reported with exit code `10` — the checker does the policing, no self-awareness required.
+
+```powershell
+node <euthyna repo>/bin/euthyna.js gate <report file>
+# re-run each reproduce command to verify (allowlisted tools, argv execution, no shell):
+node <euthyna repo>/bin/euthyna.js gate <report file> --verify --cwd <audited repo>
+```
+
+- Exit code `0` = everything passed; `10` = at least one finding downgraded; `2` = the report
+  cannot be read / has no checkable finding.
+- Under `--verify`, a reproduce command that fails to run is also a downgrade — "I can
+  reproduce it" is not a claim until the run actually succeeds.
+
+**Run `euthyna gate` on the report before handing it over.** It validates the report's own
+self-declared claims; it does not audit the target repository — so it cannot replace
+adjudication, it only guarantees that a conclusion without evidence cannot leave as
+"established".
+
+---
+
+## The report must be written to disk
+
+- Outputting only to chat is a **failure**. A report file is mandatory
+- Filename: `<PROJECT>_EUTHYNA_AUDIT_<YYYY-MM-DD>.md`
+- Fallback order when writing fails: current working directory → user desktop → temp
+  directory → **last resort** only then output to chat and ask the user to save it manually
+
+---
+
+## Pre-delivery self-check (tick every item; without all of them you may not say "audit done")
+
+- [ ] Every suspected finding went through **complete** Stage C, not "looked at it and it seems false"
+- [ ] **Ran `history` when the diff has deleted lines**; code deleted from a security-fix commit handled at highest risk
+- [ ] Every "tested / not tested" sentence in the report is backed by `coverage` output, or marked "not evaluable"
+- [ ] **No criterion with exit code `2` appears in a "clean" column**
+- [ ] Every conclusion carries a `file:line`
+- [ ] Every conclusion carries one of the three states (clean / flagged / not evaluable)
+- [ ] The coverage table states **which criteria were not evaluated and why**
+- [ ] All 13 devil's advocate questions answered (including the false-negative 12 and 13)
+- [ ] The report file has been written to disk
+- [ ] The report has passed `euthyna gate` (exit code `0`; if there are downgrades, read why)
+- [ ] "Missing data" was not written as "clean"
+
+---
+
+## Reference files
+
+Load on demand. **Do not read them all at once** — progressive disclosure is why this stays
+effective in long sessions.
+
+| File | Contents | When to read |
+|---|---|---|
+| `references/verification-gates.md` | **Stage C**: routing, the six gates, false-positive list, devil's advocate, PoC rules | when judging an existing claim (**most used**) |
+| `references/change-audit.md` | **Stage B**: baseline, depth vs risk, origin attribution, blast radius, adversarial modeling | when auditing a change |
+| `references/dependency-audit.md` | **Stage A**: manifests/lockfiles, the three states, report style, prohibitions | when auditing the dependency surface |
+| `references/bug-classes.md` | Per-class checklists for 9 defect classes and their **default assumption direction** | once the defect class is chosen |
+| `references/meta-mechanisms.md` | The six meta-mechanisms that keep the process from degrading into a formality | **read once at the start of an audit** |
+| `references/fact-producers.md` | **Operations manual**: when to run the two measurements, how to write the commands, how to handle exit codes, real output samples, failure modes | **before running a producer** (Stage B / C) |
+| `references/fact-contract.md` | Once you have a fact: what it lets you infer, **and what it does not** | after reading a producer's output |
+
+> **The skill text is self-contained**: every file above lives inside `references/`, depends
+> on nothing outside the skill directory, and the whole directory can be copied into any
+> skill root.
+>
+> ⚠️ **But the producer is a separate program, not inside the skill directory.** Copying the
+> skill does not carry the CLI along. A new environment must install it separately, or ship a
+> checkout of this project; otherwise the related criteria can only be marked "not
+> evaluable" — which is an honest result, better than a hand estimate. See
+> `references/fact-producers.md` section 1.
+
+---
+
+## Division of labor with the existing ecosystem (no duplicated work)
+
+| Already built by someone else | What euthyna does |
+|---|---|
+| Call graph / blast radius (`dsh-tool-lens`, `dsh-blast-radius`) | **does not rebuild**, consumes their output |
+| Coverage (`dsh-code-coverage`) | does not rebuild, consumes its output |
+| Dependency vulnerabilities (`dsh-dep-vuln-scan` etc.) | does not rebuild, consumes its output |
+| Secret scanning (`dsh-code-security`) | does not rebuild, consumes its output |
+| Delivery gate mechanisms (`dsh-doublecheck`, `formalswarm`) | mechanisms worth borrowing; euthyna's gate content is the **security-specific** six gates |
+| Evidence lifecycle and PoC lab (`dsh-omv`) | can coexist: `dsh-omv` can be a **consumer** of the fact contract |
+
+**euthyna only supplies the two deterministic measurements nobody else does** (see
+`docs/positioning.md` §7.2): the mechanical adjudication of git security regressions, and
+the "symbol × real execution coverage" join.

package/.agents/skills/euthyna-en/references/bug-classes.md

@@ -0,0 +1,130 @@
+# Defect-class specific requirements
+
+> When adjudicating a claim, **first fix the class, then apply that class's default assumptions**.
+>
+> Because across classes, "what counts as suspicious" and "what counts as a false positive" are **opposite**. Judging every class
+> with the same intuition guarantees systematic errors in some classes.
+
+---
+
+## 0. Default assumptions flip by class
+
+This is the most important rule in this file, and the most counter-intuitive:
+
+| Class | Direction of the default assumption |
+|---|---|
+| **memory corruption** | default to **false positive**. In memory-safe languages it is almost always a false positive, unless there is a compiler defect or a type-system hole |
+| **logic defect** | default to **not a false positive**. "Logic defects pass every boundary check" — **do not let clean static analysis convince you it is a false positive** |
+| remaining classes | see below, class by class |
+
+Flip these two rows and you flood memory corruption with false positives while missing real logic-defect vulnerabilities.
+
+---
+
+## 1. Memory corruption
+
+**Do the language check first**: memory corruption in safe Rust, in Go without `unsafe.Pointer`/cgo, and in every managed language
+(Java / C# / Python / JS) is **almost always a false positive**. Passing this gate first saves most of the work.
+
+After the language check, examine:
+
+- what exactly is corrupted (stack / heap / global / object)
+- whether the size and offset of the corruption **are attacker-controlled**
+- whether it is a useful primitive (arbitrary read, arbitrary write, vtable overwrite) or merely a crash
+- whether allocator hardening is in place
+- the object lifetime of a use-after-free (UAF): can it actually be referenced again after being freed
+- type confusion: give **proof of the type mismatch**, not "it looks like one"
+
+---
+
+## 2. Logic defect
+
+**The default assumption is reversed: do not let "static analysis is clean" convince you this is a false positive.**
+
+- judge against the **spec / RFC / design documents**, not by reading code alone
+- draw **every state transition** — can an unexpected state be reached?
+- find **implicit assumptions that are never enforced**
+- for authentication-class defects, verify **all** authentication and authorization paths, not just the main path
+
+---
+
+## 3. Race condition
+
+- is the real race window **nanoseconds or seconds**? The two are entirely different problems
+- can the attacker **widen the window** (slow filesystem, large allocations, CPU contention)
+- verify the threading model: single-threaded / event loop / multi-threaded — the conclusions are entirely different
+- check every synchronization primitive, not just whether a lock exists
+- for filesystem classes, look at **symlink races** (the classic TOCTOU form)
+
+---
+
+## 4. Integer issues
+
+- the **exact type and value range** at every point, not "roughly an integer"
+- signed overflow (undefined behavior in C/C++) vs unsigned wraparound (**defined**) — they must not be conflated
+- trace every cast / conversion / promotion
+- **is the result actually used for something dangerous**: allocation size, array index, loop bound. An overflow used for log printing is not a vulnerability
+- enable checks such as `-Wconversion` and `-Wsign-compare`, and let the compiler find them for you
+
+---
+
+## 5. Crypto weaknesses
+
+- check parameters against NIST / IETF standards and known attacks
+- verify the randomness source: is it cryptographically secure
+- **nonce reuse must be shown to actually occur twice in practice**, not "theoretically possible"
+- for timing side channels, look at two things: whether the attacker can reach it, and whether network jitter makes a remote attack impractical
+- compare against the reference implementation's test vectors
+
+---
+
+## 6. Injection
+
+- trace the attacker's input along its **full path** from entry to sink, and whether it is sanitized or escaped along the way
+- is the framework's automatic escaping enabled, **and not bypassed**
+- XSS depends on context: HTML body / attribute / JS / URL — **each needs different escaping**; one escaping cannot cover all
+- path traversal: was the path normalized **before** the access check
+- run all intermediate processing with **real payloads**; do not verify in hand-written examples
+
+---
+
+## 7. Information disclosure
+
+- **what exactly is leaked**: a stack leak (can yield an ASLR base or canary) is serious; a static string is worthless
+- is the leaked data **actually useful** for further exploitation
+- for uninitialized memory, **prove that the read point is really uninitialized**
+- for timing side channels, look at measurement precision and noise level
+- can the error information **actually reach the attacker** — being written to a log does not count
+
+---
+
+## 8. Denial of service
+
+- is the resource consumption ratio or amplification factor **meaningful**
+- are resources recoverable or permanently exhausted — the two differ greatly in severity
+- **a complexity claim must show that a real worst-case input triggers it**, not just assert O(n²):
+  name the concrete input and give the measured time
+- is the crash triggered **reliably**
+- does the service restart automatically: a 100-millisecond restart and a human having to intervene are two entirely different problems
+
+---
+
+## 9. Deserialization
+
+- does the attacker **actually control** the data that reaches the deserialization point
+- is there a **usable gadget chain** in the classpath / import graph —
+  **without a gadget chain, unsafe deserialization is a design smell, not an exploitable defect**
+- the library and version, and the chains known for that version
+- are type restrictions / allowlist filters in place
+- language-specific forms: Java `ObjectInputStream`, Python `pickle`, PHP `unserialize`, .NET `BinaryFormatter`
+
+---
+
+## Usage
+
+1. Classify the assertion at Stage C's **step zero**
+2. The class sets the direction of the default assumption (see §0)
+3. When running data-flow and exploitability analysis, **layer on** that class's specific checks (table above)
+4. When evaluating the gates, that class's particular "what counts as prevented" is judged by the definitions above
+
+> Classify wrong and everything after is wrong. **When unsure, say you are unsure — do not pick a plausible-looking one to fill in.**

package/.agents/skills/euthyna-en/references/change-audit.md

@@ -0,0 +1,212 @@
+# Stage B: change audit
+
+> Audit one change (PR / commit / diff) and answer one question: **did this change make the system weaker?**
+>
+> Prerequisite: the three non-skippable rules in `../SKILL.md`.
+
+---
+
+## B.0 Establish the baseline first
+
+**This is the first action, not prep work.** Without a baseline, every judgment that follows is guesswork.
+
+Record these on the **pre-change** revision:
+
+| What to record | Why |
+|---|---|
+| system-level invariants | "what must always be true" — without them you cannot tell whether this change broke one |
+| trust boundaries and privilege levels | which data is trusted, which is not; what identity the code runs as |
+| existing validation patterns | what validation this codebase habitually does, and where |
+| call relationships of key functions | the change's blast radius is judged through them |
+| state flow | where data comes from, what it passes through, where it goes |
+| **what the code is supposed to do** | not what it currently does — its design intent |
+
+Miss the last item and you misjudge "the implementation diverges from the design" as "the implementation has a bug" — or the reverse.
+
+---
+
+## B.1 Keep two things apart: analysis depth vs risk level
+
+These two are routinely conflated, and conflating them guarantees mistakes.
+
+**Analysis depth** is set by **change size** — it only decides how much effort you spend:
+
+| Change size | Strategy | Approach |
+|---|---|---|
+| < 20 files | deep read | read all related code, full blame |
+| 20–200 | focused | follow only one-hop dependencies, prioritize high-risk files |
+| 200+ | surgical | only the critical paths |
+
+**Risk level** is set by **what changed** — it is **unrelated** to size:
+
+| Level | Trigger |
+|---|---|
+| high | authentication, crypto, external calls, money movement, **any validation deleted** |
+| medium | business logic, state changes, new public interfaces |
+| low | comments, tests, UI, logs |
+
+> **A one-line change can be the highest risk; two thousand lines can be zero risk.** Judging risk by size is the most common shortcut.
+
+---
+
+## B.2 Read both versions, file by file
+
+For every changed file, do not look at the diff alone. **Read the pre-change and post-change versions side by side**, then answer four questions per section:
+
+| Question | What it answers |
+|---|---|
+| What was it before | the original logic |
+| What is it after | the new logic |
+| **What the change does** | the intent in one sentence |
+| **What it means for security** | does the attack surface grow or shrink? does validation get stronger or weaker? |
+
+A diff only shows "which lines changed", not "how the behavior changed". Deleting one line may delete nothing (the line may already have been dead code); adding one line may change the entire execution order.
+
+### Deleted code must be traced to its origin separately
+
+**This is the step most easily skipped in this stage, and the most valuable one.**
+
+For every block of deleted code, trace its origin with this project's producer:
+
+```powershell
+node <euthyna repo>/bin/euthyna.js history --base <pre-change revision> --repo <audited repo>
+```
+
+⚠️ **Do not write `node bin/euthyna.js`** — during an audit the current directory is **the audited project**, not the euthyna repo, and a relative path fails with `Cannot find module`. `--repo` refers to **the audited repo**, and `--base` resolves against it.
+
+It tells you which commit introduced the deleted code and whether that commit's message carries security keywords. **Code deleted from a `fix` / `CVE` / `security` commit defaults to the highest risk**, unless it can be shown to be superfluous.
+
+Do not run `git blame` yourself and read commit messages by eye — that is exactly why this producer exists: a machine adjudicating the same diff twice gives the same result; a human reading twice may not.
+
+When reading the output, watch the "⚠ criteria not evaluated" section: when it is non-empty, this run **cannot** be read as "checked, no problem". Exit code `2` means it could not measure at all — **must not be read as clean**. Commands and exit codes: see `fact-producers.md`.
+
+### Three red lines
+
+| Symptom | Default handling |
+|---|---|
+| deleted code came from a security-fix commit | treat as **highest** risk, unless shown to be no longer necessary |
+| validation deleted with no equivalent replacement | treat as **highest** risk |
+| code was added → removed for security reasons → **added back now** | treat as a **regression** |
+
+The third one is mechanically detectable with the producer:
+
+```powershell
+node <euthyna repo>/bin/euthyna.js history --base <pre-change revision> --pickaxe --repo <audited repo>
+```
+
+---
+
+## B.3 Test coverage: a gap escalates risk, it is not a footnote
+
+**Missing tests are not "worth a mention" — they are grounds for escalating risk.**
+
+| Situation | Handling |
+|---|---|
+| new function with no tests | medium risk escalates to **high** |
+| validation modified but tests did not change | **high risk** |
+| complex logic (> 20 lines) with no tests | **high risk** |
+
+To claim "covered", you need real execution evidence, not an inference from "this file has a test file":
+
+```powershell
+node <euthyna repo>/bin/euthyna.js coverage --coverage <absolute path to coverage file> --symbol <changed function>
+```
+
+With no coverage file: **either produce one by running the project's own tests, or mark the criterion "not evaluable"** — `coverage` tells you explicitly with exit code `2` that it "could not measure"; that is not "not covered".
+
+> ⚠️ This producer can **only refute, never confirm**. When it says "never invoked", that is trustworthy;
+> when it says "invoked N times", it **cannot** imply "the related call sites were executed".
+> See `fact-contract.md`.
+
+---
+
+## B.4 Blast radius
+
+Count how many callers each modified function has:
+
+| Number of callers | Tier |
+|---|---|
+| 1–5 | low |
+| 6–20 | medium |
+| 21–50 | high |
+| 50+ | extreme |
+
+**Priority is set by "risk × radius" together**:
+
+| | radius extreme | radius high/medium | radius low |
+|---|---|---|---|
+| **risk high** | P0 — deep analysis + all dependencies | P1 | P2 |
+| risk medium/low | P1 | P2 | P3 |
+
+Numbers must come from tooling, not from eyeballing. Optional upstream producers: see the ecosystem division-of-labor section in `../SKILL.md`.
+
+---
+
+## B.5 High-risk changes require adversarial modeling
+
+For every high-risk change, answer:
+
+**1. Who is the attacker**
+
+| Dimension | Values |
+|---|---|
+| WHO | unauthenticated external user / authenticated ordinary user / malicious admin / compromised dependency / race winner |
+| WHAT | can only use public interfaces / needs an authenticated role / needs specific privileges |
+| WHERE | the specific endpoint or function |
+
+**2. Attack path**: entry point → concrete calls and arguments → how the vulnerable code is reached → what happens inside the code → what is achieved.
+**A reachability proof is mandatory**: the function really is publicly reachable, the attacker really has that privilege, and the path really goes through a real interface.
+
+**3. Exploitability tiers**
+
+| Tier | Condition |
+|---|---|
+| easy | public interface, no special privilege, single call |
+| medium | needs a specific condition or elevated privilege, multi-step |
+| hard | needs privileges or rare conditions, needs significant resources |
+
+**4. Full exploitation scenario**: starting point → step by step (commands and arguments / why it works / how the system state changes) → **a concrete, testable impact**.
+
+> Impact must **never** be written as "may cause problems". It must land on exact data, specific privileges, concrete quantities.
+> If you cannot write it, you usually have not chased the impact far enough.
+
+**5. Cross-check against the baseline**
+
+- Does it violate a system-level invariant recorded in B.0?
+- Does it cross or break a trust boundary?
+- Does it bypass this codebase's habitual validation patterns?
+- Is it a regression of a previously fixed issue?
+
+---
+
+## B.6 Report
+
+**Output to chat only counts as failure.** It must be written to disk, or the findings are lost.
+
+The report must cover at least:
+
+| Section | Content |
+|---|---|
+| conclusion summary | severity distribution + overall judgment + key metrics |
+| change overview | what changed, how big, which surfaces it touches |
+| findings | each with location, origin commit, blast radius, test coverage, historical context, attack scenario |
+| test coverage analysis | where the gaps are, why they count as gaps |
+| blast radius analysis | the numbers and tiers |
+| historical context | where deleted code came from, whether it was a security fix, whether there is a regression |
+| recommendations | three tiers: block immediately / before production / technical debt |
+| analysis method | which strategy was used, **what the limitations are**, confidence |
+| appendix | evidence |
+
+> **The "limitations" section is not a formality.** What was not tested and why must be written clearly —
+> that is what lets the reader judge how far this report's conclusions reach.
+
+**Scenarios where this stage does not apply** (say so explicitly, do not force it): brand-new code (no baseline to compare against), pure documentation changes, formatting/lint, and when the requester explicitly wants only a quick summary and accepts the risk.
+
+---
+
+## B.7 Handoff to Stage C
+
+**Every suspected finding this stage reports must go through Stage C verification one by one — none may be written into the report as a conclusion directly.**
+
+Stage B produces "suspicions"; only Stage C produces "verdicts".
+Treating a suspicion as a conclusion is exactly the problem this project exists to solve.