ci(promotion): the bundle's base is the newest armed set, never the first parent (stacked on #5824) by rbuergi · Pull Request #5848 · Systemorph/MeshWeaver

rbuergi · 2026-09-28T07:49:18Z

What

This is gap 1 of 3 being ported onto the kept one-promotion-gate design, following the maintainer's decision on 2026-09-27. It is stacked on #5824 (base ci/never-block-core-merge) and stays a draft until #5824 merges. It will then be retargeted to main.

The defect. promote wrote the promotion record with base set to the core commit's first parent, and judge() pins the verdict to rec["base"].

MeshWeaver.Plugins' scope therefore diffed exactly ONE merge, and its control arm re-ran exactly one merge, of a set that usually carries several. The batch window coalesces merges, and pending supersedes older pairs instead of queueing them.
arm then armed every other merge in the set, and none of them had been measured. fix(mesh): a subscriber's own release is not announced back; a same-silo grain call shares the immutable delivery envelope #5635, fix(#5135): an owned connection's release terminates attached subscribers; one upload ceiling #5647 and fix(bake): one partition that cannot answer costs the batched discovery its own types, not all of them #5655 would have reached the fleet this way had they landed in one set.

The fix.

arm-promoted-set.py armed-base names the newest ARMED set from memex-portal-ai's manifest metadata.
- The armed <version> tag sits on the same manifest as the seven-character sha tag. I measured this on 3.0.0-ci.9538 / b9fe5ed together with the pair tag b9fe5ed-pb7390a0.
- It is a pure function with 6 self-test rows. An uninterpretable manifest (no sha tag, two sha tags, or not a list) is RED, never a guess.

promote's record step sets base to that commit, provided it resolves and is an ancestor of the candidate. It records which rule produced the base in base_kind:

`base_kind`	when	what happens
`armed`	the normal case	measured and armed as usual
`first-parent`	nothing was ever armed, or the candidate IS the armed set	measured and armed; nothing wider exists
`unresolved`	the armed set can't be read or resolved, or isn't an ancestor	promoted for CI as usual, but `select` refuses to arm it and `pending` does not measure it; a warning names why, and the next promoted set retries

So CI is never held, and the fleet never receives merges nobody measured. A record written before this change has no base_kind and is judged as before, so no set promoted during the transition is stranded.

OnePromotionGate.md gains the section "The bundle's base is the newest ARMED set", and its step 2 now names that base.

No change is needed on the Plugins side. promotion-candidate.yml already passes the record's base through to core-candidate.yml, and #2479's attribution then covers the whole bundle.

Verified

arm-promoted-set.py --self-test passes with 0 failures, including 10 new rows (armed-base, base_kind, and unresolved never armed or measured).
The armed-base CLI, run on the live manifest listing, returns {"armed_version": "3.0.0-ci.9538", "armed_short": "b9fe5ed"}.

I ran the record step itself end to end against live ACR and GitHub, writing only to a scratch RUNNER_TEMP:

candidate	result
`main` tip `003b70dd`	`armed`, base `b9fe5ed47a…` (the armed set)
the armed commit `b9fe5ed4` itself	`first-parent`
the older `9357060`	`unresolved` ("compare: behind"), with the warning

MeshWeaver.Documentation.Test: 650/650 in Release with -warnaserror.
test-cd-steps.py passes, check-workflow-timeouts and check-workflow-yaml-keys report 0 violations, and shellcheck -S warning on the record step is clean.
actionlint findings on main-cd.yml are byte-identical to ci: never block a core merge; one promotion gate arms the fleet #5824's.

Pairs-with: none — no public src/ surface (a CI script, a workflow step and a doc page).

🤖 Generated with Claude Code

…irst parent Gap 1 of 3 ported onto one-promotion-gate (maintainer decision 2026-09-27). promote wrote the record with base = the core commit's first parent, and the verdict is pinned to rec["base"] — so Plugins' scope diffed, and its control arm re-ran at, ONE merge of a set that usually carries several, and `arm` then armed every other merge unmeasured. - arm-promoted-set.py `armed-base`: names the newest armed set from memex-portal-ai's manifest metadata (the armed <version> tag shares its manifest with the 7-char sha tag — measured on 3.0.0-ci.9538 / b9fe5ed); pure, self-tested (6 rows incl. uninterpretable manifests = RED). - promote's record step: base = that commit when it resolves AND is an ancestor of the candidate (base_kind `armed`); `first-parent` when nothing was ever armed or the candidate IS the armed set; `unresolved` otherwise — CI still promotes, but select REFUSES to arm it and pending does not measure it (the next promoted set retries). Legacy records without base_kind judge as before. - OnePromotionGate.md: "The bundle's base is the newest ARMED set". Dry-run against live ACR + GitHub: main 003b70d → armed, base b9fe5ed; b9fe5ed itself → first-parent; the older 9357060 → unresolved (compare: behind), with the warning. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-28T07:54:54Z

Test Results (shard 0)

1 files ±0 1 suites ±0 3m 16s ⏱️ +4s
348 tests ±0 348 ✅ ±0 0 💤 ±0 0 ❌ ±0
352 runs ±0 352 ✅ ±0 0 💤 ±0 0 ❌ ±0