verify(v1.133): record the release evidence — and why NOTHING is promoted yet

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/<stage>: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

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 <stage>.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/<owner>/falcon/<name> 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

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