LATTICE // WORKFLOWS

Six phases when risk requires them. One evidence standard.

TRW scales the workflow from a three-phase minimal fix to a complete research-through-delivery run. Validation is never skipped, and checkpoints keep long work resumable without pretending every client has the same hooks.

Get Started READ THE LIFECYCLE SPEC

illustrative comprehensive run · client-neutral

RUNNING

LEDGER // PROBLEM

Unstructured sessions lose decisions, not just tokens

A chat transcript is not a durable execution record. When context compacts or a session changes hands, decisions, evidence, and remaining work can disappear into prose. TRW gives the run explicit phases, checkpoints, and a resume directive that another session can inspect instead of guessing.

WITHOUT TRWBlack box

On handoff
The next session reconstructs state from prose
Prior work
Decisions are buried in an expiring context window
Gotchas
Re-discovered the hard way each time

WITH TRWTraceable

On handoff
trw_checkpoint
Start from an explicit resume directive
Prior work
events.jsonl
Recorded events remain inspectable; unrecorded context stays disclosed
Gotchas
trw_session_start
Top-N learnings injected before work begins

LATTICE // PHASES

The lifecycle expands with consequence

MINIMAL work keeps IMPLEMENT, VALIDATE, and DELIVER. STANDARD adds PLAN and REVIEW. COMPREHENSIVE uses all six phases. Phase discipline defaults to warn-and-proceed unless strict mode is configured; the hard machine gates live at delivery.

RESEARCH
Recall prior work, inspect current evidence, and make open questions explicit. Required only for comprehensive work.
Exit
Source and acceptance identified; open questions explicit
PLAN
Define acceptance, change scope, verification method, dependencies, and ownership boundaries.
Exit
Acceptance, scope, verification, and ownership defined
IMPLEMENT
Implement the scoped change with focused checkpoints and update tests or other proof assets where warranted.
Exit
Changes complete or checkpointed; validation assets updated
VALIDATE
Run project-native checks, inspect the outcome, and record the observed result with trw_build_check.
Exit
Applicable project checks pass; build receipt recorded
REVIEW
Inspect the diff against requirements. STANDARD+ needs substantive review; critical blockers prevent delivery.
Exit
Diff inspected against requirements; blockers resolved
DELIVER
Summarize the result, persist progress and learnings, and use one of the three explicit delivery paths.
Exit
Result summarized; artifacts and learnings preserved

RESEARCH
01/06
Recall prior work, inspect current evidence, and make open questions explicit. Required only for comprehensive work.
Exit
Source and acceptance identified; open questions explicit
PLAN
02/06
Define acceptance, change scope, verification method, dependencies, and ownership boundaries.
Exit
Acceptance, scope, verification, and ownership defined
IMPLEMENT
03/06
Implement the scoped change with focused checkpoints and update tests or other proof assets where warranted.
Exit
Changes complete or checkpointed; validation assets updated
VALIDATE
04/06
Run project-native checks, inspect the outcome, and record the observed result with trw_build_check.
Exit
Applicable project checks pass; build receipt recorded
REVIEW
05/06
Inspect the diff against requirements. STANDARD+ needs substantive review; critical blockers prevent delivery.
Exit
Diff inspected against requirements; blockers resolved
DELIVER
06/06
Summarize the result, persist progress and learnings, and use one of the three explicit delivery paths.
Exit
Result summarized; artifacts and learnings preserved

TRACE // COMPACTION

The context-compaction problem

Long sessions can outgrow their context window. TRW provides trw_pre_compact_checkpoint to persist a recovery directive before compaction. A supported client may add a pre-compact hook, but hooks are adapters—not the recovery contract. The saved recovery record includes { run_path, phase, events_logged, last_checkpoint }. On restart, trw_session_start surfaces that directive so the agent can apply it against the current repository state.

WITHOUT TRWState evicted

state→compact→evicted

Context fills → agent compacts → state evicted
On restart: no memory of the active phase
Agent re-discovers already-solved problems
Work done may be repeated or silently lost

WITH TRWState preserved

state→checkpoint→resumed

pre-compact adapter can request a checkpoint when the client exposes the event
Writes the current phase, checkpoint, recent events, and recovery directive to local state
trw_session_start surfaces the saved directive for the agent to reconcile
Append-only events preserve the recorded trail; unrecorded context is not recoverable (delegates can use their own checkpoints too)

LEDGER // CHECKPOINTS

Durable checkpoints with an explicit next action

trw_checkpoint() persists an explicit milestone message against the active run. Append-only events keep the recorded trail inspectable. Recovery is only as good as the checkpoint: decisions left solely in chat are not magically reconstructed.

RESUME CONTRACT // EXAMPLE

ACTIVE PHASE: IMPLEMENT — pricing mobile decision path
OBSERVED EVIDENCE: Focused tests pass; full browser suite pending
NEXT ACTION: Run desktop/mobile comparison, then independent review
DO NOT REPEAT: Navigation root cause already fixed and committed

Resume by reconciling this directive with the current worktree—not by replaying the old conversation.

LEDGER // FAQ

Common questions

Can I skip phases?

Only when the ceremony tier allows it. MINIMAL uses IMPLEMENT, VALIDATE, and DELIVER; STANDARD adds PLAN and REVIEW; COMPREHENSIVE uses all six. VALIDATE is never skipped.

What exactly gets checkpointed?

The checkpoint records a milestone message against the active run and preserves the current progress trail. A pre-compaction checkpoint adds a recovery directive. Include the next action and unresolved risk; unrecorded chat context cannot be recovered.

Does this work offline?

Core run and checkpoint artifacts are local. Some optional adapters, hosted services, or external tools can require connectivity, but the local recovery contract does not.

How long does a full phase cycle take?

Highly task-dependent. A small fix can cycle through in one session; a comprehensive feature may span several. The next session starts from the last recorded directive and reconciles it with the current worktree and evidence.

What happens if VALIDATE fails?

Return to the phase that owns the failure, fix it, and validate again. For task types covered by the configured hard gate, delivery requires a passing build receipt, allow_unverified=true with a valid unverified_reason naming failed_command, residual_risk, owner, and unexpired expiry_iso, or an authorized operator/config override recorded with technical rationale. Exceptions permit delivery but do not make failed work verified.

How is DELIVER different from a checkpoint?

A checkpoint preserves an in-progress milestone and resume direction. DELIVER is the terminal ceremony that summarizes the result, persists progress and learnings, and applies the delivery gate.

TERMINAL // RUN_STRUCTURED

Give the next task the ceremony its risk deserves

Keep the evidence obligations. Shed optional ceremony when the work does not need it.