Repository navigation
docs: record why the vector capability cannot be composed yet - #5
Merged
Merged
Conversation
usd-vector-plugins 0.1.0 is pinned as an eighth candidate artifact by both its OpenStrata archive digest and its OCI manifest digest, provides usd-fileformat:geojson, and installs the probe that runs as the new required vector acceptance check. The recomposed target resolves runtime sha256:562444f4..., and tools/accept.py passes all six checks against it. The three concerns the roadmap raised are closed by facts rather than by work: the product is published to ghcr.io, its strata.lock records the same runtime digest as usd-pointcloud-plugins and usd-http-resolver, which this composition already resolves, and it now installs its probe under share/usd-vector-plugins/probes/ like the other products, so the runner still uses only installed probes. Composing a capability without releasing it exposed two assumptions that only held while one composition per target had ever existed. Every evidence record was required to match the current lock, so advancing the composition invalidated v0.1.0's record. Matching the lock is a release property, so it moves to --release, and the default run instead checks each record against the contract it was written under: the new optional required_checks field, or the v1 baseline for a record that predates it. A historical record stays valid, unedited, when a later release adds a check. Runtime metadata took the newest evidence for the target unconditionally, which after recomposing would pair the new composition identity with v0.1.0's published artifact identity and publish a runtime that no release carried. Evidence is now selected by runtime digest, and a composition with no accepted record is reported as pending while its committed document is left describing the release it still names and checked against that record. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Composing usd-vector-plugins 0.1.0 is withdrawn. The published product was not built against the runtime this composition pins, so accepting it would break the rule the repository exists to enforce: a capability enters the composition only when it was verified against the runtime it will be loaded into. Seven of the eight components record runtime identity sha256:3a4e3993..., which is the identity of the pinned OpenUSD artifact sha256:51c19df2... itself. The vector product records sha256:ce996432..., which belongs to no artifact this composition knows. Its installed bundles/vector-geojson/validation/environment.json names a hand-placed C:/usd/openusd-26.08-cy2026 tree where every other product names the managed runtime store. The probe passing here shows only that the two were ABI-compatible on one machine, which is not evidence a consumer can use. An earlier revision of this branch claimed the runtime match was established because three repositories record the same digest in their strata.lock. That was wrong: it read the provider's working tree instead of the artifact that was published, and those disagree. The claim is removed rather than corrected in place. The provider's own configuration is already right -- openstrata.ci.yaml and its release workflow pin an artifact whose identity is sha256:3a4e3993... -- so this is a release-process defect on that side and needs no source change there. The roadmap now records the blocker, what was verified and closed (the product is published and installs its probe correctly), and what this repository does once a conforming product exists, including the two tooling assumptions that adding any capability will break. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
snkmcb
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Records why
usd-vector-plugins0.1.0 cannot be composed. Net diff isdocs/roadmap/current.mdonly.The branch first composed the capability, then withdrew it. Both commits are kept because the second one's reason is the first one's result.
What was found
The composition records, for every component, the runtime identity it was built against. Seven of eight agree with the pinned OpenUSD artifact
sha256:51c19df2..., whose own identity issha256:3a4e3993.... The vector product recordssha256:ce996432..., which belongs to no artifact this composition knows.Its bundle says where that came from. The installed
bundles/vector-geojson/validation/environment.jsonrecords:while every other composed product records the managed runtime store:
So the published product was built against a hand-placed OpenUSD tree rather than a digest-pinned runtime. Composing it would break the rule this repository exists to enforce. The plugin does load and its probe does pass here — but that only says the ad-hoc tree and the pinned runtime were ABI-compatible on one machine, which is not evidence a consumer can use.
Correction
The first commit claimed the runtime match was established because
usd-vector-plugins,usd-pointcloud-pluginsandusd-http-resolverall recordsha256:3a4e3993...in theirstrata.lock. That was wrong. It read the provider's working tree rather than the artifact that was published, and for this provider the two disagree — the lock says3a4e3993, the published artifact was built asce996432. The claim is removed rather than corrected in place.Credit where due: this was caught by review, not by the tooling.
What is closed, and needs no further work
The other two concerns P0 raised turned out to be already resolved:
oci://ghcr.io/animu-sphere/usd-vector-plugins@sha256:acfbe867.... A pull verified the OCI digest, archive digestsha256:153c20f3..., per-file digests, artifact kind, and SBOM.share/usd-vector-plugins/probes/packaged_probe.py, taking--prefixlike the point-cloud and raster probes, so the runner keeps using only installed probes.The provider's own configuration is also already correct:
openstrata.ci.yamland its release workflow pin runtime artifactsha256:ebb0c7da..., whose identity issha256:3a4e3993...— the same runtime the composition pins, by a different archive. The published artifact simply was not produced by that path. This is a release-process defect on that side, and no source change is needed there.Also recorded: what adding any capability will break
The withdrawn attempt surfaced two assumptions that hold only while one composition per target has ever existed. Both are now written into P0 so the next attempt does not rediscover them:
--release, and a record needs a way to state the contract it was written under so it stays valid when the required set grows.tools/runtime_metadata.pytakes the newest evidence for the target unconditionally. After recomposing, that pairs the new composition identity with v0.1.0's published artifact identity and publishes a runtime identity no release ever carried. Evidence has to be selected by runtime digest.Working implementations of both existed in
4959cbband went out with the revert. A code review of that commit also found four defects in them, so they are recorded as requirements rather than carried forward as code.Next
A requirements note for the provider covers R1 build against the pinned runtime, R2 publish as 0.2.0 since 0.1.0 is taken, R3 keep the installed probe, R4 report a feature count alongside the refusals, R5 keep SBOM and provenance. This repository composes once a conforming product is published.
🤖 Generated with Claude Code