Skip to content

Produce the V4.1 runtime image as a fleet-converge mode, and key its PRODUCED digest against the candidate - #12008

Merged
briansrls merged 1 commit into
mainfrom
session/royal-ant-447
Sep 21, 2026
Merged

briansrls merged 1 commit into
mainfrom
session/royal-ant-447

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

What this is

docs/plans/dsv41-cut-d-redesign.md D1: the authorization for the V4.1 experiment names the PRODUCED runtime image digest, and candidate identity is not authorization. gunbc.spark.v41_runtime_candidate keys the runtime axis today from a recipe, three FlashInfer wheels and the two storage-backed Engram patches — and nothing has ever produced the image. It could not: vllm_runtime_image_build_ci_wet needs the Spark administrator credential, which only the fleet job materializes, and gunbc.spark.v41_source_patch_converge's own frontier row named the missing sibling entry by name.

This lands that entry, as a mode, and the PRODUCED standing it feeds.

1 — the mode

spark_v41_runtime_image_build, beside spark_runtime_image_probe in the same dispatch-only fleet job. Four legs, each a precondition of the next:

  1. verify the kernel wheels against the digests the candidate keys, before the build — an hours-long compile is an expensive place to learn that upstream re-published a wheel. The strength of this leg is stated at what it is (upstream drift) and not at what its name suggests: upstream's Dockerfile pip-installs flashinfer during the build, so these verified files are not, by this leg alone, the bytes the image carries. The binding readback is a declared frontier beside it, not an unstated gap.
  2. converge the patched source and build from it — converge_vllm_runtime_image_with_patches, which digests each declared patch on the host and refuses on mismatch. This module chooses neither the revision nor the population.
  3. read the produced digest back from inside the image through the probe route (v41_probe_image_in_place, factored out of the published probe: the pull is the published entry's precondition, not the question's).
  4. admit the produced digest against the candidate.

Target is SPARK_CONVERGE_TARGET against the administrator roster; observe-only refuses; the host claim is the build's own (vllm_build_host_effect_term, 3 h, source-directory residue).

2 — PRODUCED is a third grain

what it says where
KEYED what would be built — recipe, wheels, patches. No bytes. v41_runtime_candidate
PRODUCED bytes that exist on a host whose build key recomputes from the candidate's own recipe over the tree the build observed new, v41_runtime_realized
REALIZED an OCI-identified image joined to a rank-local row store — strictly more v41_runtime_realized (already stood)

Produced does not mint realized: a never-pushed image has no manifest digest, and filling that field with the config digest would be two content addresses under one name. Produced mints no key of its own either — its whole content is the correspondence, so there is nothing new to hash. The join to REALIZED is a declared frontier (publication).

3 — the discriminating RED

A recomputation, not a comparison of two transcribed hashes: take the candidate's recipe, re-derive the key that observed tree would have to produce, require the build's key and tag to be exactly those. Five witnesses, all passing locally (claim_batch):

  • an_image_built_from_this_candidates_recipe_and_tree_is_produced — the positive control
  • a_produced_image_keyed_from_another_recipe_refuses — a real key (GLM 5.3 SM121 over the same tree), not a malformed value
  • a_produced_image_built_from_another_revision_refuses
  • a_produced_image_wearing_another_tag_refuses
  • an_image_adopted_under_the_expected_tag_is_not_produced — the one a key comparison can never catch, since an adopted image carries the right key by construction

4 — the step budget, derived

A cold build of this image took ~75 min; the 60 min serving budget cuts it off mid-compile — the exact reason vllm_runtime_image_build's dissolve-on gave for the entry having no mode. The new budget is vllm_build_host_effect_term converted to minutes: a step allowed to outlive the claim that fences its host would be running in precisely the state that term exists to make visible. Job backstop moves 115 → 295, under the 360 ceiling.

5 — one preamble, not two

Reaching a Spark as the administrator is five facts in a fixed order; a second entry would have copied all of them. with_spark_build_host is that fold and the vanilla entry now consumes it. It hands back text and a verdict rather than the caller's own type because the compiler refuses a generic effectful declaration by name (carries both type parameters and a uses row); that refusal is quoted and its restoring capability declared as the trigger.

Evidence

  • whole-corpus regen (generated_artifact_gate main_wet) exits 0 and rewrites only .github/workflows/fleet-converge.yml
  • the five witnesses PASS under claim_batch

Not dispatched

No fleet dispatch has been made. The mode is the deliverable; the first build needs the operator's go, which I am asking for separately.

🤖 Generated with Claude Code

…PRODUCED digest against the candidate

docs/plans/dsv41-cut-d-redesign.md D1 states that the authorization for the V4.1
experiment names "the PRODUCED runtime image digest", and that candidate identity
is not authorization. gunbc.spark.v41_runtime_candidate keys that runtime today
from a recipe, three FlashInfer wheels and two Engram patches; nothing has ever
turned that specification into bytes, and nothing could -- the build entry needed
the Spark administrator credential, which only the fleet job materializes, and
gunbc.spark.v41_source_patch_converge's own frontier row named the missing sibling
entry by name.

THE MODE. spark_v41_runtime_image_build, beside spark_runtime_image_probe in the
same dispatch-only job: verify the candidate's three kernel wheels against the
digests the candidate keys, converge the patched source tree, build from it, read
the produced configuration digest back from INSIDE the image through the probe
route, and admit that digest against the candidate. It is a mode and not a job, so
it costs nothing on a push and adds no standing claim on a runner.

THE PRODUCED ARM IS A THIRD GRAIN, and collapsing it into either neighbour loses a
distinction. KEYED is what would be built. PRODUCED is bytes that exist on a host
whose build key RECOMPUTES from the candidate's own recipe over the tree the build
observed. REALIZED, which already stood in gunbc.spark.v41_runtime_realized, is
strictly more: an OCI-identified image joined to a rank-local row store. Produced
does not mint realized, because a never-pushed image has no manifest digest and
filling that field with the config digest would be two content addresses under one
name. Produced mints no key of its own either: its whole content is the
correspondence, so there is nothing new to hash.

THE DISCRIMINATING RED is a recomputation, not a comparison of two transcribed
hashes. Five witnesses: the faithful record is produced, and an image keyed from
another recipe, built from another revision, wearing another tag, or ADOPTED under
the expected tag each refuses -- the last being the one a key comparison can never
catch, since an adopted image carries the right key by construction.

THE STEP BUDGET IS DERIVED. A cold build of this image took about seventy-five
minutes, which the sixty-minute serving budget cuts off mid-compile -- the exact
reason the build entry had no mode. The new budget is vllm_build_host_effect_term,
the term the build's own host claim is admitted for, converted to minutes: a step
outliving the claim that fences its host is the state that term exists to make
visible.

ONE PREAMBLE, NOT TWO. Reaching a Spark as the administrator is five facts in a
fixed order and a second entry would have copied all of them, so with_spark_build_host
is that fold and the vanilla entry now consumes it. It hands back text and a verdict
rather than the caller's own type because the compiler refuses a generic effectful
declaration by name; the trigger that restores the general shape is declared beside it.

NOTHING HAS BEEN DISPATCHED. The mode is the deliverable; the first build needs the
operator's go.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@briansrls
briansrls added this pull request to the merge queue Sep 21, 2026
Merged via the queue into main with commit b1f83a3 Sep 21, 2026
4 checks passed
@briansrls
briansrls deleted the session/royal-ant-447 branch September 21, 2026 21:38
gunbai-bot Bot pushed a commit that referenced this pull request Sep 21, 2026
#12008 added SparkV41RuntimeImageBuild while this branch added
MicrovmNetworkApply, so both conflicts are the same collision seen twice.

dag/gunbc/fleet/fleet_converge_workflow.dag -- the modes list and the `mode`
dispatch description are each ONE long line, so two lanes appending to them
conflict on the whole line rather than on what either added. Resolved by
UNION in both places: main's line taken, this branch's addition inserted into
it, then asserted that both survive. MicrovmNetworkApply and
SparkV41RuntimeImageBuild now sit at 7 sites each -- symmetric, which is what
a fully wired mode looks like in that module.

.github/workflows/fleet-converge.yml -- the generated-artifact merge driver
REFUSED rather than resolving, left the path unmerged with the ours side
verbatim and no conflict markers, and printed its repair route. That refusal
is the point of the driver: both sides changed a projection since the merge
base, so neither side's bytes are the projection of the MERGED authorities,
and taking either side drops the other lane's authority-derived content with
nothing to say so. So the authority was resolved first and the projection
regenerated from the merged result. Verified the regenerated file carries
BOTH modes, in the dispatchable `options` list -- a file carrying only this
branch's mode would have read as fixed while dropping #12008's.

Regenerated with main_wet_one on that one path rather than main_wet, having
first checked it is complete here: gunbc.fleet_converge_workflow feeds exactly
one artifact (FleetConvergeYamlArtifact), and main touched no rung_drop or
recurring_failure_mode rows, so docs/design-rung-drops.md carries only this
branch's changes and needs no regeneration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gunbai-bot Bot pushed a commit that referenced this pull request Sep 21, 2026
…t_host_held_by_subject

The predicate 'is this host held by <subject>' is a host-commitment fact, and a second consumer (spark_v41_runtime_image_build, #12008 lane) is about to need it, so it lands in host_commitment (admit_host_held_by_subject, with admit_host_held_by_subject_among taking the held set as a supplied value) before it has two consumers. spark_v41_checkpoint_materialize consumes it; its local v41_group_a_admission is deleted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gunbai-bot Bot pushed a commit that referenced this pull request Sep 21, 2026
…would have been wrong

#11935 consolidated custody and REMOVED MicrovmControllerAppKeyConverge,
replacing it with HostCredentialCustodyConverge. On the same single-line
modes declaration this branch adds MicrovmNetworkApply to.

THE TRAP, recorded because the two previous conflicts on this exact line were
resolved by union and this one must not be. A token diff of the two sides
reports MicrovmControllerAppKeyConverge as "only ours" -- which reads
identically to main simply not having it yet. It is not: origin/main carries
0 occurrences of it and 7 of HostCredentialCustodyConverge. Unioning the two
sides would have RESURRECTED a mode another lane had just deleted, inside a
diff whose visible story is "adds one microVM mode".

So the resolution is not union: main's line taken wholesale, only
MicrovmNetworkApply inserted, and four conditions asserted rather than
eyeballed -- this branch's mode present, #12008's SparkV41RuntimeImageBuild
present, #11935's HostCredentialCustodyConverge present, and
MicrovmControllerAppKeyConverge ABSENT. Confirmed no dangling reference to
the deleted mode survives anywhere under dag/.

"Both sides appended" and "one side appended, the other deleted" produce an
IDENTICAL-LOOKING conflict on a single-line declaration, and only the second
punishes a union. That declaration is a growth surface every lane collides
on: three conflicts on it in one session.

The projection was regenerated from the merged authority and verified to
carry all three live modes and none of the deleted one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant