security lane: validation self-skip turns the REQUIRED check green with nothing reviewed

[kyle-sexton]

Same hole PR #387 fixed for the review lane, but in the SECURITY lane's required check: its fail-closed step gates on review-failed only, so a claude-code-action workflow-validation self-skip concludes the required check green with nothing reviewed — the exact silent-unreviewed-merge shape this program exists to eliminate.

Options and recommendation (extend fail-closed to the skip path) are recorded with full analysis in the #363 thread: #363 (comment)

Consequence of the fix to weigh: the required check goes red on every PR that edits the security caller file (validation skip fires legitimately there), making such PRs merge-blocked until the caller lands — fail-closed by design, but a policy change to merge flow.

Related

No linked issue.

[kyle-sexton]

Two additional security-lane findings from the independent verification of PR #387, recorded here so they travel with the fail-closed decision rather than getting lost in the review-lane PR:

(MEDIUM) The clear-stale step clears warnings a skip did not resolve. claude-security-review.yml's "Clear stale failure comment after successful review" step (line 1084 at current main) gates on review-failed == 'false'. A workflow-validation self-skip reports exactly that, so a skip run — which reviewed nothing — clears a prior genuine infra-failure warning from the PR, erasing the one PR-visible signal that review has not been happening. Same shape PR #387's A2 follow-up addresses in the review lane by gating on the composite's new review-ran output; whichever remediation is ratified for this lane should regate this step the same way.

(LOW) The marker copy asserts a push retries the review. The security lane's infra-failure marker copy (line 1073 at current main) states "Re-running the job, or pushing a new commit, will retry the review." The caller owns its triggers, so this is the mirror-image of the overbroad claim PR #387 corrected in the review lane: true for the canonical security caller (which keeps synchronize), false for any caller that drops it. The copy should state the condition rather than assert either way.

Both are adjacent to, not blocked by, the fail-closed decision this item tracks: the clear-stale regate depends on the same review-ran output the fail-closed fix would consume, so they land naturally in the same change.

This comment was written by an AI agent relaying independent-verifier findings from PR #387's review.

[kyle-sexton]

Resolved by PR #392 (merge 279883e), delivering the recommended option (extend fail-closed) plus both recorded findings:

• The security lane's outcome-composite pin moved to 7415d4e, so its validation self-skips now emit class=skipped-validation and are aggregator-visible.
• The fail-closed gate fires on the skip shape — identified by BOTH signals (review-ran == 'false' and review-failed != 'true', since the composite sets review-ran=false on genuine failures too); the no-verdict pass-throughs are untouched (empty outputs match neither comparison).
• The clear-stale step gates on review-ran == 'true' (the MEDIUM finding); the marker copy states the synchronize condition (the LOW finding).
• A wiring test now discovers every consuming lane dynamically and checks its consumed outputs against its own pinned composite revision — the tripwire for a gate flipped without its repoint.

Consequence, as recorded here: PRs editing the security caller go red until the caller merges — fail-closed by design. The org security-review-gate ruleset is currently enforcement: disabled, so org-level merge enforcement is unchanged until the operator enables it.

Closed by an AI agent under the operator's standing authorization for this rollout (goal directive 2026-08-08).