[lavaman131]

Three display problems showed up in a real hosted build. This fixes each one where it starts.

Task text in Build shows raw Markdown

Task titles, goals, acceptance criteria, summaries and the "After …" line were plain text, so an agent's `code` and **bold** appeared with their backticks and asterisks. They now go through a new InlineMarkdown component in apps/web/src/chat/markdown.tsx. It uses the same renderer and allowlist as Chat, limited to inline elements: code spans, emphasis, strong text and links. Raw HTML and images are dropped, and a leading 1., -, # or > stays literal so one line stays one line. A task title sits inside its toggle button, so links in a title render as plain text. Inline code uses Chat's inset chip at the surrounding text size.

The progress line shows the agent's raw shell command

The connector sent the latest ACP tool-call title as build progress. For a shell tool that title is the command itself, for example sleep 900; git -C $CHOPIN_RUN_WORKTREES/… status --short. The new activityText in @chopin/protocol/activity now decides what the line says:

• The connector remembers each tool call's kind. An execute call reads "Running a command" unless its title is already a sentence, such as "Running server tests".
• The server applies the same rule to every renew_implementation_build heartbeat without the kind. Commands from connectors that are already installed stay off the line too.
• Text that looks like a credential (known token prefixes, Bearer …, long key-like runs) becomes a generic label. Long text is cut to 80 characters.

The raw command is not shown anywhere, including on hover.

Chat flattened numbered items 3–5 of the task-graph message

The message used lead-in lines with no blank line before each list:

Needs task 1 first:
3. rewire-handler: …

CommonMark lets only a list that starts at 1 interrupt a paragraph. So items 3, 4 and 5 were lazy continuation text, and the list rendered as "Needs task 1 first: 3. rewire…". The renderer followed the spec, but Chat is Chopin's own small dialect, so the fix is on the renderer side. A small remark step (apps/web/src/chat/ordered-runs.ts) splits such a paragraph into its lead-in and an ordered list that keeps its starting number. It checks the source, so escaped markers (3\.) and code spans stay as written.

Before and after

Screenshots come from the new e2e tests: unfixed main first, then this branch. They show generic test data only.

Tests

New tests failed first on unfixed code:

• packages/protocol/activity.test.ts
• apps/connector/src/run.test.ts: the connector reports "Running a command" and no heartbeat carries the command.
• apps/server/src/tasks/routes.test.ts: a raw-command heartbeat from an older connector is stored as "Running a command".
• apps/web/src/chat/markdown.test.ts: continued numbered lists, and inline Markdown.
• e2e: Build shows an agent's inline Markdown in task text as formatting, a sent message keeps numbered items after a lead-in line as a list, and the build owner sees activity…, which now drives a raw-command tool call through the fake implementer.

Checks run on the rebased head:

• bun test apps/web packages apps/server: 6015 tests, 0 fail.
• bun test apps/connector/src/run.test.ts: 30 tests, 0 fail.
• bun run types and bun run ci both pass.
• implementation-launcher.e2e.ts and chat-composer.e2e.ts in Chromium: one test failed on the first full run because my own new test expected the wrong code spans. I fixed the test, and the new and changed tests then passed. I did not re-run both files in full afterwards.

The design-contract hash for chat/markdown.tsx is renewed. Its reviewed boundary, MessageMarkdown passing on className, is unchanged.

Experiment progress (renew_experiment) picks up the connector-side fix. The server-side check covers build heartbeats only.