fix(ai): answer each ticket once, and stop showing reporters internal ticket IDs

[NathanTarbert]

Split out of #170 so the customer-facing fix can ship on its own. 43 files, 2,133 insertions, zero database changes. The concurrency work, the response state machine, the job-queue changes, and the email header threading all remain in #170 and are not part of this PR.

The rule

Outpost answers exactly one message per ticket — the message that opened it — and never posts in that thread again, regardless of who speaks next. Not the original reporter, not a teammate, not a third party. The agent is a first line of defence; a human owns the thread from the first response onward.

Team-member detection is irrelevant to this decision and no longer gates it.

Why

Two real threads in the CopilotKit Discord.

A maintainer posted the real solution, and the bot repeated it back at them. Thread 1535447155735789708 — fourteen seconds after a maintainer posted the actual answer, the bot posted its own message summarising that same answer. Nothing added, in public, over the top of the person who had already solved it.

The bot answered the maintainer, and said it was confused. Thread 1531971013791711342 — a maintainer asked a community member a follow-up. The bot answered the maintainer, explaining that it "can't see other users' replies."

That second thread also opened with 🎫 Ticket TKT-4HS8SRR3 created — an internal dashboard reference, published into a public server.

What changed

Enqueue sites refuse on replies. No reply enqueues an AI_RESPONSE job on any platform: shared/platforms/inbound.ts handleReply (Discord, Slack, Teams, GitHub issue bodies), github-app/webhooks/issue-comment.ts (its own path, which bypassed InboundHandler entirely), web/api/webhooks/postmark/route.ts, and discord-bot/lib/shadow-mode.ts so shadow mirrors production. Only new-ticket enqueue sites remain.

This is the load-bearing layer, and it is worth being precise about why. An earlier version of this work described the handler-side gate as making the invariant unroutable-around, with the enqueue-site removals as a cost optimisation. That was backwards: a ticket freshly minted around a mid-thread reply carries no prior AI response and passes the gate untouched. The gate prevents re-answering; the enqueue refusals are what enforce one-answer-per-ticket.

A re-answer gate in the handler, reading the ticket's own message history, so a caller added later inherits the rule.

Internal ticket IDs no longer reach reporters. The Discord and Slack 🎫 Ticket TKT-… created acknowledgment posts are removed outright. All three Teams Adaptive Cards stop rendering a displayId — it was also dead payload in the response card's Action.Submit data, since card-actions.ts ignores data and resolves by conversation id. The Teams ack card no longer claims an AI is reviewing the question when no AI job was enqueued. displayId stays in the dashboard, team slash commands, and logs.

Supporting fixes, each load-bearing for the rule:

Area	Fix
inbound.ts	The orphaned-reply fallback called handleNewTicket, which enqueues — so a mid-thread reply became a "new ticket" and got answered. handleNewTicket now takes an explicit { answer, orphanedReply }, and InboundResult.isOrphanedReply gates the Teams ack card and conversationReference write.
inbound.ts	sourceId was written as threadId ?? null but looked up as threadId ?? '', so a threadId-less message could never match and every message minted a new ticket. Now one shared buildTicketSourceId helper across every call site.
ai-response.ts	Answered the latest USER message rather than the opening one, so a follow-up racing the job stole the ticket's single answer.
reopen sets	The three reply paths disagreed on which statuses a customer reply reopens — GitHub omitted CLOSED, email omitted WAITING_ON_CUSTOMER. Load-bearing because of this change: reopening is now the only signal a human gets. One shared predicate.
Teams	Replies are gated by monitored channel; the filter previously ran only for thread starts, so a reply in an excluded channel reached the handler.

Tests

130 tests pass across the four suites this PR touches in packages/outpost; full CI on the PR.

Every behavioural fix carries red-green verification — test written, source broken, RED confirmed, restored, GREEN confirmed. Eleven pre-existing tests asserted the old behaviour and were rewritten, including github-app and discord-bot cases that actively locked in "answer every follow-up", and a Teams test that asserted the orphan-reply ack card had been sent.

Notable test repairs, because they were green while proving nothing:

• The Teams leak guards were mutation-proven unable to fail — the helper read only top-level body[].text, skipping nested containers and action titles. Now a recursive walker fed leak-carrying inputs, five mutations verified RED.
• Deleting && m.isAiGenerated from the gate predicate left the whole suite green. Both halves are now independently pinned.
• Three team-member tests this change silently turned tautological were deleted or repointed onto the new-ticket path.

The gate tests mock the AI pipeline at the class seam rather than driving LLMock, because the assertion they exist to make is that no model call happens at all — generateSupportResponse not being called is the direct expression of that.

What this does not solve

This is a circuit breaker. It stops the bot speaking twice; it does not teach it to behave correctly. Two follow-ups are filed rather than folded in:

• The bot still cannot tell who is speaking. ai-response.ts collapses every non-SYSTEM message to a bare user-or-assistant role from Message.type, discarding Message.author. Maintainer, reporter and stranger are indistinguishable to the model — the direct cause of the second incident above.
• "Answer once, ever" is blunter than the intent. What we want is "stay out once a human has stepped in." Under this rule, a reporter who adds a crucial detail thirty seconds later gets nothing, even though no human has appeared. A human-presence gate is correct on both incident threads and preserves that case.

Relationship to #170

#170 stays open with the remainder: (ticketId, responseKey) uniqueness, the response state machine, job claim-token fencing, stale-job reclaim, shutdown drain, Postmark idempotency and header threading — plus four database migrations. That half has not had a review pass and has three known findings outstanding, so it is deliberately not in this PR.

These two must not be recombined; independent rollback is the point of the split.

[jerelvelarde]

Approving — this is exactly the validated split

Verified against the split I built and tested locally before the plan was written. Every gate matches.

Gate	Required	Actual
Files under packages/outpost/db/prisma	0	0
packages/outpost/queue/src/worker.ts	untouched	untouched
Size vs main	43 files / 2,133 insertions	43 files / 2,133 insertions / 387 deletions
PR-touched packages/outpost suites	130 passed	130 passed
CI	green	green (Lint/Typecheck/Test, zizmor, notify)

Composition is right. e02f620 (the 13 reviewed commits) with aa95e94 and 9180591 lifted on top — the Teams channel gate and the orphan-reply silence. Nothing else rode along.

No delta leakage. Grepped for every marker of the unreviewed half — responseKey, claimToken, PRIMARY_AI_RESPONSE, responseState, MessageResponseState, findTicketByReplyMessageIds, reclaimStaleJobs. Zero hits across apps/ and packages/. The job queue and schema are genuinely untouched by this PR, which is what makes it independently revertable.

Both review blockers are present and correct. isOrphanedReply lands in platforms/types.ts, platforms/inbound.ts and teams-bot/src/handlers/message.ts — the ack card and the conversationReference write are both gated on it, and the monitored-channel filter now covers replies as well as thread starts.

ae314de also cleared the em-dash escape nit from my original review. The remaining \uD83C sequences are emoji in string literals, consistent with existing code.

Known limitations shipping with this

Both are tracked and both are closed by #170's remainder — noting them so the gap is explicit while this is in production:

• #175 — an undelivered response can flip its job to COMPLETED on retry.
• #176 — AI_RESPONSE can double-post under timeout-retry. Pre-existing in main; this PR strictly reduces exposure by enqueuing fewer jobs.

Neither is a regression introduced here, and neither touches the bug this fixes.

On the split itself

Thanks for cutting it cleanly and for the rationale comment on #170 — "the two must not be recombined" is the right instinct and worth keeping in the #170 description as it gets reduced.

The commit hygiene is what made this cheap: two cherry-picks and one trivial test conflict. That's a direct dividend of committing in small scoped pieces rather than one blob.

Good to merge on my end.