How VaultRadar was built, artifacts and attribution
This directory is the working record of the workflow that produced VaultRadar, kept because the submission rules require spec files, prompts and planning artifacts to ship with the code, and because the record is more honest than a summary of it would be.
The tool and the shape of the collaboration
The project was built with Claude Code (Anthropic), models Opus and Sonnet, driven from a
terminal in this repository. The workflow is the superpowers plugin's
subagent-driven-development process:
brainstorm → written spec → written plan → one fresh implementer per task
→ an independent reviewer for that task's diff → fix rounds
→ one whole-branch review at the end → one fix wave → one scoped re-review
Every implementer worked from a written brief and never saw the conversation that produced it. Every reviewer was a separate agent that read only the brief, the report and the diff. Reviews that found problems produced fix rounds, and the fix rounds were themselves re-reviewed.
Attribution, stated plainly: the code, tests, documentation and diagrams in this repository were generated by Claude Code. The human contribution was direction, decisions and credentials: choosing the project and the three partner tracks, approving the design spec, setting scope and the cut order, supplying every account, key and funding source, making the deployment and key-management decisions, running the steps that required a browser (the Substreams registry login, the Circle faucet), and reviewing and merging the result. No part of the source was hand-written by a person. If that falls short of a rule's bar for human involvement, the rules disagree with the project rather than the reverse, and this file is the record to judge it by.
What is here
| File | What it is |
|---|---|
direction.md |
The human's prompts in sequence, and what each one produced. The shortest honest account of where the direction came from. |
ledger.md |
The decision log, in order. Every ruling the controller made when the plan met reality, each with the reason and what it would cost if wrong, including the scope cuts (the Hedera harness PR, HCS-14 UAID, Falcon, upstream x402 to The Graph) and the calls made under time pressure. Start here. |
task-N-brief.md |
What each implementer was told. These are the prompts: one per task, written to be self-contained, with the exact values, signatures and tests required. |
task-N-report.md |
What each implementer did, what it deviated on and why, which tests it added, and the concerns it raised. |
final-review-report.md |
The whole-branch review, run on the most capable model against the full diff. |
final-fix-brief.md |
What that fix wave was told to do: every finding with its file, its failure scenario, the required fix and the required test. The most concrete example here of a prompt written to be checked against. |
final-fix-report.md |
The single fix wave that answered it. |
final-rereview-report.md |
The scoped re-review of that wave, finding by finding. |
The spec and plan the work argues from are not duplicated here; they live at
docs/superpowers/specs/2026-09-05-vaultradar-design.md
(the binding authority) and
docs/superpowers/plans/2026-09-09-vaultradar.md.
docs/one-prompt.md is a single-prompt generation experiment that was
deliberately not run, with the reasoning and the exact prompt recorded.
What the process caught, since that is the point of showing it
The review structure was not ceremony. The whole-branch review found that the on-chain key anchor, the check that is supposed to stop a substituted agent card, compared the registry's hash against a value the card itself asserted rather than the hash of the key that signed, and that a card listing no identity skipped the check entirely. Both are now closed, with the adversarial cases as tests.
The last bug of the project was not found by any of that. checkSealedRequestPayer compared
the sealed request's payer against the rail's payer case-sensitively; viem hands the client a
checksummed address and Circle's Gateway reports the payer in lower case, so every Arc
payment failed after settlement on a rail with no refund path. It surfaced by running one real
payment against the deployed service and printing what the rail actually put on the request,
both sides were correct in isolation, which is why 464 unit tests never saw it. The number of
files in this directory is the honest measure of how much got fixed along the way.