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.
15 questions on this
In plain terms. Clara's lead-email alert has paged five times in three weeks, and each fix so far added another stamp by hand. The replacement is built and parked as a draft: every lead email that ends without an answer now reports itself once, at the moment it happens, instead of being caught later by a sweep. Approving it means the team hears about these in Slack rather than in Sentry, and hears one alert per lead instead of one per batch; leaving it parked means the hand-patching continues and the next forgotten exit goes quiet with nobody noticing.
0 of 5 answered
1May propflowai #22165 be flipped from DRAFT to ready now, as built? Flipping it is effectively the decision to ship it, because pr-autoqueue arms any green unheld ready PR every 300s and merge is the production deploy here. It sits MERGEABLE and unarmed at head 01ef5127cda5, with a propflow-code-reviewer YELLOW and no RED at that head, a fresh-context local review, an independent codex review, and the full CI test lane green. It introduces one door every terminal save of a lead-shaped email ingestion row passes through, plus a shrink-only ratchet refusing new raw saves and a throw-mid-pipeline test proving a FAILED row is stamped and alerted.
In plain terms. Fede - the lead-email fix is built and parked as a draft; may this session flip it to ready, which is what actually ships it?
Why the raiser recommends it
The session raising this recommends: Keep it a draft until the alert questions below are settled, then flip it. Fede's 2026-10-22 rule reserves alert-contract changes to him, and here the alert's channel moves, not only how often it fires.
2The alert's CHANNEL moves, not just its frequency, and this was not in the original description. The old sweep's page surfaced as Sentry JAVASCRIPT-NEXTJS-1FB via the cron automation run. The new door posts only through notify, and notify contains no Sentry capture, so 1FB goes quiet for every exit the door catches and Slack #alerts becomes the only signal. The shape also moves from once per tick for a whole batch to once per row; measured volume is 4 events in 30 days.
In plain terms. Fede - this fix stops the lead-email alert appearing in Sentry and sends it only to Slack #alerts; is that the right place for it?
Why the raiser recommends it
The session raising this recommends: Slack alerts only is fine; let the Sentry issue go quiet. The team already reads these in #alerts, and the per-row page names the exit it came from, which the Sentry issue never did.
3A guest card whose only copy reaches a clara-only address at a property that is not armed: page #alerts once, or hold it silently? This reframes what the original description implied. Main ALREADY pages for this exit, because #22161 never landed and main carries no ses-data-only handling. So page-once is today's behaviour and SILENT is the change. #22161 made it silent without saying so, and that is the one thing this PR deliberately does not carry forward. This answer also decides whether the duplicate-page suppression PR gets built at all: if the ruling is silent, there is no duplicate page left to suppress and that work is dropped.
In plain terms. Fede - when a lead's only copy lands at a Clara address on a building that is not switched on, should the team still get one alert?
Why the raiser recommends it
The session raising this recommends: Alert the team once, as it does today and as this change keeps it. It is the contract that is live right now, and going silent hides a lead that nobody answered.
4On the SES lane a PartialCandidateSetError now pages that Clara did not answer an email, for an email SES is about to redeliver. This is not a regression: that lane mints a fresh row id per delivery, so the old sweep paged the orphaned FAILED row too. If you want it quiet, the fix is to stamp a non-alerting outcome for that one rethrown class, which is a one-line change rather than a redesign.
In plain terms. Fede - should the team get an alert about an email Amazon is about to re-send to PropFlow anyway?
Why the raiser recommends it
The session raising this recommends: Make it quiet, and record the reason without alerting. SES normally redelivers these within minutes, so the page fires for something that resolves itself.
5The follow-on PR #22168 adds a NEW non-alerting stamp, decision:redelivery-pending, for the inbox lane. That lane reuses a row id when SES redelivers, so without the stamp the door would page a lead that then gets answered on the very same row. It joins the non-alerting DECISION_HOLD family, which makes it an alert-contract change and therefore yours rather than mine.
In plain terms. Fede - when Amazon re-sends the same email, the fix stays quiet the first time instead of alerting; is that correct?
Why the raiser recommends it
The session raising this recommends: Approve staying quiet on the first delivery. Without it the door pages a lead that is answered seconds later on the same row, which is noise the team cannot act on.
Why, and what was tried
Tried first, unsuccessfully: fable-decide f99d315b9 RESOLVED 2-for-2 (as-given and reversed, answered by claude-fable-5, no Astra fallback): keep the PR a draft and raise the alert-contract items to Fede. It verified independently that notify carries no Sentry capture and that main has no ses-data-only handling, so the alert's channel, shape and timing all move. This raise EXECUTES that resolution rather than overriding it; the five questions below are the items it said are Fede's. Precedent under the same hold: block b92778002 (#22069, green and approved, raised to Fede, still held).