feat(api): show the autopilot the message it sent (#128)

[psanders]

Closes #128.

The gap

Dispatch stores the collection notice as flat channelData.messageBody. Both ingest paths build their thread from channelData.emailThread / whatsAppThread — keys dispatch never writes. So the thread always initialized empty, and the agent's first view of a conversation was the customer's reply.

The production "mora temprana" prompt tells the agent to redirect payment questions to WhatsApp, but the link exists only in that notice. The agent could say "escríbenos por WhatsApp" and never cite it.

WHATSAPP had the identical gap, and so did the eval harness — which is why it went unnoticed: the tool used to test agents reproduced the same blind spot.

Before / after, real model, same prompt and account

Customer: ¿De qué trata esto?

Before — no link, balance invented from context:

¡Hola! Somos Créditos Demo. Te escribimos para recordarte sobre tu crédito pendiente. Actualmente tienes un saldo de 4800 y 12 días de atraso. Si tienes preguntas sobre tu pago o necesitas datos bancarios, por favor contáctanos por WhatsApp para ayudarte de inmediato.

After — answers the question, cites the real link:

Estimada Ana, este correo es un recordatorio sobre el saldo vencido de su préstamo con Créditos Demo. Para cualquier pregunta o para coordinar su pago, por favor escríbanos a nuestro WhatsApp: https://wa.me/18095550123

Approach

The notice is prepended at decision time by a shared buildThreadWithOpener in @qcobro/common, not seeded into the stored thread. #128 proposed the latter; it costs more than it saves:

• GestionDetail.tsx:363/:448 already render messageBody above the thread, so seeding shows the notice twice
• GestionDetail.tsx:201 requests an AI analysis when the thread is non-empty — a dispatch-time seed makes that fire on conversations that haven't happened
• it needs a backfill, so it wouldn't reach any gestión currently in flight
• it duplicates the notice into two keys that then have to agree

generateGestionInsight.ts already had its own copy of this prepend; it now uses the same helper, so an insight and a reply can't be built from different views.

Also in here

• the engine persists the rendered EMAIL subject — only the manual dispatch path was keeping it
• the prompt renderer includes a message's subject; previously only body was rendered
• an agent reply falls back to the subject we sent (the old fallback resolved to the first inbound message)
• eval scenarios seed the same notice, rendered against the scenario's synthetic account
• adjacent: WHATSAPP now passes referenceDate, as EMAIL always has — without it "el viernes" couldn't resolve to a dated PaymentPromise

Truncation question, answered

There is none. Both prompt builders render the whole thread every turn; the only .slice( calls extract JSON from fenced responses. The only bound is the reply cap (default 3). That was an accident of the implementation, so the specs now state it — a future windowing change has to be deliberate.

Testing

• 250 pass in mods/common, 541 in mods/apiserver, including a continuity test across three replies asserting the notice stays at index 0 and nothing earlier is dropped
• email.integration.test.ts run against real Postgres — both pass, covering the new dispatch-subject assertion
• the before/after above is the real Gemini autopilot through createIngestEmailReply, with the send and persistence stubbed

Note for review

whatsapp.integration.test.ts has one pre-existing failure on main — 4,800 vs 4800, a stale expectation against the money-formatting behaviour (see the active money-workspace-locale change). Untouched by this PR.

Follow-up, not code

Facts that exist only in the outbound template (the WhatsApp link) should also be stated in systemPrompt — it's the one field guaranteed to reach the model every turn and it survives someone editing the message template. This PR makes the notice visible; it doesn't make it the right home for a load-bearing fact. Recorded in design.md.

Eval scenario expectations were authored against an agent that couldn't see the notice, so the suite needs a re-run and a triage pass before its results mean anything again.

🤖 Generated with Claude Code

https://claude.ai/code/session_012893PhmVYDiGkL8p7hyavx

[psanders]

Review follow-up — critical finding fixed (d0c2521)

A code review flagged that the referenceDate addition in this PR did nothing at runtime, and it was right.

WhatsApp doesn't use emailAutopilot.ts's prompt builder — it has its own in whatsAppAutopilot.ts, which never read req.referenceDate and carried neither of EMAIL's two date lines. So referenceDate reached decide and was dropped on the floor: "le pago el viernes" still went to the model with no anchor date and no format rule.

That lands in persisted data. emailAutopilotDecisionSchema types dueDate as a bare z.string().optional(), so a literal "el viernes" validates and is written straight through as intentMetadata.promisedDate on a real PaymentPromise.

The test I'd written asserted only that the field reached decide, so it passed either way — which is the worse half of the bug. A green test plus a spec scenario asserting behaviour that doesn't exist closes the question for future readers.

Fixed by adding the two date lines to the WhatsApp prompt builder, and by testing the prompt text actually sent to the model, for both channels, rather than the request handed to decide. Confirmed the new test catches it: reverting the one-line fix turns WHATSAPP: the reference date reaches the model red.

548 tests pass in mods/apiserver.

Three further findings, not fixed here

Recording them so they aren't lost. None block this PR in my view, but the first is worth a look before merge if you disagree.

1. runAutopilotEvaluation.ts:45 — the WHATSAPP eval opener renders to empty placeholders. It uses renderTemplate, but a stored whatsAppConfig.messageBody is a Meta template with lowercase snake_case parameters; production dispatch uses renderWhatsAppTemplate, which maps first_name → firstName first. So a WHATSAPP opener of "Estimado {{first_name}}, su saldo es {{outstanding_balance}}." seeds as "Estimado , su saldo es ." — the eval half of this PR is defeated for that channel. Fix is a type branch; EMAIL is unaffected.

2. referenceDate is the UTC date, not the workspace's (ingestWhatsAppMessage.ts, ingestEmailReply.ts). nowIso.slice(0, 10) ignores the configured timezone (America/Santo_Domingo, UTC−4). A reply at 21:30 local Thursday already reads as Friday, so "mañana" lands a day late. Pre-existing on EMAIL; this PR propagates the same computation to WhatsApp.

3. ingestEmailReply.ts:152 uses ?? where it wants ||. inboundEmailSchema types subject as z.string().optional(), so a reply carrying an empty Subject: parses as "". ?? doesn't skip "", so the chain stops there and the reply goes out as bare "Re:" — defeating the notice-subject fallback this PR adds, in exactly the case it was added for. Two-character fix.

Happy to fold any of these in — say which.

🤖 Generated with Claude Code

https://claude.ai/code/session_012893PhmVYDiGkL8p7hyavx

[psanders]

All four review findings now fixed (e6adf2d)

Following on from the critical one in d0c2521 — the remaining three are in.

WHATSAPP eval openers rendered empty (runAutopilotEvaluation.ts). A stored whatsAppConfig.messageBody is a Meta template with lowercase snake_case parameters; the account context is camelCase. renderWhatsAppTemplate maps between them, plain Handlebars doesn't — so "Estimado {{first_name}}, su saldo es {{outstanding_balance}}." seeded as "Estimado , su saldo es .". Now branches on agent.type.

?? → || on the reply subject (ingestEmailReply.ts). An empty Subject: parses as "", which ?? keeps — sending a bare "Re:" and skipping the notice fallback this PR adds, in exactly the case it was added for.

referenceDate is now the workspace's calendar day, not UTC's. workspaceTimezone rides on both gestión views; both Prisma loaders already read the settings row for currency/locale, so this adds no query. DEFAULT_TIMEZONE in @qcobro/common mirrors the Prisma column default for the lazily-seeded case.

Verification

Each fix has a test, and I checked each one actually catches its bug by reverting the fix and watching it go red:

Fix	Test	Red without the fix
WhatsApp prompt reads referenceDate	whatsAppAutopilot.test.ts	✓
WhatsApp eval opener rendering	runAutopilotEvaluation.test.ts	✓
?? → `		`
Workspace timezone	ingestEmailReply.test.ts, ingestWhatsAppMessage.test.ts	✓

553 pass in mods/apiserver, 250 in mods/common. email.integration.test.ts passes against real Postgres.

The timezone tests are worth a look — they assert on instants that are genuinely a different date in the two zones (00:30 UTC on the 27th is 20:30 on the 26th in Santo Domingo), so they'd fail under the old UTC computation rather than passing coincidentally.

🤖 Generated with Claude Code

https://claude.ai/code/session_012893PhmVYDiGkL8p7hyavx