Turn AI-generated code into verified engineering work.
Recover the active task, preserve meaningful milestones, and bind project-native checks to the handoff—without replacing your coding client or repository workflow.
Fast output still leaves an evidence gap
The failure is rarely typing speed. It is losing the decisions, proof, and resume state that let another person—or another session—trust what happens next.
- 01
Context decays
Architecture decisions, failed approaches, and edge cases remain trapped in a chat transcript unless they become durable project knowledge.
Relevant recall at session start
- 02
Proof gets separated from the claim
A passing command in terminal history is useful, but reviewers still need to know which work it covered and whether it ran after the final edit.
A recorded, content-bound build receipt
- 03
Handoffs lose the operating state
The next session needs the active task, last safe milestone, residual risk, and verification state—not another summary written from memory.
A recoverable checkpoint and run pin
One session. Six inspectable transitions.
TRW surrounds the work with durable state. Your repository still owns implementation and validation; tool names below mark lifecycle transitions rather than copy-paste commands.
- 1ORIENT
trw_session_start()Relevant learnings and any active run are loaded before the edit.
- 2ATTACH
trw_init / trw_adopt_runA new task creates or adopts a run; a recovered active run can skip this transition.
- 3IMPLEMENT
trw_checkpoint("milestone + next step")Current run state and the caller-supplied milestone message become recoverable.
- 4VERIFY
make checkThe repository runs its real tests, types, lint, build, or schema checks.
- 5RECORD
trw_build_checkThe observed command result becomes current delivery evidence.
- 6HANDOFF
trw_deliver()The verified or explicitly disclosed state is persisted for the next session.
Verified evidence can satisfy the coding delivery gate.
Failed checks remain failed when an exception path is disclosed.
Durable controls at the moments that matter
Each tool owns one narrow lifecycle transition. Your coding client and repository still own the work; TRW preserves the context, checkpoint, evidence, and handoff around it.
The next session has no operating context
Recall relevant learnings and recover the active run before work begins
Returns prior knowledge, run phase, checkpoint state, and degraded-mode warnings.
trw_session_start()
A long task has no safe resume point
Persist a meaningful milestone while the work is still in progress
Persists the current run state with the milestone and resume detail supplied by the caller.
trw_checkpoint()
A test claim is detached from the changed work
Record project-native check results as delivery evidence
The repository runs the checks; TRW records their outcome and scope for the gate.
trw_build_check()
A completed task disappears into chat history
Persist the handoff only after the applicable delivery policy is satisfied
Coding, RCA, and eval work require verified evidence or a structured exception path.
trw_deliver()
Turn a delivery claim into an inspectable handoff
TRW cannot prove that generated code is good by itself. It can preserve the chain from the claim and changed source to observed checks, recorded evidence, and the next resume point.
- 01CLAIM
Webhook retries are safe to shipWhat the change says it achieved
- 02SOURCE
src/payments/webhooks.pyThe implementation under review
- 03CHECK
pytest tests/payments -qA project-native command run after the edit
- 04RECEIPT
scope=payments · 42 passedThe recorded result bound to this work
- 05HANDOFF
verified · checkpoint retainedWhat the next reviewer or session can inspect
- Which project-native checks were reported, when, and for what scope.
- Whether the active task has a passing receipt or disclosed exception path.
- Which checkpoint and durable learnings are available to the next session.
- That a check ran merely because a tool name appears in a transcript.
- That remembered advice automatically improves the code using it.
- That an authorized exception converts unverified work into verified work.
Verification is a chain, not a badge
A trustworthy handoff separates the command that ran, the evidence recorded from it, and the policy decision that follows. Skipping a link leaves an explicit gap.
Project-native checks
Run the repository’s real tests, type checks, linters, builds, or schemas. TRW does not replace the command or infer that it passed.
RUN
outside the receipt
Recorded evidence
Record the observed result, scope, count, and static-check state after the command finishes so the delivery gate can evaluate current evidence.
RECEIPT
bound to the task
Explicit delivery decision
Deliver verified work, or disclose a structured acceptable-failure record or authorized override. An exception never turns a failed check into a pass.
DECIDE
verified or disclosed
Install locally. Keep your client.
Use the guided installer for the supported client path, then verify the generated project configuration before beginning the first session.
$ curl -fsSL https://trwframework.com/install.sh | bashPrefer to inspect the archive or install without a shell pipeline? Use the create a free account for downloads.
WHAT THE PATH DOES
- 1Detect the supported coding clients available on this machine.
- 2Install the local TRW package and initialize project-scoped state.
- 3Write the client configuration needed to expose the MCP tools.
- 4Show the exact next command and verification path for this project.
Stop rebuilding context.
Start shipping with proof.
Start with one project. Run its real checks, record the result, and inspect what the next session receives before you widen the rollout.