New features are tested on a real system, not fakes
On Deep work (new capabilities or security changes), Claude tests the change on a real deployed copy of your app instead of fakes, and saves the results with the commands to rerun them. If you ask, a separate checker that never saw the code tests each goal and reports what fails.
How to use it
/tlmforge:buildRuns inside /tlmforge:build on Deep work, after the final review (Stage 5) and its fixes are done. Medium work skips it. The separate QA checker runs only when you ask, for example: "live verify this", "evaluate this end-to-end" or "QA this against the deployed environment".
Words you will see on this page
- Deep work
- TLM Forge's most thorough setting, used for new capabilities or anything that changes a security decision.
- Deployed environment
- A real running copy of your app that the tests can reach, such as a staging server.
- Mocks
- Fake stand-ins for real services that tests often use instead of the real thing.
- Lifecycle script
- A script that exits with 0 when the feature is healthy and with another code when something broke.
- E2E_VERIFICATION.md
- The file where the live results are saved next to the commands that produced them.
- Fresh-context QA agent
- A separate checker started with no memory of the conversation, so it cannot lean on what the builder believed.
Light vs Medium vs Deep: does the live check run?
| Kind of work | Live check (Stage 6) | What happens instead or next |
|---|---|---|
| Light: a tiny edit like a typo, rename or config value | No | Claude handles it directly, with a test first |
| Medium: fixing or improving existing behavior | No | Goes straight from the final review to the proof pack |
| Deep: a new capability or a security change | Yes | Live results feed the proof pack |
The built-in live check vs the QA agent you can ask for
| Question | Stage 6 (built in) | QA agent (on request) |
|---|---|---|
| Who runs it | Claude, as part of the build | A separate agent with no memory of the build |
| When | Deep work, automatically | Only when you ask |
| What it checks | Live tests and the lifecycle script | Each goal, one at a time |
| What you get | Results and rerun commands in E2E_VERIFICATION.md | PASSED or FAILED per goal, with evidence |
| Availability | Part of the recipe | Only if your version includes the live-evaluator skill |
What it does
Stage 6 runs on Deep work only, after the final review and its fixes. Its job is to prove the feature works on a real deployed environment, not with mocks (fake stand-ins for real services). Claude runs the tests as a dedicated test user. It also runs a lifecycle script, a small script that exits with 0 when the feature is healthy and with another code when something broke.
The results go in E2E_VERIFICATION.md in the feature's folder: sample database records with personal data hidden, real API responses, live results for each phase and the exact commands to rerun them. When the feature needs them, Stage 6 also prepares the rollout: a plan with stop conditions and rollback steps, and operator scripts that do a safe practice run unless told --confirm or --execute.
For a second opinion, ask for live verification. A separate QA agent starts with no memory of the conversation and assumes every expected result is wrong until it sees it work. It takes the goals word for word from the feature's notes, tests them one at a time, and marks each PASSED or FAILED with evidence. It is told to report failures, not fix them. TLM Forge does not launch it unless you ask.
How it works, step by step
Wait for the final review
Claude can draft the results file early. Nothing runs against the deployed environment until every reviewer has reported and the fixes are in.
Test the real system
Claude runs the live tests as a dedicated test user, then runs the lifecycle script, which exits 0 when the feature is healthy.
Write down the evidence
Sample records with personal data hidden, real API output, results per phase and the commands to rerun them go in E2E_VERIFICATION.md.
Prepare the rollout
When the feature needs them, Claude writes a rollout plan and operator scripts that default to a safe practice run.
Optional: ask for a fresh check
Say "live verify this" and a separate QA agent tests each goal, records PASSED or FAILED, and reports failures with steps to reproduce them.
Hand the evidence on
These results become the after side of the proof pack in the wrap-up stage (Stage 7).
What it looks like
Part of an E2E_VERIFICATION.md written by the separate QA agent when you ask for live verification. Each goal shows what was expected, the command run, what came back and the verdict. (Layout from the plugin, a few lines left out; the content is made up.)
# Saved cards: Live Verification
Verified by: live-evaluator (fresh context)
Environment: staging, version 3f9c2a1
## Criterion 2: a timed-out payment is charged once
Expected: exactly one charge after a retried timeout
Command: curl -s https://staging.shop.example/api/orders/demo-17/charges
Observed:
[{"amount": 10800, "status": "succeeded"}]
Verdict: PASSED
11/12 criteria passed. Failures: criterion 7 (order history lists the saved card twice).Why it is better
A real system, not fakes
Without TLM Forge, "tests pass" can mean tests against mocks. With it, Deep work is checked on a deployed environment with real API calls, real database records and a script that says healthy or not.
A checker that did not write the code
Without a fresh check, whoever built the feature also grades it. Ask for live verification and the checker has never seen the build, only the goals and the running system.
Results anyone can rerun
Without the commands, a result is just a claim. With TLM Forge, each result sits next to the exact command that produced it, so a teammate or future operator can reproduce it.
Failures stay visible
Without a rule, a checker could patch a failure and mark it as passing. The QA agent is told not to fix anything, so you see the failure and how to reproduce it.
Good to know
- Stage 6 runs on Deep work only. Medium work goes straight from the final review to the proof pack.
- Claude runs Stage 6 itself. The separate QA agent comes from an add-on skill called live-evaluator, runs only when you ask in plain English, and is available only if your installed version includes it.
- It needs a deployed environment it can reach. If that environment is broken, the QA agent is told to stop and tell you rather than test against it.
- For UI checks, the QA agent needs Playwright MCP (a browser-control tool) set up in Claude Code. Without it, API goals are checked with curl and UI goals come back to you with steps to try yourself.
- Fixing a failure counts as new code. Any code change after the final review, including a lifecycle script written late, trips the commit lock until it gets its own short review.