Skip to main content
TRW
LATTICE // VERIFICATION
5 GATES ENFORCED

Done means evidence, not assertion

Tests, types, coverage, review — enforced before the agent can close. Your existing test suite is the truth. TRW just makes skipping it impossible.

tests_pass

pytest — full suite, structured pass/fail, structured output

types_clean

mypy --strict — zero type errors required

coverage_threshold

Line coverage ≥ build_check_coverage_min (default 85%)

review_clean

trw-adversarial-auditor — per-finding pass / warn / block

deliver_clock

trw_deliver() fires — all prior gates satisfied

LEDGER // PROBLEM

AI agents complete tasks convincingly

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.

GitHub Actions run after merge — too late. The CI failure is already in main, the review is already approved, and the signal arrived at the worst possible moment. TRW runs verification in-session, before the agent can declare completion. The test suite runs. Types are checked. A separate adversarial auditor reviews the output. The session cannot close until every gate passes.

WITHOUT GATES
Test runPost-merge CI
Type checkDeveloper discretion
ReviewSame agent that wrote the code
Delivery signalAgent says done
WITH TRW GATES
Test runIn-session, before close
Type checkmypy --strict, enforced
ReviewIndependent adversarial auditor
Delivery signalAll 5 gates pass
LATTICE // GATES

The five gates

Every verification phase must clear all five gates before trw_deliver() is permitted to fire. This is Phase 4 VALIDATE of the lifecycle. Each gate is independently verifiable and logged to build-status.yaml.

Tool / gateWhat it checksConfiguration
trw_build_checkpytest + mypy --strictCaches result to build-status.yaml
coverage floorLine coverage ≥ thresholdbuild_check_coverage_min (default 85)
trw_reviewStructured per-finding verdictpass / warn / block per finding
trw-adversarial-auditorIndependent agent auditRuns separately from implementer — breaks confirmation bias
stop-ceremony.shSession-exit enforcementBlocks up to 2 exits until trw_deliver() fires
TERMINAL // STOP_CEREMONY

The hook that can't be ignored

Hooks are the load-bearing primitive. When your AI CLI fires its session-stop event, TRW's stop-ceremony hook inspects whether verification ran and whether trw_deliver() was called. If either is missing, the hook rejects the stop and prepends a warning to the next tool response. The same wiring is active across all five supported CLI profiles — Claude Code, Codex, Cursor, Aider, and opencode — because the trigger is a lifecycle event, not a client-specific command.

The hook allows up to two rejections before an operator override becomes available. The design errs toward rigor: a delayed close is recoverable; unverified code merged to main is not.

LIFECYCLE — stop-ceremony firing

session ends

stop-ceremony hook fires

verification gates evaluated

[stop-ceremony] ERROR: trw_build_check not called this session.

[stop-ceremony] ERROR: trw_deliver not called this session.

Complete validation before closing. (Rejection 1 of 2)

$ _

LEDGER // HIERARCHY

Truthfulness before velocity

“Truthfulness > Quality > Knowledge > Velocity. Never misrepresent the state of the work. Never bypass verification.”

TRW VISION — value hierarchy invariant

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?

No. Gates run once at the end of a phase, not after every file change. For most sessions the verification step adds under two minutes to a phase that already takes 20–40 minutes to execute.

Can I skip verification if I need to ship fast?

Not without an operator override. The stop-ceremony hook rejects exit up to 2 times. After that, an operator can force-close. The hook errs toward rigor, not convenience — unverified code is technical and compliance debt.

What if my tests are flaky and the gate fires incorrectly?

The block still fires. TRW takes the position that a flaky test suite is a test-quality problem, not a reason to disable the gate. Fix the flaky test; do not remove the checkpoint.

What if I don't have tests yet?

TRW still runs the gates it can — type-check, adversarial review, stop-ceremony — and records the absent suite as a warn-level finding. The block only escalates once a suite exists and produces failing runs. Greenfield repos are not penalized; they are flagged so tests get written, not waived.

Can I customize which gates run?

Yes. Each gate is independently toggleable in .trw/config.yaml. Teams commonly relax the coverage floor during spikes or disable the adversarial-auditor gate for trivial doc-only changes. The stop-ceremony hook itself is the one gate that should stay on — it is the mechanism that makes the others unskippable.

What's the coverage floor and can I override it?

The default line-coverage floor is 85% (build_check_coverage_min). You can raise, lower, or disable it per-repo in .trw/config.yaml. Overrides are logged to build-status.yaml alongside the run, so reviewers can see when a session cleared a reduced bar rather than the standard one.
TERMINAL // SHIP_WITH_EVIDENCE

Stop shipping unverified code

Every gate in TRW is a commitment: the agent cannot close until the evidence exists. Access is currently limited while onboarding hardens.

TERMINAL~/repo

# one-line install — pulls trw-mcp from PyPI

$ curl -fsSL https://trwframework.com/install.sh | bash