test(recover): repeat the #1166 field test so fragment coverage depends on the restore #1575

New issue

Open

opened 2026-10-08 01:41:30 +02:00 by engineer · 0 comments

engineer commented

2026-10-08 01:41:30 +02:00

Member

Follow-up to #1166. That tracker's AC2 field test (comment 115998) passed but did not discriminate the restore at the coverage gate. This tracker repeats it so that it does.

Why the first run could not discriminate

#417's orphan check reports a stranded cut only once a release-relevant commit sits above the prepare. On tic-tac-toe that commit (tic-tac-toe#7) was a fix: with its own fragment. The re-prepared rolling PR (tic-tac-toe#9) therefore consumed 3 fragments, and the control with the restore skipped still gave PASS - fragment present on #7's fragment alone. The restore was proven by content (byte-exact files, each entry rendered once), not by the gate.

AC

A staged recovery (B) where the stranding commit carries no-changelog: and no fragment, so the restored files are the only fragments the re-prepare can consume.
The rolling PR after the fold passes pr / gates fragment coverage with no body edit.
Control on the same rolling PR's head, restore skipped (CHANGELOG only): FAIL - forgotten. The control must fail, or the run proves nothing.
The recovery goes through the recover pending cut workflow, not the local route. This depends on #1574.

Recipe, as measured on tic-tac-toe

A rolling PR that consumes at least one fragment is merged with the release workflow disabled (Actions → release → Disable workflow), then release is re-enabled. decide now says mode=cut, a due cut, so nothing may push or dispatch release until step 2 lands. Cuts are the operator's.
A fix: commit touching more than CHANGELOG, manifest and VERSION, with a no-changelog: line in its PR body. decide then gives blocked / pending_cut, and the push's release run writes nothing.
Dispatch recover pending cut (dry run, then real), review and merge its PR. The push opens the re-prepared rolling PR.

Not this tracker

#1574, the workflow's push 400. It is a prerequisite for the fourth AC.
Whether to repeat on toolkit-self rather than an adopter.

Refs #1166, #1574, #417

Follow-up to #1166. That tracker's AC2 field test (comment 115998) passed but **did not discriminate** the restore at the coverage gate. This tracker repeats it so that it does. ## Why the first run could not discriminate #417's orphan check reports a stranded cut only once a release-relevant commit sits above the prepare. On tic-tac-toe that commit (tic-tac-toe#7) was a `fix:` **with its own fragment**. The re-prepared rolling PR (tic-tac-toe#9) therefore consumed 3 fragments, and the control with the restore skipped still gave `PASS - fragment present` on #7's fragment alone. The restore was proven by content (byte-exact files, each entry rendered once), not by the gate. ## AC - [ ] A staged recovery (B) where the stranding commit carries **`no-changelog:`** and no fragment, so the restored files are the only fragments the re-prepare can consume. - [ ] The rolling PR after the fold passes `pr / gates` fragment coverage with no body edit. - [ ] Control on the same rolling PR's head, restore skipped (CHANGELOG only): `FAIL - forgotten`. **The control must fail, or the run proves nothing.** - [ ] The recovery goes through the `recover pending cut` workflow, not the local route. This depends on #1574. ## Recipe, as measured on tic-tac-toe 1. A rolling PR that consumes at least one fragment is merged with the `release` workflow disabled (Actions → release → Disable workflow), then `release` is re-enabled. `decide` now says `mode=cut`, a due cut, so nothing may push or dispatch `release` until step 2 lands. Cuts are the operator's. 2. A `fix:` commit touching more than CHANGELOG, manifest and VERSION, with a `no-changelog:` line in its PR body. `decide` then gives `blocked / pending_cut`, and the push's release run writes nothing. 3. Dispatch `recover pending cut` (dry run, then real), review and merge its PR. The push opens the re-prepared rolling PR. ## Not this tracker - #1574, the workflow's push 400. It is a prerequisite for the fourth AC. - Whether to repeat on toolkit-self rather than an adopter. Refs #1166, #1574, #417

engineer referenced this issue

2026-10-08 01:41:30 +02:00

recover-pending-cut leaves changelog.d empty, so the re-prepared rolling PR fails fragment-check #1166

engineer added the

labels