II.
Page overview
Reference · livepage:docs-agent-mux-archive-design-20-tui-kanban-workspaces
Agent Mux TUI Kanban + Workspaces Design overview
Inspect the raw attributes, linked wiki pages, and inbound or outbound graph edges for page:docs-agent-mux-archive-design-20-tui-kanban-workspaces.
Attributes
nodeKind
Page
sourcePath
docs/agent-mux/archive/design/20-tui-kanban-workspaces.md
sourceKind
repo-docs
title
Agent Mux TUI Kanban + Workspaces Design
displayName
Agent Mux TUI Kanban + Workspaces Design
slug
docs/agent-mux/archive/design/20-tui-kanban-workspaces
articlePath
wiki/docs/agent-mux/archive/design/20-tui-kanban-workspaces.md
article
# Agent Mux TUI Kanban + Workspaces Design
## Summary
This design proposal covers adding `kanban` and `workspaces` views to `packages/agent-mux/tui` as a thin presentation and command layer over existing `packages/kanban` and `packages/agent-mux/core` seams.
The key architectural decision is simple:
- `packages/agent-mux/tui` owns Ink rendering, navigation, and action invocation
- `packages/kanban` remains the owner of backlog policy and workspace/worktree lifecycle
- `packages/agent-mux/core` remains the shared type contract
## Why this direction
The repository already has the hard parts:
- shared kanban/workspace types in `packages/agent-mux/core/src/kanban.ts`
- backlog policy and issue mutation logic in `packages/kanban/src/lib/services/backlog-query-service.ts`
- worktree-aware workspace lifecycle logic in `packages/kanban/src/lib/workspace-lifecycle.ts`
- MCP tool surfaces in `packages/kanban/src/mcp/tools/backlog.ts` and `packages/kanban/src/mcp/tools/workspaces.ts`
Duplicating those behaviors in the TUI would create:
- divergent issue/workspace mutation rules
- duplicated worktree inventory logic
- higher regression risk across CI/release and staging publish flows
## Proposed package seams
### `packages/agent-mux/tui`
Add:
- a package-local integration adapter for kanban/workspace state
- `kanban` and `workspaces` plugins under `src/plugins/`
- cross-view navigation wiring in `src/app.tsx`
- command-palette and hotkey integration
- view-contract and feature tests
### `packages/agent-mux/core`
Only add or refine shared types here when the TUI needs a stable contract that does not yet exist.
Do not import `packages/kanban` private service result types into the TUI if they should be shared.
### `packages/kanban`
Keep ownership of:
- backlog state and mutation policy
- workspace/worktree lifecycle
- issue-to-workspace provisioning and linking
Refine tool payloads or typed seams only where the TUI integration proves a real contract gap.
## View model expectations
### `kanban`
The first phase can start with a backlog/issue-centric presentation instead of a dense ncurses-style board.
The important requirement is that it exposes:
- issue state
- dispatch/readiness state
- repository lifecycle state
- workspace/session linkage
- management actions
### `workspaces`
The workspaces surface must stay worktree-aware.
It should expose:
- workspace path/name/branch/head
- primary repo vs linked worktree state
- archived/missing/rebase states
- linked issue context
- active session/run context
- lifecycle actions
## CI and publish implications
This feature touches both `@a5c-ai/agent-mux-tui` and the shared kanban/workspace release-critical surfaces.
That means implementation needs to remain compatible with:
- `.github/workflows/ci.yml`
- `.github/workflows/release.yml`
- `.github/workflows/staging-publish.yml`
It also means the TUI package should ship its new `specs/` directory if the README links to those planning artifacts.
## Planning artifacts
The canonical planning artifacts for this proposal are:
- `packages/agent-mux/tui/specs/kanban-workspaces-spec.md`
- `packages/agent-mux/tui/specs/kanban-workspaces-subtasks.md`
- `.a5c/processes/agent-mux-tui-kanban-workspaces-planning.js`
- `.a5c/processes/specs/agent-mux-tui-kanban-workspaces-planning-request.md`
documents
[]
Outgoing edges
None.
Incoming edges
contains_page1
- page:docs-agent-mux-archive-design·Pageagent-mux archive: design