The flaw (rc3 diagnosis; affects every VM sweep)
#762 made vm-network the authoritative image_render source whenever ANY per-run /image denominator exists. But on the VM, every recorded request 404s by construction: the UI requests minted instance ids (scope=location:loc_<minted>, portrait-<char_id>), the resolver (viewer/server.py:_latest_descriptor ~450-468) exact-matches only canonical ingested keys (portrait_abdirak, class_fighter, …), zero location_* dirs are ingested (0 of 2,359), and no imagegen gateway runs on the VM. So any persona that reaches the table screen generates a non-zero denominator of guaranteed 404s → image_render is RED-by-construction on the VM lane and the mac-handoff escape can never fire.
Decision needed (architectural — pick one)
A. Wire minted→canonical at mint time: when the engine mints a location/character from canon, stamp the canonical art.scope_key on the entity; the viewer requests by scope_key with the minted id as fallback. (Matches the UI-audit "wire-up not ingest" finding; fixes the PRODUCT, not just the gate — players on any machine get more art hits.)
B. Denominator hygiene: exclude minted-scope requests that have no canonical mapping from the VM image denominator (they are unanswerable-by-design there), letting the mac-handoff probe be the source when the remaining denominator is 0.
Recommendation: A (product-true), with B as an interim if A is large. Either way add a regression test: a VM-lane-shaped run with only minted-scope 404s must not hard-fail image_render when a valid same-SHA mac handoff carries the probe.
Refs: #762, the rc3 diagnosis (scratchpad), docs/ui-audit MASTER_TRACKER ("most asset-gaps are wire-up not ingest").
The flaw (rc3 diagnosis; affects every VM sweep)
#762 made
vm-networkthe authoritative image_render source whenever ANY per-run/imagedenominator exists. But on the VM, every recorded request 404s by construction: the UI requests minted instance ids (scope=location:loc_<minted>,portrait-<char_id>), the resolver (viewer/server.py:_latest_descriptor~450-468) exact-matches only canonical ingested keys (portrait_abdirak,class_fighter, …), zerolocation_*dirs are ingested (0 of 2,359), and no imagegen gateway runs on the VM. So any persona that reaches the table screen generates a non-zero denominator of guaranteed 404s → image_render is RED-by-construction on the VM lane and the mac-handoff escape can never fire.Decision needed (architectural — pick one)
A. Wire minted→canonical at mint time: when the engine mints a location/character from canon, stamp the canonical
art.scope_keyon the entity; the viewer requests by scope_key with the minted id as fallback. (Matches the UI-audit "wire-up not ingest" finding; fixes the PRODUCT, not just the gate — players on any machine get more art hits.)B. Denominator hygiene: exclude minted-scope requests that have no canonical mapping from the VM image denominator (they are unanswerable-by-design there), letting the mac-handoff probe be the source when the remaining denominator is 0.
Recommendation: A (product-true), with B as an interim if A is large. Either way add a regression test: a VM-lane-shaped run with only minted-scope 404s must not hard-fail image_render when a valid same-SHA mac handoff carries the probe.
Refs: #762, the rc3 diagnosis (scratchpad), docs/ui-audit MASTER_TRACKER ("most asset-gaps are wire-up not ingest").