Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.
1
In plain terms. Two texts showed up in a resident's message history that didn't go through any of PropFlow's normal sending process — do you want us to just fix the record, or dig into how they got there first?
Our safety check for this caught 2 messages in the same conversation, sent hours apart, added in a way we've never seen before — like someone typed them straight into the database instead of sending them through the app.
The full question, as raised
conversation-conformance-drift sweep flagged 2 nonconformant post-epoch Message rows in conversation f37c24de-9cbb-40c9-b726-1e106e74cf46 (both variant=outbound, missing=writerId(unregistered:operator.manual-outbound-record)). msgIds 'manual-SM09cdcb1a987c44681b462eb1e4951a2c' and 'manual-undefined' (the second name itself looks bugged), timestamps 2026-09-29T22:37:45Z and 2026-09-30T03:19:36Z. writerId 'operator.manual-outbound-record' is absent from conversation-writers.registry.ts and its TOLERATED_RETIRED_WRITER_IDS map, and git log -S plus git grep across every checked-out repo (propflowai, agent-smith, appfolio-browser-agent, propflow-ai-app, cerebrus, propflowai-book, propflow-brand-assets) return zero hits, in history or on disk. So this was not written by any code path that has ever existed in these repos — it reads as a hand-written prod DynamoDB PutItem, not a runtime bypass of buildMessage. The documented remediation (scripts/_reconcile-conformance-rewrite.ts row rewrite) is a prod-data mutation, which is outside my charter to do unprompted.
Why, and what was tried
The session raising this recommends: Find out who or what did this before fixing anything The writer id has never existed in any of our code, so we don't know the source yet, and it's the kind of thing worth confirming before writing it off. Tried first, unsuccessfully: Verified the 2 rows directly against propflow-prod DynamoDB (AUTOMATION_RUN#conversation-conformance-drift latest run row). Searched every checked-out repo's source tree AND full git history for the writerId string and the 'operator.manual' prefix — zero matches anywhere. Checked conversation-writers.registry.ts and its retired-writer tolerance map — no entry. Checked 'blocked outstanding' — no existing decision covers this cause. Tried to pull the full conversation transcript (property, message content) via pull-link/getConversation to add more context, but it times out — getConversation does a full 20,810-conversation portfolio scan and the box is heavily loaded right now — so I stopped rather than burn more time on a machine-load issue for a decision that's answerable without the transcript.