Skip to content

fix(ci): let the complexity delta account for itself — the receipt could not see it - #31

Merged
wshallwshall merged 1 commit into
mainfrom
claude/complexity-delta-liveness
Jul 29, 2026
Merged

fix(ci): let the complexity delta account for itself — the receipt could not see it#31
wshallwshall merged 1 commit into
mainfrom
claude/complexity-delta-liveness

Conversation

@wshallwshall

Copy link
Copy Markdown
Collaborator

The liveness control shipped in #25 had this
workflow's own failure mode inside it.

The complexity receipt proved liveness with ruff --show-files, which counts the files ruff would
enumerate — true whether or not the delta step ran. So a delta that bailed on an unresolvable merge
base emitted a ::notice, exited 0, and left a green measured receipt behind. On a PR the delta is
the point of that job, and it could go quiet while the gate reported success.

The fix

The delta records its own outcome to c901-delta.env — written last on the success path, so its
absence proves the step died, and written explicitly on the bail path, so a skip is distinguishable
from a crash. The receipt rules on it:

Situation Verdict
PR + delta ran measured — evidence names the merge base and base/head finding counts
PR + marker missing failed — "did not complete"
PR + delta bailed failed — carries the recorded reason
cron / dispatch measured — "the PR delta does not apply on <event>"

That last row is deliberate: on a non-PR event the delta legitimately doesn't run and the whole-repo
triage is the measurement. Failing there would fire on good news, and a check that fires on good news
gets muted — worse than not having it.

Two bugs found by executing the receipt shell, not reading it

  1. The reason was silently discarded. The receipt sources the marker, and the reason was written
    unquoted — bash parsed a value containing spaces as a command and left the variable unset. The
    failure reported "no reason recorded", throwing away the only useful diagnostic on the exact path
    that exists to provide one.
  2. My own new test was vacuous. It asserted the marker appeared ≥2 times in the step, which the
    bail path satisfies alone (it writes two lines) — so deleting the success-path marker passed.
    Caught by mutating the workflow and watching the assertion fail to go red. It now partitions the
    step at the c901_delta.py call and requires a marker on both sides.

Verification

All four receipt paths executed against the shell extracted from the YAML; all four negative probes on
the new assertions go red. 55 quality tests pass · ruff check clean · zizmor real exit 0 · YAML valid.

Advisory-only as before: no write scope on any job, no new required check.

…uld not see it

The liveness control shipped in #25 had this workflow's own failure mode inside it. The complexity
receipt proved liveness with `ruff --show-files`, which counts the files ruff would enumerate — true
whether or not the DELTA step ran. So a delta that bailed on an unresolvable merge base emitted a
`::notice`, exited 0, and left a green `measured` receipt behind. On a PR the delta IS the point of
that job, and it could go quiet while the gate reported success.

The delta now records its own outcome to c901-delta.env, written LAST on the success path so its
absence proves the step died, and written explicitly on the merge-base bail path so a skip is
distinguishable from a crash. The receipt rules on it:

  PR + delta ran        -> measured, evidence names the merge base and the base/head finding counts
  PR + marker missing   -> failed, "did not complete"
  PR + delta bailed     -> failed, carrying the recorded reason
  cron / dispatch       -> measured, "the PR delta does not apply on <event>"

That last row is deliberate. On a non-PR event the delta legitimately does not run and the whole-repo
triage IS the measurement; failing there would fire on good news, and a check that fires on good news
gets muted -- which would leave us worse off than before.

TWO BUGS FOUND BY EXECUTING THE RECEIPT SHELL, not by reading it:

* The reason was silently discarded. The receipt SOURCES the marker, and the reason was written
  unquoted, so bash parsed a value containing spaces as a command and left the variable unset. The
  failure reported "no reason recorded" -- throwing away the only useful diagnostic, on the exact
  path that exists to provide one. Now single-quoted, and asserted.
* My own new test was vacuous. It asserted the marker appeared at least twice in the step, which the
  bail path satisfies on its own (it writes two lines), so deleting the SUCCESS-path marker passed.
  Caught by mutating the workflow and watching the assertion fail to go red. It now partitions the
  step at the c901_delta.py call and requires a marker on both sides.

All four receipt paths were executed against the extracted shell; all four negative probes on the new
assertions now go red.
@wshallwshall
wshallwshall enabled auto-merge (squash) July 28, 2026 23:47
@wshallwshall
wshallwshall merged commit c4d8cad into main Jul 29, 2026
33 checks passed
@wshallwshall
wshallwshall deleted the claude/complexity-delta-liveness branch July 29, 2026 00:06
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