plan(roadmap): defer TRACE-P02 to v1.134 — v1.133 is the OCI/release arc - #341
Merged
Conversation
v1.133's scope is the OCI/release arc (OCI-P02 no_std cascade, OCI-P04 WIT namespace, REL-P01 draft-then-finalize), which is implementation-complete and waiting only on CI. TRACE-P02 (drive implemented->verified from the gate's own per-artifact result) is independent of that arc and large enough to warrant its own release rather than holding the OCI arc behind it. Deliberate scope move, logged in the artifact itself rather than done silently. No code, no status change: TRACE-P02 stays `proposed`. v1.133 scope after this: OCI-P02, OCI-P04, REL-P01. v1.134 scope after this: OCI-P03, TRACE-P02. `rivet validate` PASS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG
The push that would have triggered CI landed during the outage (Actions was in major_outage 15:22Z-00:0xZ; zero runs were created repo-wide for hours), so no run exists for this branch. Empty commit to generate a fresh synchronize event. Squash-merge drops it from main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG
avrabe
enabled auto-merge (squash)
August 7, 2026 01:29
avrabe
added a commit
that referenced
this pull request
Sep 2, 2026
…te (#342) * fix(ci): a Verify-Filter matching zero artifacts must not pass the gate The verification gate is a REQUIRED check, and it could be silenced by a one-word change to the PR body. `scripts/run-falcon-verification.py` exits 0 when its filter matches nothing — correctly, in isolation: no artifact ran, so none failed. But the gate's verdict is exactly that exit code (`steps.verify.outcome`), so a `Verify-Filter:` that matches zero artifacts turns a required safety gate green while verifying nothing. It even renders "✅ Rivet verification gate — 0/0 passed" into the sticky PR comment, so the deception is not visible to a reviewer skimming it. The PR body is attacker-controllable. The INJECTION risk was already handled (env-bound, quoted, never interpolated into run:) — but the SEMANTIC trust of the filter was not: an untrusted string decides how much verification happens, and "none" was an accepted answer. Caught empirically, not by review: `(has-tag "traceability")` reads perfectly plausible and matches 0 of the 195 sw-verification artifacts, because that tag lives on sw-reqs, not on verifications. I had put exactly that filter on #341. Fix: after the sweep, fail if the script reports `0 artifact(s) matched`. Verified locally: (has-tag "traceability") -> 0 artifacts -> guard fires (has-tag "oci") -> 1 artifact -> no false positive (has-tag "falcon") -> 156 artifacts (the default) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG * fix(ci): raise the verification-gate timeout 90 -> 150 (STOPGAP, see #350) The sweep has grown into its own ceiling. Measured across one day, same 156-artifact sweep: #340 ~63m success #344 1h30m21s FAILURE — killed at timeout-minutes: 90 #344 (earlier) cancelled #342 failed twice the same way #343 success twice Variance now exceeds headroom, so a REQUIRED check is decided by runner load rather than by whether anything is wrong. And a timeout surfaces as `fail`, indistinguishable from a real failure unless you read the duration — which already cost a diagnosis cycle. Worst of all, it was blocking the two PRs meant to improve this gate (#342 fail-open fix, #343 sweep speedup). Raising the ceiling does not weaken the gate: it is being KILLED, not failing. Landing it here because this PR already owns this file and is itself blocked by the timeout it fixes. THIS IS A STOPGAP and the third reactive bump (60 -> 90 -> 150). The trend is the real problem: 45m in July, >=90m now. #350 tracks it, and names the next measurement — the compile-vs-test split ON the runner. The sweep spans 64 crates with 29 `--release` steps, so compilation is the likely dominant cost; whole-crate -> named conversion (#343/#262) is right for traceability but, measured, will not close a 30-minute gap on its own (the non-falcon-core offenders run in 0-5s). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG * fix(ci): my zero-match guard emitted INVALID YAML — backslash continuation at column 0 Self-inflicted, and it broke the very gate the guard was meant to strengthen. The guard's error message used a backslash-continued string whose continuation lines started at COLUMN 0: echo "::error::Verify-Filter matched 0 ... — \ refusing to pass a gate that verified nothing. Fix the filter or drop the \ override to use the default." Inside a `run: |` block scalar, a line at column 0 TERMINATES the block. The whole workflow file was therefore invalid YAML from the moment I added the guard, which is almost certainly why this PR's verification gate failed twice — NOT the 90-minute timeout I attributed it to in the previous commit. `python3 -c "yaml.safe_load(...)"` reports: ScannerError: while scanning a simple key, line 234 ... could not find expected ':' Fixed by keeping the message on one line, with a comment saying why, so the next person does not "tidy" it back into a continuation. Lesson worth the comment: I verified this file for the thing I was thinking about (no `${{ }}` inside `run:` — which I DID check, with a parser) and not for whether it still parsed at all. Both checks now run. YAML parses: OK, timeout-minutes=150 ${{ }} inside run: blocks: none Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
What
Moves
SWREQ-FALCON-TRACE-P02fromfalcon-v1.133.0tofalcon-v1.134.0.v1.133 scope after this: OCI-P02, OCI-P04, REL-P01
v1.134 scope after this: OCI-P03, TRACE-P02
Why
v1.133 is the OCI/release arc — the no_std cascade conversion, the WIT namespace
rename, and draft-then-finalize release ordering. That arc is
implementation-complete and waiting only on CI.
TRACE-P02 (drive
implemented→verifiedfrom the verification gate’s ownper-artifact result) is independent of it, and is a large sweep in its own right:
of the 140 sw-reqs TRACE-P01 backfilled, 137 link only to verifiers that are
themselves unpromoted. Holding the OCI arc behind that sweep buys nothing.
This is a deliberate scope move, logged in the artifact itself rather than
done silently — per the release-planning rule that deferral is a scope decision,
surfaced, not quiet.
Not in this PR
No code. No status change — TRACE-P02 stays
proposed. This is only therelease:field and its rationale, so the two-commit rule is not in play.Evidence
rivet validate→ PASS (352 warnings, all pre-existing)the complete set
Correction
This PR originally carried
Verify-Filter: (has-tag "traceability"). That filtermatches 0 of 195 sw-verification artifacts —
traceabilityis a tag onsw-reqs, not on verifications — so it would have passed the gate vacuously
(
0/0 passed, rendered with a ✅).The override is removed; this PR now runs the default
(has-tag "falcon")sweep. The underlying fail-open is fixed separately in #342.
🤖 Generated with Claude Code
https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG