Docs
Verification
Run the repository's real checks first. Then record exactly what ran, review the actual change, and let the delivery boundary evaluate that evidence. TRW stores and gates on receipts; it does not execute your test suite for you.
Evidence, without inflated claims
Verification separates an agent's narration from an inspectable result. Keep the claim no broader than the command, scope, and evidence that produced it.
Confirmed
The named project command ran, and its observed result is recorded with the matching scope.
Recorded
TRW persists the result supplied by the caller so delivery logic and later diagnostics can inspect it.
Not proven
A receipt does not prove the command was honest, complete, independent, or sufficient for every requirement.
Three delivery paths — no fourth path
Coding, RCA, and eval work block by default when no valid build evidence exists. Docs, research, planning, and unknown task types remain advisory. A review label or free-text excuse is not an exception record.
Passing build receiptInspect
- Required record
- A recorded trw_build_check with passing tests and the static-check state.
- What it means
- Delivery may proceed as verified against the checks the caller actually ran.
Acceptable failure — documented exceptionInspect
- Required record
- allow_unverified=true plus failed_command, residual_risk, owner, and an unexpired expiry_iso.
- What it means
- Delivery may proceed with known risk. The affected work remains unverified.
Authorized overrideInspect
- Required record
- An operator or configured override recorded with technical rationale.
- What it means
- Delivery may proceed by explicit authority. The override is not proof that checks passed.
| Path | Required record | What it means |
|---|---|---|
| Passing build receipt | A recorded trw_build_check with passing tests and the static-check state. | Delivery may proceed as verified against the checks the caller actually ran. |
| Acceptable failure — documented exception | allow_unverified=true plus failed_command, residual_risk, owner, and an unexpired expiry_iso. | Delivery may proceed with known risk. The affected work remains unverified. |
| Authorized override | An operator or configured override recorded with technical rationale. | Delivery may proceed by explicit authority. The override is not proof that checks passed. |
Run first, record second
- Run the project-native test, build, lint, type-check, or schema command.
- Read the real exit status and counts; do not infer a pass from partial output.
- Call
trw_build_checkwith the observed result and an honest scope.
npm test && npm run type-check
trw_build_check(
tests_passed=True,
test_count=247,
failure_count=0,
static_checks_clean=True,
scope="platform test + type-check",
)Review is separate evidence
Review the actual diff for correctness, requirement drift, security, accessibility, and maintainability. trw_review records findings and a verdict; it does not make a self-review independent. Use a scoped helper, another model, or a cold-context pass when independence matters, and label the provenance honestly.
Hooks are optional adapters
A compatible client can surface reminders, checkpoints, or bounded stop behavior. Hook availability and event names differ by client, and trusted hooks may require explicit enablement. The delivery decision remains in TRW tools and middleware when no hook fires.
Core
Project checks, typed receipts, run-bound review evidence, and delivery logic.
Adapter
Optional client event wiring that makes the core workflow harder to forget.
Boundary
No hook can turn a failing or unverified result into passing evidence.
Exceptions preserve the risk
Use an acceptable failure documented with the required fields only when a named check cannot pass now and delivery is still an explicit decision. The record must identify the failed command, residual risk, owner, and expiry. Expired or incomplete records do not satisfy the gate.
failed_commandresidual_riskownerexpiry_isoDebug a blocked delivery
- Read the current
trw_delivergate response and identify the named block. - Confirm the receipt belongs to this session, run, command scope, and post-edit state.
- Inspect the active run's
meta/review.yamlwhen review readiness is involved. - Fix and rerun the command, or use one of the two explicit exception paths.