# Gate: W5 — bundled adapters land on apply (releases#338, core PR #269)

Gater doyle, 2026-09-24, HFENDULEAM. Subject sha **`47275b34512ee47dc3fffc800cc5b2847bf01bec`**,
parent `447fc9eb` == `origin/main` tip at gate time. Rig: `.worktrees/gate-w5-47275b34...` (detached,
own pool `gate-w5-47275b34`).

Builder todlando rebased mid-gate, from `7d8008c7` onto current main, after I found the landing
blocker below. I re-pinned the rig to the rebased sha rather than gating the sha that would not land
(probe the SHA, not the stale worktree). His identity evidence, which I did not take on faith for the
part that matters: `patch-id --stable` identical across the rebase (`738d18e2…`), and the diff
`7d8008c7..47275b34` is `docs/INFRA-REGISTER.md +2` only — main's #268 delta, the docs lane I landed
myself. So the code under gate is byte-identical to the code he tested.

## Landing blocker found at gate (not a code finding)

`7d8008c7`'s parent was `437562d9`, but main had moved to `447fc9eb` when I landed PR #268. The lane
must land by a fast-forward push of the sha, and that push is REJECTED while the head's parent is not
main's tip. Rebase ordered, done clean, verified above.

This is a consequence of the verb correction made earlier today: `gh pr merge --rebase` does NOT
preserve the sha (#268 measured: head `488ee001` landed as `447fc9eb`, GitHub re-commits with a
merge-time committer date). Landing by `git push origin <sha>:main` is what keeps tested == merged,
and it costs a rebase whenever main moves under a lane. Record:
`.spt/preserved/331/land-268-rebase-rewrites-sha.md`.

## Review — every ruling checked against the code, not the PR body

- **Bundle filter before the verifier.** `land_bundle_in` returns `NothingToApply` on
  `meta.filter(|m| m.bundle.is_some())` failing, BEFORE `verify_update_set_bundle` is called. The
  release-side Malformed refusal is untouched, which is the stop-and-refer condition I set, and it
  was not triggered. Unit row 1 pins the trap explicitly: it asserts the verifier DOES refuse a
  bundle-less set, then asserts the apply leg never asks it.
- **`built_in`, my amendment, as ruled.** Additive on `AdapterRecord` (`serde(default)`,
  `skip_serializing_if` so a false mark writes no key); `register_with_core` writes `false`
  unconditionally, so any non-bundle update clears it; the bundle leg calls `mark_built_in` only
  after checking the registry actually runs the bundled version. `install_source` untouched — the
  equal/newer row asserts the record is byte-identical.
- **No downgrade.** `bundle_member_action` is pure and total over the four states; only `None`
  installs and only `version_is_newer` upgrades. Operator-removed (inactive record) reads `Removed`
  and is left removed.
- **AUTO-SET SEAM (W7, releases#336)** marker sits at the upgrade site with the W7 gate named, and
  in the REQ text. Both, as ruled.
- **Isolation.** A bundle failure prints `UPDATE_BUNDLE_SKIPPED` and never changes the binary
  apply's outcome, which is decided before the leg runs — the docs-leg precedent.
- **Reuse is real reuse**, not copies: `complete_adapter_add` for an absent member,
  `update_one_adapter` with a preset candidate for an upgrade, `apply_release_crc_swap`,
  `check_archive_identity`, `docs_pull_due` for the peer backoff.
- **Path safety.** `bundle_safe_component` rejects separators and leading dots for both the member
  name and its asset, so neither can climb out of the extraction dir or the adapters home. Archive
  extraction itself carries the same trust as the signed core archive: the bundle is verified
  against the SIGNED set entry before a single member is extracted.

## Test craft — two things worth naming

1. **A vacuous green was caught by its author.** Row 1 first passed with a fixture that staged NO
   set, so it was passing for a reason unrelated to its claim. `stage()` now asserts the set is
   staged. Repaired at the fixture, which is where it belonged.
2. **Row 2 measures rather than asserts.** It reads the tar-recorded names, then fails a bare-name
   lookup against them as a NAMED negative control, and the reader under test addresses no member by
   name at all. The dialect split behind it was measured, not assumed: bsdtar 3.8.4 extracts a bare
   `bundle.json` from a `./`-recorded archive (rc 0), GNU tar 1.35 refuses it (rc 2). CI's Linux unit
   leg exercises that row under GNU tar, so both dialects are covered across the two legs.

Four negative-control mutations, each red on exactly its row, tree restored (porcelain 0).

## Gate arms — all green, LANDED

| arm | result |
| --- | --- |
| review vs rulings | PASS (above) |
| `traceable-reqs check` | exit **0**, 967 OK |
| CI run `36027963320` @ `2e52677a` | **all six jobs SUCCESS**, both unit legs included |
| independent `bundled_adapters_e2e` | **1 passed**, 7.75s, isolated rig + own pool |

**The lane rebased twice** (`7d8008c7` -> `47275b34` -> `2e52677a`) because main moved under it: my
#268 docs land, then hertz's #270. Patch-id `738d18e2971415a801fc2b9ff68c6164a6415b5a` is identical
across all three and I verified that myself rather than taking the builder's number; each delta was
`docs/INFRA-REGISTER.md` only. So the code gated is the code landed.

**The two earlier CI runs were CANCELLED by those rebase pushes** (`36026531032` @ `7d8008c7`,
`36027406498` @ `47275b34`). I had reported "thin lane CI green" off the jobs that finished before
the cancel — true of those jobs, and misleading about the run: W5's unit legs had completed on NO
sha until `36027963320`. A cancelled run is a labelled hole, and it reads as a completion to anyone
waiting on the box, which is exactly how hertz nearly took kitsubito early on a window I worded
badly. He had already read it correctly himself.

## Landed

    git push origin 2e52677a...:refs/heads/main   ->   c39fa636..2e52677a
    git ls-remote origin refs/heads/main          ->   2e52677a
    PR #269 MERGED, mergeCommit.oid == headRefOid == 2e52677a

Subject verified BEFORE the push: run headSha == PR head == `2e52677a`, parent == main tip
`c39fa636`, 0 behind 1 ahead. **Tested sha == merged sha holds exactly** — the fifth witness of the
ff-push verb and the first I ran myself since the correction.

## Three predicate misses of mine this gate, all caught, all the same shape

1. `traceable-reqs check | tail -15; echo $?` reported **`tail`'s** exit, not the checker's.
2. A CI poll whose settled-test was `grep -qE "queued|in_progress"` declared ALL_SETTLED on a run
   whose status was **`pending`** — a word the predicate did not know.
3. The repair for (2) used `.conclusion // "NONE"`, but an unfinished run's conclusion is the empty
   **string**, not null, so the default never fired and it declared settled again.

Each one would have reported a green that no measurement supported. The third try counted
`status=completed` rows against total rows, which is a predicate that cannot quietly pass. Same
family as the verdict-from-exit-not-silence rule, and the lesson is narrower than "be careful": **a
settled-test must be written over the states the tool actually emits, and an unknown state must
count as not-settled rather than fall through the filter.**