Announce this lane's ceremony to a phone, not only to a GitHub issue

[bdelanghe]

Measured 2026-08-31: a deploy ceremony here opened, waited its full 15-minute window, and reached no phone.

infra#552 gave the seven infra ceremony lanes a push; this repo was not in that scope, so the only announcement was the notification issue the run opens — a GitHub notification, batched and routed wherever GitHub decides, against a window that can be as short as two minutes.

Two independent gaps, so fixing either alone changes nothing: the lane had no notice step, and desk's NOTIFY_WORKFLOW_REFS did not carry it. The desk half is merged (desk#64).

approve_url was a local shell variable — as it was in every infra lane before #552. The notice reads steps.ceremony.outputs.approve_url, so without the echo it would post an empty URL and report "skipped" forever.

No guard on the notice, because the ceremony above it has none: this lane has no break-glass (infra#18), so if the ceremony ran, an approval is genuinely waiting. Non-fatal on every path — the gate is the Face ID, and a notice that failed to send must not fail a deploy that is otherwise authorized.

The ratchet is the point

A test reads the workflow files and asserts every lane containing authorize/start also notifies, before the wait, with approve_url published and id-token: write reachable. Reading files rather than a list of lane names means the next ceremony lane is covered the day it is added, not the day someone remembers this test exists.

Mutation-tested, and the first pass was not evidence

Four mutations. The first run reported two "surviving" — and both survivors were my mutations being broken, not the tests being weak. The id-token: write line carries a trailing comment, so a replace string requiring a newline straight after write never matched; that check was never exercised at all.

The other miss was real: renaming the wait step made wait === -1, and the ordering check then silently skipped itself — passing while proving nothing. That is the same shape as the scaffolding-blind checks found repeatedly in this session, this time inside a test written specifically to prevent recurrence. wait === -1 is now a failure rather than a skip.

All four now go red: notice removed, approve_url dropped, id-token broken, wait step renamed.

133 tests pass.

Pairs with

desk#64 (merged) · .github#308 · .github-private#814 · front-desk-scheduler#193

Claim-issue: bounded-systems/.github#305

🤖 Generated with Claude Code

https://claude.ai/code/session_01EmJrUXmQBxc6Gsf3Lqvp4f

[bdelanghe]

Correction to this PR's body: the count is wrong.

It says the guarantee held for "nine lanes out of eleven." An audit of every workflow containing authorize/start found seventeen ceremony lanes org-wide, not eleven. Wrong in both the numerator and the denominator: before this work ten notified, and seven did not — this lane, front-desk-scheduler's lease-deploy, .github's site-deploy, and all six in .github-private.

The reasoning in the body still holds and the diff is unchanged; only the arithmetic was wrong. If anything it understated the case — an unmarked exception is worse when there are seven of them.

Worth recording how it was wrong, because it is the same defect the ratchet in this PR exists to prevent: I counted by reading the lanes I already knew about, rather than by asking the filesystem which lanes open ceremonies. A hand-kept count drifts silently, and this one had drifted by six.

The rest of the set is closed in .github#308 and .github-private#814, with desk#64 carrying all 19 allowlist entries.

---

Generated by Claude Code