Context
The v1.0.4-rc1 rollup (#728 record) used the VM 5-persona evidence + the Mac part-A handoff (100/100). release_readiness.py correctly sets split_vm_handoff_evidence and then requires a same-SHA --support-preflight-json (from qa/support_vm_preflight.py) to guard against mixing stale VM evidence with a Mac handoff. We didn't run the preflight, so native_gate's signal was PASS (handoff valid) but the gate withheld credit (evidence gap) → RRI 3.6 instead of ~4.5.
Ask
For the next RC rollup: run qa/support_vm_preflight.py --expected-sha <SHA> ... on the support VM at the same SHA, then pass --support-preflight-json <artifact> to release_readiness.py. This is a measurement-completeness step, not a product fix — it does NOT change the v1.0.4-rc1 verdict (the product gaps sat/critical/story/mech/ui_audit dominate at ~4.5/10), but it makes native_gate's credit honest + the RRI comparable across RCs. Document it in the worldos-dev VM-sweep procedure so the sweep emits the preflight artifact inline.
Context
The v1.0.4-rc1 rollup (#728 record) used the VM 5-persona evidence + the Mac part-A handoff (100/100).
release_readiness.pycorrectly setssplit_vm_handoff_evidenceand then requires a same-SHA--support-preflight-json(fromqa/support_vm_preflight.py) to guard against mixing stale VM evidence with a Mac handoff. We didn't run the preflight, so native_gate's signal was PASS (handoff valid) but the gate withheld credit (evidence gap) → RRI 3.6 instead of ~4.5.Ask
For the next RC rollup: run
qa/support_vm_preflight.py --expected-sha <SHA> ...on the support VM at the same SHA, then pass--support-preflight-json <artifact>torelease_readiness.py. This is a measurement-completeness step, not a product fix — it does NOT change the v1.0.4-rc1 verdict (the product gaps sat/critical/story/mech/ui_audit dominate at ~4.5/10), but it makes native_gate's credit honest + the RRI comparable across RCs. Document it in theworldos-devVM-sweep procedure so the sweep emits the preflight artifact inline.