Skip to content

docs(spec): Phase 2 design — unified agent panel + 2a plan#204

Merged
BunsDev merged 2 commits into
mainfrom
docs/unified-agent-panel-phase2-spec
Jul 18, 2026
Merged

docs(spec): Phase 2 design — unified agent panel + 2a plan#204
BunsDev merged 2 commits into
mainfrom
docs/unified-agent-panel-phase2-spec

Conversation

@BunsDev

@BunsDev BunsDev commented Jul 18, 2026

Copy link
Copy Markdown
Member

Description

Design/spec PR for review — no implementation. Phase 2 of the Coven agent-surface reconciliation: merge CastCodes' two AI-conversation panels into one unified panel.

Phase 1 (#201) made both surfaces render through the shared agent_transcript module. They still diverge everywhere else: the shipped ai_assistant/Familiar panel (Coven daemon, stream-history.json, "Coven Sessions" list) vs. the feature-flagged cli_chat panel (OSC-777 CLIs in a terminal, sqlite, conversation list, model picker, composer).

Two documents under specs/castcodes-unified-agent-panel/:

Doc What it is
DESIGN.md A new app/src/agent_panel hosting a conversation model generalized over ConversationBackend { Cli(AgentKind) | Daemon{harness} }, fed by two sources (CLIAgentSessions + a Coven-daemon source), one sqlite store (add a backend column; non-destructive stream-history.json migration), one composer routing per backend, one entry point. Backend picker + native mechanics (daemon headless-in-panel, CLIs stay in a terminal pane); OSC-777 retirement stays deferred to Phase 3. Both old panels deprecated behind a flag, deleted after parity.
PLAN-2a.md Code-complete, 6-task TDD plan for sub-phase 2a — the shared conversation core + schema/data migration — behavior-preserving (gated by cli_chat's suite).

What I'd like reviewed

  1. The unified-panel architecture — a new panel both fold into (vs. taking over one existing panel), generalized over ConversationBackend.
  2. The interaction model — backend picker + native mechanics (daemon headless, CLIs in a terminal), unifying presentation/list/history/persistence but not the launch mechanics (that's Phase 3).
  3. The stream-history.json → sqlite migration — non-destructive (rename to .migrated, one text blob → one AssistantResponse entry). OK, or drop the old text history and start fresh?
  4. Deprecation staging — land behind a flag, delete the two old panels in a follow-up after parity (vs. same PR).

Non-goals of this PR

  • No code — design/spec only. 2a implementation follows once the approach is agreed; 2b–2d get their own plans after 2a lands.
  • Phase 3 (routing CLIs through the daemon / retiring OSC-777) is deferred.

Linked Issue

Continues the reconciliation roadmap (specs/castcodes-coven-agent-transcript/, Phase 1 shipped in #201). No separate tracking issue.

  • The linked issue is labeled ready-to-spec or ready-to-implement.

Testing

  • Docs-only. ./script/check_ai_attribution + ./script/check_rebrand pass.
  • I have manually tested my changes locally with ./script/run (n/a — specs only).

Agent Mode

BunsDev added 2 commits July 18, 2026 00:30
Design for merging CastCodes' two AI-conversation panels (the shipped
ai_assistant/Familiar daemon panel and the feature-flagged cli_chat
OSC-777 panel) into one surface. A new app/src/agent_panel hosts a
conversation model generalized over a ConversationBackend enum
(Cli(AgentKind) | Daemon{harness}), fed by two sources (CLIAgentSessions
+ a Coven-daemon source), persisted in the existing sqlite ChatStore
(add a backend column; non-destructive idempotent migration of
stream-history.json), with one composer routing per backend and one
entry point. Backend picker + native mechanics (daemon headless-in-panel,
CLIs stay in a terminal pane); OSC-777 retirement deferred to Phase 3.
Both old panels deprecated behind a flag, deleted after parity.
…migration)

Bite-sized TDD plan for 2a: add a ConversationBackend enum
(Cli(AgentKind)|Daemon{harness}), generalize ChatConversation over it, a
schema v2 `backend` column migration, and a non-destructive idempotent
stream-history.json -> sqlite data migration. Behavior-preserving for the
CLI path (cli_chat suite gates it). 2b-2d get their own plans after 2a.
Copilot AI review requested due to automatic review settings July 18, 2026 05:40

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Design/spec documentation for Phase 2 of reconciling CastCodes’ two agent conversation surfaces, proposing a new unified agent panel architecture and a TDD plan for sub-phase 2a (shared conversation core + persistence/migration groundwork) without landing implementation.

Changes:

  • Adds a Phase 2 design doc describing the unified agent panel architecture (backend picker, unified list/history/store, staged deprecation).
  • Adds a Phase 2a implementation plan to generalize cli_chat over a ConversationBackend enum and migrate ~/.coven/stream-history.json into sqlite.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
specs/castcodes-unified-agent-panel/DESIGN.md Defines the Phase 2 unified agent panel architecture, data flow, risks, and staged rollout approach.
specs/castcodes-unified-agent-panel/PLAN-2a.md Provides a task-by-task TDD plan for Phase 2a: backend enum + schema/store changes + stream-history migration.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.


3. **Persistence** — the existing sqlite `ChatStore`, extended:
- Schema migration (`chat_schema_version` bump): add a `backend` column to `chat_conversation` (`'cli'` for existing rows, `'daemon'` for coven-code). `agent` continues to carry the harness/kind name.
- One-time, **non-destructive, idempotent** data migration: read `~/.coven/stream-history.json` (`{conversation_id, text}` records), insert each as a `coven-code` `Daemon` conversation with a single `AssistantResponse` entry, then rename the file `.migrated` (never delete user data). Guarded by a migration marker so it runs once.
Comment on lines +191 to +193
// Apply only version 1, insert a legacy row, then migrate to current.
conn.execute_batch(super::super::store_schema::V1_FOR_TEST).unwrap();
conn.execute(
let _ = std::fs::rename(&path, path.with_extension("json.migrated"));
}
```
Confirm `ChatStore::insert_entry` uses `INSERT OR IGNORE` (or add `OR IGNORE`) so re-inserting `sequence = 0` is a no-op — verify against `store.rs` line ~72 (`insert_entry`); if it's a plain `INSERT`, change to `INSERT OR IGNORE` for idempotency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants