Skip to content

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

Open
avrabe wants to merge 3 commits into
mainfrom
verify/v1133-promote-verified
Open

verify(v1.133): record the release evidence — and why NOTHING is promoted yet#347
avrabe wants to merge 3 commits into
mainfrom
verify/v1133-promote-verified

Conversation

@avrabe

@avrabe avrabe commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Verify-Filter: (has-tag "oci")

Scoped: the full 156-artifact sweep is now killed at the job's own
timeout-minutes: 90 (this PR died at 1h30m23s, #344 at 1h30m21s). This PR
only edits artifact descriptions — no steps change — and (has-tag "oci")
matches 4 artifacts including all three touched here, so the scoped sweep
exercises exactly what changed. Timeout raise tracked in #350 / fixed in #342.

falcon-v1.133.0 shipped and every falsification criterion in the tag passed. This records that evidence against the three verification artifacts.

It promotes nothing. Each requirement’s own verification-criteria are broader than "the release worked", and promoting on the evidence I happen to have rather than the evidence the requirement asked for is exactly the failure this process exists to prevent.

What the release proved

Measured on the published artifacts, not the workflow’s word:

check result
header 0061736d0d000100 (component, not core module) 6/6
memory.grow 0
wasi:* imports 0
embedded WIT namespace pulseengine:falcon-cascade 6/6
legacy falcon:cascade 0
OCI annotations 9 each, real descriptions

cosign verify → subject release.yml@refs/tags/falcon-v1.133.0, githubWorkflowSha 7809e93d — the exact commit the pre-tag gate was green on. That closes the loop between "CI was green" and "this is what people pull".

REL-P01 observed live: 18:03 draft → 18:38 draft with 12 assets attached18:53 published with 20.

The 18:38 sample is the load-bearing one: twelve assets attached and still invisible to consumers. That is precisely the v1.131.0 window, now unreachable rather than merely unlikely.

Why each artifact stays implemented

OCI-P02 — criteria carry a kill-criterion owned by gale/meld: with every stage converted, meld fuse --memory shared --address-rebase must accept the fused cascade. Not run. Zero memory.grow is necessary for that fuse, not sufficient — it was the known blocker (gale#89, meld#299), not a proof. Promoting on bytes alone would assert the very outcome the kill-criterion exists to test.

OCI-P04 — (a) published + anonymously pullable → met; (b) wasm.directory registered with [[interface]] entries → 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 registry/pulseengine.toml follow-up for the nested paths.

REL-P01 — criteria say verification is by "DELIBERATE FAILURE INJECTION, not by reasoning": (a) no published release after a broken component build, (b) the guard still blocks, (c) an unbroken run publishes correctly. This release discharges (c) only.

The distinction this PR is making

The artifacts are verified. The requirements are not. Those are different claims, and this release only supports the first.

Evidence

  • rivet validate PASS, exit 0 — v0.19.0, the version the gate pins
  • gate on these artifacts: 7 steps PASS, 0 FAIL
  • no status changes; no code

🤖 Generated with Claude Code

https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG

…oted yet

falcon-v1.133.0 shipped and every falsification criterion in the tag passed.
This records that evidence against the three verification artifacts.

It promotes NOTHING. Each requirement's own verification-criteria are broader
than "the release worked", and I am not going to promote on the evidence I
happen to have rather than the evidence the requirement asked for.

WHAT THE RELEASE PROVED (measured on the published artifacts, not the workflow):

  all six components, pulled from ghcr.io/pulseengine/falcon/<stage>:1.133.0
    header 0061736d0d000100 (component, not core module)   6/6
    memory.grow                                            0
    wasi:* imports                                         0
    embedded WIT namespace  pulseengine:falcon-cascade     6/6
    legacy `falcon:cascade`                                0
    OCI annotations                                        9 each, real
  cosign verify: subject release.yml@refs/tags/falcon-v1.133.0,
    githubWorkflowSha 7809e93 — the exact commit the pre-tag gate was green on
  REL-P01 live: 18:03 draft -> 18:38 draft WITH 12 ASSETS -> 18:53 published, 20

The 18:38 sample is the one that matters: 12 assets attached and still
invisible. That is the falcon-v1.131.0 failure window, now unreachable.

WHY EACH STAYS `implemented`:

  OCI-P02  criteria carry a KILL-CRITERION owned by gale/meld — `meld fuse
           --memory shared --address-rebase` must ACCEPT the fused cascade now
           that every stage is converted. Not run. Zero memory.grow is
           NECESSARY for that fuse, not SUFFICIENT: it was the known blocker
           (gale#89, meld#299), not a proof. Promoting on bytes alone would
           assert the very outcome the kill-criterion exists to test.

  OCI-P04  criteria are (a) published + anonymously pullable — MET; (b)
           wasm.directory registered with [[interface]] entries — 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 registry/pulseengine.toml
           follow-up for the nested paths.

  REL-P01  criteria say verification is by "DELIBERATE FAILURE INJECTION, not
           by reasoning": (a) no published release after a broken component
           build, (b) the guard still blocks, (c) an unbroken run publishes
           correctly. This release discharges (c) ONLY. The failure injection
           is deliberately deferred to a scratch tag — happy path proven on the
           real train first.

So the honest state is: the ARTIFACTS are verified, the REQUIREMENTS are not.
Those are different claims and this release only supports the first.

rivet validate (v0.19.0, the version the gate pins): PASS, exit 0.
Gate on these artifacts: 7 steps PASS, 0 FAIL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG
@avrabe
avrabe enabled auto-merge (squash) August 7, 2026 19:03
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