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.
1appfolio-sync 'vendors' worker bypassed the isTest fence (dispatcher hands every worker a non-empty event.propertyIds, handler.ts:2173-2174 vs 4472) → at 2026-09-12T18:19Z (worker requestId 0e5e1a0b) it minted 817 org_sandbox VendorMemberships + Persons + tier-1 primary phone claims for the jpco roster, and an org_jpco engagement for the eval vendor 1478 (pers_7a4d4fde-1aec-4289-be8a-1eccd2c114a6 / vm_appfolio_org_jpco_1478_1789237192536) that now wins pickPrimaryClaim over the seeded org_sandbox in-house Person (pers_813d6e98…), so the handyman preflight throws for all 8 handyman scenarios. The code fix (fence uses explicitTargets = propertyIds && no connectionKeys) stops recurrence but does NOT restore the eval. Which prod-data remediation?
In plain terms. The nightly maintenance check went red because a vendor-sync change copied the customer's whole vendor list into our test sandbox and also created a duplicate record for the test handyman, so the check no longer recognizes him. Fixing the code stops the copying, but the stray records have to be removed by hand. Should we remove the sandbox copies and retire the duplicate handyman record, or just re-seed the test bench and leave the copies in place?
The session raising this recommends: Remove the sandbox copies and retire the duplicate handyman record Re-seeding only wins a timestamp race that any future re-verification loses again; the 817 sandbox claims are the newest tier-1 claims on real vendor phones and would route real vendors' texts into the sandbox org (Camellia's own tech phone already resolves there; 0 conversations since the burst, so not yet bitten) Tried first, unsuccessfully: Read the run's Temporal history (8x 'bench preflight FAILED'), ran the resolver walk read-only against propflow-prod, counted the burst per org via listMembershipsForOrg (org_sandbox 817, org_jpco 2), matched the lambda log lines, confirmed the fence bypass from the dispatcher payload; the deletions/deprecations and the seed script are prod writes I do not run.