Paliadin: opt into aichat multi-conversation (sidebar history, resumable threads, recall MCP) #63

Open
opened 2026-05-20 12:26:41 +00:00 by mAi · 0 comments
Collaborator

Trigger

Delegation from mai/head 2026-05-20 14:25 (mAi project): aichat (the centralized Claude-in-tmux backend that powers Paliadin) just shipped multi-conversation as a primitive across all personas (m/mAi#243). Hugo / Lexie will get the same surface. paliad/Paliadin opt-in is gated on this issue.

Aichat-side is fully shipped + deployed on mRiver (5 PRs, ~7700 LOC). No paliad change is needed for the current behaviour to continue — legacy single-thread keeps working until we opt in.

What opting in unlocks

  • Sidebar of past Paliadin conversations per user, each resumable.
  • 'Was hatten wir vor zwei Wochen besprochen?' — the agent can read its own history via the aichat-history MCP server (4 read-only tools, RLS-scoped to the calling user).
  • Backfill of existing paliad.paliadin_turns audit log as a single 'Imported history' conversation (optional, separate subcommand).

5 asks from mai/head

  1. DSN provisioning — pick a Postgres role + DB in paliad's Supabase for aichat to write aichat.conversations, aichat.turns, etc. Apply 00001_init.sql (idempotent). Set the DSN env var on mRiver's aichat systemd unit. Credential-bearing — escalate to m.
  2. MCP HMAC secretAICHAT_MCP_HMAC_SECRET gates the history MCP. Recommended: enable from day one so Paliadin can answer 'in welcher Konferenz hatten wir das gesagt?'. Per-pane bearer tokens scope reads to (tenant=paliad, user=m, persona=paliadin) server-side.
  3. paliad relay changesPOST /chat/turn/stream body gains optional conversation_id; response carries conversation_id + resumed. New endpoints to wrap as pass-throughs: GET/POST /chat/conversations, POST /<id>/select, DELETE /<id> (soft), PATCH /<id>, GET /<id>/turns.
  4. Frontend — conversation chooser sidebar in paliad's chat surface. 'New conversation' button maps to POST /chat/conversations + select. Conversation switch hydrates via GET /chat/conversations/<id>/turns.
  5. paliadin_turns backfill — optional. mai/head can instruct a coder to add the migrate subcommand if we want the historical context surfaced in the new sidebar.

Sequencing (mai/head's recommendation)

DSN provisioned → tenant added → migrations applied → MCP secret (if opted in) → paliad's relay PR → frontend PR → soak → done.

paliad-side decisions to make (head can decide unless flagged)

  • DSN env var name: recommended PALIAD_AICHAT_DSN.
  • MCP secret enable: recommended yes from day one — context recall is the headline UX win. The bearer-token scoping is server-enforced; no information leak risk.
  • Backfill: recommended yes, runs once per user, fully reversible. Defer until the new sidebar is live so the imported history has a place to land.
  • Frontend sidebar shape: recommended a left-rail collapsible list (same shape as Hugo/Lexie are getting) + a 'New conversation' button + per-row rename/delete affordances. m's design language: lime-accent active state.

Hard escalations to m

  • The Postgres password for the new aichat role — m owns the paliad Supabase creds. Head proposes generating a strong random password via Supabase MCP, but m signs off.
  • 'When to opt in' — current paliad backlog is heavy; opt-in lands in a follow-up wave after the current 16-issue batch stabilises. m confirms cadence.

References

  • Design doc: m/mAi:docs/design/aichat-conversations-2026-05-20.md
  • Deploy runbook: m/mAi:docs/runbooks/aichat-deploy.md
  • youpcorg cutover (in flight in parallel)

Role recommendation

inventor → coder for the paliad side. The relay + frontend work is meaningful (~few hundred LOC); inventor maps out the relay endpoint contracts + the sidebar UX, then a coder ships. Pair with #62 (Paliadin SKILL.md improvements) since both touch the Paliadin surface.

## Trigger Delegation from `mai/head` 2026-05-20 14:25 (mAi project): aichat (the centralized Claude-in-tmux backend that powers Paliadin) just shipped multi-conversation as a primitive across all personas (m/mAi#243). Hugo / Lexie will get the same surface. paliad/Paliadin opt-in is gated on this issue. Aichat-side is fully shipped + deployed on mRiver (5 PRs, ~7700 LOC). No paliad change is needed for the current behaviour to continue — legacy single-thread keeps working until we opt in. ## What opting in unlocks - Sidebar of past Paliadin conversations per user, each resumable. - 'Was hatten wir vor zwei Wochen besprochen?' — the agent can read its own history via the `aichat-history` MCP server (4 read-only tools, RLS-scoped to the calling user). - Backfill of existing `paliad.paliadin_turns` audit log as a single 'Imported history' conversation (optional, separate subcommand). ## 5 asks from mai/head 1. **DSN provisioning** — pick a Postgres role + DB in paliad's Supabase for aichat to write `aichat.conversations`, `aichat.turns`, etc. Apply `00001_init.sql` (idempotent). Set the DSN env var on mRiver's aichat systemd unit. **Credential-bearing — escalate to m.** 2. **MCP HMAC secret** — `AICHAT_MCP_HMAC_SECRET` gates the history MCP. Recommended: enable from day one so Paliadin can answer 'in welcher Konferenz hatten wir das gesagt?'. Per-pane bearer tokens scope reads to (tenant=paliad, user=m, persona=paliadin) server-side. 3. **paliad relay changes** — `POST /chat/turn/stream` body gains optional `conversation_id`; response carries `conversation_id` + `resumed`. New endpoints to wrap as pass-throughs: `GET/POST /chat/conversations`, `POST /<id>/select`, `DELETE /<id>` (soft), `PATCH /<id>`, `GET /<id>/turns`. 4. **Frontend** — conversation chooser sidebar in paliad's chat surface. 'New conversation' button maps to `POST /chat/conversations` + `select`. Conversation switch hydrates via `GET /chat/conversations/<id>/turns`. 5. **paliadin_turns backfill** — optional. mai/head can instruct a coder to add the migrate subcommand if we want the historical context surfaced in the new sidebar. ## Sequencing (mai/head's recommendation) DSN provisioned → tenant added → migrations applied → MCP secret (if opted in) → paliad's relay PR → frontend PR → soak → done. ## paliad-side decisions to make (head can decide unless flagged) - **DSN env var name**: recommended `PALIAD_AICHAT_DSN`. - **MCP secret enable**: recommended **yes from day one** — context recall is the headline UX win. The bearer-token scoping is server-enforced; no information leak risk. - **Backfill**: recommended **yes**, runs once per user, fully reversible. Defer until the new sidebar is live so the imported history has a place to land. - **Frontend sidebar shape**: recommended a left-rail collapsible list (same shape as Hugo/Lexie are getting) + a 'New conversation' button + per-row rename/delete affordances. m's design language: lime-accent active state. ## Hard escalations to m - The Postgres password for the new aichat role — m owns the paliad Supabase creds. Head proposes generating a strong random password via Supabase MCP, but m signs off. - 'When to opt in' — current paliad backlog is heavy; opt-in lands in a follow-up wave after the current 16-issue batch stabilises. m confirms cadence. ## References - Design doc: `m/mAi:docs/design/aichat-conversations-2026-05-20.md` - Deploy runbook: `m/mAi:docs/runbooks/aichat-deploy.md` - youpcorg cutover (in flight in parallel) ## Role recommendation **inventor → coder** for the paliad side. The relay + frontend work is meaningful (~few hundred LOC); inventor maps out the relay endpoint contracts + the sidebar UX, then a coder ships. Pair with #62 (Paliadin SKILL.md improvements) since both touch the Paliadin surface.
mAi self-assigned this 2026-05-20 12:26:41 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#63
No description provided.