Skip to content

fix: say what is applied, and build what ships - #10

Merged
rldyourmnd merged 1 commit into
mainfrom
fix/say-what-is-applied
Aug 25, 2026
Merged

fix: say what is applied, and build what ships#10
rldyourmnd merged 1 commit into
mainfrom
fix/say-what-is-applied

Conversation

@rldyourmnd

Copy link
Copy Markdown
Contributor

Two things the seven were quietly not doing, both found by running them rather
than reading them.

A restore forgot the setup it had just restored. The bytes came back exactly
-- identity equal to the slot's, drift clean -- but status then said
Setup (unnamed) about a target that was byte for byte a known setup. The name
was not missing: the slot being restored from records which setup was in
effect when it was captured, in the same read that produced the identity, and
the restore threw it away. Refusing to name a setup is right when the bytes came
from somewhere the catalog does not know; it is not right when they came from a
slot that wrote the name down.

setup_definition_digest was never written at all, by any operation. The
catalog computes it -- it is the setup's identity, since two setups with the
same bytes are the same setup whatever they are called -- provider state has the
field, and nothing connected them. Same for bundle_format, bundle_digest and
artifact_digest after a bundle arrives over the wire. All four are in the
contract's provenance fields, and all four were hardcoded None.

So Mutation now carries an Applied -- what state should record about
whatever the mutation leaves behind -- instead of a bare setup name. The catalog
path fills in the definition digest, the bundle path fills in the bundle's three
identities, and a restore adopts the identity of the slot it restored.

setup_version and setup_version_passport_digest stay null on purpose: a
local setup carries an id and a description and no version, and inventing one
would be worse than the absence. They are for setups that arrive with a passport.

SlotRecord gains setup_definition_digest without a schema bump, and a guard
proves a slot written before the field still reads. Bumping would have refused
slots that are complete, restorable captures -- trading a recoverable target for
a field that is allowed to be absent.

And the release profile now lives in the workspace it describes. lto,
codegen-units, strip and panic = "abort" existed only in the rendered
public manifests, so the tree the code is written in never built what the
releases ship: 1,521,600 bytes locally against 912,448 published, and unwinding
panics where the shipped binary aborts. The renderer reads the block now instead
of carrying its own copy, and renders it byte-identically. A local release build
is 918,424 bytes.

Both guards were observed red on the defect before they were kept.

Gate: fmt, clippy -D warnings, 239 tests. Conformance 21/21 on all seven, and
install -> select -> restore returns every one of them to the exact bytes and
now names the setup it returned to.

Two things the seven were quietly not doing, both found by running them rather
than reading them.

**A restore forgot the setup it had just restored.** The bytes came back exactly
-- identity equal to the slot's, drift clean -- but `status` then said
`Setup (unnamed)` about a target that was byte for byte a known setup. The name
was not missing: the slot being restored *from* records which setup was in
effect when it was captured, in the same read that produced the identity, and
the restore threw it away. Refusing to name a setup is right when the bytes came
from somewhere the catalog does not know; it is not right when they came from a
slot that wrote the name down.

**`setup_definition_digest` was never written at all**, by any operation. The
catalog computes it -- it *is* the setup's identity, since two setups with the
same bytes are the same setup whatever they are called -- provider state has the
field, and nothing connected them. Same for `bundle_format`, `bundle_digest` and
`artifact_digest` after a bundle arrives over the wire. All four are in the
contract's provenance fields, and all four were hardcoded `None`.

So `Mutation` now carries an `Applied` -- what state should record about
whatever the mutation leaves behind -- instead of a bare setup name. The catalog
path fills in the definition digest, the bundle path fills in the bundle's three
identities, and a restore adopts the identity of the slot it restored.

`setup_version` and `setup_version_passport_digest` stay null on purpose: a
local setup carries an id and a description and no version, and inventing one
would be worse than the absence. They are for setups that arrive with a passport.

`SlotRecord` gains `setup_definition_digest` without a schema bump, and a guard
proves a slot written before the field still reads. Bumping would have refused
slots that are complete, restorable captures -- trading a recoverable target for
a field that is allowed to be absent.

**And the release profile now lives in the workspace it describes.** `lto`,
`codegen-units`, `strip` and `panic = "abort"` existed only in the rendered
public manifests, so the tree the code is written in never built what the
releases ship: 1,521,600 bytes locally against 912,448 published, and unwinding
panics where the shipped binary aborts. The renderer reads the block now instead
of carrying its own copy, and renders it byte-identically. A local release build
is 918,424 bytes.

Both guards were observed red on the defect before they were kept.

Gate: fmt, clippy -D warnings, 239 tests. Conformance 21/21 on all seven, and
install -> select -> restore returns every one of them to the exact bytes and
now names the setup it returned to.
@rldyourmnd
rldyourmnd merged commit 5bb9a4b into main Aug 25, 2026
24 checks passed
@rldyourmnd
rldyourmnd deleted the fix/say-what-is-applied branch August 25, 2026 09:43
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