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.
1The nightly AppFolio portfolio-arm coverage check reports org_sandbox#jpco as UNKNOWN coverage every run (last two nights: unknown=3 -> unknown=1, this one being the persistent one). It resolves to a legacy per-user AppFolio credential (owner userId 89e046ad-84d0-44f9-a5ee-95dee4468310, database=jpco, client id ...5cd0, still active) that the new org-scoped credential door cannot read -- confirmed live via a read-only DynamoDB check. scripts/backfill-pms-credential-to-org.ts already exists to copy that credential into an org-scoped row for org_sandbox, additively (it never touches or disables the legacy row). Should someone run it, and who?
In plain terms. Want someone to fix a blind spot in our nightly AppFolio health check, or should it keep alerting for now?
The session raising this recommends: Run the fix now -- someone with access presses the one script The check is correctly flagging real blindness -- this connection genuinely cannot be judged safe -- so quieting it hides a real signal and leaving it re-pages nightly forever. The migration is additive and reversible (the legacy row is never touched or deleted), and it is the SAME jpco credential Fede already pressed portfolio arms for two nights ago (block b89411968), whose own notes flagged this exact unknown= gap as 'a separate fix.' But docs/integrations/appfolio.md says eight times that touching a real customer's AppFolio credential is never done by an agent session, and the root policy bars Smith from prod DynamoDB writes outside the PR-merge flow -- so this is one command, but it has to be a human's hands on it. Command: DATA_BACKEND=dynamodb DYNAMODB_TABLE_NAME=propflow-prod npx tsx scripts/backfill-pms-credential-to-org.ts --org=org_sandbox --user-id=89e046ad-84d0-44f9-a5ee-95dee4468310 --apply --confirm-table=propflow-prod Tried first, unsuccessfully: Read-only checks before raising: confirmed org_sandbox#jpco resolves to a legacy PMSCRED row for user 89e046ad-84d0-44f9-a5ee-95dee4468310 (database=jpco, last4=5cd0, not disabled), confirmed org_sandbox has no org-scoped credential row yet (getOrgPmsCredentialSummary returned null), confirmed the property behind it is appfolio-45/The Willows (isTest=true, a bench property riding a real customer's credential -- exactly the shape scripts/backfill-pms-credential-to-org.ts's own header warns about). Checked blocked outstanding for a duplicate: none open; the one related resolved block (b89411968, 2026-09-14) armed different portfolio paths on the same jpco account and explicitly deferred this unknown= gap as separate work. I did not run the migration script myself -- writing a credential into propflow-prod is outside what an agent session may do.