[PierreMardon]

The end to end tests held four scenarios, all of /surface-execute from a prepared state. Five more were described in tests/e2e/README.md to be driven by hand, and #9 lists the paths no scenario covered: a session killed anywhere but in a slice, two plans on one branch, a break an executor suspects, the ceiling in planning, an abandon. #8 asked for a toy whose CI reacts to a push.

This adds 23 scenarios, 26 tests with those played once per command or per agent, to the four. The first seven commits are the work of an agent given #9 as its task, each stage its own commit. The next two are the mark on the one scenario that fails and the record of the runs, and the last mends what a review found.

What is played now

• The scenarios driven by hand, with their answers written in the test, one session per answer: planning from the specs killed during the interview, an amendment killed once recorded, an amendment in the conversation and a sentence that agrees, a break on a commit of the developer refused, and accepted, the ceiling then its three ways on.
• The status command and a branch with two plans: an abandon that waits for a yes, then the conformity check that fails on it; each of the three commands puts two plans to the developer and records nothing.
• A CI that runs on a push (Exercise the pull request steps and the host CI snippet against GitHub #8): /surface-plan warns and waits before the first push, pushes and opens the draft on a yes, and pushes nothing on a no.
• Sessions that died: in a fix, in a gate run, in a review, in the extraction, in the cross-check, and, from prepared states, between a record and its commit and between a commit and its push.
• The ceiling in planning, and a break suspected in a slice, confirmed then refused, and dismissed, from prepared states.

How each is played and what it must hold is in tests/e2e/README.md, rewritten: nothing is left to drive by hand.

How

• No model plays the developer here, which is what the evaluations do: every question of the chain carries a recommendation, so one written reply that takes it answers a question that changes from run to run.
• A scenario asserts what the project holds once its sessions ended, the journal, the plan folder, git and the record of the stand-in gh, and of what a session said one word at most.
• tests/e2e/toy/toy.py gains the prepared states those paths start from, each documented in the README and checked without a session by test_a_prepared_state_is_the_one_named. A state that holds work not committed or not pushed is what a death there leaves: an agent chains a record and its commit in one command, and leaves no moment to kill it at.
• A kill now also takes what the session left at work in the project, since a gate runs in a process group of its own and would record its run while the next session works.
• ARCHITECTURE.md and ADR 0025 say that the answers are written in the tests, where they said that those scenarios were played by hand.

Nothing of skills/, agents/, the stand-in gh or the image changes.

Played

Every scenario was played on the prompts of commit 4220424: 33 runs, 13.61 USD at list price. docs/e2e/2026-10-07.md keeps the verdicts and the cost of each. 21 of the 23 new scenarios passed their only run, one passed on its second, and one fails as the chain stands.

They were not played in one command, and every verdict but five rests on one run: how often a scenario fails for a path a model takes is not known.

What they found

• A session that dies between the commit of a conformant plan and its push leaves the push to nobody #114, a push left to nobody. A session that dies between the commit of conformant and its push is taken up by no relaunch. The scenario is marked as expected to fail, strictly: the day the chain takes that push up, the mark fails and goes.
• A line of attribution under the description of a draft, once in seven openings: the fault of A draft pull request is opened with a line of attribution under the description the state script prints #93, after its fix. Recorded there.
• An existing scenario that passed by luck: the kill of a session in a slice waited for a window that one run closed in a fraction of a second. The toy can be built with a slow test, which holds it open.

Read by an independent reviewer

Before its merge, on 2026-10-08: fifteen findings, none of them a failure that repeats. The last commit mends those that cost little and that a run can check:

• A look that took a lock. The scenarios looked at the repository of a running session with a plain git status, which takes the lock of the index, and could make a git add of that session fail: the reviewer counted 24 failures in 400 against a status asked without a pause. The look passes --no-optional-locks.
• A session left running. A watch that raised left its session running to its end, billed, behind a scenario that had failed. The session is killed whatever the watch raises, and a stream read as it grows no longer raises on a character cut in two.
• A kill in a slice with a loop of its own, without the guard that the moment came: the helper of the other kills plays it.
• Smaller. An agent launched under the other name of the tool, Task, is read. A reply after a refusal goes to the session the refusal gave. The plan folder is read in the project, where a scenario named it from the date after its session. Three slips of the README.

The tests that start no session pass in the container, and the kill in a slice was played once more as it stands, on the prompts of commit 505848a: killed after the approval and before any slice was done, then passed, 0.43 USD.

Left as they are:

• A kill that takes more than a real death does. It takes what the session left at work in its project, a gate under way among it. So no scenario plays what a kill -9 of claude leaves on a developer's machine: a gate that outlives its session and records its run under the next one. No run shows it as a fault of the chain. The README says it where it describes a kill by hand.
• The strict mark of A session that dies between the commit of a conformant plan and its push leaves the push to nobody #114 covers its whole test: any failure of that scenario reads as the expected one until the mark goes.
• A conversation takes the recommendation after every session that did not reach the state it waits for, without reading that a question was asked, twelve times at most.
• The kill in a review does not assert that the relaunch launched a reviewer: a report the killed one left is recorded as it stands, which is the chain's rule, and the scenario passes on either path.
• What a prepared state is made of is spread over several tables of toy.py, the README and the list of a test, and nothing checks that they agree.

Not done

• A real kill between a record and its commit, and a real executor that suspects a break: both start from prepared states, for the reasons above.
• The run by hand against GitHub and the pin of actions/checkout in the guide, which Exercise the pull request steps and the host CI snippet against GitHub #8 keeps.
• The set was not played again on main as it stands: two prompts changed since, the extractor (A blueprint whose long sections hold a title in bold on each thing the developer comes back for #111) and the hand over (A hand over that tells none of the steps that led to it, and gives the address of the pull request #113), and no scenario asserts what either says.