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.
1Nightly AppFolio portfolio-arm coverage still reports UNKNOWN for org_sandbox#jpco and (newly) org_53047a06-2c49-4231-92c2-6f2a7009149a#jpco (Fairhaven test org). Both resolve to the SAME legacy per-user AppFolio credential (ownerId 89e046ad-84d0-44f9-a5ee-95dee4468310, database=jpco, client id ...5cd0, confirmed live and not disabled) that the org-scoped credential door cannot read. Verified read-only against propflow-prod just now: org_sandbox still has NO org-scoped credential row (getOrgPmsCredentialSummary -> null) even though block b89545443 was answered 'Run the fix now' 7 days ago -- the approved fix was never executed. org_53047a06 is in the identical shape (its org-scoped credential only covers a different account, 'demo'; its three jpco-database properties fall back to the same legacy row). scripts/backfill-pms-credential-to-org.ts already exists and is additive-only (never touches/disables the legacy row). Should someone with access run it now for both orgs, and who?
In plain terms. Want us to run a one-line credential fix for two test AppFolio portfolios that our nightly health check can't verify? They both share one old shared login our new system can't read — you already approved this fix for one of them a week ago but it was never actually run, and now a second portfolio hit the same wall.
The session raising this recommends: Run it now for both -- someone with access presses the fix twice Same root cause as the already-approved b89545443 (legacy credential 89e046ad, database jpco), now hitting a second org. The migration is additive and reversible, the live AppFolio accounts it actually syncs (jpco, westernslopepm) are already fully armed against the per-property fan-out bug, so there's no cost emergency -- but this blind spot re-pages every night until someone runs it, and it has already sat approved-but-undone for a week. Tried first, unsuccessfully: Read-only checks against propflow-prod before raising: confirmed org_sandbox has NO org-scoped AppFolio credential (getOrgPmsCredentialSummary('org_sandbox','appfolio',{}) -> null, both with and without accountId=jpco filter) -- the approved b89545443 fix was never executed. Confirmed org_53047a06-2c49-4231-92c2-6f2a7009149a (Fairhaven test org) has 10 properties: 6 on an org-scoped 'demo' credential (fine), 3 (Quillwood/Thistledown, database=jpco) on ownerId 89e046ad-84d0-44f9-a5ee-95dee4468310 with no org-scoped row for that account -- the exact same legacy credential org_sandbox uses. Confirmed via the GitHub Actions run log that the live AppFolio accounts (jpco#5cd0, westernslopepm#17a5) are fully armed (live=0 dormant=0 fenced=0) -- the per-property fan-out cost this check exists to catch is NOT currently happening; this is purely the coverage blind spot. Checked blocked outstanding for a duplicate: b89545443 covers org_sandbox only and is already resolved (answered, not re-raisable), nothing covers org_53047a06. Did not run the migration script myself -- writing a production AppFolio credential is barred for an agent session (docs/integrations/appfolio.md, root policy).