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.
1PAYMENTS_PORTFOLIO arm is OFF (default) on 2 live accounts (appfolio#jpco#5cd0, appfolio#westernslopepm#17a5) that the nightly portfolio-arm-coverage check flags as still fanning out one receivables_activity request per property. A portfolio-wide path exists (writers/payments-portfolio.ts) and is capability-proven (2026-09-16 live sample: 501 rows / 59 distinct PropertyIds), but arming it is explicitly gated to a human in the script's own docblock — this job's writes are PERMANENT, TTL-free payment history (feeds collections payment-habit + owner-report recovery rate), so an under-reporting portfolio pull would corrupt real financial history, not just cost more. The pre-arm bench dry-run also can't be followed as written (org_sandbox is itself a live customer account, not a real sandbox), so the first exercise of this path is necessarily on a live account either way.
In plain terms. Should we switch two customer accounts to the faster, whole-account payment sync now, or keep them on the slower per-property one? Both are still pulling payment data one property at a time even though the faster method is built and tested; switching it on writes permanent payment records, so it needs a person's go-ahead rather than mine.
The session raising this recommends: Turn it on now for both accounts Capability is proven, the write path fails closed instead of partial-writing, and every unarmed tick keeps paying the same per-property cost pattern that caused the 2026-09-12 429 storm Tried first, unsuccessfully: Confirmed via the alert run's own output that both accounts are unarmed live pairs with the job ENABLED, checked the integration doc and found no documented exception for either account (so per the check's own discriminator this is unfinished rollout, not a deliberate choice), read the arm script's docblock which explicitly reserves the write for a human, and confirmed no existing decision covers this specific arm (searched open decisions and the alert history, no hits).