Passing build receipt
01- Required evidence
- trw_build_check records passing project-native tests, build, and static checks
- Result
- Delivery allowed
LATTICE // VERIFICATION
EVIDENCE-GATED DELIVERY
Done means evidence, not assertion
Run the checks your repository trusts, record the result, and make delivery answer to evidence. A failed build needs a complete acceptable-failure record or an authorized override—not a confident explanation.
Illustrative trace · not live session status
Example sequence awaiting evidence.project_checks
Run the repository-native tests, build, lint, and static checks that apply
trw_build_check
Record content-bound command results and the observed outcome
delivery_policy
Evaluate the passing receipt or a documented, authorized exception path
trw_deliver
Persist the verified result, checkpoint, and session learnings
LEDGER // PROBLEM
A completion claim is not a build receipt
AI fluency is not correctness. Without a gate, “done” means “the agent stopped typing.” The prose is confident, the code compiles, and the PR description is thorough. None of that is evidence.
TRW moves applicable project-native checks into the working session and records what actually ran. The delivery decision can then distinguish a passing build from a known, explicitly owned exception instead of flattening both into “done.”
ASSERTION ONLYNo durable receipt
Agent claims completion
fluent summary, no receipt
Checks are assumed
command and scope unknown
Risk stays implicit
no owner or expiry
Decision cannot be audited
no durable evidence path
Failure escapes
assertion outran proof
WITH EVIDENCEInspectable decision
Run project checks
repository-native commands
Record the receipt
trw_build_check
Evaluate delivery policy
pass or explicit exception
Name residual risk
failed command + owner + expiry
Deliver or remain blocked
decision is enforced
Handoff retains proof
future work can inspect it
LATTICE // GATES
Three explicit paths through the delivery gate
For coding, RCA, and eval work, trw_deliver() accepts one of three inspectable decisions. This is part of Phase 4 VALIDATE of the lifecycle. A review label or free-text excuse does not substitute for build evidence.
| Delivery path | Required evidence | Result |
|---|---|---|
| Passing build receipt | trw_build_check records passing project-native tests, build, and static checks | Delivery allowed |
| Acceptable failure — explicitly documented | allow_unverified=true + unverified_reason: failed_command, residual_risk, owner, unexpired expiry_iso | Delivery allowed; decision recorded; failed work remains unverified |
| Authorized override | Operator or configuration authorization with technical rationale | Delivery allowed; decision recorded; failed work remains unverified |
Acceptable failure — explicitly documented
02- Required evidence
- allow_unverified=true + unverified_reason: failed_command, residual_risk, owner, unexpired expiry_iso
- Result
- Delivery allowed; decision recorded; failed work remains unverified
Authorized override
03- Required evidence
- Operator or configuration authorization with technical rationale
- Result
- Delivery allowed; decision recorded; failed work remains unverified
TERMINAL // STOP_CEREMONY
Hooks can remind. The delivery gate decides.
Client hooks are optional, trust-gated adapters. When a supported CLI exposes a session-stop event, TRW's stop-ceremony hook looks for recent reflection and delivery evidence, including trw_deliver() activity, and can nudge the operator when ceremony is incomplete. Clients without the same hook surface still get the same correctness policy through TRW tools and middleware.
Hooks are additive hints, not correctness gates. Reminders are bounded and fail open on contention; the deliver tool still requires a passing build receipt, a complete acceptable-failure record, or an authorized operator/config override.
EXAMPLE — bounded stop reminder
→ session ends
→ stop-ceremony hook fires
→ recent reflection / delivery evidence checked
[stop-ceremony] REMINDER: delivery ceremony appears incomplete.
Finish the ceremony or continue after the bounded reminder. Client behavior varies.
$ _
LEDGER // HIERARCHY
Truthfulness before velocity
When values conflict, the first one wins. This is not a suggestion — it is the value-hierarchy invariant from the TRW Vision. The bar chart reads top-down; each layer outweighs the one below it.
- 1TRUTHFULNESS
Never misrepresent the state of the work. Disclose failures and exceptions explicitly.
- 2QUALITY
Use the project-native checks and requirement-matched evidence that fit the risk.
- 3KNOWLEDGE
Persist what matters. Let learnings compound between sessions and agents.
- 4VELOCITY
Ship — but not at the cost of any of the first three. Speed is a reward, not a trade.
“Unverified code is not a fast path — it is deferred debt.”
When a build gate fires, it is not slowing delivery; it is preventing a class of failure that costs significantly more to fix after merge. Verification is the operational expression of the truthfulness principle: the agent's claim that something works must rest on evidence, not on fluent prose.
LEDGER // FAQ
Common questions
Does verification slow down the agent?
Verification time depends on the repository-native checks that apply. TRW does not invent a universal duration; use focused checks while iterating, then run the project-defined delivery gate before claiming completion.
Can I skip verification if I need to ship fast?
A failed build can only deliver through a complete acceptable-failure record or an authorized operator/config override with technical rationale. A review label or free-text reason alone is not enough.
What if my tests are flaky and the gate fires incorrectly?
Record the observed failure. Fix the flake, or use the explicit acceptable-failure path with the failed command, residual risk, owner, and expiry. That preserves the truth instead of relabeling a red build green.
What if I don't have tests yet?
Run the checks the project currently defines and record that scope honestly. If behavior has no meaningful verification yet, treat that as residual risk rather than implying that an absent suite passed.
Can I customize which gates run?
Projects choose their native test, build, static, and coverage checks. TRW records the resulting evidence and applies its delivery policy; optional hooks can add reminders but are not the source of correctness.
What's the coverage floor and can I override it?
Coverage is project-configurable and should be recorded when measured. A configured minimum can fail the build receipt, but coverage alone is not proof that the requirement works on its real path.
TERMINAL // SHIP_WITH_EVIDENCE
Make the next delivery carry its proof
Run project-native checks, record the outcome, and preserve the decision path for the next human or agent. Create a free account and install in minutes.
TERMINAL~/repo
# one-line install — pulls trw-mcp from PyPI
$ curl -fsSL https://trwframework.com/install.sh | bash