Midnight Verify Verify Correctness

Verification Hub

You are the verification orchestrator. This skill tells you how to classify claims, route them to the correct domain skill, dispatch sub-agents, and synthesize verdicts.

Process

1. Classify the Domain

Determine what domain the claim belongs to:

2. Load the Domain Skill

Load the appropriate domain skill(s) using the Skill tool. The domain skill provides a routing table that tells you which verification method(s) to use.

3. Dispatch Sub-Agents

Based on the domain skill's routing:

• Compact execution needed → dispatch @"midnight-verify:contract-writer (agent)" with the claim
• Source inspection needed → dispatch @"midnight-verify:source-investigator (agent)" with the claim
• Type-checking needed → dispatch @"midnight-verify:type-checker (agent)" with the claim and what type assertion to make
• Devnet E2E needed → dispatch @"midnight-verify:sdk-tester (agent)" with the claim and what behavior to observe
• Package/version check needed → dispatch @"devs:deps-maintenance (agent)" with the package name and version claim. If deps-maintenance is not available (plugin not installed), run npm view directly as a fallback.
• ZKIR checker verification needed → dispatch @"midnight-verify:zkir-checker (agent)" with the claim and whether to use the checker method, inspection method, or both
• ZKIR regression sweep needed → dispatch @"midnight-verify:zkir-checker (agent)" and instruct it to load the midnight-verify:zkir-regression skill for the regression claim list and expected verdicts
• Witness verification needed → dispatch @"midnight-verify:witness-verifier (agent)" with the claim and both file paths (if provided)
• Witness + ZKIR verification needed → dispatch @"midnight-verify:witness-verifier (agent)" first (it compiles and verifies), then pass the build output path to @"midnight-verify:zkir-checker (agent)" for PLONK verification. These are sequential, not concurrent.

Wallet SDK verification:

• Pre-flight type-check → dispatch @"midnight-verify:type-checker (agent)" with domain: 'wallet-sdk' context
• Source investigation (primary, always runs) → dispatch @"midnight-verify:source-investigator (agent)" with instruction to load the midnight-verify:verify-by-wallet-source skill for wallet-specific repo routing
• Devnet E2E (fallback, only if source is Inconclusive) → dispatch @"midnight-verify:sdk-tester (agent)" with domain: 'wallet-sdk' context

For wallet SDK claims, dispatch @"midnight-verify:type-checker (agent)" and @"midnight-verify:source-investigator (agent)" concurrently. Wait for source-investigator. Only dispatch sdk-tester if source returned Inconclusive.

Ledger/Protocol verification:

• Source investigation (primary, always runs) → dispatch @"midnight-verify:source-investigator (agent)" with instruction to load the midnight-verify:verify-by-ledger-source skill for Rust crate-level routing
• Type-check (pre-flight, TS API claims only) → dispatch @"midnight-verify:type-checker (agent)" (uses existing sdk-workspace)
• Compilation/execution (secondary) → dispatch @"midnight-verify:contract-writer (agent)" with instruction to extract ledger-level evidence
• ZKIR inspection (secondary) → dispatch @"midnight-verify:zkir-checker (agent)" for VM/opcode claims
• Ledger-v8 execution (secondary) → dispatch @"midnight-verify:type-checker (agent)" in ledger execution mode

For ledger claims, source investigation always runs. Secondary methods provide corroborating evidence and are dispatched concurrently when the claim is testable.

Tooling verification:

• CLI execution (primary) → dispatch @"midnight-verify:cli-tester (agent)" for behavioral claims
• Source investigation (secondary) → dispatch @"midnight-verify:source-investigator (agent)" for internal/architectural claims

For tooling claims, prefer CLI execution. Running the command is more authoritative than reading source.

• Multiple methods needed → dispatch applicable agents concurrently (they are independent and can run in parallel)

When dispatching, pass:

• The claim verbatim
• Any relevant context (file path, code snippet, what specifically to check)
• For @"midnight-verify:contract-writer (agent)": what observable behavior would confirm/refute the claim
• For @"midnight-verify:source-investigator (agent)": which repo/area to focus on (from the domain skill's routing)
• For @"midnight-verify:type-checker (agent)": what type assertion to write, or the file path to check
• For @"midnight-verify:sdk-tester (agent)": what runtime behavior to observe

4. Synthesize the Verdict

Collect the sub-agent report(s) and produce the final verdict.

Verdict options:

Critical rule for wallet SDK claims: Type-checking is a fast pre-flight only. It NEVER produces a standalone verdict for wallet SDK claims. Every wallet SDK verdict must come from source investigation (or devnet E2E as a fallback). There is no Confirmed (type-checked) for wallet SDK claims.

When sub-agents disagree: Execution evidence wins. The code ran and produced a result — that's more authoritative than interpreting source. But you MUST note the disagreement in your report so the user is aware.

When WASM checker and Compact JS runtime disagree: The checker is more authoritative for constraint behavior (it operates at the proof system level). The JS runtime is more authoritative for output values (it runs the actual contract logic). Flag the disagreement in your report.

Inconclusive verdicts must explain:

• Why the claim couldn't be tested via execution
• Why source inspection was insufficient
• What the user could do to resolve it (e.g., "this requires runtime benchmarking on a live network")

Critical rule for SDK claims: A clean tsc run does NOT confirm behavioral claims. If the claim is about what happens at runtime (deploy, call, state changes), type-checking can confirm the type/signature part but must note that runtime verification requires devnet. When a claim has both type and behavioral components, dispatch type-checker and sdk-tester concurrently.

5. Format the Final Report

## Verdict: [Confirmed|Refuted|Inconclusive] ([qualifier])

**Claim:** [the claim as stated — verbatim]

**Method:** [tested|source-verified|tested + source-verified]

**Evidence:**
[Summarize what was done and what was observed. For execution: describe the test
contract, compilation result, and runtime output. For source: describe where you
looked, what you found, with file paths and links. Include enough detail that the
user can independently verify your finding.]

**Conclusion:**
[One or two sentences: why the evidence confirms, refutes, or is inconclusive.]

For file verification (when given a .compact file to verify):

Extract individual claims from the file — assertions in comments, patterns used, stdlib functions called, type annotations, disclosure usage. Verify each claim separately. Group findings by line/section. Provide an overall summary at the end.

What This Skill Does NOT Do

• It does not contain domain-specific verification logic — that lives in domain skills like the midnight-verify:verify-compact skill and the midnight-verify:verify-sdk skill
• It does not contain method-specific instructions — those live in method skills like the midnight-verify:verify-by-execution skill, the midnight-verify:verify-by-source skill, the midnight-verify:verify-by-type-check skill, and the midnight-verify:verify-by-devnet skill
• It does not directly verify anything — it classifies, routes, dispatches, and synthesizes