diff --git a/artifacts/verification/FV-FALCON-OCI-002.yaml b/artifacts/verification/FV-FALCON-OCI-002.yaml index be01014..cfd05ba 100644 --- a/artifacts/verification/FV-FALCON-OCI-002.yaml +++ b/artifacts/verification/FV-FALCON-OCI-002.yaml @@ -38,10 +38,43 @@ artifacts: published component. That is checked per release against the actual published blobs, and is recorded in FV-FALCON-OCI-001. - SCOPE (honest): (a) proves the SOURCE is uniformly converted; it does not - prove the emitted binary is WASI-free — a dependency could reintroduce - std transitively. Only (b) proves that, and (b) is bench-only here. The - per-release blob inspection is what closes it. + (b) IS NOW DISCHARGED for falcon-v1.133.0. All six published components + were pulled from the registry and inspected as BYTES — not as manifest + metadata, which cannot be trusted here (the OCI config.mediaType reads + "component" regardless of the payload; that is how falcon-rate:1.129.0 + shipped as a core module past a green check). + + stage first 8 bytes verdict memory.grow wasi:* + flight 0061736d0d000100 component 0 0 + iekf 0061736d0d000100 component 0 0 + position 0061736d0d000100 component 0 0 + attitude 0061736d0d000100 component 0 0 + rate 0061736d0d000100 component 0 0 + mixer 0061736d0d000100 component 0 0 + + Pulled from the NESTED paths (ghcr.io/pulseengine/falcon/:1.133.0), + so that migration is evidenced by the same check. Header 0061736d0d000100 + is a component; 0061736d01000000 would be a raw core module. + + This is the first release where the WHOLE cascade satisfies it: v1.129 had + one converted stage and five that still linked std. + + SCOPE (honest): verified for the six components published at 1.133.0. It + is not a standing guarantee — a future dependency could reintroduce std + transitively, which (a) would not catch. The per-release blob inspection + is what keeps it true, and must be repeated per release. + + REMAINING, AND WHY THIS ARTIFACT IS NOT `verified`: SWREQ-FALCON-OCI-P02 + carries a KILL-CRITERION this evidence does not touch — "with all stages + converted, `meld fuse --memory shared --address-rebase` accepts the fused + cascade; if it still rejects, that is a real finding and this requirement + is not met". That check is owned by gale/meld and has NOT been run against + the v1.133.0 components. + + Zero `memory.grow` is necessary for that fuse to succeed but is not + sufficient — it was the known blocker (gale#89, meld#299), not a proof. + Promoting on the byte-level evidence alone would assert the outcome the + kill-criterion exists to test. Stays `implemented` until the fuse is run. tags: [verification, falcon, oci, wasm, no-std, embedded, component-model, v1.133] fields: method: test diff --git a/artifacts/verification/FV-FALCON-OCI-003.yaml b/artifacts/verification/FV-FALCON-OCI-003.yaml index ddd44a9..82cc9ad 100644 --- a/artifacts/verification/FV-FALCON-OCI-003.yaml +++ b/artifacts/verification/FV-FALCON-OCI-003.yaml @@ -29,10 +29,44 @@ artifacts: Measured at the time this landed: 0 remaining references across the whole wit/ tree. - SCOPE (honest): this verifies the WIT SOURCE. That the published OCI - manifests and the wasm.directory listing agree with it is covered by the - OCI distribution evidence (FV-FALCON-OCI-001) and re-checked per release; - this artifact does not claim it. + ARTIFACT-LEVEL CONFIRMATION (falcon-v1.133.0). The steps above check the + SOURCE. The published binaries were also inspected, which is the stronger + claim — the rename is only real if it survives into what consumers pull: + + $ wasm-tools component wit .wasm # pulled from ghcr.io + rate -> pulseengine:falcon-cascade + mixer -> pulseengine:falcon-cascade + iekf -> pulseengine:falcon-cascade + legacy `falcon:cascade` across ALL SIX published components -> 0 + + So the embedded interface namespace agrees with the registry namespace, + which is the whole point of the requirement: wasm.directory indexes + components by registry namespace but interfaces by WIT package namespace, + and a mismatch splits our surface across two namespaces. + + SCOPE (honest): the WIT source and the published component bytes agree. + + REMAINING, AND WHY THIS ARTIFACT IS NOT `verified`: SWREQ-FALCON-OCI-P04's + criteria are broader than the source and the bytes. Of the three: + + (a) published to ghcr.io//falcon/ on a tagged release and + anonymously pullable -> MET + (all six pulled anonymously from the nested paths at 1.133.0) + (b) the namespace registered on wasm.directory with `[[interface]]` + entries, and the namespace page no longer reporting "0 packages" + -> NOT MET + (c) a component page's export links resolve into an OWNED namespace, + "verified by fetching the live pages, not by inspecting the + workflow" -> NOT MET + + (b) and (c) need the follow-up PR to registry/pulseengine.toml moving the + entries to the nested repository paths, and then a fetch of the live + pages. Until then the requirement's own stated method — checking the + rendered pages — has not been carried out, so this stays `implemented`. + + Note the criteria name the `falcon` namespace; OCI-P04 is precisely the + change that unified it to `pulseengine`, so the criteria wording should be + updated to match when (b) is done. tags: [verification, falcon, oci, wit, namespace, wasm-directory, v1.133] fields: method: test diff --git a/artifacts/verification/FV-FALCON-REL-001.yaml b/artifacts/verification/FV-FALCON-REL-001.yaml index 1748e8e..e0d2ab5 100644 --- a/artifacts/verification/FV-FALCON-REL-001.yaml +++ b/artifacts/verification/FV-FALCON-REL-001.yaml @@ -35,11 +35,30 @@ artifacts: happy path is proven before the failure path is provoked on the real release train. - SCOPE (honest): (a) is verified mechanically on every PR. (b) is NOT - verified at the time this artifact lands — it cannot be, since it requires - a tagged release. This artifact stays `implemented` until falcon-v1.133.0 - has run and its draft->published transition is recorded; only then does it - become `verified`. This is the same two-tier split as FV-FALCON-OCI-001. + (b) IS NOW DISCHARGED — observed live on falcon-v1.133.0, run + 31205220348. The transition was watched, not inferred: + + 18:03:40Z release created isDraft=true + 18:38:21Z 5 platform builds + Create isDraft=true, 12 assets + GitHub Release all `success`, + flight-component still running + 18:53:00Z guard passed, draft flipped isDraft=false, 20 assets + + The 18:38 sample is the load-bearing one. The release had TWELVE ASSETS + ALREADY ATTACHED and was still invisible to consumers. That window is + exactly the falcon-v1.131.0 failure: under the previous ordering this + release would have been PUBLISHED and public at that moment, carrying its + platform binaries and missing every wasm component. A consumer pulling it + then would have received half a release. With draft-then-finalize that + state is unreachable rather than merely unlikely. + + SCOPE (honest): what is discharged is the HAPPY PATH — the guard permits + publication once everything is present. The FAILURE path (force an upload + to fail, confirm the release STAYS a draft) is NOT verified here and is + deliberately deferred to a scratch tag, so the happy path is proven on the + real release train before the failure path is provoked on it. Until that + runs, this artifact evidences "publishes only after the guard", not + "provably never publishes when the guard fails". tags: [verification, falcon, release, oci, ordering, v1.133] fields: method: test