Record which coworker a person chose on /channel/new, not only in the home composer

[kevin9327]

What this changes

server/src/routing/routes.ts records a channel.routed row for both ways a message finds a coworker, and says why the named case is recorded at all: "without that the trail answered 'why did this go to Risk Analyst' for routed conversations and said nothing at all for chosen ones, which reads exactly like a row that failed to write." The home composer honours that — routes/_authed/_app/index.tsx calls routeMessage(text, agentId) for an @ choice before start.

/channel/new never did. It is where the sidebar's + (app-sidebar.tsx), a coworker's card on the home screen, and a coworker's profile all lead; the person picks a coworker in the To: field and the screen calls start alone. routeMessage is referenced from index.tsx and nowhere else, so every conversation begun from those three places has no channel.routed row: a trail with rows for some conversations and none for others, on the surface people use most.

The fix is one shared sequence, startWithChosen in lib/channels/start.ts: record the choice, swallowing a failure to write it (the person already decided and a missing row must not stop the conversation — the same stance index.tsx already took), then start. useStartChannel exposes it as startChosen, bound to routeMessage; /channel/new calls it, and index.tsx's @ branch calls it too so the two screens cannot drift. The routed branch of index.tsx is unchanged.

Not covered, and said out loud: a hidden coworker reached through a profile link is not on the roster POST /api/route reads, so it answers 404 and the row is still not written; that is the server's call to make and is outside this change.

#296 moves the recording into a routing service; it keeps POST /api/route with agentId and touches nothing under app/, so this composes with it either way.

Where it runs

• New state that outlives a request? None.
• What happens on the second replica? The row is written by whichever replica answers POST /api/route, into audit_events, as today.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Every acting call still goes through the gateway: this adds the audit write that one surface was missing, before the act.
• New refusals and new failures each write a row: nothing new is refused; a channel.routed row now exists for a conversation that previously wrote none.
• Nothing new is trusted from the client: the server still reads the roster for the person asking and refuses a coworker not on it.

Changelog

• A section under Unreleased.

Proof

Before: grep -rn routeMessage app/src — lib/channels/route.ts (the definition) and routes/_authed/_app/index.tsx only; channel/new.tsx calls start(recipient.id, draft.text) with no record.

After: app/tests/start-chosen.test.ts pins the sequence both screens now run — record before start, with the message and the coworker; a record that fails does not stop the conversation; the server's answer cannot change who was chosen; a channel that cannot be started still fails the send.

$ cd app && bun test tests/start-chosen.test.ts
 4 pass
 0 fail

bun run format:check, bun run lint, and the app typecheck pass. Hook glue is left untested, as elsewhere in app/.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.