Fix roundtable capture: sequential AskUserQuestion + per-participant analysis rows + MCP tools for dedicated tables

[ZaxShen]

Context

Surfaced during PR #64 Mode A dogfood (Zax, 2026-04-25). Roundtable runs end-to-end and lands a 1-line roundtable_summary ledger row + a markdown summary file at docs/trustmybot/roundtable/<date>-<topic>.md. But significant trajectory data is lost. Per Zax's review, three independent fixes:

Fix 1 — AskUserQuestion, ONE QUESTION AT A TIME

Symptom

Roundtable's "open questions for Human" phase outputs the questions as plain text:

1. Website secondary, CLI primary — yes?
2. OK to roll our own auth UI instead of paying Clerk?
3. Marketing page in v1, or just GitHub + Homebrew?

Tell me the answers and I'll spawn the SWE work for whichever shape you pick.

Human types "yes" / "yes" / "no" as freeform text. Bro then writes discussion_append(kind='answer') + discussion_append(kind='decision') per answer. Works, but:

• No structured trigger event — the skill is inferring "this is the answer" from context.
• Worse UX — Human types instead of clicking.
• Likelier to lose answers (Human's reply could be ambiguous; AskUserQuestion forces clarity).

Fix

tmb_roundtable skill calls AskUserQuestion one question per call, sequentially. Not batched.

Why one-at-a-time (per Zax's UX preference):

• Each answer can inform the next question (e.g., "auth?" → if yes, "provider?").
• Human isn't overwhelmed with 3 forms at once.
• Bro processes each answer immediately and can write the kind='decision' row before showing the next question.

The trade-off (3 round trips instead of 1) is acceptable for a meeting that already takes minutes. The latency gain from batching is not worth the UX cost here.

Acceptance

• tmb_roundtable skill emits Step "Ask Human's open questions" — for EACH question, call AskUserQuestion with a single question, wait for answer, write discussion_append(kind='answer') + discussion_append(kind='decision'), THEN proceed to next question
• Plain-text question output (the "Tell me the answers and I'll..." pattern) is forbidden in the roundtable skill
• If a question's answer is "Other" or freeform, bro re-prompts with a follow-up AskUserQuestion to refine

Fix 2 — Per-participant kind='analysis' rows during the meeting

Symptom

Each participant's position currently lives ONLY in the markdown summary file. The skill never writes discussion_append(kind='analysis', author='<participant>') rows during the meeting.

So if next week you ask "why did cto argue against Clerk?", you can read the markdown summary's bullet point but cannot pull cto's exact reasoning row from the audit trail.

Fix (decision: SHIP IT)

tmb_roundtable writes ONE discussion_append(kind='analysis', author='<participant-name>') row per participant DURING the meeting (not at the end, not just in the markdown). The markdown file remains as the human-readable rollup; the discussion rows are the replayable audit.

Cost: 1 extra MCP call per participant (2-4 calls total per roundtable). Negligible vs the value of replay-ability.

Acceptance

• After collecting each participant's position, bro writes discussion_append(kind='analysis', author='<participant-name>', body=<their full position text>) BEFORE the next participant is consulted (or BEFORE the synthesis if last)
• The markdown summary file at docs/trustmybot/roundtable/<date>-<topic>.md continues to exist as the human-readable rollup; not a substitute for the discussion rows
• discussions table for the issue contains one analysis row per participant after the roundtable

Fix 3 — MCP tool surface for dedicated roundtables + roundtable_votes tables

Symptom

Schema includes roundtables (id, issue_id, topic, status, outcome, created_at, closed_at) and roundtable_votes (id, roundtable_id, agent, vote, rationale, created_at) — but ZERO rows landed during the dogfood test. No MCP wrapper exists, so the LLM physically cannot write to them.

Existing schema (verified via .schema):

CREATE TABLE roundtables (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    issue_id    INTEGER NOT NULL REFERENCES issues(id),
    topic       TEXT    NOT NULL,
    status      TEXT    NOT NULL DEFAULT 'open',
    outcome     TEXT    NOT NULL DEFAULT '',
    created_at  TEXT    NOT NULL,
    closed_at   TEXT
);

CREATE TABLE roundtable_votes (
    id             INTEGER PRIMARY KEY AUTOINCREMENT,
    roundtable_id  INTEGER NOT NULL REFERENCES roundtables(id),
    agent          TEXT    NOT NULL,
    vote           TEXT    NOT NULL,
    rationale      TEXT    NOT NULL DEFAULT '',
    created_at     TEXT    NOT NULL
);

Fix (per Zax: "good idea")

Add three MCP tools, all bro-only via requireRoles(['bro']):

1. roundtable_create(agent='bro', issue_id, topic) → returns { roundtable_id }. Inserts a row into roundtables with status='open'.
2. roundtable_vote(agent='bro', roundtable_id, agent_name, vote, rationale) → appends a row to roundtable_votes. Called once per participant after their analysis.
3. roundtable_close(agent='bro', roundtable_id, outcome) → flips status='closed', sets outcome, sets closed_at. Called after Human answers the open questions.

Then tmb_roundtable skill is updated to:

• Call roundtable_create at the start
• Call roundtable_vote per participant (alongside the discussion_append(kind='analysis') from Fix 2 — different audit views of the same event)
• Call roundtable_close after Human answers in Fix 1

Acceptance

• Three MCP tools exist with requireRoles(['bro']) enforcement
• Schema is unchanged (the tables already exist)
• tmb_roundtable skill calls all three at the appropriate phases
• After a roundtable, the dedicated tables have rows (not just the ledger summary + markdown file)
• Layer 2 integration tests cover the happy path + role-rejection cases (architect/swe/pr-reviewer should be forbidden)

Doctrine summary post-fix

When a roundtable runs, capture lands in FOUR places:

1. discussions — one kind='analysis' row per participant (replayable per-voice)
2. discussions — kind='answer' + kind='decision' rows for each Human-answered question (Fix 1)
3. roundtables + roundtable_votes — structured meeting record (Fix 3)
4. docs/trustmybot/roundtable/<date>-<topic>.md — human-readable rollup (existing)
5. ledger.roundtable_summary — 1-line audit anchor (existing)

Lossy capture eliminated. Replay quality from any of the four DB views.

Priority

Medium-High. Roundtable is one of the highest-information events in the workflow (multi-perspective decisions); losing replay quality bleeds value over time.

Related

• Multi-consultant voting protocol (architect/cto/ceo as advisors, not deciders) #57 (multi-consultant voting protocol — companion design issue)
• tmb_roundtable trigger ergonomics — Human shouldn't have to say the literal word "roundtable" #67 (roundtable trigger ergonomics — discoverability)
• PR 🚧 chore: latency reduction — proposals on review #64 (latency reduction — explicitly excluded these fixes from scope)

[ZaxShen]

Issue tracking moved to Linear. This issue continues as TRU-13: https://linear.app/trustmybot/issue/TRU-13

GitHub issues are no longer the active tracker for this project — see the Linear workspace for current state. Closed-as-migrated, not closed-as-resolved.

[ZaxShen]

Disregard the prior 'closed-as-migrated' comment. GitHub remains the public issue tracker for this project — file new issues, PRs, and discussion here as normal. TMB team mirrors this issue internally to Linear (TRU-13) for our own workflow, but that mirror is auto-synced from GitHub — contributors don't need a Linear account.

[ZaxShen]

Closing — focusing on v0.8.x. Planning lives on GitLab milestones (v0.8.0 / v0.8.1). Will re-mirror active items to GH once tri-source schema sync (#48) lands.