GeezerVison

Why

Part of the Automations RFC (CODAGT-1135). An automation will publish a message into a chat on behalf of a webhook or a schedule. That message never goes through the HTTP send path, so its user_prompt_submit hooks do not run there. The RFC has chatd run them when the message starts a turn, keyed only on the prompt_hooks_pending flag, so chatd needs no knowledge of automations.

Stacked on #32067. Review only this diff. It merges after #32067.

This PR teaches chatd that one thing. Nothing sets the flag yet (the publish path is a later PR), so every chat behaves as before.

What changed

• A turn step first settles the oldest message with prompt_hooks_pending set. With lifecycle hooks off it only clears the flag. Otherwise it dispatches user_prompt_submit outside any transaction, then applies the result in one short transaction through a new ResolvePromptHooks transition and ends the task. The history change starts the next task, as after a steer delivery.
• A rewrite replaces the message content. A denial soft-deletes the message and fails the chat with kind hook_denied and the hook's user message, in the same transaction, so a crash cannot leave the message deleted and the chat running. Messages queued behind it stay queued.
• A dispatch failure keeps the flag and fails the chat with kind hook_dispatch_failed, like the other generation-time hooks. The hooks run again when the chat resumes. A worker that dies before the transaction commits, or loses its lease, leaves the flag set, so the next worker runs the hooks again.
• The flag follows a message through the queue: queue inserts and promotions carry it, a queued edit clears it (the edit path already ran the hooks), and a soft delete or ClearContext clears it, so no stale flag blocks the down migration.
• A flagged message stays out of every model prompt until its hooks have run: GetChatMessagesForPromptByChatID skips it, and so does the manual title path.

Scope

• No writer of the flag, no read of automation_id or any automation, no experiment, no SDK fields.
• A human message still runs its hooks once, when it is sent.

Tradeoffs

• The hooks run at least once per flagged message. A consumer that must not see a prompt twice has to be idempotent, as for any retried dispatch.
• The hooks use the generation capacity class, not the admission class, because the message is already accepted.

Blast radius

Every chat turn now scans its loaded history for the flag at every step. With the flag false the step is unchanged, and a test pins that a human message runs its hooks once, not again at turn start. The prompt query gains one AND prompt_hooks_pending = false filter.

Live check

Built ./enterprise/cmd/coder, ran coder server with agent-lifecycle-hooks, the stock scripts/agenthooks-server (and a throwaway denying consumer) and a fake OpenAI server, and set the flag by SQL: allow, rewrite, denial (chat error hook_denied, the model got no request), a human turn with the flag false (one hook call), and hooks off (flag cleared, no hook call) all behaved as above.

ARCHITECTURE.md prose was drafted by an agent at the user's request; the user will review it.

Generated with xum • Model: anthropic:claude-sonnet-5-5 • Thinking: xhigh