Feat: board redraft loop (#139)

* feat(board): expose board review brief + guard approve-and-start

Slice 1 of the board-informed intake re-draft loop (backend foundation):

- JournalService.board_review_brief(task_id): the PO + Head of Marketing
  DECISION_LOG entries for a task, oldest-first, each tagged with author —
  the board's review as structured data.
- GET /api/tasks/{task_id}/board-review (PM-or-above) backing the CEO's
  approval/redraft surface, so the real board analysis is readable instead
  of a placeholder; BoardReviewEntry response schema.
- Guard: approve_and_start now refuses a board task whose review is not
  complete (service invariant + precise BOARD_REVIEW_INCOMPLETE at the route).
  Previously only the UI hid the button; the backend let an early/rogue call
  hand the task to Main PM mid-review.

Tests: brief filtering/ordering + endpoint (200/404) + the two guard paths.

* feat(panel): show real board review at the approve gate + live refresh

Slice 1 frontend of the board-informed intake re-draft loop:

- tasksApi.getBoardReview + useBoardReview hook consume GET
  /tasks/{id}/board-review.
- The Approve & Start dialog now renders the actual Product Owner + Head of
  Marketing notes (markdown) instead of a static placeholder, so the CEO reads
  the board's analysis before approving.
- C2: useTask polls (4s) while a task is still on the board with an
  incomplete review, so the Approve & Start button appears as soon as the
  board finishes — there is no per-task websocket. Polling stops once
  board_review_complete flips.

* feat(intake): board-informed re-draft loop (backend, cold path)

Slice 2 of the re-draft loop:

- update_live_draft: apply a board-informed re-draft to the EXISTING task in
  place (title/description/acceptance_criteria) — never a duplicate — then route
  it: 'main_pm' hands it to the Main PM via approve_and_start; 'board' clears
  board_review_complete for another review round.
- confirm route branches on task_id → update_live_draft vs confirm_live_draft;
  LiveConfirmRequest.task_id added (scope taken from the task, not required).
- POST /live/re-interview/{task_id} (PM-or-above): spawns a fresh intake session
  seeded with the current draft + the board brief (compose_redraft_message),
  scoped to the task's product/project. The cold path + Slice-3 fallback.
- format_board_briefing / compose_redraft_message helpers.

Tests: pure helpers + update_live_draft (main_pm hand-off, re-board reset,
missing-task).

* feat(panel): board-informed re-draft entry + prompter re-draft guidance

Slice 2 panel of the re-draft loop:

- 'Re-draft with board feedback' button on a board-reviewed task detail →
  /prompter?redraft=<taskId>.
- usePrompter.startRedraft(taskId): calls POST /prompter/live/re-interview/{id},
  scopes the chat to the task, and streams the re-draft; redraftTaskId is
  threaded (persisted across reload) so confirm carries task_id and updates the
  existing task in place rather than creating a duplicate.
- prompterLiveApi.reInterview; ConfirmPayload.task_id.
- Prompter role prompt: a 'Re-drafting after board review' section so the agent
  revises the included draft from the board brief instead of starting over.

Panel verified by CI (no local node_modules).

* feat(intake): keep-alive re-draft — park the intake agent during board review

Slice 3 of the re-draft loop (in-context fidelity; cold path is the fallback):

- Registry: LiveIntakeSession.task_id + park(session_id, task_id) (keep alive
  instead of reaping) + find_by_task() for board-completion injection.
- Confirm: the board route (first pass) PARKS the intake agent instead of
  reaping, so it keeps the whole interview in context.
- Orchestrator: on board-review completion, inject the synthesized board brief
  into the parked session (_inject_board_brief_into_parked_intake) so the
  resident prompter re-drafts in-context. No-op when nothing is parked (the
  container died / a new intake replaced it) — the cold /re-interview path
  covers that. No reaper change needed (an idle parked session spends no tokens
  and the budget sweep is the only agent-stopping sweep).
- Panel: confirm(board) keeps the chat alive (parked, redraftTaskId set) with a
  notice; the injected revised draft arrives over the existing stream to approve.

Tests: registry park/find_by_task/closed-ignored. Container delivery + the full
panel parked flow need live (container-runtime) verification.

---------

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

agents/prompts/roles/prompter.md

@@ -70,6 +70,20 @@ When — and only when — you can write a complete spec:
 
 A draft card appears for the human with three choices: **Keep chatting**, **Board review & Start**, or **Approve & Start**. **Choosing is the human's action, not yours** — you cannot create, start, or route the task. If they pick **Board review & Start**, it becomes a pending task owned by the Board (Product Owner + Head of Marketing) to review first; if they pick **Approve & Start**, it becomes a pending task that goes straight to the Main PM to delegate to the cells. Either way, your job ends the moment you call `propose_draft`. Do not say you'll "kick it off", "send it to the PM chain", or route it anywhere — you have no such ability, and which path it takes is the human's choice on the card.
 
+## Re-drafting after board review
+
+Sometimes your opening message is not a fresh request but a **revision brief**: it
+contains the current task draft plus the Product Owner / Head of Marketing review
+("You are revising an existing task draft with board feedback"). When that happens:
+
+- Treat the included draft as the starting point — you are improving it, not
+  starting over. Keep what's good; change what the board flagged.
+- Fold the board's points into the spec (naming, scope, acceptance criteria, risks
+  they called out). Where two reviewers conflict, reconcile sensibly and note it.
+- Briefly say what you changed and why, then **call `propose_draft`** with the
+  revised draft. The human reviews the new draft and confirms it — which updates
+  the same task, not a new one.
+
 ## Workflow
 
 1. Read the scoped repo(s) to ground yourself in the real surface.