Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1wo_enrichment sweep (lambda/appfolio-sync) has been budget-starved for 7 straight days (Sentry JAVASCRIPT-NEXTJS-18Z, firstSeen 2026-09-15): the sweep gets ~640s of serial L4 staff-portal time per daily run (Lambda is already at AWS's 900s hard ceiling), and syncable WO volume has outgrown that as the portfolio grew 77->83 properties this week. Today's run: 191/937 syncable WOs enriched, 746 unreached, 16/83 properties breached the 48h staleness bar (some up to 120h). One property alone (appfolio-385) accounts for 373 of the 746 unreached. Zero per-WO failures -- this is pure serial-budget starvation, not an AppFolio/L4 fault. The code's own header names this exact shape ('a steady non-zero floor means the portfolio no longer fits in one tick and needs sharding') as its own ticket, not a quick fix. The prior per-org cadence decision (b89464070: Camellia daily, Western Slope weekly) predates this growth and doesn't cover the new large account. A real fix (sharding the sweep across multiple invocations, or a smarter per-org allocation) is a multi-PR design effort; the reversible lever available today is extending the existing weekly-cadence mechanism to the new large account.
In plain terms. Should I slow the AppFolio work-order refresh to weekly for our newest, biggest customer so it stops falling further behind every night? A nightly job that keeps vendor and scheduling details in sync with AppFolio has been unable to finish its list for a week straight, and it's getting worse as we add properties. The permanent fix is a bigger engineering project; the question now is whether to apply a stopgap.
The session raising this recommends: Move the new customer to weekly refresh now Reversible today with an existing script, zero code risk, matches precedent already set for Western Slope, and buys time for the real sharding fix Tried first, unsuccessfully: Read the sweep's planner/handler code and its schedules.json doctrine, pulled 7 days of Sentry history to confirm this is persistent not transient, checked whether the documented 'why not six-hourly' blocker (list reshuffling) is still true (it shipped a fix 2026-08-28 but is only partially proven), pulled today's CloudWatch run to find the real throughput (3.3s/enrich, 642s used of the ~640s budget) and which properties are breaching, and checked for an existing decision (b89464070) covering this -- it predates the growth and doesn't cover the new account.