Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.
1
In plain terms. The fix turned out to be deleting the crashing alarm rather than making it cheaper — do you want me to re-word what counts as done for this job? What it watched for can no longer happen in our code, and a nightly check already catches the real version of that problem and fails the build on it. But 'done' is currently written as 'prove the alarm reads far fewer rows than before', and an alarm that is gone reads nothing at all, so that sentence can never be ticked off even once the problem is solved. I can't change what done means myself.
The full question, as raised
The acceptance criterion reads: per-run DDB reads bounded by new/changed rows (or an index Query), proven by a prod run log showing items read << total conversations, and no prod failure for 48h after deploy. The decided approach (receipt f8b313a38, held under reversal) is to RETIRE the check instead of bounding it, so there is no run log to produce and the 48h clause is trivially true. Only drive --replace can change a criterion. Re-word it, or keep it and adjudicate the mismatch at report time?
Why, and what was tried
The session raising this recommends: Re-word done as: alarm retired, nightly check proven to cover it The goal's own stated intent was to make the probe's cost independent of estate size; deleting it makes that cost zero, which over-satisfies the intent while breaking the letter. Verified first-hand before acting on the decision: tenantId is not a field on the Conversation type and nothing in src/ agents/ lambda/ writes the 'unknown' sentinel, so the alarm re-counts a frozen set of pre-cleanup rows and can detect nothing new; and assertConversationTenantBinding (src/lib/data/invariants.ts:137) already flags a conversation whose personId is missing OR wrong against the live tenant matched on property+phone at severity critical, called from scripts/audit-prod-invariants.ts:166 and run nightly against propflow-prod by nightly.yml:1456, where critical > 0 exits 1 and fails the job. So the coverage is broader than what is being deleted, not narrower. Option 2 leaves a gate that reads unsatisfiable forever, which is the shape that lets a driver quietly reinterpret its own goal — the thing the acceptance gate exists to prevent. Option 3 spends real work making a dead question cheap to ask. Tried first, unsuccessfully: Decider receipt f8b313a38 settled the APPROACH (retire, held under reversal, both passes agreeing). It was not asked this question — whether to re-word the criterion — because moving a driver's own goal is reserved to the human door by rule, so no model rung may rule on it.