hex-audit 0.6.3 → 0.8.0

package/dist/skills/init-audit/references/agents/standards-checker.md

@@ -0,0 +1,39 @@
+# Standards checker
+
+You check the in-scope contracts against the standards they claim or implement: ERC/EIP specs (from `.hex/stats.json` → `erc_eip_usage`) and interfaces they inherit (`npx --no-install hex facts query linearization <Contract>`).
+
+**Write to:** `{output}`
+
+For each ERC/EIP:
+
+1. Fetch the canonical spec with WebFetch from `https://eips.ethereum.org/EIPS/eip-<number>`. If the fetch fails, note `"spec_fetched": false` and use what you know.
+2. Turn every MUST / SHOULD / MAY requirement into a checklist entry and verify it against the implementation. Use `npx --no-install hex facts query function <Contract.fn>` for exact signatures, modifiers and calls.
+3. Known gotchas to check explicitly:
+   - **ERC-20:** return values on `transfer`/`approve`, zero-amount transfers, the approval race.
+   - **ERC-4626:** rounding direction per function (previews and actions), preview vs actual, `max*` returns, behavior when paused.
+   - **ERC-721:** `safeTransferFrom` callbacks.
+   - **ERC-2612:** deadline, nonce, and domain separator chain id.
+
+For contracts that hold ERC-20s, also classify how they handle weird tokens: fee-on-transfer (balance-diff vs trusting the amount), rebasing, blocklists (DoS in loops or liquidations), and double entry points.
+
+Then check interface conformance: every function of each inherited interface is implemented, with the semantics its NatSpec promises.
+
+```json
+{
+  "agent": "standards",
+  "checks": [
+    {
+      "id": "STD-001",
+      "standard": "ERC-4626",
+      "requirement": "previewWithdraw MUST round up.",
+      "spec_location": { "type": "eip", "number": 4626, "section": "previewWithdraw", "url": "https://eips.ethereum.org/EIPS/eip-4626" },
+      "status": "CONFORMS | DEVIATES | PARTIAL | UNVERIFIABLE",
+      "finding": "What the code does vs what the spec demands, one or two sentences.",
+      "code_location": { "file": "src/Vault.sol", "line_start": 80, "line_end": 84 },
+      "severity_hint": "Info | Low | Medium | High | Critical"
+    }
+  ]
+}
+```
+
+You may read the code; you are the only Phase-1 agent whose job is the code-vs-spec comparison, because a spec's requirements are exact.

package/dist/skills/init-audit/references/agents/synthesizer.md

@@ -0,0 +1,50 @@
+# Synthesizer
+
+You turn the independent readers' drafts into **one** consistent protocol model. You are the only agent that sees every draft, so your job is integration: merge duplicates, reconcile conflicting framings by checking the code, and fill cross-cluster gaps (a flow that starts in one cluster and ends in another).
+
+**Inputs:** `.hex/model/drafts/*.json` (readers; docs and standards drafts are for the conformance checker, so read docs claims only for vocabulary), `.hex/facts.json`, `.hex/stats.json`, **(differential)** `.hex/diff.json` and `.hex/diff/changes.patch`.
+**Exact relationships:** `npx --no-install hex facts query …` (function, callers, callees, readers, writers, reach, layout, linearization, entry-points).
+
+## Write `.hex/model/protocol.json`
+
+Every item carries `claim_id` (keep the reader's id when one claim maps to it; mint `S-NNN` for new ones), `evidence` (`[{file, line_start, line_end}]`) and `status: "unverified"` (skeptics verify later). Function references are **exact facts ids** (`Vault.withdraw(uint256)`); `npx --no-install hex model validate` rejects unknown ids.
+
+```json
+{
+  "generated_at": "<ISO>",
+  "summary": "One paragraph: what the protocol does and for whom.",
+  "actors": [{ "claim_id": "", "id": "owner", "name": "Owner", "kind": "user|admin|keeper|guardian|external_protocol|other", "trust": "trusted|semi_trusted|untrusted", "powers": ["<fn id>"], "description": "", "evidence": [], "status": "unverified" }],
+  "assets": [{ "claim_id": "", "id": "usdc", "name": "USDC", "kind": "erc20|native|nft|shares|debt|other", "token": "", "held_by": ["Vault"], "moved_by": ["<fn id>"], "description": "", "evidence": [], "status": "unverified" }],
+  "privileges": [{ "claim_id": "", "actor": "<actor id>", "function": "<fn id>", "effect": "", "worst_case": "", "timelock": "", "evidence": [], "status": "unverified" }],
+  "trust_assumptions": [{ "claim_id": "", "text": "", "evidence": [], "status": "unverified" }],
+  "external_dependencies": [{ "claim_id": "", "id": "", "name": "", "kind": "oracle|dex|bridge|lending|token|other", "used_by": ["<fn id>"], "failure_modes": [""], "evidence": [], "status": "unverified" }],
+  "state_machines": [{ "claim_id": "", "id": "", "entity": "", "states": [""], "transitions": [{ "from": "", "to": "", "function": "<fn id>", "guard": "" }], "evidence": [], "status": "unverified" }],
+  "accounting": [{ "claim_id": "", "id": "", "name": "", "equation": "", "terms": [{ "term": "", "updated_by": [{ "function": "<fn id>", "direction": "increase|decrease|set" }] }], "evidence": [], "status": "unverified" }],
+  "risky_flows": [{ "claim_id": "", "id": "", "name": "", "entry": "<fn id>", "steps": [{ "actor": "", "contract": "", "function": "", "kind": "call|callback|oracle|transfer|state", "note": "" }], "risk": "", "evidence": [], "status": "unverified" }]
+}
+```
+
+## Write `.hex/model/invariants.json`
+
+From the readers' `invariant_candidates` plus what the accounting and state machines imply. Deduplicate; make each one precise and testable.
+
+```json
+{
+  "updated_at": "<ISO>",
+  "invariants": [
+    { "id": "INV-001", "statement": "", "kind": "accounting|access|bound|monotonic|state-machine|liveness|economic", "scope": { "contracts": [""], "functions": ["<fn id>"] }, "evidence": [], "on_chain_enforced": false, "status": "proposed" }
+  ]
+}
+```
+
+All invariants start `proposed`; the auditor accepts them.
+
+## Write `.hex/overview.md`
+
+`# Protocol Overview: <Name>` + 2–3 paragraphs (what it does, the core mechanism, the key contracts and their roles, notable patterns: upgradeability, oracles, external dependencies) + `## Key Contracts` table (Contract | Type | nSLOC | Role, nSLOC from `stats.json`) + `## External Dependencies` + `## Architecture Notes`. Descriptive only: no findings, no speculation, no code snippets, no AI disclaimers.
+
+## (differential) Write `.hex/diff-overview.md`
+
+`# Changes: <base short> → <head short>`, then sections: **What changed and why** (from the diff and `git log --oneline <base>..<head> -- <scope>`), **Removed or replaced behavior**, **Storage layout** (every `storage_layout_changes` entry, and whether the contract sits behind a proxy), **Impacted flows** (impacted entry points grouped into user flows, and how the change reaches each). Descriptive, no findings.
+
+Write leads you notice to the relevant contract with `npx --no-install hex note lead <Contract> --text "…" --source init-audit --source-ref <claim_id>`. Do not create cards.

package/dist/skills/prevalidate.md

@@ -0,0 +1,62 @@
+---
+description: 'Pre-validate new machine-generated cards (AI audit, AuditAgent, invariant violations) in parallel: PoC or refutation per card; conclusive cases move automatically, the rest wait for the auditor'
+---
+
+# Skill: Pre-validate
+
+Machine-generated findings favour recall over precision. This skill puts every new `unverified` card through an independent validation by background agents, so the auditor triages conclusions ("6 reproduced, 5 refuted, 3 need you"), not raw claims. `/ai-audit` and `/ingest-aa-report` call it at the end; the auditor can also run it directly (`/prevalidate`, or `/prevalidate H-012 H-015`).
+
+Use `npx --no-install hex …` for every Hex command.
+
+## What may move on its own
+
+The CLI enforces this; agents cannot override it:
+
+- **Reproduced → Verified** only when the PoC **passes** and **asserts the impact**, and the finding **passes the reality gate** (it is true *and* a security issue, not by design, not self-inflicted, not out of scope).
+- **Refuted → Rejected** only when **two independent refuter agents** both cite the code that blocks the attack.
+- Everything else stays in **Potential** with its verdict (`uncertain`) and memo. The auditor decides.
+
+Every auto-move is marked on the card and can be reverted from the board (or `npx --no-install hex issue revert-auto <id>`).
+
+## Step 1 — Pick the cards
+
+Arguments, if given; otherwise every tracking entry with `status: "unverified"` and no `validation` yet (`npx --no-install hex issue show <id>` shows it). Skip cards in Duplicate or Rejected. If there are none, say so and stop.
+
+## Step 2 — Validate in parallel
+
+Spawn one **validator** agent per card as background Agent calls, **at most 6 at a time** (start the next batch as earlier ones finish). Give each validator this brief, with the card id substituted:
+
+> Validate card **{id}** in this Hex project. Read it with `npx --no-install hex issue show {id}`, the code it points to, and exact facts via `npx --no-install hex facts query …`. Also read the triage rules (`npx --no-install hex rules list`): a finding whose whole impact depends on a rule is not security-relevant.
+>
+> 1. **Correctness.** Trace the claimed path in the code. Find every guard, modifier, check and invariant that could stop it.
+> 2. **Reality gate.** Is it security-relevant? Not by design, not a missing feature, not only self-inflicted by a trusted role, not defense-in-depth noise.
+> 3. **PoC.** If it is correct and security-relevant, write a minimal PoC following the project's own test setup in `test/hex-pocs/{id}_<short>.t.sol` (Foundry; `.test.ts` for Hardhat). Assert the **impact** (funds lost, invariant broken, access gained), not just that a call succeeds, and log the economic impact. Run it (`forge test --match-path <file> -vv`) and iterate until it passes or you are convinced it cannot.
+> 4. Write the memo to `.hex/validations/{id}_memo.md` (sections: Claim, Analysis, Protections evaluated, Reality gate, PoC, Verdict).
+> 5. Record the result. Use exactly one of:
+>    - `npx --no-install hex issue validation {id} --verdict reproduced --by agent --poc <file> --poc-status passing --reality-gate --memo .hex/validations/{id}_memo.md --auto-move`
+>    - `npx --no-install hex issue validation {id} --verdict refuted --by agent --memo .hex/validations/{id}_memo.md` (a single refutation never moves the card)
+>    - `npx --no-install hex issue validation {id} --verdict uncertain --by agent --memo .hex/validations/{id}_memo.md`
+>
+> Do not move the card yourself and do not edit .hex JSON by hand.
+
+## Step 3 — Second refuter
+
+For every card a validator **refuted**, spawn a second, **independent** refuter that does not see the first memo: the same brief, plus "Look for the strongest reason this finding is NOT real; cite the exact code." If it also refutes, record both:
+
+```bash
+npx --no-install hex issue validation <id> --verdict refuted --by agent --refuters 2 --memo .hex/validations/<id>_memo.md --auto-move
+```
+
+(Append the second refuter's reasoning to the memo first.) If the two disagree, record `--verdict uncertain` with both arguments in the memo.
+
+## Step 4 — Summary
+
+```
+Pre-validation — N cards
+- R reproduced → Verified (auto): H-…, H-…
+- X refuted → Rejected (auto, 2 refuters): H-…
+- U uncertain → still in Potential: H-…
+Review the auto-moves on the Board; revert any with one click.
+```
+
+Then, for each uncertain card, one line on what it needs from the auditor.

package/dist/skills/sync-issues.md

@@ -4,7 +4,6 @@ description: 'Two-way sync between local Hex findings and GitHub Issues — GitH
 
 # Skill: Sync Issues
 
-**Recommended model:** Sonnet
 
 Hex's GitHub Issues integration. Hex never authenticates with GitHub — you authenticate once via `gh auth login` and this skill drives the `gh` CLI. One invocation runs both directions.
 
@@ -66,15 +65,15 @@ Extract severity from the title, and the four body fields. If a body is **blatan
 **1c. Reconcile by issue number `#N`:**
 - **A local finding already records `github.issue_number === N`** → it's the same issue; pull GitHub's content into it:
   ```bash
-  npx hex issue sync-set <local-H-id> --issue-number N --issue-url <url> --state <open|closed> \
+  npx --no-install hex issue sync-set <local-H-id> --issue-number N --issue-url <url> --state <open|closed> \
     --title "<title-without-[Severity]>" --severity <Severity> \
     --description-file /tmp/N_desc.md --recommendation-file /tmp/N_reco.md \
     --resolution "<Status>" --update-from-client-file /tmp/N_update.md
   ```
 - **No local finding has `#N`** (a teammate's hand-added issue, or one created outside Hex) → create a local finding for it, then sync-set:
   ```bash
-  ID=$(npx hex issue new --source github --source-ref N --title "<title>" --severity <Severity>)
-  npx hex issue sync-set "$ID" --issue-number N --issue-url <url> --state <open|closed> \
+  ID=$(npx --no-install hex issue new --source github --source-ref N --title "<title>" --severity <Severity>)
+  npx --no-install hex issue sync-set "$ID" --issue-number N --issue-url <url> --state <open|closed> \
     --description-file /tmp/N_desc.md --recommendation-file /tmp/N_reco.md \
     --resolution "<Status>" --update-from-client-file /tmp/N_update.md
   ```
@@ -83,33 +82,20 @@ Either way the card lands in the **Synced** column, locked. Reconcile strictly b
 
 ## Phase 1.5 — Dedup before push (GitHub is canonical)
 
-Before pushing, guard against filing a finding that is already on GitHub (e.g. a teammate created it by hand, and you pulled it into Synced in Phase 1). For each **verified** local finding that has no `github.issue_number` yet, semantically compare it against every **synced** finding on these axes:
-
-| Signal | Compare |
-|---|---|
-| **contract** (boolean) | affected contract name |
-| **function** (boolean) | affected function name |
-| **root_cause** (`same`/`overlapping`/`different`) | the technical mechanism |
-| **attack_vector** (`same`/`overlapping`/`different`) | what an attacker actually does |
-
-A match is at least one of: `root_cause = same` AND `function = true`; or `root_cause = same` AND `contract = true` AND `attack_vector = same`; or `root_cause = overlapping` AND `function = true` AND `attack_vector = same`.
-
-On match — the synced (on-GitHub) finding is canonical, so the local verified copy becomes the duplicate. Do **not** push it:
+Before pushing, guard against filing a finding that is already on GitHub (e.g. a teammate created it by hand, and you pulled it into Synced in Phase 1). For each **verified** local finding with no `github.issue_number` yet:
 
 ```bash
-npx hex issue move <verified-H-id> --to duplicate --duplicate-of <synced-H-id>
+npx --no-install hex issue dedup <verified-H-id>
 ```
 
-Then append to `<output_dir>/comparison.json` under `duplicates` (the board renders the chip + signals from this):
+It lists candidates touching the same exact functions first and prints the match rules (one engine for every source). Judge only **synced** candidates here. On a match, the synced (on-GitHub) finding is canonical, so the local verified copy becomes the duplicate and is **not** pushed:
 
-```json
-{ "ai_finding": "<verified-H-id>", "matches": "<synced-H-id>", "confidence": "high|medium|low",
-  "match_signals": { "contract": true, "function": true, "root_cause": "same", "attack_vector": "same" },
-  "reasoning": "<one sentence>" }
+```bash
+npx --no-install hex issue mark-duplicate <verified-H-id> --of <synced-H-id> \
+  --root-cause <same|overlapping|different> --attack-vector <same|overlapping|different> \
+  [--same-contract] [--same-function] --reasoning "<one sentence>"
 ```
 
-If `comparison.json` doesn't exist, create it with `{ "duplicates": [], "novel": [], "rejected": [] }`.
-
 ## Phase 2 — Push (verified local findings → GitHub)
 
 Skip if `push_enabled` is false.
@@ -137,7 +123,7 @@ Stamp labels **only at creation** — never edit labels on an issue that already
 Parse the returned URL for `#N`, then lock it into Synced and record the number:
 
 ```bash
-npx hex issue sync-set <H-id> --issue-number N --issue-url <url> --state open
+npx --no-install hex issue sync-set <H-id> --issue-number N --issue-url <url> --state open
 ```
 
 From now on the finding is identified by `#N`; the next pull matches it by number, so it never duplicates.

package/dist/skills/validate-all-findings.md

@@ -4,11 +4,11 @@ description: "Walk every Potential issue on the board and validate them one by o
 
 # Skill: Validate All Findings
 
-**Recommended model:** Opus
-
 Runs `/validate-finding` over every issue currently in the **Potential** column, one at a time, so the auditor can clear the backlog in a single pass without naming each id.
 
-Each issue gets `/validate-finding`'s full two-axis verdict — correctness **and** the Step-2.5 security-relevance gate. **`auditagent` / `github` findings skew recall-over-precision, so the realism gate is mandatory for them**; `manual` / `conformance` items already passed an auditor's eye and can lean lighter.
+Each issue gets `/validate-finding`'s full two-axis verdict — correctness **and** the Step-2.5 security-relevance gate. **`auditagent` / `ai-audit` / `github` findings skew recall-over-precision, so the realism gate is mandatory for them**; `manual` / `conformance` items already passed an auditor's eye and can lean lighter.
+
+**Machine-generated cards first go through `/prevalidate`.** If the Potential column holds `unverified` cards (AI audit, AuditAgent, invariant) that have no `validation` yet, offer to run `/prevalidate` on them first: it validates them in parallel with PoCs and moves the conclusive ones, so this interactive pass only sees what really needs the auditor. Cards that already carry an agent verdict show it; start from that memo (`.hex/validations/<id>_memo.md`) instead of from scratch.
 
 ## Step 1 — Build the work list
 

package/dist/skills/validate-finding.md

@@ -1,17 +1,17 @@
 ---
-description: "Validate any potential finding on the board (manual / auditagent / conformance / github): check both correctness and security relevance, then route to Verified, Rejected, or leave Uncertain"
+description: "Validate any potential finding on the board (manual / ai-audit / auditagent / conformance / github / prior-audit): check both correctness and security relevance, then route to Verified, Rejected, or leave Uncertain"
 ---
 
 # Skill: Validate Finding
 
-**Recommended model:** Opus
-
 ## What this skill does
 
 Takes a single potential issue from the dashboard's Issues board and runs an independent validation pass on it. Source-agnostic — the issue can come from any of:
 
 - **Manual** (`/write-finding`) — `source: "manual"`, `status: "pending_validation"`.
 - **Auditagent** (`/ingest-aa-report`) — `source: "auditagent"`, `status: "unverified"`.
+- **AI audit** (`/ai-audit`) — `source: "ai-audit"`, `status: "unverified"`.
+- **Prior audit** (regressions found by `/init-audit` in a differential audit) — `source: "prior-audit"`, `status: "pending_validation"`.
 - **Conformance** (materialized by `/init-audit`) — `source: "conformance"`, `status: "pending_validation"`.
 - **GitHub** (teammate findings via `/sync-issues`) — `source: "github"`, `status: "pending_validation"`.
 
@@ -40,10 +40,14 @@ Once the issue is resolved, read:
 - Source-specific raw data:
   - `manual` → `<output_dir>/findings.json` (the full finding record).
   - `auditagent` → `<output_dir>/ai-results/auditagent/findings.json` (the matching `findings[*]` entry).
+  - `ai-audit` → `<output_dir>/ai-results/ai-audit/findings.json` (the matching `findings[*]` entry; the scan's own write-up is in `<output_dir>/ai-audit/runs/<scan_stamp>/full-report.md`).
+  - `prior-audit` → `<output_dir>/previous-audit/findings.json` (the prior finding) and `previous-audit/review.json` (why it was judged a regression).
   - `conformance` → `<output_dir>/spec-conformance.json` (the matching `items[*]` entry).
   - `github` → `<output_dir>/external/github/findings.json` (the matching entry).
-- `<output_dir>/state-vars.json`, `<output_dir>/access-control.json`, `<output_dir>/external-calls.json` for cross-referenced facts.
-- The affected contract source via `npx hex context --target <affected_contract>`.
+- The affected source files themselves (read them; do not rely on summaries).
+- Exact relationships from the compiler facts: `npx --no-install hex facts query function|callers|callees|readers|writers|reach <ref>` (who can reach the vulnerable code, who else writes the state it depends on).
+- The protocol model (`.hex/model/protocol.json`): trust assumptions and privileges, which decide many reality-gate calls.
+- The triage rules: `npx --no-install hex rules list`. A finding whose whole impact depends on a rule (trusted role, out-of-scope token type, known issue) is not security-relevant.
 
 ## Validation pass
 
@@ -67,7 +71,7 @@ For conformance items, the "claim" is `spec_text` + the finding paragraph — i.
 
 ### 2.5 Reality gate — is it security-relevant?
 
-Correctness is not enough. AI scanners (and sometimes teammates) surface claims that are **factually true but not security issues** — by-design behavior, missing features, defense-in-depth nice-to-haves, or risks only the deployer can inflict on themselves. This is the precision pass. **Run it for every finding; treat it as mandatory for `source: auditagent | github`** (those skew recall-over-precision). `manual` / `conformance` items already passed an auditor's eye, so they can lean lighter.
+Correctness is not enough. AI scanners (and sometimes teammates) surface claims that are **factually true but not security issues** — by-design behavior, missing features, defense-in-depth nice-to-haves, or risks only the deployer can inflict on themselves. This is the precision pass. **Run it for every finding; treat it as mandatory for `source: auditagent | ai-audit | github`** (those skew recall-over-precision). `manual` / `conformance` items already passed an auditor's eye, so they can lean lighter.
 
 For a claim you found **true**, run these five checks — each one pushes toward *not-security-relevant*:
 
@@ -92,35 +96,35 @@ Combine the two axes — correctness (Step 2) and security relevance (Step 2.5):
 
 **Verified — true and security-relevant:**
 
-1. Use **AskUserQuestion** to ask:
-   > The finding appears **VALID and security-relevant**. How would you like to proceed?
-   >
-   > 1. Generate a full PoC test, then promote to Verified.
-   > 2. Accept with rational verification only — validation memo, no PoC.
-   >
-   > Reply **1** or **2**.
+1. **Write a PoC. This is the default.** Follow the `generate-poc` flow: read the project's test setup, write `test/hex-pocs/<id>_<name>.t.sol` (or `.test.ts`), assert the **impact**, run it, and iterate until it passes. The PoC is what fix review re-runs later to prove the fix.
 
-2. **If PoC chosen:** invoke the `generate-poc` skill flow (read the project test setup, write the PoC, run and iterate until it passes). Note the test path, e.g. `test/hex-pocs/<id>_<name>.t.sol`.
+2. **Memo-only is the exception.** Skip the PoC only when one cannot reasonably exist (an off-chain or governance-process issue, a pure spec deviation with no exploit, an Info-level code-quality finding), and say why in the memo.
 
-3. **If memo-only chosen:** no PoC file.
+3. **Record the result on the card:**
+   ```bash
+   npx --no-install hex issue validation <id> --verdict reproduced --by auditor \
+     --poc test/hex-pocs/<id>_<name>.t.sol --poc-status passing --memo .hex/validations/<id>_memo.md
+   # memo-only:
+   npx --no-install hex issue validation <id> --verdict valid_no_poc --by auditor --memo .hex/validations/<id>_memo.md
+   ```
 
 4. **Calibrate severity — don't inherit it.** The source's severity (especially AuditAgent's) is a *hypothesis*, not authoritative. Re-derive it from realistic impact × likelihood; many technically-true findings collapse to Info. A finding whose worst case is self-inflicted or chain-conditional must say so and re-rate accordingly.
 
-5. **Persist via the CLI — do not hand-edit `findings.json` or `tracking.json`.** The `hex issue` command is the single source of truth for board mutations; it materializes a `findings.json` entry from the source record (conformance / auditagent / github) when one does not exist yet, and routes fields correctly. Write the validation memo and the recommendation to temp files, then:
+5. **Persist via the CLI — do not hand-edit `findings.json` or `tracking.json`.** The `hex issue` command is the single source of truth for board mutations; it materializes a `findings.json` entry from the source record (conformance / auditagent / ai-audit / github / prior-audit) when one does not exist yet, and routes fields correctly. Write the validation memo and the recommendation to temp files, then:
 
    ```bash
    # Land the editable fields (materializes a finding for conformance/auditagent/github ids):
-   npx hex issue patch <id> \
+   npx --no-install hex issue patch <id> \
      --severity <Severity> \
      --description-file <output_dir>/validations/<id>_memo.md \
      --recommendation-file /tmp/<id>_reco.md
    # Promote to Verified:
-   npx hex issue move <id> --to verified
+   npx --no-install hex issue move <id> --to verified
    ```
 
    For a memo-only verdict, the same two commands apply (the PoC fields just stay unset). For `--description-file`, you may pass either the memo or a dedicated description file; prefer a clean description file if the memo is long.
 
-   Any description you write must be **structured, readable prose** (no markdown headings), not a single dense block. Split it into short paragraphs that separate how the code is supposed to work (expected behavior / the spec), what is wrong (the flaw), and the impact, and include a fenced ```` ```solidity ```` block of the offending code. Do not introduce paragraphs with bold section labels (`**Summary**:`/`**Impact**:`/`**Details**:`/`**Affected code**:`) — the separation is paragraph breaks, not headers. **Backtick every Solidity identifier**, writing functions as `` `functionName(...)` `` with literal `(...)` and contracts/variables/constants in plain backticks; never leave a bare identifier in the prose. Keep each paragraph tight (no padding), and add a 1–2 sentence hedged recommendation. This matches the finding template used by the dashboard copy and the GitHub issue body. If the affected files are missing or wrong, set them with `--file` (repeatable) rather than narrating them in the description: `npx hex issue patch <id> --file src/Foo.sol [--file src/Bar.sol]`.
+   Any description you write must be **structured, readable prose** (no markdown headings), not a single dense block. Split it into short paragraphs that separate how the code is supposed to work (expected behavior / the spec), what is wrong (the flaw), and the impact, and include a fenced ```` ```solidity ```` block of the offending code. Do not introduce paragraphs with bold section labels (`**Summary**:`/`**Impact**:`/`**Details**:`/`**Affected code**:`) — the separation is paragraph breaks, not headers. **Backtick every Solidity identifier**, writing functions as `` `functionName(...)` `` with literal `(...)` and contracts/variables/constants in plain backticks; never leave a bare identifier in the prose. Keep each paragraph tight (no padding), and add a 1–2 sentence hedged recommendation. This matches the finding template used by the dashboard copy and the GitHub issue body. If the affected files are missing or wrong, set them with `--file` (repeatable) rather than narrating them in the description: `npx --no-install hex issue patch <id> --file src/Foo.sol [--file src/Bar.sol]`.
 
    **A conformance-sourced (or auditagent/github) finding must be rewritten to the exact same standard as a manual `/write-finding` finding** — do not pass the raw source text through. AuditAgent findings in particular arrive as one long unformatted paragraph; reshape them into the structured, backticked, snippet-bearing form above. Specifically, the prose you land must obey the report-facing content rules:
    - **Structure + identifiers:** short expected/flaw/impact paragraphs, a ```solidity snippet, every identifier backticked and functions as `` `name(...)` `` (as above).
@@ -138,20 +142,21 @@ Combine the two axes — correctness (Step 2) and security relevance (Step 2.5):
    >
    > Would you like to change the severity? Reply with the new severity (Critical / High / Medium / Low / Info), or **no** to keep it.
 
-7. If the user provides a new severity, run `npx hex issue patch <id> --severity <NewSeverity>`.
+7. If the user provides a new severity, run `npx --no-install hex issue patch <id> --severity <NewSeverity>`.
 
 **Rejected — true but not a security issue (by-design / informational):**
 
 The claim is correct, but Step 2.5 says it isn't a vuln worth reporting (self-inflicted, design decision, missing feature, defense-in-depth noise). This is **not** the same as "incorrect" — give it its own disposition so it's distinguishable from a false positive and AuditAgent gets honest feedback.
 
-1. Write the memo with `Disposition: by-design` (or `informational`) and the Step-2.5 reasoning.
-2. Mark the disposition and move it:
+1. Write the memo with `Disposition: by-design` (or `informational`) and the Step-2.5 reasoning, and record it: `npx --no-install hex issue validation <id> --verdict refuted --by auditor --memo .hex/validations/<id>_memo.md`.
+2. **Propose a triage rule** when the reason is general (a trusted role, an out-of-scope token type, a deliberate design choice), so AI runs stop raising the same class. Ask the auditor once, with AskUserQuestion: "Add a triage rule: *<one sentence>*?". On yes: `npx --no-install hex rules add --kind <trusted_role|out_of_scope|by_design|known_issue> --text "<sentence>" --from <id>`.
+3. Mark the disposition and move it:
    ```bash
-   npx hex issue patch <id> --resolution Acknowledged
-   npx hex issue move <id> --to rejected
+   npx --no-install hex issue patch <id> --resolution Acknowledged
+   npx --no-install hex issue move <id> --to rejected
    ```
    `Acknowledged` on a Rejected card means "AA was right, but it's by-design / not a security issue" — the board shows a **By-design** chip. (A Rejected card with *no* resolution = factually incorrect; see below.)
-3. Do NOT write a finding body or carry it into the report.
+4. Do NOT write a finding body or carry it into the report.
 
 **Rejected — incorrect (false positive):**
 
@@ -160,13 +165,13 @@ The claim is factually wrong. Explain why:
 - Are the preconditions impossible? Why?
 - Is the impact assessment wrong? What actually happens?
 
-Move it to the Rejected column with **no** resolution (the board shows an **Invalid** chip): `npx hex issue move <id> --to rejected`. Do NOT write a finding body — the memo records the reasoning.
+Record and move it with **no** resolution (the board shows an **Invalid** chip): `npx --no-install hex issue validation <id> --verdict refuted --by auditor --memo .hex/validations/<id>_memo.md`, then `npx --no-install hex issue move <id> --to rejected`. Do NOT write a finding body — the memo records the reasoning.
 
 **Uncertain:**
 
 1. List specific questions that need manual investigation.
 2. State what would confirm or deny the issue.
-3. Leave the column as-is (no `hex issue move`). Record the open questions on the card: `npx hex issue patch <id> --notes "<open questions>"`.
+3. Leave the column as-is (no `hex issue move`). Record it: `npx --no-install hex issue validation <id> --verdict uncertain --by auditor --memo .hex/validations/<id>_memo.md` and the open questions: `npx --no-install hex issue patch <id> --notes "<open questions>"`.
 
 ## Output: validation memo
 
@@ -175,7 +180,7 @@ Write `<output_dir>/validations/<id>_memo.md` (always — for valid, invalid, an
 ```markdown
 # Finding Validation: <ID> — <Title>
 
-**Source:** <manual | auditagent | conformance | github>
+**Source:** <manual | ai-audit | auditagent | conformance | github | prior-audit>
 **Original record:** <pointer to the specific record being validated — e.g., findings.json#F003, ai-results/auditagent/findings.json#AA-014>
 **Correctness:** True / False / Uncertain
 **Security relevance:** security-relevant / not-security-relevant / n/a

package/dist/skills/write-finding.md

@@ -4,7 +4,6 @@ description: "Write a manual issue as a Potential card on the board (pending val
 
 # Skill: Write Finding
 
-**Recommended model:** Sonnet
 
 This skill records a manual issue that the auditor has spotted during review. The issue lands on the dashboard's Issues board as a **Potential** card with `status: "pending_validation"` and `source: "manual"`. The auditor promotes it to Verified later (via drag-drop on the board, or by running `/validate-finding <id>` which produces a validation memo and optional PoC).
 
@@ -17,11 +16,11 @@ Read:
 
 ## Step 0: Duplicate gate
 
-Scan `findings.json` and `tracking.json` for any existing entry that covers the same vulnerability (same affected contract/function, same or overlapping root cause). If a match is found, warn the auditor:
+After filling the card (Actions steps 1 and 2), run `npx --no-install hex issue dedup <id>`: it finds the exact functions from the description's code block and backticked names, lists existing cards on those functions, and prints the match rules. Run it on the filled card; on an empty one it finds no functions and misses every duplicate. If a candidate matches under those rules, warn the auditor:
 
 > "This appears to duplicate `<H-NNN>`: \<title\>. Proceed anyway?"
 
-Only continue if confirmed.
+If they say it is a duplicate, record it with `npx --no-install hex issue mark-duplicate <id> --of <H-NNN> …` (signals as the rules describe) instead of filling in the fields. Otherwise continue.
 
 ## Severity Guide
 
@@ -133,17 +132,19 @@ Persist through the `hex issue` CLI — never hand-edit `findings.json` or `trac
 
 1. **Create the issue** — pass `--file` once per affected file so the **File(s)** line is populated (repeatable). Do **not** narrate the affected files in the description instead:
    ```bash
-   npx hex issue new --source manual --title "<concise title>" --severity <Severity> \
+   npx --no-install hex issue new --source manual --title "<concise title>" --severity <Severity> \
      --file src/Foo.sol [--file src/Bar.sol]
    ```
    This prints the allocated id (e.g. `H-007`). Capture it.
 
 2. **Fill the fields** (write the description and recommendation to temp files first, to preserve newlines):
    ```bash
-   npx hex issue patch <id> --description-file /tmp/<id>_desc.md --recommendation-file /tmp/<id>_reco.md
+   npx --no-install hex issue patch <id> --description-file /tmp/<id>_desc.md --recommendation-file /tmp/<id>_reco.md
    ```
    The description must be self-contained (what the issue is, why it exists, the impact) and follow the **Description format** rules below. The recommendation is prose only, hedged (`Consider...`), no code.
 
+3. **Run the duplicate gate** (Step 0) on the filled card.
+
 There is **no source-file annotation** — Hex does not write `@audit-issue` comments into the client's `.sol` files. The board and the finding record are the single place the issue lives.
 
 ## After writing

package/dist/types/index.d.ts

@@ -1,11 +1,7 @@
 import { z } from 'zod';
-import { ConfigSchema, StatsSchema, DepsSchema, AccessControlSchema, StateVarsSchema, ExternalCallsSchema, FindingsSchema, TrackingSchema, ComparisonSchema, SpecConformanceSchema, EvidenceSchema, ConfidenceSchema, DerivedFromSchema, PerContractStatsSchema, TestCoverageSchema, GraphNodeSchema, ClusterSchema, AccessFunctionSchema, RoleFunctionRefSchema, RoleSchema, StateVariableSchema, ExternalCallSchema, FindingSchema, TrackingEntrySchema, TrackingSourceSchema, ResolutionSchema, SpecItemSchema } from '../core/schema.js';
+import { ConfigSchema, StatsSchema, FindingsSchema, TrackingSchema, ComparisonSchema, SpecConformanceSchema, EvidenceSchema, ConfidenceSchema, DerivedFromSchema, PerContractStatsSchema, TestCoverageSchema, FindingSchema, TrackingEntrySchema, TrackingSourceSchema, ResolutionSchema, SpecItemSchema, DiffSchema, DiffChangeSchema, ImpactedFunctionSchema, StorageLayoutChangeSchema, PriorFindingsSchema, PriorReviewSchema, FactsSchema, FactsFunctionSchema, FactsContractSchema, FactsStateVarSchema, FactsStorageSlotSchema, ProtocolModelSchema, InvariantSchema, InvariantsFileSchema, TriageRuleSchema, ValidationSchema, FunctionReviewSchema, DiagramSpecSchema, DiagramIndexEntrySchema, FixReviewSchema, FixReviewCardSchema } from '../core/schema.js';
 export type Config = z.infer<typeof ConfigSchema>;
 export type Stats = z.infer<typeof StatsSchema>;
-export type Deps = z.infer<typeof DepsSchema>;
-export type AccessControl = z.infer<typeof AccessControlSchema>;
-export type StateVars = z.infer<typeof StateVarsSchema>;
-export type ExternalCalls = z.infer<typeof ExternalCallsSchema>;
 export type Findings = z.infer<typeof FindingsSchema>;
 export type Tracking = z.infer<typeof TrackingSchema>;
 export type Comparison = z.infer<typeof ComparisonSchema>;
@@ -15,16 +11,30 @@ export type Confidence = z.infer<typeof ConfidenceSchema>;
 export type DerivedFrom = z.infer<typeof DerivedFromSchema>;
 export type PerContractStats = z.infer<typeof PerContractStatsSchema>;
 export type TestCoverage = z.infer<typeof TestCoverageSchema>;
-export type GraphNode = z.infer<typeof GraphNodeSchema>;
-export type Cluster = z.infer<typeof ClusterSchema>;
-export type AccessFunction = z.infer<typeof AccessFunctionSchema>;
-export type RoleFunctionRef = z.infer<typeof RoleFunctionRefSchema>;
-export type Role = z.infer<typeof RoleSchema>;
-export type StateVariable = z.infer<typeof StateVariableSchema>;
-export type ExternalCall = z.infer<typeof ExternalCallSchema>;
 export type Finding = z.infer<typeof FindingSchema>;
 export type TrackingEntry = z.infer<typeof TrackingEntrySchema>;
 export type TrackingSource = z.infer<typeof TrackingSourceSchema>;
 export type Resolution = z.infer<typeof ResolutionSchema>;
 export type SpecItem = z.infer<typeof SpecItemSchema>;
+export type Diff = z.infer<typeof DiffSchema>;
+export type DiffChange = z.infer<typeof DiffChangeSchema>;
+export type ImpactedFunction = z.infer<typeof ImpactedFunctionSchema>;
+export type StorageLayoutChange = z.infer<typeof StorageLayoutChangeSchema>;
+export type PriorFindings = z.infer<typeof PriorFindingsSchema>;
+export type PriorReview = z.infer<typeof PriorReviewSchema>;
+export type Facts = z.infer<typeof FactsSchema>;
+export type FactsFunction = z.infer<typeof FactsFunctionSchema>;
+export type FactsContract = z.infer<typeof FactsContractSchema>;
+export type FactsStateVar = z.infer<typeof FactsStateVarSchema>;
+export type FactsStorageSlot = z.infer<typeof FactsStorageSlotSchema>;
+export type ProtocolModel = z.infer<typeof ProtocolModelSchema>;
+export type Invariant = z.infer<typeof InvariantSchema>;
+export type InvariantsFile = z.infer<typeof InvariantsFileSchema>;
+export type TriageRule = z.infer<typeof TriageRuleSchema>;
+export type Validation = z.infer<typeof ValidationSchema>;
+export type FunctionReview = z.infer<typeof FunctionReviewSchema>;
+export type DiagramSpec = z.infer<typeof DiagramSpecSchema>;
+export type DiagramIndexEntry = z.infer<typeof DiagramIndexEntrySchema>;
+export type FixReview = z.infer<typeof FixReviewSchema>;
+export type FixReviewCard = z.infer<typeof FixReviewCardSchema>;
 //# sourceMappingURL=index.d.ts.map

package/dist/types/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/types/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,YAAY,EACZ,WAAW,EACX,UAAU,EACV,mBAAmB,EACnB,eAAe,EACf,mBAAmB,EACnB,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,qBAAqB,EACrB,cAAc,EACd,gBAAgB,EAChB,iBAAiB,EACjB,sBAAsB,EACtB,kBAAkB,EAClB,eAAe,EACf,aAAa,EACb,oBAAoB,EACpB,qBAAqB,EACrB,UAAU,EACV,mBAAmB,EACnB,kBAAkB,EAClB,aAAa,EACb,mBAAmB,EACnB,oBAAoB,EACpB,gBAAgB,EAChB,cAAc,EACf,MAAM,mBAAmB,CAAC;AAE3B,MAAM,MAAM,MAAM,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC;AAClD,MAAM,MAAM,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AAChD,MAAM,MAAM,IAAI,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,UAAU,CAAC,CAAC;AAC9C,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,SAAS,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,eAAe,CAAC,CAAC;AACxD,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAEpE,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAC5D,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtE,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAC9D,MAAM,MAAM,SAAS,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,eAAe,CAAC,CAAC;AACxD,MAAM,MAAM,OAAO,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,aAAa,CAAC,CAAC;AACpD,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAClE,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AACpE,MAAM,MAAM,IAAI,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,UAAU,CAAC,CAAC;AAC9C,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAC9D,MAAM,MAAM,OAAO,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,aAAa,CAAC,CAAC;AACpD,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAClE,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/types/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,YAAY,EACZ,WAAW,EACX,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,qBAAqB,EACrB,cAAc,EACd,gBAAgB,EAChB,iBAAiB,EACjB,sBAAsB,EACtB,kBAAkB,EAClB,aAAa,EACb,mBAAmB,EACnB,oBAAoB,EACpB,gBAAgB,EAChB,cAAc,EACd,UAAU,EACV,gBAAgB,EAChB,sBAAsB,EACtB,yBAAyB,EACzB,mBAAmB,EACnB,iBAAiB,EACjB,WAAW,EACX,mBAAmB,EACnB,mBAAmB,EACnB,mBAAmB,EACnB,sBAAsB,EACtB,mBAAmB,EACnB,eAAe,EACf,oBAAoB,EACpB,gBAAgB,EAChB,gBAAgB,EAChB,oBAAoB,EACpB,iBAAiB,EACjB,uBAAuB,EACvB,eAAe,EACf,mBAAmB,EACpB,MAAM,mBAAmB,CAAC;AAE3B,MAAM,MAAM,MAAM,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC;AAClD,MAAM,MAAM,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AAChD,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAEpE,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAC5D,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtE,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAC9D,MAAM,MAAM,OAAO,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,aAAa,CAAC,CAAC;AACpD,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAClE,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,QAAQ,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AACtD,MAAM,MAAM,IAAI,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,UAAU,CAAC,CAAC;AAC9C,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtE,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;AAC5E,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAC5D,MAAM,MAAM,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AAChD,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtE,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,SAAS,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,eAAe,CAAC,CAAC;AACxD,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAClE,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAC1D,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAClE,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAC5D,MAAM,MAAM,iBAAiB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,uBAAuB,CAAC,CAAC;AACxE,MAAM,MAAM,SAAS,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,eAAe,CAAC,CAAC;AACxD,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC"}

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "hex-audit",
-  "version": "0.6.3",
+  "version": "0.8.0",
   "type": "module",
-  "description": "CLI toolkit for Solidity smart contract auditors",
+  "description": "AI-enhanced manual review for Solidity audits: exact compiler facts, a verified protocol model, attacker agents that must prove their findings, and a review workspace next to Claude Code",
   "bin": {
     "hex": "./dist/index.js"
   },
@@ -50,14 +50,16 @@
     "node": ">=18.0.0"
   },
   "dependencies": {
+    "@dagrejs/dagre": "^3.1.3",
     "@dnd-kit/core": "^6.1.0",
+    "@excalidraw/excalidraw": "^0.18.1",
+    "@modelcontextprotocol/sdk": "^1.32.2",
     "@solidity-parser/parser": "^0.18.0",
-    "@tanstack/react-table": "^8.17.0",
     "chalk": "^5.3.0",
     "chokidar": "^3.6.0",
     "commander": "^12.1.0",
     "glob": "^10.3.10",
-    "mermaid": "^11.4.0",
+    "minimatch": "^9.0.4",
     "next": "14.2.5",
     "next-themes": "^0.4.6",
     "ora": "^8.0.1",