I'm parked on you

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. Our own AI key that the AppFolio robot needs to log in is being rejected — can someone check or replace it in Anthropic's console?
The full question, as raised

ANTHROPIC_API_KEY in Vercel prod for appfolio-browser-agent returns 401 'invalid x-api-key' when hit directly (confirmed with a live curl to api.anthropic.com/v1/messages). It's been failing since 2026-10-13 (Sentry JAVASCRIPT-NEXTJS-1HC, 4 events 08:00-08:01 UTC today, plus the playbook's mistake #25 logging the same root cause starting 2026-10-13). Every AppFolio login drive dies on its first act (stagehand.extract) before a password is typed, so ALL AppFolio browser automation (work orders, renewals, vendor/tenant lookups) is blocked across every identity. PR #511/#512 already fixed the SIDE EFFECT (it no longer wrongly escalates the AppFolio credential breaker), but the actual key is still dead — nothing in my reach can mint a new Anthropic API key or change Anthropic console state.

Why, and what was tried
The session raising this recommends: Check console/billing first
a 175-day-old key suddenly 401ing looks more like an intentional revoke/cleanup than a random expiry, so confirming avoids generating a key that gets revoked again
Tried first, unsuccessfully: confirmed root cause live: pulled the prod key from Vercel, curled it straight at Anthropic's Messages API, got 401 invalid x-api-key; checked git history (no recent repo change to key handling, last Vercel env write was 175d ago) and the playbook (mistake #25) which independently timestamps the same failure starting 2026-10-13; searched the open-decisions ledger for an existing block on this and found none

cfb9fd66 (adopted from 28f57607) is parked on this.

2

In plain terms. When our AppFolio robot breaks for the same reason twice — say its AI key dies again — the second time may send no Slack alert at all, because we just taught it to file repeats under the original report instead of shouting again. Flipping one switch in Sentry means a repeat outage still pings #alerts once; leaving it means somebody has to notice the robot is down on their own.
The full question, as raised

Approve adding REGRESSION notifications to Sentry alert rule 17072804 (preserving its production/high-priority filters and #alerts routing), after verifying its current conditions? Grouping the robot's errors by cause means a cause whose Sentry issue was RESOLVED reopens that same issue as a regression on its next outage — and a 'new high-priority issue' rule does not fire on a regression, so the SECOND outage of a dead key or a tripped breaker may post nothing to #alerts.

Why, and what was tried
The session raising this recommends: Yes — add regression as an additional trigger (new OR regression, never AND)
Going silent on a recurring real outage is the 'say the wrong thing' failure in its worst direction, which is the opposite of what the noise-diet ask was for. It is a reversible console toggle, but third-party production config is reserved to a human by the OPERATING-CONSTITUTION, so it is yours rather than mine. A code-side time-bucket mitigation was considered and rejected: it fragments causes and still misses recurrences inside a bucket.
Tried first, unsuccessfully: receipt faea36ed0 — RESOLVED, and ANSWERED BY ASTRA (gpt-6-astra), NOT Fable, whose 5h session window was spent. It ruled option A (raise for a human, merge both PRs meanwhile): Constitution Art. X reserves third-party production config and Art. XI's Oct 8 ruling explicitly preserves that reservation, so ADR-0025 §7's reversible-work grant does not override it. It supplied the wording of this question, warned to combine new OR regression rather than AND, and rejected time buckets. Held under reversal at medium/medium. It could NOT verify the live rule conditions or the implementation, and neither could I — rule 17072804's trigger set is reported by the lane that built the fix and is credible but UNVERIFIED; it needs Sentry console access this session does not have.

cfb9fd66 (adopted from 28f57607) is parked on this.

Pick an option above, then press Done.
PropFlow Docs