Omniweft · Engineering note
Omniweft explains why an asset remains stored
A read-only inspector lists retention reasons and predicts collection at an expected catalog revision. Shared bytes and distinct provenance remain separate.
Source: https://louijiecompo.com/updates/omniweft-retention-inspector/
Explain retention at one catalog revision
- Inspect roots. List every explicit current and history retention reason at the expected revision.
- Separate identity from bytes. Two provenance-distinct manifests can retain the same content-addressed blob.
- Predict collection. Return sorted removable manifests and blobs. A stale revision rejects without a report or mutation.
Merged PR #30 implements the bounded FP-008 asset-retention inspector. It returns sorted current and history root reasons, shared-blob retainers and exact collection candidates at the expected Catalog revision. Stale revisions reject without a report or mutation.
The seed-7 CPU fixture uses two provenance-distinct assets sharing one blob and an independent third asset. Dropping one manifest can leave shared bytes retained by another. Prediction is checked against ordinary collection in a fresh private Catalog; detached-report edits preserve the original state.
Inspection grants no new authority and does not infer World or undo references. It adds no durable store, remote endpoint, renderer or physics behavior. The example retains historical draft wording; the GitHub merge record establishes integration. Other adopted feature proposals remain separate from implemented capability.
Explore the topic
Follow the evidence
Read source evidence ↗ (opens in a new tab)
Related reading
- Why Is This Asset Still Stored?
- Retrying AI Workers Without Duplicating Actions
- From Python Agent to Vulkan Frame: Designing a Bounded Control Path
Follow writing and engineering notes
Add this feed to your RSS reader to follow new articles and engineering notes. No signup or tracking on this site.
Follow via RSS