Exercise the pull request steps and the host CI snippet against GitHub

[PierreMardon]

Status

Open, half done. The first thing proposed below is done by #91: a stand-in gh in the image plays the pull request steps, in the end to end tests and in the evaluations. What is left needs GitHub itself, or the developer: a toy whose CI reacts to a push, one run by hand in a scratch repository with the snippet of the guide, and whether that snippet pins actions/checkout.

What #91 shows, played on 2026-10-05:

• The nominal scenario of the end to end tests passes with its new assertions: the description of the pull request is the one surface-status pr-body prints, set by a gh pr edit, the pull request is still a draft, and no call marks it ready.
• In the seven runs of the fourth campaign of the evaluations, a draft is open at every hand over, its description is refreshed at conformity, and nothing marks it ready (Campaign 1 of the evaluations: findings, status, and the work done on them #77).
• A fault it let see: in 3 of the 6 runs that had a gh to call, the draft is opened with a line of attribution under its description (A draft pull request is opened with a line of attribution under the description the state script prints #93).

Earlier: the hand back at conformity fits a branch with no pull request (#78), and the manual moved from the README to docs/guide.md (#45), the CI snippet with it.

What has never run

The end to end harness pushes to a local bare remote, so every step that talks to GitHub is skipped or fails there: gh cannot open a pull request on a folder. As a result, these promises of the README and of the guide have never run against GitHub. Since #91 the first two run against the stand-in:

• /surface-plan opens a draft pull request at the first plan-drafted, linking blueprint.md and plan.md.
• Every stop of /surface-execute refreshes the description with surface-status pr-body | gh pr edit --body-file - (in the runs it failed on the local remote).
• Before the first push, the command reads the CI triggers and waits for the developer's agreement: the toy project has no CI, so only the "no CI" branch was seen.

The conformity check is proven in a checkout shaped like the one actions/checkout leaves (tests/ci, and the conformity check in a CI checkout job), but that checkout is built by the test with git init and a fetch. The snippet of the guide itself, actions/checkout@v4 with fetch-depth: 0 then check --require conformant, was never run in a host repository.

Proposed

• Done by A stand-in gh in the test image: the pull request steps played, recorded and measured #91. In the toy harness, a fake gh first on the PATH that records its calls, so the scenarios assert the draft and the body without a network. The end to end image has no gh (End to end runs fail on permissions an agent's exploration needs; leave that to the permission mode #6), so the fake is the only one on the PATH. The evaluations use that image too (Evaluations: the container has no gh, so the pull request steps are never played and every message is scored with that absence in it #75).
• A toy variant whose CI reacts to a push, to see the warning and the wait.
• Once, by hand, a scratch GitHub repository: the one-line install, a plan to conformant, the snippet of the guide in its workflow (pass on the conformant plan, fail on a plan in progress, exit 2 at depth 1). Record the run in the repository, in a new docs/e2e/ folder.
• Decide whether the snippet of the guide pins actions/checkout by SHA, as this repository's own workflow does. The snippet names v4 today, and this repository's workflow pins v7.0.1.