cat README.md | head -1
agent said "done" it wasn't!
Your agent says "done": but did you verify it? trust-no-agent answers both questions mechanically: whether the work is actually correct (receipts + commit gate) and what to do next (the chain + receipts). Bring your own workflow; the trust layer applies regardless.
[ exit 0 ] the work is legible enough to trust
01 / OPERATING IDEA
the core
Most agent workflows stop at output. This one stops at a proof boundary. The router makes the next action explicit, asks for decisions when the request is underspecified, and rejects a completion claim that has no fresh evidence behind it.
The point is not ceremony. It is to make the expensive failure visible while it is still cheap to change.
claim the agent says what changed
evidence a test, command, or rendered result checks it
receipt the result records what passed and what remains open
guardrail accepted findings become rules for the next session
The design rationale and eval record live in docs/design.md.
02 / ROUTE
the chain
Large work crosses one named boundary at a time. The next stage is proposed, not assumed.
- 01breakpoint surface decisions before code makes them expensive
- 02save-as write a spec with acceptance criteria that can fail
- 03fork-it slice the spec into tickets with blocking edges
- 04make-it-so build test-first and keep repair to two rounds
- 05roast-my-code review standards, spec fit, and security separately
- 06ship-log append the state so the next session does not guess
Quick fixes have a shorter route. Test-writing never skips fail-first: a test that passes immediately may only be certifying the wrong behavior.
03 / PROOF
the verification gates
Four commands turn “done” from a tone of voice into an observable result. Exit zero is the minimum boundary, not a promise that intent was correct.
The gate checks the framework's structure and behavior. It does not pretend to prove your product intent. That distinction is part of the contract.
The same checks run in CI on every push. The commands above are the repository's recorded gate output.
04 / BOUNDARY
the iron laws
01No work without verification. Read the evidence before you call the result complete.
02No fix without root cause. Investigate the failure before adding another patch.
03No done claim without a receipt. The test fails first, then passes with the output recorded.
04No irreversible action without human sign-off. Commit, push, publish, and delete stay yours to authorize.
Canonical wording and the reason for each boundary: docs/design.md.
05 / MEMORY
the ledger
ledger entry site redesign Verdict: evidence recorded after the check Evidence: command output or rendered result Ruling: keep green for evidence only Open: name the proof that is still missing accepted finding promotion: router rule for every future session
Context compacts. A good session should not disappear with it. The private ledger keeps the state, rulings, recipes, and open evidence that the next session needs.
The important move is promotion. When a review finding is accepted, it becomes a permanent router rule instead of a one-time correction. Memory is not a claim that the work is right. It is a record of what was checked, what was decided, and what still needs a human.
Ledger design and memory tiers: README.md and docs/design.md.
DIFFERENCES
Trust is a workflow, not a mood
The framework is deliberately honest about what its gates can and cannot prove.
| the moment | without a boundary | with trust-no-agent |
|---|---|---|
| “It is done” | a confident summary | a fresh receipt with output read |
| the request is unclear | the agent guesses | breakpoint surfaces the decision |
| a bug appears | another patch | root-cause investigation first |
| the session ends | context evaporates | the ledger carries state forward |
| feedback lands | agree and implement | no-thanks verifies the claim first |
START WITH THE ROUTER
put a proof boundary around your next task
The first npx run executes third-party code. Verify the package with npm view skills before trusting it.
12 skills and the router. It works on a harness that reads AGENTS.md. The router makes mandatory discipline load before the model starts improvising; and the onboarder asks which workflow you use, so the trust layer fits your setup.