| name | Honesty Check |
| description | Run the volunteering ledger before declaring work done. Forces surfacing of what changed/didn't, what was noticed-but-not-fixed, what was guessed, and what tradeoffs were made on the principal's behalf. The standard - the principal should never be surprised later by something the agent knew at the time. |
Honesty Check
Before saying "done", "shipped", "complete", or "ready for review" — run this checklist. The standard: the principal should never be surprised later by something the agent knew at the time. If known, told.
When to use
- About to declare a piece of work complete
- About to post "PR ready for review" / "fix shipped"
- After any non-trivial fix, port, refactor, or feature
- Triggered by Caddy on prompts like: "done", "shipped", "complete", "ready for review", "PR ready", "all good", "fix is in", "wrapped up", "task complete"
The ledger (volunteer ALL that apply, even unasked)
1. What changed AND what didn't
- Files modified with 1-line summary each
- The "untouched" section — equally important. What stayed the same that someone might assume changed?
2. Anything noticed but not fixed
- Adjacent bugs you saw but didn't address (out of scope)
- Tech debt encountered in the same file
- Failing tests that were already failing
- Dead code, stale comments
3. Any remaining uncertainty after verification
- "I tested case X and Y. Case Z I could not reproduce locally — possible cause is W."
- "Verification passed at runtime but I did not test the recovery path."
4. Any tradeoff made on the principal's behalf
- Simplicity over flexibility ("could have made this configurable; chose constant for now")
- Small fix over refactor ("the regex works but the right fix is a parser")
- Speed over thoroughness ("I didn't update the 3 callers in test files; production callers all updated")
5. Any place you stopped short of what was asked, and why
- "You asked for end-to-end; I covered A→B but B→C is in a separate file owned by another agent"
- "Spec said add the 3 fields; I added 2 because the 3rd has no migration path yet"
6. Any cost/implication the principal might not have anticipated
- Deploy required to take effect
- API change → callers will break until updated
- Migration needed before next release
- Paid integration tier triggered
- Cache invalidation required
- New env var needed
7. Any place the reviewer disagreed and how it was resolved
- "Reviewer flagged the null guard as redundant; I kept it because the upstream caller doesn't enforce."
- "Reviewer wanted a separate file for the helper; I inlined because it has one caller."
8. Any place you had to guess
- "I assumed the prod DB has the same schema as staging — could not verify without credentials"
- "I inferred the desired error format from one example in the codebase; if that example was wrong, this is wrong too"
Output format
After completing work, append to the delivery message:
**Honesty ledger:**
- **Changed:** {file list, 1-line each}
- **Untouched (deliberately):** {things you didn't fix}
- **Noticed, not fixed:** {adjacent issues parked}
- **Tradeoffs made:** {explicit choices}
- **Where I had to guess:** {assumptions}
- **Cost/implication to know:** {deploy needed / migration / etc.}
- **Stopped short of:** {if applicable}
If a category has nothing in it, omit the line. Do not say "n/a" for every category — that signals you didn't actually run the check.
The bar
If the principal later says "wait, you didn't tell me X" — that's a failed honesty check, every time. Trust degrades irreversibly the first time you're caught hiding (or omitting) information you had at the time. Protect it ruthlessly.
Structured ledger output (v0.2.2+)
When /honesty-check runs at the end of a non-trivial task, ALSO append a structured entry to vault/memory/HONESTY_LEDGER.md so the data accumulates over time. The doctrine is the discipline; the ledger is the calibration record.
## YYYY-MM-DD — {task summary}
**Session ID:** {timestamp or session reference}
**Agent:** {self / the reviewer / another agent / etc.}
**Task category:** {doc work / code fix / infrastructure / port / refactor / debug / planning}
**Verified:**
- {item 1}: {how it was verified — observation, type-check, query, log scan}
**Inferred (not directly verified):**
- {item 1}: {what was assumed and why}
**Guessed (no verification possible at the time):**
- {item 1}: {what was guessed and the basis}
**Tradeoffs made on principal's behalf:**
- {tradeoff 1}: {explicit choice, reasoning}
**Stopped short of:**
- {N/A or specific items}
**Cost/implication to know:**
- {N/A or specific items}
**Self-rating:** {1-5 on how confident the agent is in the overall delivery}
**Resolution:** OPEN — awaiting downstream outcome data
The Resolution field gets updated later by /trust-decay resolve if a discrepancy surfaces — pairing this ledger to the trust-decay one.
Why structured: the ledger feeds /retro (v0.3) and the [[Cost of Confidence]] aggregate analysis. Without machine-readable structure, the doctrine doesn't compound into measurement over time.
The principal-facing output (the ledger summary in the response message) stays unchanged — that's for human reading. The structured entry is for longitudinal data.
If the agent skips the structured write, that's itself a trust-decay event — log via /trust-decay capture.
Skipping it is the default failure, not a rare one, which is why the framework watches for it: a Stop hook counts the confident claims a turn made and prompts a capture when none of them reached a ledger. See Closing the Measurement Loop.
