template: inventory the decisions of the case matrix, prove the private-text case, and keep dry runs and fixes honest #425

Outside the plan: Pascal assigns this card. Its pull request says that it is outside the plan. It follows #423, whose pull request #424 is open and not merged. Stack this work on the branch feat/423-case-matrix of #424, or on main after the stack #418, #421, #424 merges.

Problem

The day-1 trials ran 6 rounds of 3 fresh agents each (2026-10-30 to 2026-11-01). Each agent built an extension for a program that Nicely never wrapped. An independent judge replayed the same 36 cases on each extension.

The loop now holds:

• The first failing run is real, and just signoff replays it.
• Agents that wrote none of the code review each round.
• The ledger keeps each finding. Free-form grades fail.
• The agents stop honestly at the limit of 5 rounds.

But no build reached an earned "Done when" in 6 rounds. In round 6, one build passed just finish and said Ready, but the judge found three losses in it. The judge gives this cause: a check of the form of the files cannot prove that the tests are complete. The holes below occur in 2 or 3 of the 3 extensions of round 6, or they recur from earlier rounds.

1. The case matrix omits branches (3 of 3)

Each build had a matrix before its first review. But later rounds still found branches that classify an input, and modes of the output, that the matrix did not list. The check of ## Case matrix reads the references only. It cannot see a missing branch.

2. Private text in data that a reader needs (2 of 3 leak, 3 of 3 untested)

The rule of #423 is prose only. No build had a test file that holds private text in a block that a reader needs, with a value that is not the default. Two builds keep the private text in the output.

3. The dry run predicts a result that the run does not give (3 of 3)

On a destination with no hard link and no rename that refuses to replace, the dry run exits 0. The run then exits 1. No matrix had a family for the abilities of the destination.

4. A promise narrows to close a finding (1 of 3, also rounds 3 and 4)

One build closed a warn finding as fixed. Its repair refused a type of input that the spec accepted before. The user did not accept that limit.

5. Lines marked proven before a test exists (2 of 3)

The first spec commit marked lines proven before any scenario existed.

6. Reviews stop on an approval that nobody gives (rounds 4, 5, and 6)

A reviewer ran rm with a glob, or a recursive delete inside sh -c. The coding harness asked for an approval, and the review waited for hours. The prose rule of #423 did not prevent two more cases in round 6. One reviewer also mounted a file system through a system service.

7. Damage that no reader can detect (1 of 3)

One build kept a finding open because a valid input with changed content passes. No reader can detect that change without a checksum from outside. generic-cases.md does not say which damage the command must detect.

Scope

1. An inventory of decisions before the matrix

In template/spec.md.jinja, the template skill, and readiness-review.md, the matrix starts from an inventory of decision points:

• Each way that the input declares how to read it, and the order of precedence
• Each refusal and each rule that classifies an error
• Each ability of the destination that the command needs, such as a hard link or a rename that refuses to replace
• Each mode of publication, and the dry run beside the run

Each row has a pair of tests at the same decision point. The two inputs differ only at that point. One test reused for many rows proves only one row. just finish checks what it can count. The reviewer of round 1 checks that the inventory is complete, and records the evidence.

2. Proof of the private-text case

For a command whose output keeps data that a reader needs, acceptance.sh records a receipt with these parts:

• The private bytes in the test file
• The value that is not the default, and its independent reference
• The independent reader
• A changed handler that keeps the raw block, and its failing result

just finish fails when the receipt is missing, if a check is practical. Otherwise, AGENTS/rule-index.md says "Prose only".

3. The dry run and the abilities of the destination

In docs/north-star/contract/generic-cases.md and replace-a-file.md of the template skill, the dry run checks the same abilities of the destination as the run. When the dry run cannot check an ability, it says that the result is unknown. It does not predict success. The tests inject the failure of each system call, with no mount and no system service.

4. A fix must not narrow a promise

The reviewer of each round compares the set of inputs that the spec accepts before and after each fix of a warn or block finding. A smaller set is a limit, and only the user can accept it. Add this rule to readiness-review.md. If a check is practical, just finish fails on it.

5. The first spec has no proven line

The lines of the first spec commit are open. A line becomes proven only in the commit of its test, or after it. If a check is practical, just finish fails on it. The reviewer of round 1 checks the first spec commit, not only the last spec.

6. A recipe for experiments, and a limit on the wait for an approval

• The template skill gives a concrete recipe: each experiment makes a new folder with mktemp -d. The agent never cleans a folder for a second use. It never runs rm with a glob, or a recursive delete in a shell loop or in sh -c. It keeps the evidence, or it uses trash after the work ends.
• The brief of each reviewer holds the same recipe.
• A reviewer can wait for an approval for longer than a set time. Then the agent that started it reports the blocked command and cancels that attempt. It starts the same review again, with no hint about the content. The new attempt is not a new round.
• The examples of a fault use the injection of a system call, never a mount or a system service.

7. Which damage the command detects

In generic-cases.md, the case "Input, truncated" covers damage that the structure of the input or its reader can detect. A valid input whose content changed is not damage, unless an expected checksum comes from outside.

Rules for the text

• Take each new example from text files or from the inspect command of the template. Do not add an example that names an existing extension or a file format of a specific domain.
• For each new rule, AGENTS/rule-index.md names the check that enforces it, or it says "Prose only".
• No text claims that the trials succeeded.

Out of scope

• feat(template): bâtir une extension à plusieurs agents dans T3 Code (un code, un autre vérifie) #414 and its items. Do not change feat(template): bâtir une extension à plusieurs agents dans T3 Code (un code, un autre vérifie) #414.
• A merge of ✨ feat: template: a build stops at 5 rounds, and a ledger keeps every finding #418, ✨ feat: template: finish proves the first failing run and one state of open work, and release runs finish again #421, or ✨ feat: template: one case matrix before the first review, and signoff runs the first failing run again #424, and a release.
• A higher limit of rounds, or a lower severity to reach "Done when".

Done when

• just check passes.
• Tests fail first on these states, and then pass for a correct repository, for each check that the pull request adds:
  • A matrix row whose pair of tests is one test reused
  • A private-text receipt that is missing
  • A dry run that predicts success where the run fails
  • A line marked proven in the first spec commit
• Each rule that stays prose has its row "Prose only" in AGENTS/rule-index.md.
• The pull request passes just signoff. Pascal decides when it merges.