[nexus] fix(audit): resolve integration checker findings — straggler strings, query param pre-fill, orphaned import

- Alias uses absolute path (path.resolve) for correct Vite import resolution
- [nexus] comment marks the change for rebase visibility
- Original OnboardingWizard.tsx and App.tsx remain unmodified

.planning/MILESTONES.md

@@ -1,12 +0,0 @@
-# Milestones
-
-## v1.2.1 Universal Skill Management (Shipped: 2026-04-01)
-
-**Phases completed:** 1 phases, 2 plans, 2 tasks
-
-**Key accomplishments:**
-
-- One-liner:
-- Zone taxonomy (DISPLAY/CODE/STORED), commit-msg hook enforcing [nexus] prefix, and git rerere established as rebase safety infrastructure before any upstream files are modified
-
----

.planning/PROJECT.md

@@ -1,124 +0,0 @@
-# Nexus
-
-## What This Is
-
-Nexus is a personal fork of Paperclip (MIT, v2026.318.0) that reframes the "companies with CEOs" corporate metaphor as "workspaces with agents." It's a project orchestration tool for a solo developer (Mikkel) managing AI agents across personal and professional projects. The fork stays mergeable with upstream by limiting changes to the display layer (UI strings, CLI output, agent templates, documentation) while leaving DB schema, API routes, code identifiers, and token formats unchanged.
-
-## Core Value
-
-A fresh onboard asks for ONE thing (root directory), auto-creates PM + Engineer agents, and drops you in the dashboard — no company names, missions, or corporate language anywhere.
-
-## Requirements
-
-### Validated
-
-- Existing Paperclip agent orchestration engine (heartbeats, task lifecycle, adapters)
-- Plugin system with worker isolation and host/worker RPC
-- Multi-adapter support (Claude Code, Codex, Cursor, Gemini, OpenCode, Pi, Hermes)
-- Issue/task management with sub-issues, priorities, assignments
-- Project entity (groups issues, lead agent, git repo integration)
-- Execution workspaces with git worktree isolation
-- Cost tracking and budget enforcement
-- Routine/cron scheduled task creation
-- Real-time SSE updates to UI
-- CLI tooling (onboard, run, doctor, configure, client commands)
-- Company import/export portability
-- Board authentication (local_trusted + authenticated modes)
-
-### Active
-
-- [ ] Onboarding redesign: root directory picker, auto-create PM + Engineer, skip to dashboard
-- [ ] Terminology rename (display only): Company→Workspace, CEO→Project Manager, Board→Owner, Hire→Add, Fire→Remove, Paperclip→Nexus
-- [ ] Predefined agent templates: PM and Engineer with sensible AGENTS.md, HEARTBEAT.md, SOUL.md, TOOLS.md
-- [ ] Directory restructure: everything under user-chosen root, no ~/.paperclip/, human-readable agent dirs
-- [ ] ~/.nexus pointer file mechanism (single file with root path)
-- [ ] UI overhaul: Nexus branding, sidebar renames, dashboard cleanup, agent config page cleanup
-- [ ] New Agent dialog: "Add Agent" button, predefined templates dropdown
-- [ ] CLI output strings updated (paperclipai branding → nexus branding where display-only)
-
-### Out of Scope
-
-- DB schema renames (companies table, company_id columns) — upstream sync priority
-- API route path changes (/api/companies stays) — upstream sync priority
-- TypeScript identifier renames (companyService, boardAuthService etc.) — upstream sync priority
-- Package name renames (@paperclipai/* stays) — upstream sync priority
-- Environment variable renames (PAPERCLIP_* stays) — upstream sync priority
-- Token prefix changes (pcp_board_* stays) — would invalidate issued tokens
-- Plugin API contract changes (company.created events, companies.read capability) — breaks plugins
-- .paperclip.yaml export format rename — breaks upstream import compatibility
-- Recipe Registry plugin — separate project
-- Catppuccin Mocha full theme — stretch goal, not v1
-- Telegram Channels integration — future
-- NPM reverse proxy — future
-- Danish business integrations — future
-- Multi-workspace support — works via existing multi-company feature, just renamed
-
-## Context
-
-**Upstream:** [paperclipai/paperclip](https://github.com/paperclipai/paperclip) — MIT licensed
-**Fork repo:** /Volumes/UsbNvme/repos/nexus/ (origin: git.georgsen.dk/mikkel/nexus)
-**Working directory:** /Volumes/UsbNvme/agent/
-
-**Codebase:** TypeScript monorepo (pnpm workspaces). Server (Express), UI (React/Vite), CLI (Commander.js), packages (db/shared/adapter-utils/adapters), plugins (SDK + examples).
-
-**Key naming collision resolved:** Paperclip already has a `Project` entity (groups issues, has lead agent, git repo). Original PRD renamed Company→Project but that collides. Decision: Company→Workspace in display layer. Existing Project entity stays unchanged.
-
-**Rename strategy:** Display-only. All user-facing surfaces (UI strings, CLI output, agent template content, error messages, documentation) get renamed. All code-level identifiers, DB schema, API routes, env vars, token prefixes stay as upstream for merge compatibility.
-
-**Existing "Project" in Paperclip:** Projects live under a Company (now displayed as "Workspace"). A Workspace contains Projects, which contain Issues. This maps cleanly to Nexus's mental model.
-
-**Fork maintenance:** [nexus] commit prefix for all Nexus changes. Periodic `git rebase upstream/master` to stay current. Display-only changes minimize conflict surface.
-
-## Constraints
-
-- **Upstream sync**: All changes must be display-layer only to allow `git rebase upstream/master` with minimal conflicts
-- **Deploy target**: Mac Mini M4 only, local_trusted mode, single user
-- **No data migration**: No changes to DB tables, columns, stored enum values, or migration files
-- **Forgejo**: Push to git.georgsen.dk/mikkel/nexus (SSH port 2222)
-
-## Key Decisions
-
-| Decision | Rationale | Outcome |
-|----------|-----------|---------|
-| Company → Workspace (not Project) | Paperclip already has a Project entity; naming collision | -- Pending |
-| Display-only renames | Upstream sync priority; minimize merge conflicts | -- Pending |
-| Keep all @paperclipai/* package names | Thousands of import statements; mechanical but huge merge conflict surface | -- Pending |
-| Keep API routes (/api/companies) | UI translates on client side; server stays upstream-compatible | -- Pending |
-| Keep DB schema unchanged | No migrations, no data migration, clean upstream rebase | -- Pending |
-
-## Evolution
-
-This document evolves at phase transitions and milestone boundaries.
-
-**After each phase transition** (via `/gsd:transition`):
-1. Requirements invalidated? → Move to Out of Scope with reason
-2. Requirements validated? → Move to Validated with phase reference
-3. New requirements emerged? → Add to Active
-4. Decisions to log? → Add to Key Decisions
-5. "What This Is" still accurate? → Update if drifted
-
-**After each milestone** (via `/gsd:complete-milestone`):
-1. Full review of all sections
-2. Core Value check — still the right priority?
-3. Audit Out of Scope — reasons still valid?
-4. Update Context with current state
-5. **Post-milestone upstream rebase** (see below)
-
-## Post-Milestone Upstream Rebase (Nexus-Specific)
-
-After every `/gsd:complete-milestone`, perform an upstream rebase before starting the next milestone. This keeps conflicts small and manageable — upstream Paperclip is active (120+ commits since fork).
-
-**Steps:**
-1. `git fetch upstream master` — fetch latest upstream
-2. `git rebase upstream/master` — rebase nexus/main onto upstream
-3. Resolve conflicts: merge upstream content into Nexus vocabulary (don't just delete upstream additions)
-4. `pnpm dev` — verify build still works after rebase
-5. `git push origin nexus/main --force-with-lease` — push to Forgejo (git.georgsen.dk)
-6. Log rebase result in STATE.md: commits behind before, conflicts resolved count, build status
-
-**Why:** Waiting too long means compound conflicts. Each milestone boundary is a natural sync point — code is tested, tagged, and stable.
-
-**Autonomous mode:** The autonomous workflow MUST check for this section and run the rebase after `complete-milestone` returns, before starting the next milestone.
-
----
-*Last updated: 2026-04-01 after v1.2.1 milestone*

.planning/REQUIREMENTS.md

@@ -1,183 +0,0 @@
-# Requirements: v1.3 Web Chat Interface
-
-**Milestone:** v1.3
-**Status:** Queued
-**Source PRD:** ~/Downloads/nexus-v1.3-prd-web-chat.md
-**Depends on:** v1.2 (Skill Aggregator + Generalist Agent)
-**Total v1 requirements:** 65
-
----
-
-## Categories
-
-### Chat Core (14)
-
-- [ ] **CHAT-01** — Real-time streaming responses: tokens appear as they are generated, not after completion
-- [x] **CHAT-02** — Markdown rendering in messages: code blocks with syntax highlighting, tables, lists, headings, links, images
-- [x] **CHAT-03** — Code blocks have a one-click copy button and a language label
-- [x] **CHAT-04** — Multiple concurrent conversations: sidebar shows the full conversation list
-- [x] **CHAT-05** — Conversation titles: auto-generated from the first message, manually editable by the user
-- [x] **CHAT-06** — Delete, archive, and pin conversations
-- [ ] **CHAT-07** — Full-text search across all conversations
-- [ ] **CHAT-08** — Agent selector: switch which agent you are talking to mid-conversation or per-conversation
-- [ ] **CHAT-09** — System message indicator: when the Brainstormer hands off to PM, or PM delegates to Engineer, the handoff is visible in chat
-- [ ] **CHAT-10** — Message editing: edit a previous message and regenerate the response
-- [ ] **CHAT-11** — Response regeneration: retry button on any assistant message
-- [ ] **CHAT-12** — Stop generation: cancel button available while a response is streaming
-- [ ] **CHAT-13** — Message reactions / bookmarks: mark important messages for later reference
-- [ ] **CHAT-14** — Conversation branching: editing a mid-conversation message creates a branch; both branches are preserved
-
-### Input (7)
-
-- [x] **INPUT-01** — Multi-line text input with auto-resize: grows with content up to a max height before scrolling
-- [ ] **INPUT-02** — File/image upload via drag-and-drop or button with inline preview before sending
-- [ ] **INPUT-03** — Paste image from clipboard directly into the chat input
-- [ ] **INPUT-04** — Voice input via Whisper (when local AI is enabled): record button with transcription preview before sending
-- [ ] **INPUT-05** — Slash commands: `/brainstorm`, `/ask-pm`, `/ask-engineer`, `/task`, `/search`
-- [ ] **INPUT-06** — `@mention` agents: type `@engineer` to route a message to a specific agent
-- [x] **INPUT-07** — Keyboard shortcuts: Enter to send, Shift+Enter for newline, Cmd+K for search, Escape to cancel
-
-### Agent Integration (7)
-
-- [ ] **AGENT-01** — Default agent is the Brainstormer (Generalist with a Superpowers-style system prompt, or a dedicated 4th Brainstormer agent)
-- [ ] **AGENT-02** — Brainstormer follows a structured questioning flow: asks clarifying questions, produces a spec template, and hands off to PM
-- [ ] **AGENT-03** — PM agent can receive specs from chat and create Nexus tasks/issues from them
-- [ ] **AGENT-04** — Agent responses show which agent is speaking with avatar and name
-- [ ] **AGENT-05** — Handoff indicators visible in chat: "Brainstormer → PM: Here's the spec for approval"
-- [ ] **AGENT-06** — Task creation from chat: user or agent can say "create a task for this" and it becomes a Nexus issue
-- [ ] **AGENT-07** — Status updates from agents appear in chat: "Engineer completed task X" notification in the relevant conversation
-
-### History & Persistence (6)
-
-- [x] **HIST-01** — All conversations persisted in libSQL
-- [x] **HIST-02** — Conversation list in sidebar: sorted by most recent, searchable, filterable by agent
-- [x] **HIST-03** — Infinite scroll in the conversation list sidebar
-- [ ] **HIST-04** — Conversation export: download as Markdown or JSON
-- [x] **HIST-05** — Cross-device sync: conversations accessible from any device on the network via the Nexus server API
-- [x] **HIST-06** — Chat history survives server restarts: no in-memory-only state
-
-### PWA & Mobile (8)
-
-- [ ] **PWA-01** — Service worker for offline capability: cached UI loads instantly, queues messages until back online
-- [ ] **PWA-02** — Web App Manifest: installable on iOS, Android, macOS, and Windows as a standalone app
-- [ ] **PWA-03** — Responsive layout: adapts to phone, tablet, and desktop screen sizes
-- [ ] **PWA-04** — Mobile-optimized input: large touch targets, sticky input bar at bottom, keyboard-aware resize
-- [ ] **PWA-05** — Pull-to-refresh on the mobile conversation list
-- [ ] **PWA-06** — Push notifications (where supported): agent mentions, task completions, handoff requests
-- [ ] **PWA-07** — App icon and splash screen with Nexus branding, theme-aware
-- [ ] **PWA-08** — "Add to Home Screen" prompt on first mobile visit
-
-### Theme Integration (3)
-
-- [x] **THEME-01** — Chat interface respects the Nexus theme system (Catppuccin Mocha, Tokyo Night, Catppuccin Latte)
-- [x] **THEME-02** — Code blocks use theme-appropriate syntax highlighting colors
-- [ ] **THEME-03** — Agent avatars/colors are visually distinguishable in all three themes
-
-### Performance (5)
-
-- [ ] **PERF-01** — Initial load under 2 seconds on broadband, under 5 seconds on 3G
-- [ ] **PERF-02** — Streaming response latency under 100ms from server to UI
-- [ ] **PERF-03** — Conversations with 1,000+ messages scroll smoothly via a virtualized list
-- [ ] **PERF-04** — Full-text search returns results in under 500ms across 10,000+ messages
-- [ ] **PERF-05** — PWA cached load under 1 second
-
-### File System (13)
-
-- [ ] **FILE-01** — Local file storage directory structure under `<nexus-root>/files/` with subdirectories: `projects/<slug>/assets/`, `projects/<slug>/docs/`, `projects/<slug>/generated/`, `projects/<slug>/placeholders/`, `chat/<conversation-id>/`, and `exports/`
-- [ ] **FILE-02** — libSQL `files` table tracking all file metadata: id, filename, original_filename, mime_type, size_bytes, storage_path, git_hash, checksum, dual-scope fields (project_id, conversation_id, message_id, agent_id, workspace_id, task_id), source, category, placeholder fields, and lifecycle timestamps
-- [ ] **FILE-03** — libSQL `file_references` table enabling a single file to be referenced from multiple conversations without duplication
-- [ ] **FILE-04** — Dual scoping: a file uploaded during a project-linked conversation lives in `files/projects/<slug>/` but is also referenced by the chat message; a file in a general chat (no project context) lives in `files/chat/<conversation-id>/`
-- [ ] **FILE-05** — File upload from chat input via drag-and-drop or button; file is stored on disk and its metadata is written to libSQL
-- [ ] **FILE-06** — Inline file preview in chat: images render inline, PDFs show a first-page preview, code files show a syntax-highlighted preview
-- [ ] **FILE-07** — One-click file download from chat for any attached or generated file
-- [ ] **FILE-08** — Agent-generated files (code output, specs, presentations) stored in `files/projects/<slug>/generated/`, linked to the originating task and conversation in libSQL
-- [ ] **FILE-09** — Git integration: `files/` is a git repository; every file operation (upload, generate, replace, delete) creates a commit with a descriptive message
-- [ ] **FILE-10** — Version history: user can view the git log for any file and see its change history
-- [ ] **FILE-11** — Placeholder asset tracking: Nexus auto-maintains a `PLACEHOLDERS.md` manifest in each project directory; when a placeholder is replaced by a final asset, the manifest and DB are updated with the replacement chain
-- [ ] **FILE-12** — File scope promotion: a chat-scoped file can be promoted to a project scope; a project file can be referenced in any chat conversation
-- [ ] **FILE-13** — Cross-device file access: files are served via the Nexus server API so a file uploaded on one device is accessible on any other device on the network
-
----
-
-## Out of Scope (v1.4+)
-
-The following are explicitly deferred:
-
-- Voice call / audio conversation mode
-- Video sharing / screen recording in chat
-- Collaborative chat (multiple human users in one conversation)
-- End-to-end encryption
-- Chat API for third-party integrations
-- Custom chat themes beyond the Nexus theme system
-- Chat-based agent configuration / settings changes
-- Telegram bridge (Telegram messages appearing in web chat and vice versa)
-
----
-
-## Traceability
-
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| CHAT-01 | Phase 22 | Pending |
-| CHAT-02 | Phase 21 | Complete |
-| CHAT-03 | Phase 21 | Complete |
-| CHAT-04 | Phase 21 | Complete |
-| CHAT-05 | Phase 21 | Complete |
-| CHAT-06 | Phase 21 | Complete |
-| CHAT-07 | Phase 24 | Pending |
-| CHAT-08 | Phase 22 | Pending |
-| CHAT-09 | Phase 23 | Pending |
-| CHAT-10 | Phase 22 | Pending |
-| CHAT-11 | Phase 22 | Pending |
-| CHAT-12 | Phase 22 | Pending |
-| CHAT-13 | Phase 24 | Pending |
-| CHAT-14 | Phase 24 | Pending |
-| INPUT-01 | Phase 21 | Complete |
-| INPUT-02 | Phase 25 | Pending |
-| INPUT-03 | Phase 25 | Pending |
-| INPUT-04 | Phase 25 | Pending |
-| INPUT-05 | Phase 22 | Pending |
-| INPUT-06 | Phase 22 | Pending |
-| INPUT-07 | Phase 21 | Complete |
-| AGENT-01 | Phase 23 | Pending |
-| AGENT-02 | Phase 23 | Pending |
-| AGENT-03 | Phase 23 | Pending |
-| AGENT-04 | Phase 22 | Pending |
-| AGENT-05 | Phase 23 | Pending |
-| AGENT-06 | Phase 23 | Pending |
-| AGENT-07 | Phase 23 | Pending |
-| HIST-01 | Phase 21 | Complete |
-| HIST-02 | Phase 21 | Complete |
-| HIST-03 | Phase 21 | Complete |
-| HIST-04 | Phase 24 | Pending |
-| HIST-05 | Phase 21 | Complete |
-| HIST-06 | Phase 21 | Complete |
-| PWA-01 | Phase 26 | Pending |
-| PWA-02 | Phase 26 | Pending |
-| PWA-03 | Phase 26 | Pending |
-| PWA-04 | Phase 26 | Pending |
-| PWA-05 | Phase 26 | Pending |
-| PWA-06 | Phase 26 | Pending |
-| PWA-07 | Phase 26 | Pending |
-| PWA-08 | Phase 26 | Pending |
-| THEME-01 | Phase 21 | Complete |
-| THEME-02 | Phase 21 | Complete |
-| THEME-03 | Phase 22 | Pending |
-| PERF-01 | Phase 26 | Pending |
-| PERF-02 | Phase 22 | Pending |
-| PERF-03 | Phase 22 | Pending |
-| PERF-04 | Phase 24 | Pending |
-| PERF-05 | Phase 26 | Pending |
-| FILE-01 | Phase 25 | Pending |
-| FILE-02 | Phase 25 | Pending |
-| FILE-03 | Phase 25 | Pending |
-| FILE-04 | Phase 25 | Pending |
-| FILE-05 | Phase 25 | Pending |
-| FILE-06 | Phase 25 | Pending |
-| FILE-07 | Phase 25 | Pending |
-| FILE-08 | Phase 25 | Pending |
-| FILE-09 | Phase 25 | Pending |
-| FILE-10 | Phase 25 | Pending |
-| FILE-11 | Phase 25 | Pending |
-| FILE-12 | Phase 25 | Pending |
-| FILE-13 | Phase 25 | Pending |

.planning/ROADMAP.md

@@ -1,193 +0,0 @@
-# Roadmap: v1.3 Web Chat Interface
-
-**Milestone:** v1.3
-**Status:** Queued (not yet active)
-**Phases:** 21–26 (6 phases)
-**Granularity:** Standard
-**Coverage:** 65/65 requirements mapped
-
----
-
-## Phases
-
-- [x] **Phase 21: Chat Foundation** — Persistent conversation storage, sidebar, CRUD, markdown rendering, theme integration, keyboard shortcuts (completed 2026-04-01)
-- [ ] **Phase 22: Agent Streaming** — Real-time streaming via SSE/WebSocket, agent selector, agent identity on messages, stop/edit/regenerate, slash commands and @mentions
-- [ ] **Phase 23: Brainstormer Flow** — Brainstormer agent persona, structured questioning flow, spec generation, PM handoff, task creation from chat, agent status updates in chat
-- [ ] **Phase 24: Search, History & Branching** — Full-text search across all conversations, export, conversation branching, message bookmarks
-- [ ] **Phase 25: File System** — Local file storage with dual scoping, libSQL tracking, inline preview, download, agent-generated files, git versioning, placeholder tracking
-- [ ] **Phase 26: PWA & Performance** — Service worker, Web App Manifest, responsive mobile layout, push notifications, install prompt, performance targets
-
----
-
-## Phase Details
-
-### Phase 21: Chat Foundation
-**Goal**: Users can open Nexus, create and manage conversations, and read fully rendered agent responses — with persistent storage and correct theme styling from the start
-**Depends on**: Nothing (first phase of v1.3; depends on v1.2 milestone being shipped)
-**Requirements**: CHAT-02, CHAT-03, CHAT-04, CHAT-05, CHAT-06, INPUT-01, INPUT-07, HIST-01, HIST-02, HIST-03, HIST-05, HIST-06, THEME-01, THEME-02
-**Success Criteria** (what must be TRUE):
-  1. User can create a new conversation, give it a title, and see it appear in the sidebar conversation list
-  2. User can delete, archive, and pin conversations from the sidebar
-  3. Agent messages render with full markdown: code blocks with syntax highlighting and a copy button, tables, lists, headings, links, and inline images
-  4. Conversations and all messages are stored in libSQL and survive a server restart
-  5. The chat interface applies Catppuccin Mocha, Tokyo Night, and Catppuccin Latte themes correctly; code block highlighting matches the active theme
-**Plans:** 4/4 plans complete
-Plans:
-- [x] 21-01-PLAN.md — DB schema, shared types, service layer, and REST API for conversations and messages
-- [x] 21-02-PLAN.md — ChatMarkdownMessage with syntax highlighting/copy button, ChatInput with auto-resize/keyboard shortcuts, theme CSS
-- [x] 21-03-PLAN.md — Chat API client, panel context, hooks, ChatPanel/ConversationList/MessageList, Layout integration
-- [x] 21-04-PLAN.md — Full test suite verification and visual/functional checkpoint
-**UI hint**: yes
-
-### Phase 22: Agent Streaming
-**Goal**: Users receive live streaming responses from any agent they select, with full control to stop, edit, or retry — and agent identity is clearly visible on every message
-**Depends on**: Phase 21
-**Requirements**: CHAT-01, CHAT-08, CHAT-10, CHAT-11, CHAT-12, INPUT-05, INPUT-06, AGENT-04, THEME-03, PERF-02, PERF-03
-**Success Criteria** (what must be TRUE):
-  1. Tokens from an agent appear in the chat window as they are generated; the first token appears in under 500ms
-  2. User can switch the active agent for a conversation at any time via the agent selector
-  3. Every assistant message shows the agent's name and avatar; agent colors are distinguishable across all three themes
-  4. User can click Stop to cancel an in-progress streaming response
-  5. User can edit a previous message to regenerate the response, or click Retry on any existing assistant message; conversations with 1,000+ messages scroll without jank via a virtualized list
-  6. Slash commands (`/brainstorm`, `/ask-pm`, `/ask-engineer`, `/task`, `/search`) route messages to the correct agent; `@mention` syntax routes to the named agent
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 23: Brainstormer Flow
-**Goal**: Users can open Nexus, start a conversation with the Brainstormer, receive structured clarifying questions, approve a spec, and watch it become real Nexus tasks — without ever touching the dashboard
-**Depends on**: Phase 22
-**Requirements**: AGENT-01, AGENT-02, AGENT-03, AGENT-05, AGENT-06, AGENT-07, CHAT-09
-**Success Criteria** (what must be TRUE):
-  1. The Brainstormer is the default agent when a user opens a new conversation; it greets the user and begins a structured questioning flow
-  2. After the user answers clarifying questions, the Brainstormer produces a formatted spec card with What / Why / Constraints / Success fields and action buttons (Send to PM, Edit, Save as Draft)
-  3. When the user clicks "Send to PM," a handoff indicator appears in the chat showing "Brainstormer → PM" with the spec content
-  4. The PM agent creates one or more Nexus issues from the spec; the user can see task IDs referenced in the PM's reply
-  5. When an Engineer or Generalist completes a task, a status update message appears in the relevant chat conversation
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 24: Search, History & Branching
-**Goal**: Users can find any message across all conversations in under 500ms, export conversations, bookmark key messages, and branch from any point in a conversation
-**Depends on**: Phase 21
-**Requirements**: CHAT-07, CHAT-13, CHAT-14, HIST-04, PERF-04
-**Success Criteria** (what must be TRUE):
-  1. Cmd+K opens a search overlay; typing a query returns matching messages from all conversations in under 500ms, even with 10,000+ messages stored
-  2. User can bookmark any message and later filter or navigate to bookmarked messages
-  3. Editing a message that already has a response creates a new branch; both the original and the new branch are preserved and the user can switch between them
-  4. User can export any conversation as a Markdown file or as a JSON file containing all messages and metadata
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 25: File System
-**Goal**: Users and agents can upload, generate, preview, and download files in chat, with all files tracked in libSQL, version-controlled by git, and accessible across devices
-**Depends on**: Phase 21
-**Requirements**: FILE-01, FILE-02, FILE-03, FILE-04, FILE-05, FILE-06, FILE-07, FILE-08, FILE-09, FILE-10, FILE-11, FILE-12, FILE-13, INPUT-02, INPUT-03, INPUT-04
-**Success Criteria** (what must be TRUE):
-  1. User can drag-and-drop a file or image onto the chat input, see an inline preview, and send it; the file is stored on disk under `<nexus-root>/files/` and its metadata is written to libSQL
-  2. User can paste an image from the clipboard directly into the chat input and send it
-  3. Images attached to messages render inline in the message; PDFs show a first-page preview; code files show a syntax-highlighted preview; any file can be downloaded with one click
-  4. Every file operation (upload, agent generation, replacement, deletion) produces a git commit in the `files/` repository; user can view the git log for any file
-  5. When an agent generates a placeholder asset, `PLACEHOLDERS.md` is updated in the project directory; when the placeholder is replaced, the DB records the replacement chain and the manifest reflects the change
-  6. A file uploaded in a conversation linked to a project lives in `files/projects/<slug>/`; a file from an unlinked conversation lives in `files/chat/<conversation-id>/`; the user can promote a chat file to project scope
-  7. Voice input is available when local AI is enabled: user can hold the record button, speak, see a transcription preview, and confirm to send
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 26: PWA & Performance
-**Goal**: Nexus is installable as a standalone app on any device, loads under 2 seconds, and works offline — delivering the full chat experience on phone, tablet, and desktop
-**Depends on**: Phase 22
-**Requirements**: PWA-01, PWA-02, PWA-03, PWA-04, PWA-05, PWA-06, PWA-07, PWA-08, PERF-01, PERF-05
-**Success Criteria** (what must be TRUE):
-  1. On first mobile visit, the browser shows an "Add to Home Screen" prompt; after installation the app opens as a standalone window with no browser chrome
-  2. The installed app has a Nexus icon and theme-aware splash screen on iOS, Android, macOS, and Windows
-  3. When the device goes offline, the cached UI loads in under 1 second and queues outgoing messages; messages are delivered automatically when the connection returns
-  4. On a phone, the input bar is sticky at the bottom of the screen, touch targets are large enough to tap without errors, and the layout resizes correctly when the software keyboard appears
-  5. Pulling down on the conversation list on mobile triggers a refresh; push notifications arrive for agent mentions, task completions, and handoff requests where the platform supports them
-  6. The initial page load on broadband completes in under 2 seconds and on a 3G connection in under 5 seconds; PWA cached load completes in under 1 second
-**Plans**: TBD
-**UI hint**: yes
-
----
-
-## Coverage Validation
-
-All 65 v1 requirements are mapped to exactly one phase. No orphans.
-
-| Requirement | Phase |
-|-------------|-------|
-| CHAT-01 | 22 |
-| CHAT-02 | 21 |
-| CHAT-03 | 21 |
-| CHAT-04 | 21 |
-| CHAT-05 | 21 |
-| CHAT-06 | 21 |
-| CHAT-07 | 24 |
-| CHAT-08 | 22 |
-| CHAT-09 | 23 |
-| CHAT-10 | 22 |
-| CHAT-11 | 22 |
-| CHAT-12 | 22 |
-| CHAT-13 | 24 |
-| CHAT-14 | 24 |
-| INPUT-01 | 21 |
-| INPUT-02 | 25 |
-| INPUT-03 | 25 |
-| INPUT-04 | 25 |
-| INPUT-05 | 22 |
-| INPUT-06 | 22 |
-| INPUT-07 | 21 |
-| AGENT-01 | 23 |
-| AGENT-02 | 23 |
-| AGENT-03 | 23 |
-| AGENT-04 | 22 |
-| AGENT-05 | 23 |
-| AGENT-06 | 23 |
-| AGENT-07 | 23 |
-| HIST-01 | 21 |
-| HIST-02 | 21 |
-| HIST-03 | 21 |
-| HIST-04 | 24 |
-| HIST-05 | 21 |
-| HIST-06 | 21 |
-| PWA-01 | 26 |
-| PWA-02 | 26 |
-| PWA-03 | 26 |
-| PWA-04 | 26 |
-| PWA-05 | 26 |
-| PWA-06 | 26 |
-| PWA-07 | 26 |
-| PWA-08 | 26 |
-| THEME-01 | 21 |
-| THEME-02 | 21 |
-| THEME-03 | 22 |
-| PERF-01 | 26 |
-| PERF-02 | 22 |
-| PERF-03 | 22 |
-| PERF-04 | 24 |
-| PERF-05 | 26 |
-| FILE-01 | 25 |
-| FILE-02 | 25 |
-| FILE-03 | 25 |
-| FILE-04 | 25 |
-| FILE-05 | 25 |
-| FILE-06 | 25 |
-| FILE-07 | 25 |
-| FILE-08 | 25 |
-| FILE-09 | 25 |
-| FILE-10 | 25 |
-| FILE-11 | 25 |
-| FILE-12 | 25 |
-| FILE-13 | 25 |
-
----
-
-## Progress
-
-| Phase | Milestone | Plans Complete | Status | Completed |
-|-------|-----------|----------------|--------|-----------|
-| 21. Chat Foundation | v1.3 | 4/4 | Complete    | 2026-04-01 |
-| 22. Agent Streaming | v1.3 | 0/? | Not started | - |
-| 23. Brainstormer Flow | v1.3 | 0/? | Not started | - |
-| 24. Search, History & Branching | v1.3 | 0/? | Not started | - |
-| 25. File System | v1.3 | 0/? | Not started | - |
-| 26. PWA & Performance | v1.3 | 0/? | Not started | - |

.planning/STATE.md

@@ -1,102 +0,0 @@
----
-gsd_state_version: 1.0
-milestone: v1.3
-milestone_name: milestone
-status: executing
-stopped_at: Completed 21-03-PLAN.md
-last_updated: "2026-04-01T12:16:05.775Z"
-last_activity: 2026-04-01
-progress:
-  total_phases: 6
-  completed_phases: 1
-  total_plans: 4
-  completed_plans: 4
-  percent: 0
----
-
-# Project State
-
-## Project Reference
-
-See: .planning/PROJECT.md (updated 2026-03-30)
-
-**Core value:** Fresh onboard asks for ONE thing (root directory), auto-creates PM + Engineer, drops you in dashboard — no corporate language anywhere.
-**Current focus:** Phase 21 — chat-foundation
-
-## Current Position
-
-Phase: 22
-Plan: Not started
-Status: Ready to execute
-Last activity: 2026-04-01
-
-Progress: [░░░░░░░░░░] 0%
-
-### Upstream Rebase Log
-
-| Date | Commits Behind | Conflicts | Build | Notes |
-|------|---------------|-----------|-------|-------|
-| 2026-04-01 | 0 | 0 | OK | Already rebased from 120+ commits session; upstream hasn't moved |
-
-## Performance Metrics
-
-**Velocity:**
-
-- Total plans completed: 0
-- Average duration: -
-- Total execution time: 0 hours
-
-**By Phase:**
-
-| Phase | Plans | Total | Avg/Plan |
-|-------|-------|-------|----------|
-| - | - | - | - |
-
-**Recent Trend:**
-
-- Last 5 plans: none yet
-- Trend: -
-
-*Updated after each plan completion*
-| Phase 01-foundation P01 | 2 | 2 tasks | 7 files |
-| Phase 21-chat-foundation P02 | 15 | 3 tasks | 7 files |
-| Phase 21-chat-foundation P01 | 4 | 2 tasks | 15 files |
-| Phase 21-chat-foundation P03 | 5 | 2 tasks | 9 files |
-
-## Accumulated Context
-
-### Decisions
-
-Decisions are logged in PROJECT.md Key Decisions table.
-Recent decisions affecting current work:
-
-- Roadmap: Company → Workspace (not Project) to avoid collision with existing Project entity
-- Roadmap: Display-only renames — all code identifiers, DB schema, routes, env vars unchanged
-- Roadmap: Branding package (`packages/branding/`) as single string mutation surface
-- Roadmap: Vite alias redirects OnboardingWizard import to Nexus-owned replacement (Phase 4)
-- Roadmap: `~/.nexus` pointer file with read-both-paths fallback for migration safety (Phase 2)
-- [Phase 01-foundation]: Keep @paperclipai/branding package name for upstream sync compatibility
-- [Phase 01-foundation]: Use as const for VOCAB to enable TypeScript literal type inference on all values
-- [Phase 01-foundation]: Hook source tracked in scripts/nexus-commit-msg-hook.sh for post-clone reinstallation
-- [Phase 01-foundation]: rerere.autoupdate=true so resolved conflicts are auto-staged during future rebases
-- [Phase 21-chat-foundation]: highlight.js 11.11.1 (via lowlight) lacks base16/catppuccin-mocha.css; wrote all three theme color palettes inline via .dark, .theme-tokyo-night, :root:not(.dark) selectors
-- [Phase 21-chat-foundation]: ChatInput/ChatMarkdownMessage tests use jsdom+createRoot+act (not @testing-library/react which is not installed)
-- [Phase 21-chat-foundation]: isNull(chatConversations.title) with AND condition for idempotent title-setting on first message
-- [Phase 21-chat-foundation]: listConversations fetches limit+1 to determine hasMore without extra COUNT query
-- [Phase 21-chat-foundation]: mutateAsync(undefined) required for optional-arg mutations in TanStack Query — TS2554 fix
-- [Phase 21-chat-foundation]: ChatInput focus management uses DOM querySelector('[aria-label=Message input]') to avoid ref threading across component tree
-
-### Pending Todos
-
-None yet.
-
-### Blockers/Concerns
-
-- Phase 4: `POST /api/companies` required fields not fully documented — read `server/src/routes/companies.ts` before implementing new wizard
-- Phase 3: Exact count of test files asserting on old display strings unknown — grep audit needed as first step
-
-## Session Continuity
-
-Last session: 2026-04-01T11:13:12.828Z
-Stopped at: Completed 21-03-PLAN.md
-Resume file: None

.planning/codebase/ARCHITECTURE.md

@@ -1,512 +0,0 @@
-# Architecture
-
-**Analysis Date:** 2026-03-30
-**Codebase:** Paperclip (nexus repo at `/Volumes/UsbNvme/repos/nexus/`)
-
----
-
-## Pattern Overview
-
-**Overall:** Multi-package TypeScript monorepo. Server-rendered React SPA (Vite) + Express API server + CLI tool + adapter plugin system.
-
-**Key Characteristics:**
-- pnpm workspaces monorepo with five top-level workspace members: `server`, `ui`, `cli`, `packages/*`, `plugins/*`
-- Express REST API with actor-based auth middleware (board users, agents, instance admin)
-- React SPA using React Router v6 with company-prefixed URL scheme (e.g., `/PAP/issues`)
-- Agent execution driven by a heartbeat lifecycle: wakeup requests → heartbeat runs → adapter subprocess calls
-- Plugin system with isolated worker processes and structured host/worker RPC
-
----
-
-## Monorepo Structure
-
-```
-nexus/
-├── server/              # Express API + business logic
-│   ├── src/
-│   │   ├── routes/      # Express route handlers
-│   │   ├── services/    # Business logic layer
-│   │   ├── adapters/    # Agent execution adapter registry
-│   │   ├── auth/        # BetterAuth integration
-│   │   ├── middleware/  # auth, logging, validation, error handling
-│   │   ├── realtime/    # WebSocket live-events bridge
-│   │   ├── secrets/     # Secret provider abstraction
-│   │   ├── storage/     # S3/local file storage abstraction
-│   │   └── app.ts       # Express app factory
-├── ui/                  # React SPA (Vite)
-│   └── src/
-│       ├── pages/       # Top-level page components
-│       ├── components/  # Shared UI components
-│       ├── context/     # React contexts (company, dialog, live updates)
-│       ├── api/         # API client modules (one per domain)
-│       ├── hooks/       # Custom React hooks
-│       └── App.tsx      # Router + route tree
-├── cli/                 # paperclipai CLI (Commander.js)
-│   └── src/
-│       ├── commands/    # CLI command implementations
-│       ├── config/      # Config file read/write
-│       └── prompts/     # @clack/prompts interactive wizards
-├── packages/
-│   ├── db/              # Drizzle ORM schema + migrations + DB client
-│   ├── shared/          # Shared types, validators (Zod), constants
-│   ├── adapter-utils/   # Shared adapter type contracts + session utils
-│   └── adapters/        # Adapter packages (one per AI tool)
-│       ├── claude-local/
-│       ├── codex-local/
-│       ├── cursor-local/
-│       ├── gemini-local/
-│       ├── opencode-local/
-│       ├── pi-local/
-│       └── openclaw-gateway/
-└── plugins/
-    ├── sdk/             # @paperclipai/plugin-sdk (worker-side SDK)
-    ├── create-paperclip-plugin/  # Plugin scaffolding tool
-    └── examples/        # Example plugins
-```
-
----
-
-## Layers
-
-**Database Layer:**
-- Purpose: Schema definitions, migrations, Drizzle ORM client
-- Location: `packages/db/src/`
-- Contains: Drizzle table definitions in `schema/`, migration SQL in `migrations/`, `client.ts` (embedded Postgres or external URL)
-- Depends on: PostgreSQL (embedded via `embedded-postgres` or external)
-- Used by: Server services exclusively
-
-**Services Layer:**
-- Purpose: All business logic; one service function per domain
-- Location: `server/src/services/`
-- Contains: `agentService`, `companyService`, `heartbeatService`, `issueService`, `pluginLifecycleManager`, etc.
-- Pattern: Each service is a factory function taking `db: Db` and returning an object of async methods. No class instances.
-- Depends on: `@paperclipai/db` schema tables, other services
-- Used by: Route handlers
-
-**Route Layer:**
-- Purpose: HTTP request parsing, auth assertions, response shaping
-- Location: `server/src/routes/`
-- Contains: One file per resource domain (companies, agents, issues, projects, routines, plugins, etc.)
-- Pattern: Each route file exports a factory `function fooRoutes(db: Db): Router`. Routes call service methods, assert auth via `assertBoard` / `assertCompanyAccess` helpers.
-- Depends on: Services layer, middleware
-
-**Middleware Layer:**
-- Purpose: Cross-cutting request processing
-- Location: `server/src/middleware/`
-- Files:
-  - `auth.ts` — `actorMiddleware`: resolves `req.actor` as board user, agent, or none
-  - `board-mutation-guard.ts` — blocks unsafe mutations on read-only mounts
-  - `private-hostname-guard.ts` — hostname allowlist enforcement
-  - `validate.ts` — Zod schema validation helper
-  - `logger.ts` — pino logger
-  - `error-handler.ts` — global Express error handler
-
-**Adapter Layer:**
-- Purpose: Execute agents via different AI tools (Claude, Codex, Cursor, etc.)
-- Location: `server/src/adapters/` (registry + process/http sub-adapters), `packages/adapters/` (per-tool implementations)
-- Pattern: Each adapter implements `ServerAdapterModule` from `@paperclipai/adapter-utils`. The registry (`registry.ts`) maps adapter type strings to module instances. `heartbeatService` calls `getServerAdapter(type).execute(...)` to run agents.
-
-**UI Layer:**
-- Purpose: React SPA for the board (human operators)
-- Location: `ui/src/`
-- API communication: `ui/src/api/client.ts` — simple `fetch` wrapper. All domain API modules (e.g., `ui/src/api/agents.ts`) use this `api` object. No external HTTP library.
-- State: TanStack Query (`@tanstack/react-query`) for server state. React Context for cross-component state (company selection, dialogs, live updates, theme).
-- Real-time: SSE from `/api/realtime` consumed by `LiveUpdatesProvider` in `ui/src/context/LiveUpdatesProvider.tsx`.
-
-**CLI Layer:**
-- Purpose: Operator tooling — first-run setup, diagnostics, server run, one-off commands
-- Location: `cli/src/`
-- Framework: Commander.js with `@clack/prompts` for interactive steps
-
----
-
-## Authentication Model
-
-Two principal types flow through `actorMiddleware` (`server/src/middleware/auth.ts`):
-
-**Board (human):**
-- `local_trusted` deployment: automatically granted `isInstanceAdmin: true`, no auth needed
-- `authenticated` deployment: BetterAuth session cookie OR bearer API key (from `board_api_keys` table)
-- `req.actor.type === "board"`, carries `userId`, `companyIds[]`, `isInstanceAdmin`
-
-**Agent:**
-- Bearer token: either a hashed API key from `agent_api_keys` table, or a short-lived JWT (`createLocalAgentJwt`)
-- `req.actor.type === "agent"`, carries `agentId`, `companyId`
-- Agents cannot access other companies; CEO agents get additional mutation rights (branding, portability)
-
-Route authorization helpers live in `server/src/routes/authz.ts`:
-- `assertBoard(req)` — throws 403 if not board
-- `assertCompanyAccess(req, companyId)` — throws 403 if actor cannot access this company
-- `assertInstanceAdmin(req)` — throws 403 if not instance admin
-
----
-
-## Company Model
-
-Companies are the top-level tenant container. They map to what will become "projects" in Nexus.
-
-**Schema:** `packages/db/src/schema/companies.ts`
-```
-companies
-  id uuid (PK)
-  name text
-  description text
-  status text  (active | paused | archived)
-  issuePrefix text UNIQUE  // e.g. "PAP" — used in URLs and identifiers
-  issueCounter integer     // auto-increment for issue numbers
-  budgetMonthlyCents integer
-  requireBoardApprovalForNewAgents boolean
-  brandColor text
-```
-
-**Company creation flow (`POST /api/companies`):**
-1. Board asserts instance admin
-2. `companyService.create(data)` inserts company
-3. `accessService.ensureMembership(...)` adds creator as owner in `company_memberships`
-4. If budget set, `budgetService.upsertPolicy(...)` creates budget policy
-5. Activity logged
-
-**Company service:** `server/src/services/companies.ts` — `companyService(db)` factory returning `list`, `getById`, `create`, `update`, `archive`, `remove`, `stats`.
-
-**Company portability:** `server/src/services/company-portability.ts` — import/export bundles; CEO agents can run imports/exports on their own company.
-
-**Company members:** `packages/db/src/schema/company_memberships.ts` — `principalType` (user|agent), `principalId`, `companyId`, `role` (owner|member), `status` (active|invited|etc.)
-
----
-
-## Agent Model
-
-Agents are AI workers belonging to a company. CEO is a special role with elevated permissions.
-
-**Schema:** `packages/db/src/schema/agents.ts`
-```
-agents
-  id uuid (PK)
-  companyId uuid (FK companies)
-  name text
-  role text         // "ceo" | "general" | custom
-  title text
-  reportsTo uuid    // self-referential FK for org chart
-  status text       // idle | running | paused | terminated | pending_approval
-  adapterType text  // "claude_local" | "codex_local" | "cursor" | etc.
-  adapterConfig jsonb   // adapter-specific config (model, instructionsFilePath, etc.)
-  runtimeConfig jsonb   // session compaction policy, max concurrent runs
-  budgetMonthlyCents integer
-  permissions jsonb     // canCreateAgents, etc.
-  lastHeartbeatAt timestamp
-```
-
-**Agent service:** `server/src/services/agents.ts` — `agentService(db)` factory. Key methods:
-- `create`, `update`, `pause`, `resume`, `terminate`, `remove`
-- `orgForCompany(companyId)` — builds hierarchical org tree from `reportsTo` links
-- `getChainOfCommand(agentId)` — walks up `reportsTo` chain
-- `createApiKey`, `listKeys`, `revokeKey`
-- `rollbackConfigRevision` — restores an agent config from `agent_config_revisions`
-
-**CEO agents:** Identified by `role === "ceo"`. Only CEO agents can:
-- Update company branding (`PATCH /api/companies/:id/branding`)
-- Manage company portability (import/export)
-- The default first task in onboarding is assigned to the CEO agent
-
----
-
-## Agent Heartbeat / Task Lifecycle
-
-This is the core execution engine. An "agent run" is called a **heartbeat run**.
-
-**Flow:**
-
-```
-1. Wake request queued
-   → agent_wakeup_requests (status: queued)
-   → agentWakeupRequest.source = "timer" | "assignment" | "on_demand" | "automation"
-
-2. heartbeatService.runHeartbeat(agentId, options)
-   → acquires per-agent start lock (Map<agentId, Promise>)
-   → checks concurrent run limits (runtimeConfig.maxConcurrentRuns, default 1)
-   → resolves execution workspace (project repo, task session, or agent home dir)
-   → resolves session state (previous session params from agent_task_sessions)
-   → checks session compaction (rotate if maxSessionRuns / maxRawInputTokens exceeded)
-   → inserts heartbeat_runs row (status: queued → running)
-
-3. getServerAdapter(adapterType).execute(context, meta)
-   → adapter launches subprocess or HTTP call
-   → streams stdout/stderr chunks back
-   → heartbeatService writes live log chunks to run log store
-
-4. On completion:
-   → updates heartbeat_runs (status: done | error | cancelled)
-   → persists session state to agent_task_sessions
-   → writes cost event to cost_events
-   → publishes live event to EventEmitter for SSE clients
-   → updates issue status if issue was being worked
-
-5. Wakeup request marked finished
-```
-
-**Key tables:**
-- `heartbeat_runs` — one row per execution (`packages/db/src/schema/heartbeat_runs.ts`)
-- `agent_wakeup_requests` — queued wakeup requests, coalesced by idempotency key
-- `agent_task_sessions` — persisted session params per (agent, adapterType, taskKey)
-- `agent_runtime_state` — current session ID for an agent
-
-**heartbeatService:** `server/src/services/heartbeat.ts` (~1400 lines). The central orchestrator. Dependencies: adapter registry, workspace services, session codec, budget service, issue service, cost service.
-
----
-
-## Adapter System
-
-Adapters wrap specific AI tools (Claude Code, OpenAI Codex, Cursor, Gemini, etc.).
-
-**Contract:** `ServerAdapterModule` from `packages/adapter-utils/`. Key methods:
-- `execute(context, meta): Promise<AdapterExecutionResult>` — run the agent
-- `testEnvironment(config): Promise<AdapterEnvironmentTestResult>` — check prerequisites
-- `listSkills/syncSkills` — skill management
-- `sessionCodec` — serialize/deserialize session state
-- `onHireApproved` (optional) — notify adapter when a hired agent is approved
-
-**Registry:** `server/src/adapters/registry.ts` — maps type string to `ServerAdapterModule`. Falls back to `processAdapter` for unknown types.
-
-**Registered adapter types:**
-- `claude_local` — Claude Code CLI subprocess (`packages/adapters/claude-local/`)
-- `codex_local` — OpenAI Codex (`packages/adapters/codex-local/`)
-- `opencode_local` — OpenCode (`packages/adapters/opencode-local/`)
-- `pi_local` — Pi adapter (`packages/adapters/pi-local/`)
-- `cursor` — Cursor IDE (`packages/adapters/cursor-local/`)
-- `gemini_local` — Gemini CLI (`packages/adapters/gemini-local/`)
-- `openclaw_gateway` — HTTP gateway adapter (`packages/adapters/openclaw-gateway/`)
-- `process` — generic subprocess adapter (`server/src/adapters/process/`)
-- `http` — generic HTTP adapter (`server/src/adapters/http/`)
-- `hermes_local` — third-party Hermes adapter
-
-**Process adapter:** `server/src/adapters/process/` — launches a configured command as a child process, streams stdout/stderr, parses structured JSON event chunks from the process.
-
----
-
-## Plugin System
-
-Plugins extend Paperclip with custom tools, UI slots, scheduled jobs, and webhooks.
-
-**Architecture:**
-- Each plugin runs as a separate worker process (isolated via `pluginWorkerManager`)
-- Host (server) communicates with worker via JSON-RPC over stdin/stdout
-- Host provides `PluginContext` services to the worker via the SDK
-
-**Key services:**
-- `plugin-lifecycle.ts` — state machine: `installed → ready → disabled/error/upgrade_pending → uninstalled`. Starting/stopping worker processes on transitions.
-- `plugin-loader.ts` — loads plugin packages from disk, validates manifests
-- `plugin-worker-manager.ts` — spawns/manages worker processes
-- `plugin-job-coordinator.ts` + `plugin-job-scheduler.ts` — scheduled job execution
-- `plugin-tool-dispatcher.ts` — routes tool invocations from agents to plugin workers
-- `plugin-event-bus.ts` — dispatches Paperclip events (issue.created, agent.run.completed, etc.) to plugin workers
-- `plugin-host-services.ts` — host-side service implementations exposed to workers via SDK
-- `plugin-registry.ts` — DB CRUD for plugin records
-
-**Worker SDK:** `packages/plugins/sdk/src/` — `@paperclipai/plugin-sdk`. Plugin authors import this to define tools, jobs, webhooks, UI slots, and interact with Paperclip state.
-
-**Plugin manifest:** `PaperclipPluginManifestV1` from `@paperclipai/shared` — declares capabilities, tools, jobs, webhooks, UI slots.
-
-**DB tables:** `plugins`, `plugin_config`, `plugin_state`, `plugin_jobs`, `plugin_logs`, `plugin_entities`, `plugin_webhooks`, `plugin_company_settings`
-
----
-
-## Issue / Task Model
-
-Issues are work items assigned to agents or users.
-
-**Schema:** `packages/db/src/schema/issues.ts` — key fields:
-```
-issues
-  id, companyId, projectId, goalId, parentId (self-ref)
-  title, description, status (backlog|todo|in_progress|in_review|blocked|done|cancelled)
-  priority (low|medium|high|urgent)
-  assigneeAgentId, assigneeUserId
-  checkoutRunId, executionRunId  // FK to heartbeat_runs
-  executionWorkspaceId
-  issueNumber, identifier (e.g. "PAP-42")
-  originKind, originId  // "manual" | "routine_execution" | "heartbeat"
-  requestDepth  // for sub-issues created by agents
-```
-
-**Identifier format:** `{issuePrefix}-{issueNumber}` — e.g., `PAP-42`. The prefix is unique per company.
-
-**Sub-issues:** `parentId` self-reference allows agent-created sub-issues. `requestDepth` tracks nesting.
-
-**Execution workspace:** Each issue can have an `executionWorkspaceId` pointing to a specific git worktree or container workspace. Managed by `execution-workspace-policy.ts`.
-
----
-
-## Project Model
-
-Projects group issues and have an optional lead agent and git repo.
-
-**Schema:** `packages/db/src/schema/projects.ts`
-```
-projects
-  id, companyId, goalId
-  name, description, status (backlog|active|paused|done|archived)
-  leadAgentId
-  targetDate, color
-  executionWorkspacePolicy jsonb  // repo URL, worktree settings
-```
-
-Projects will become the renamed entity in Nexus (replacing "companies" as the primary project container).
-
----
-
-## Goal Model
-
-Goals are objectives that group projects and issues.
-
-**Schema:** `packages/db/src/schema/goals.ts` — `id, companyId, title, description, status, parentId` (hierarchical)
-
----
-
-## Onboarding Flow
-
-### CLI Onboarding (`paperclipai onboard`)
-
-Interactive wizard in `cli/src/commands/onboard.ts` driven by `@clack/prompts`:
-
-1. **Mode selection** — "quickstart" (embedded Postgres, sane defaults) or "advanced" (custom DB, S3, auth)
-2. **Database** — embedded Postgres (auto-configured) or external `DATABASE_URL`
-3. **LLM** — configure default LLM provider/API key
-4. **Server** — port, host, deployment mode (`local_trusted` vs `authenticated`), public URL
-5. **Storage** — local filesystem or S3
-6. **Secrets** — local encrypted file or external secret manager
-7. Writes config to `~/.paperclip/config.yaml` (or `--config` path)
-8. Optionally runs `auth bootstrap-ceo` to generate first admin invite
-
-### UI Onboarding Wizard (`OnboardingWizard.tsx`)
-
-4-step dialog at `ui/src/components/OnboardingWizard.tsx`:
-
-- **Step 1 — Company**: enter company name + high-level goal. Creates company via `POST /api/companies`, creates a Goal record.
-- **Step 2 — Agent**: name the CEO agent, select adapter type (claude_local, codex_local, cursor, etc.), configure model. Tests adapter environment. Creates agent via `POST /api/companies/:id/agents`.
-- **Step 3 — First Task**: pre-filled task description (`"Hire a founding engineer, write a hiring plan, break the roadmap into concrete tasks"`). Creates a project + issue assigned to the CEO agent.
-- **Step 4 — Launch**: confirms entities created, navigates to issue detail. Shows run transcript.
-
-**Trigger:** `openOnboarding()` from `DialogContext`. Also triggered by route `/onboarding` or by navigating to company-prefixed routes when no companies exist.
-
-**Default task:** The CEO agent's first issue is "Hire your first engineer and create a hiring plan" with the task description guiding it to hire a founding engineer and begin delegating work.
-
----
-
-## Real-time Updates
-
-**Server:** `server/src/services/live-events.ts` — in-process `EventEmitter`. Services call `publishLiveEvent({ companyId, type, payload })` after mutations. SSE endpoint in `server/src/realtime/live-events-ws.ts` streams events per company.
-
-**Client:** `ui/src/context/LiveUpdatesProvider.tsx` — subscribes to SSE, calls `queryClient.invalidateQueries(...)` to refresh TanStack Query caches on relevant events. Also shows toast notifications for agent run completions and issue status changes.
-
----
-
-## CLI Commands
-
-Entry point: `cli/src/index.ts` — Commander.js program named `paperclipai`.
-
-**Setup commands:**
-- `onboard` — interactive first-run setup wizard
-- `run` — onboard + doctor + start server
-- `configure` — update config sections (llm, database, logging, server, storage, secrets)
-- `doctor` — diagnostic checks + optional auto-repair
-- `env` — print deployment environment variables
-- `allowed-hostname` — add hostname to allowlist
-- `db:backup` — one-off database backup
-
-**Runtime commands:**
-- `heartbeat run --agent-id <id>` — trigger one agent heartbeat and stream logs
-
-**Client commands (interact with a running Paperclip instance):**
-- `company list|create|get` — CRUD on companies
-- `issue list|create|get|update` — CRUD on issues
-- `agent list|create|get|update` — CRUD on agents
-- `approval list|get|approve|reject` — manage approvals
-- `activity list` — view activity log
-- `dashboard` — display dashboard stats
-- `plugin list|install|enable|disable|uninstall` — plugin management
-- `auth login|logout|whoami|bootstrap-ceo` — auth operations
-- `worktree ...` — git worktree management for execution workspaces
-
-Config/context for client commands loaded from `~/.paperclip/config.yaml` or `--config` flag.
-
----
-
-## Routine Model
-
-Routines are scheduled triggers that create issues on a cron-like cadence.
-
-**Schema:** `packages/db/src/schema/routines.ts`
-
-Routines fire at configured intervals, create issues with the configured title/description, and assign them to the specified agent. `server/src/services/cron.ts` drives the scheduling.
-
----
-
-## Execution Workspace Model
-
-Execution workspaces provide isolated git checkouts per project or issue.
-
-**Schema:** `packages/db/src/schema/execution_workspaces.ts`, `project_workspaces.ts`
-
-Managed by `server/src/services/execution-workspace-policy.ts` and `workspace-runtime.ts`. On heartbeat start, `heartbeatService` calls `realizeExecutionWorkspace(...)` to ensure the workspace directory + git clone exist before passing `cwd` to the adapter.
-
----
-
-## Key Data Model Relationships
-
-```
-Instance
-  └── companies (1:N)
-        ├── agents (1:N) — role: ceo | general | custom
-        │     └── reportsTo (self-ref tree)
-        ├── projects (1:N)
-        │     └── issues (1:N)
-        ├── goals (1:N, hierarchical)
-        ├── routines (1:N)
-        ├── heartbeat_runs (1:N, via agents)
-        │     └── heartbeat_run_events (1:N)
-        ├── agent_wakeup_requests (1:N)
-        ├── agent_task_sessions (1:N)
-        ├── approvals (1:N)
-        ├── cost_events (1:N)
-        ├── company_secrets (1:N)
-        └── plugins (M:N via plugin_company_settings)
-```
-
----
-
-## Entry Points
-
-**Server:**
-- `server/src/index.ts` — boots Postgres, runs migrations, calls `createApp(db, opts)`, starts HTTP listener
-- `server/src/app.ts` — `createApp(db, opts)` — wires Express middleware, mounts all routes, initializes plugin system, returns `app`
-
-**UI:**
-- `ui/src/main.tsx` — React root, wraps `<App />` in TanStack Query provider, `CompanyProvider`, etc.
-- `ui/src/App.tsx` — top-level router with `CloudAccessGate`, company-prefixed routes, `<OnboardingWizard />`
-
-**CLI:**
-- `cli/src/index.ts` — Commander program, registers all commands, calls `program.parseAsync()`
-
----
-
-## Error Handling
-
-**Server:** `server/src/errors.ts` exports `notFound`, `conflict`, `forbidden`, `unprocessable` helpers that throw typed errors. `server/src/middleware/error-handler.ts` catches them and returns structured JSON: `{ error: string }`.
-
-**UI:** `ui/src/api/client.ts` — `ApiError` class with `status` and `body`. Components check `error instanceof ApiError` and display `error.message`.
-
----
-
-## Deployment Modes
-
-Controlled by `PAPERCLIP_DEPLOYMENT_MODE`:
-- `local_trusted` — single-user local, no auth required. All requests automatically get `isInstanceAdmin: true`.
-- `authenticated` — multi-user, requires BetterAuth session or API key. Board API keys stored in `board_api_keys`.
-
-`PAPERCLIP_DEPLOYMENT_EXPOSURE`:
-- `public` — open to external traffic
-- `private` — private-hostname-guard enforces allowlist
-
----
-
-*Architecture analysis: 2026-03-30*

.planning/codebase/CONCERNS.md

@@ -1,342 +0,0 @@
-# Codebase Concerns — Paperclip Fork (Nexus)
-
-**Analysis Date:** 2026-03-30
-**Source repo:** `/Volumes/UsbNvme/repos/nexus`
-**Fork goal:** Rename company→project, CEO→Project Manager, Board→Owner. UI overhaul, onboarding redesign, directory restructure.
-
----
-
-## Terminology Embedding Depth
-
-### "company" — Pervasive at All Layers
-
-The word `company` is not a UI display string. It is a core identifier embedded at every layer of the stack.
-
-**Database schema — DO NOT rename columns:**
-- `packages/db/src/schema/companies.ts` — table `companies`, all columns use `company_id`
-- `packages/db/src/schema/agents.ts` — `company_id` FK column on every agent
-- `packages/db/src/schema/approvals.ts` — `company_id` column
-- `packages/db/src/schema/company_memberships.ts` — table name + `company_id`
-- `packages/db/src/schema/goals.ts` — `company_id` column; `level` field has value `"company"` as a constant
-- `packages/db/src/schema/company_logos.ts`, `company_secrets.ts`, `company_skills.ts` — table names with `company_` prefix
-- 47 migration SQL files in `packages/db/src/migrations/` reference `company_id` columns — renaming is impossible without new migrations and data migration
-
-**TypeScript types — must be renamed carefully:**
-- `packages/shared/src/types/company.ts` — exports `interface Company`
-- `packages/shared/src/types/company-portability.ts` — ~15 exported interfaces all named `CompanyPortability*`
-- `packages/shared/src/types/agent.ts` — `companyId` field on `Agent`, `AgentInstructionsBundle`, `AgentAccessState`
-- `packages/shared/src/constants.ts` — `COMPANY_STATUSES`, `BUDGET_SCOPE_TYPES` contains `"company"` string, `GOAL_LEVELS` contains `"company"` string, `PLUGIN_CAPABILITIES` contains `"companies.read"`, `PLUGIN_RESERVED_COMPANY_ROUTE_SEGMENTS` contains `"company"` and `"companies"`, plugin event types include `"company.created"` and `"company.updated"`
-
-**API routes — affect URL shape:**
-- `server/src/routes/companies.ts` — `/api/companies/:companyId` prefix for all company operations
-- `server/src/routes/*.ts` — almost every route file takes `/:companyId` in the path
-- `packages/shared/src/api.ts` — `API.companies = "/api/companies"` constant drives all frontend API calls
-- `ui/src/api/companies.ts` — all company API calls
-- `ui/src/context/CompanyContext.tsx` — `CompanyContext`, `CompanyProvider`, `useCompany`, `createCompany`; also uses `localStorage.setItem("paperclip.selectedCompanyId", ...)` as a persisted key
-
-**UI components:**
-- `ui/src/components/CompanyRail.tsx`, `CompanySwitcher.tsx`, `CompanyPatternIcon.tsx`
-- `ui/src/pages/Companies.tsx`, `CompanySettings.tsx`, `CompanySkills.tsx`, `CompanyExport.tsx`, `CompanyImport.tsx`
-- `ui/src/hooks/useCompanyPageMemory.ts`
-- `ui/src/lib/company-routes.ts` — routing helpers named `BOARD_ROUTE_ROOTS`, `extractCompanyPrefixFromPath`, `normalizeCompanyPrefix`
-- `ui/src/lib/company-export-selection.ts`, `company-portability-sidebar.ts`, `company-page-memory.ts`
-
-**CLI — user-visible command names:**
-- `cli/src/commands/client/company.ts` — CLI commands named `company import`, `company export`, etc.
-- `cli/src/__tests__/company.test.ts`, `company-delete.test.ts`, `company-import-*.test.ts`
-- `cli/src/index.ts` — registers company sub-commands on the CLI tree
-
-**Server services:**
-- `server/src/services/companies.ts` — `companyService()`
-- `server/src/services/company-portability.ts`, `company-skills.ts`, `company-export-readme.ts`
-
-**Impact:** Renaming `company` to `project` in code will conflict with the existing `projects` concept (there is already a `Project` entity distinct from `Company`). This is the single highest-risk rename.
-
----
-
-### "CEO" — In Code, Not Just UI
-
-**Constants (breaking if changed):**
-- `packages/shared/src/constants.ts` line 38: `AGENT_ROLES` array contains `"ceo"` as a string literal
-- `packages/shared/src/constants.ts` line 53: `AGENT_ROLE_LABELS` maps `ceo: "CEO"`
-- `packages/shared/src/constants.ts` line 332: `INVITE_TYPES` contains `"bootstrap_ceo"`
-- `packages/shared/src/constants.ts` line 187: `APPROVAL_TYPES` contains `"approve_ceo_strategy"`
-- `packages/shared/src/types/agent.ts` — `taskAssignSource` field has literal value `"ceo_role"`
-
-**CLI commands:**
-- `cli/src/commands/auth-bootstrap-ceo.ts` — exported function `bootstrapCeoInvite`
-- `cli/src/index.ts` line 146: `.command("bootstrap-ceo")` — this is a user-typed command
-- `cli/src/commands/onboard.ts` — calls `bootstrapCeoInvite`, displays "Generating bootstrap CEO invite" in terminal output, generates invite URL with path `/invite/...` and message "Created bootstrap CEO invite"
-- `cli/src/commands/run.ts` — imports `bootstrapCeoInvite`
-
-**Server services:**
-- `server/src/services/default-agent-instructions.ts` — `resolveDefaultAgentInstructionsBundleRole()` returns `"ceo"` for the ceo role; `DEFAULT_AGENT_BUNDLE_FILES` has `ceo:` key; reads from `onboarding-assets/ceo/` directory
-- `server/src/services/approvals.ts` lines 112, 179 — checks `type === "hire_agent"` (not CEO specifically but linked)
-
-**Onboarding assets — must be rewritten:**
-- `server/src/onboarding-assets/ceo/SOUL.md` — "You are the CEO." throughout; contains `"board"`, `"hire"`, `"fire"` language extensively
-- `server/src/onboarding-assets/ceo/AGENTS.md` — "You are the CEO. Your job is to lead the company..."; references board, hire, fire, CTO, CMO, delegates using `paperclip-create-agent` skill
-- `server/src/onboarding-assets/ceo/HEARTBEAT.md`, `TOOLS.md` — same corpus
-- `server/src/onboarding-assets/default/AGENTS.md` — likely also contains company/board references
-
-**UI:**
-- `ui/src/components/OnboardingWizard.tsx` line 114: `agentName` default is `"CEO"`
-- `ui/src/components/OnboardingWizard.tsx` line 71: `DEFAULT_TASK_DESCRIPTION` starts with `"You are the CEO. You set the direction for the company."` and contains `"hire a founding engineer"`
-- `ui/src/components/ApprovalPayload.tsx` lines 5-6: `approve_ceo_strategy: "CEO Strategy"` in display map; line 21: `approve_ceo_strategy: Lightbulb` in icon map
-- `ui/src/pages/App.tsx` line 62: shows `pnpm paperclipai auth bootstrap-ceo` as UI copy
-- `ui/src/pages/InviteLanding.tsx` — checks `invite.inviteType === "bootstrap_ceo"` in 5 places; displays "Bootstrap your Paperclip instance"
-
-**Database values (stored in rows):**
-- The `role` column on the `agents` table can contain `"ceo"`. Any existing databases have `"ceo"` stored as a role value. A rename would require a data migration.
-- The `invites.invite_type` column stores `"bootstrap_ceo"` as a string value.
-- The `approvals.type` column stores `"approve_ceo_strategy"` as a string value.
-
----
-
-### "Board" — Auth System Identity
-
-**Board = the human operator role.** This is deeply baked into the auth and API key system.
-
-**Service layer:**
-- `server/src/services/board-auth.ts` — `boardAuthService()`, `createBoardApiToken()` returns tokens prefixed `pcp_board_...`, `touchBoardApiKey()`, `revokeBoardApiKey()`, `resolveBoardAccess()`, `resolveBoardActivityCompanyIds()`
-- `server/src/middleware/board-mutation-guard.ts` — middleware that guards write operations by board users
-- `server/src/board-claim.ts` — dedicated board claim flow
-
-**Database schema:**
-- `packages/db/src/schema/board_api_keys.ts` — table named `board_api_keys`
-- `packages/db/src/schema/cli_auth_challenges.ts` — column `requested_access` stores `"board"` as a value
-
-**Token prefixes (stored in DB, shared with CLI):**
-- `server/src/services/board-auth.ts` line 30: `pcp_board_${...}` — tokens with this prefix are stored in the DB and used by the CLI
-- `cli/src/client/board-auth.ts` — CLI-side board authentication
-
-**Constants:**
-- `packages/db/src/schema/companies.ts` line 16: `requireBoardApprovalForNewAgents` column
-- `packages/shared/src/types/company.ts`: `requireBoardApprovalForNewAgents` field on `Company`
-- `packages/shared/src/types/company-portability.ts`: `requireBoardApprovalForNewAgents` in the manifest type
-
-**UI:**
-- `ui/src/pages/BoardClaim.tsx` — page for claiming board access
-- `ui/src/lib/company-routes.ts` line 1: `BOARD_ROUTE_ROOTS` set used for routing logic; the name encodes the concept
-
-**Impact:** Renaming `board` to `owner` requires changing token prefixes (`pcp_board_` → `pcp_owner_`), the `board_api_keys` DB table name (requires migration), and all auth middleware. Token prefix changes break existing issued tokens — any users with `pcp_board_*` tokens will be logged out.
-
----
-
-### "hire" / "fire" — In Approval Types and Agent Instructions
-
-**Code-level occurrences:**
-- `packages/shared/src/constants.ts` line 187: `APPROVAL_TYPES` contains `"hire_agent"` — stored in DB `approvals.type` column
-- `server/src/services/hire-hook.ts` — entire file named after hire; exports `notifyHireApproved`, uses `HireApprovedPayload` type from `packages/adapter-utils/src/types.ts`
-- `packages/adapter-utils/src/types.ts` line 213: `HireApprovedPayload` interface; line 277: `onHireApproved` lifecycle hook on `ServerAdapterModule`
-- `server/src/routes/agents.ts` line 1228: creates `type: "hire_agent"` approval
-- `server/src/routes/approvals.ts` line 66, 281: checks `type === "hire_agent"`
-- `cli/src/commands/client/approval.ts` line 114: CLI option says `hire_agent|approve_ceo_strategy`
-- `ui/src/components/ApprovalPayload.tsx` line 5: `hire_agent: "Hire Agent"` in label map
-- `ui/src/components/ApprovalPayload.tsx` line 131: branching on `type === "hire_agent"`
-
-**Agent instruction content:**
-- `server/src/onboarding-assets/ceo/SOUL.md` line 15: "Hire slow, fire fast"
-- `server/src/onboarding-assets/ceo/AGENTS.md` line 6: "Hire new agents when the team needs capacity"
-- `server/src/onboarding-assets/ceo/AGENTS.md` line 16: delegates via `paperclip-create-agent` skill with instruction to hire
-- `skills/paperclip-create-agent/` skill is entirely named around hiring
-
-**Stored DB values:** `hire_agent` appears in the `approvals.type` column. Existing rows cannot be silently changed. A rename requires either a data migration or keeping the stored value while changing the label only.
-
----
-
-## Data Directory Concerns
-
-### `~/.paperclip` — The Home Directory
-
-**All path roots use the name "paperclip":**
-- `server/src/home-paths.ts` line 18: `path.resolve(os.homedir(), ".paperclip")` — default home dir
-- `server/src/home-paths.ts` — exported functions: `resolvePaperclipHomeDir()`, `resolvePaperclipInstanceId()`, `resolvePaperclipInstanceRoot()`
-- `cli/src/config/home.ts` line 10: same `.paperclip` default
-- `server/src/paths.ts` line 13: looks for `.paperclip/config.json` when searching ancestor directories for config
-- `cli/src/config/store.ts` line 16: same ancestor search for `.paperclip/config.json`
-- `cli/src/client/context.ts` line 25: looks for `.paperclip/context.json`
-
-**Environment variable names:**
-- `PAPERCLIP_HOME` — overrides the home directory
-- `PAPERCLIP_INSTANCE_ID` — overrides instance ID
-- `PAPERCLIP_CONFIG` — overrides config path
-- `PAPERCLIP_AGENT_JWT_SECRET` — agent auth secret
-- `PAPERCLIP_PUBLIC_URL`, `PAPERCLIP_DEPLOYMENT_MODE`, `PAPERCLIP_DEPLOYMENT_EXPOSURE`, `PAPERCLIP_ALLOWED_HOSTNAMES`, `PAPERCLIP_AUTH_*`, `PAPERCLIP_STORAGE_*`, `PAPERCLIP_SECRETS_*`
-- These appear in ~25+ places across `cli/src/commands/onboard.ts`, `server/src/home-paths.ts`, `server/src/startup-banner.ts`, `server/src/ui-branding.ts`, Docker files
-
-**Impact:** Renaming `~/.paperclip` to `~/.nexus` requires changing:
-1. The default string in `server/src/home-paths.ts` and `cli/src/config/home.ts`
-2. All `PAPERCLIP_*` env var names (breaking change for existing deployments)
-3. Docker config `PAPERCLIP_HOME: "/home/reviewer/.paperclip-review"` in `docker-compose.untrusted-review.yml`
-4. Shell scripts `scripts/provision-worktree.sh` and `scripts/backup-db.sh`
-5. Docs in `doc/DATABASE.md`, `doc/DOCKER.md`, `doc/SPEC-implementation.md`
-6. The `.paperclip/config.json` ancestor-search path logic
-
----
-
-### "companies" Subdirectory in Instance Root
-
-- `server/src/services/agent-instructions.ts` line 135: agent instructions are stored at `~/.paperclip/instances/<id>/companies/<companyId>/agents/<agentId>/instructions/`
-- `server/src/services/company-skills.ts` line 1282: skills stored at `~/.paperclip/instances/<id>/skills/<companyId>`
-- `server/src/home-paths.ts` line 85: managed project workspaces stored at `~/.paperclip/instances/<id>/projects/<companyId>/<projectId>/<repoName>/`
-
-These paths are embedded in the filesystem on any existing deployment. Renaming `companies` in the path would break existing agent instruction directories unless a migration script is provided.
-
----
-
-### `.paperclip.yaml` Portability File
-
-- `server/src/services/company-portability.ts` — the export format emits `.paperclip.yaml` as a sidecar file
-- `cli/src/commands/client/company.ts` lines 183, 189-190: CLI detects and processes `.paperclip.yaml` and `.paperclip.yml`
-- `ui/src/pages/CompanyExport.tsx` lines 75, 778-785: UI references `.paperclip.yaml`
-- The file format is documented in `docs/companies/companies-spec.md` under the `schema: paperclip/v1` header
-
-**Impact:** Any exported company bundles from the upstream will have `.paperclip.yaml` files. If Nexus renames to `.nexus.yaml`, these files become incompatible. Either keep reading `.paperclip.yaml` (and emit `.nexus.yaml`) or accept breaking import compatibility.
-
----
-
-## "paperclip" Brand in Package Names and Token Prefixes
-
-**npm package names:**
-- `cli/package.json`: `"name": "paperclipai"` — the CLI binary is named `paperclipai`
-- `packages/shared/package.json`: `"name": "@paperclipai/shared"`
-- `packages/db/package.json`: `"name": "@paperclipai/db"`
-- `packages/adapter-utils/package.json`: `"name": "@paperclipai/adapter-utils"`
-- All internal imports use `@paperclipai/*` throughout the entire monorepo
-
-**Impact:** Renaming packages requires updating every `import` statement in the codebase (thousands of occurrences). The `pnpm-workspace.yaml` and all `package.json` dependency declarations must also change. This is purely mechanical but extremely high volume.
-
-**API token prefixes:**
-- `pcp_board_*` — board API keys stored in DB
-- `pcp_bootstrap_*` — CEO bootstrap invite tokens stored in DB
-- `pcp_cli_auth_*` — CLI auth challenge tokens stored in DB
-
-These are stored as values in the database. If renamed, existing tokens become invalid unless the server accepts both prefixes.
-
-**CLI binary name:**
-- `package.json` script: `"paperclipai": "node cli/node_modules/tsx/dist/cli.mjs cli/src/index.ts"`
-- CLI displays `paperclipai onboard`, `paperclipai run`, `paperclipai auth bootstrap-ceo`
-- `ui/src/App.tsx` renders `pnpm paperclipai auth bootstrap-ceo` as literal user-facing instruction
-- `server/src/startup-banner.ts` line 96: `run \`pnpm paperclipai onboard\`` as warning text
-
----
-
-## Onboarding Flow — High Complexity Change
-
-### UI Onboarding Wizard
-
-The onboarding wizard (`ui/src/components/OnboardingWizard.tsx`) is the primary first-run experience. It is deeply coupled to the corporate metaphor:
-
-- Step 1 prompts for "company name" and "company goal" — variables named `companyName`, `companyGoal`
-- Step 2 creates the first agent with default name `"CEO"`, default description: *"You are the CEO. You set the direction for the company. - hire a founding engineer - write a hiring plan..."*
-- Step 3 creates the first task with `taskTitle` defaulting to `"Hire your first engineer and create a hiring plan"`
-- The entire flow uses `companiesApi.create()` which calls `/api/companies`
-- `ui/src/lib/onboarding-launch.ts` — `ONBOARDING_PROJECT_NAME = "Onboarding"` and `selectDefaultCompanyGoalId()` filters `goal.level === "company"`
-
-**The onboarding wizard must be substantially rewritten** to replace company creation with project creation (given company maps to project in Nexus). However, since the DB entity is still `company`, this is a UI-layer rename only — the API calls still go to `/api/companies`.
-
-### CLI Onboarding
-
-`cli/src/commands/onboard.ts` is the other half of onboarding:
-- Displays banner: `p.intro(pc.bgCyan(pc.black(" paperclipai onboard ")))`
-- Calls `bootstrapCeoInvite` on completion
-- Displays "Start Paperclip now?" prompt
-- Generates next-steps text: `paperclipai run`, `paperclipai configure`, `paperclipai doctor`
-
-All terminal strings that reference `paperclipai` and `Paperclip` are hardcoded — there is no i18n or constant layer for branding strings.
-
----
-
-## Schema References That Should NOT Change
-
-Per the fork PRD, the database schema must stay compatible with upstream. The following identifiers should be left as-is in the database layer, treating them as opaque internal keys:
-
-- Table names: `companies`, `company_memberships`, `company_secrets`, `company_skills`, `company_logos`, `board_api_keys`
-- Column names: all `company_id` foreign keys
-- Stored enum values: `"ceo"` in `agents.role`, `"hire_agent"` and `"approve_ceo_strategy"` in `approvals.type`, `"bootstrap_ceo"` in `invites.invite_type`, `"company"` in `goals.level`, `"board"` in `cli_auth_challenges.requested_access`
-
-These values exist in the running DB and in migration history. Any rename here requires new migration SQL + data migration.
-
----
-
-## Hardcoded Strings vs Constants
-
-There is NO i18n or centralized string table for user-facing copy. All UI labels are inline JSX strings or TypeScript constants.
-
-**Somewhat centralised (easier to change):**
-- `packages/shared/src/constants.ts` — `AGENT_ROLE_LABELS` maps roles to display strings; changing `ceo: "CEO"` here propagates to wherever the label map is used
-- `packages/shared/src/api.ts` — `API.companies` constant drives all frontend API path construction
-- `ui/src/components/ApprovalPayload.tsx` lines 5-6 — `hire_agent: "Hire Agent"`, `approve_ceo_strategy: "CEO Strategy"` are display-only labels
-
-**Fully hardcoded (harder to change):**
-- All terminal output in `cli/src/commands/onboard.ts` — every `p.log.*` call is a literal string
-- `server/src/startup-banner.ts` — the ASCII art says "PAPERCLIP", `resolveAgentJwtSecretStatus` message references `pnpm paperclipai onboard`
-- `ui/src/components/OnboardingWizard.tsx` — `DEFAULT_TASK_DESCRIPTION`, `taskTitle` default, `agentName` default are all hardcoded literals
-- `server/src/onboarding-assets/ceo/SOUL.md` and `AGENTS.md` — plain Markdown prose
-
----
-
-## Plugin System Concerns
-
-The plugin API surface exposes company-centric types to third-party plugins:
-
-- `packages/shared/src/constants.ts` — `PLUGIN_CAPABILITIES` includes `"companies.read"` — this is a capability string that plugins declare in their manifests; changing it breaks all plugins that declare this capability
-- `packages/shared/src/constants.ts` — `PLUGIN_EVENT_TYPES` includes `"company.created"` and `"company.updated"` — changing these breaks plugin event subscriptions
-- `packages/shared/src/constants.ts` — `PLUGIN_RESERVED_COMPANY_ROUTE_SEGMENTS` includes `"company"` and `"companies"` — changing this affects URL routing validation
-- `packages/shared/src/constants.ts` — `PLUGIN_STATE_SCOPE_KINDS` includes `"company"` — plugin state scoped to a company would break
-
-Any fork that changes these strings is breaking the plugin API contract. If Nexus wants to maintain upstream plugin compatibility, these must remain unchanged.
-
----
-
-## Upstream Sync Risk
-
-If this fork intends to periodically merge upstream Paperclip changes:
-
-- Any rename of package names (`@paperclipai/*` → `@nexusai/*`) will cause merge conflicts on every upstream file that imports those packages — this is nearly every file
-- Renames of `company` to `project` in service/route files will conflict heavily with upstream changes to the `companies.ts` service
-- Renamed function names (`bootstrapCeoInvite`, `companyService`, `boardAuthService`) will not patch-merge cleanly
-- The `server/src/onboarding-assets/ceo/` directory name, if renamed, creates a merge conflict on any upstream changes to those files
-
-**Recommendation:** If upstream sync is a requirement, keep all code-level identifiers unchanged and do only display-layer (UI string) renames. Make a clear boundary between "DB/code identity" (unchanged) and "display vocabulary" (renamed).
-
----
-
-## Test Coverage Gaps for Fork Changes
-
-**Untested areas relevant to the fork:**
-- The `DEFAULT_TASK_DESCRIPTION` and default `agentName = "CEO"` in `OnboardingWizard.tsx` have no unit tests — changing them is safe but unverified
-- `server/src/onboarding-assets/ceo/` content is loaded at runtime via `fs.readFile` in `default-agent-instructions.ts` — no test validates the file content structure, only the loading mechanism
-- CLI terminal output strings (`p.log.*` calls in `onboard.ts`) are not covered by automated tests — manual smoke tests in `tests/release-smoke/` cover the auth flow but not every string
-
-**Covered by tests (risky to change):**
-- `cli/src/__tests__/board-auth.test.ts` — tests the board auth flow including token prefix behavior
-- `server/src/__tests__/hire-hook.test.ts` — tests the hire approval hook
-- `server/src/__tests__/invite-onboarding-text.test.ts` — likely tests invite text containing "CEO"; check before renaming
-- `server/src/__tests__/company-branding-route.test.ts`, `company-portability.test.ts`, `company-portability-routes.test.ts` — all test company-named routes; renaming these routes breaks these tests
-
----
-
-## Summary Risk Table
-
-| Area | Risk | Breaking Change |
-|------|------|----------------|
-| DB table/column names (`companies`, `company_id`) | **Critical** | Yes — requires migration |
-| Stored enum values (`"ceo"`, `"hire_agent"`, `"bootstrap_ceo"`) | **Critical** | Yes — data migration |
-| `pcp_board_*` token prefix | **High** | Yes — existing tokens invalidated |
-| `@paperclipai/*` package names | **High** | Yes — breaks every import |
-| `PAPERCLIP_*` env var names | **High** | Yes — breaks all existing deployments |
-| `~/.paperclip` home dir | **High** | Yes — breaks existing data paths |
-| `companies/` subdir in instance root | **High** | Yes — breaks existing instruction files |
-| CLI binary name `paperclipai` | **Medium** | Yes — users must relearn commands |
-| `bootstrap-ceo` CLI subcommand | **Medium** | Yes — changes user-facing command |
-| `company.created` plugin event types | **Medium** | Yes — breaks third-party plugins |
-| `.paperclip.yaml` export format | **Medium** | Yes — breaks import of upstream bundles |
-| UI display strings ("company", "CEO", "board") | **Low** | No — display only |
-| `OnboardingWizard` default task/agent text | **Low** | No — display only |
-| Onboarding asset prose (SOUL.md, AGENTS.md) | **Low** | No — content only |
-
----
-
-*Concerns audit: 2026-03-30*

.planning/codebase/QUALITY.md

@@ -1,293 +0,0 @@
-# Code Quality — Paperclip (Nexus)
-
-**Analysis Date:** 2026-03-30
-
----
-
-## Testing Frameworks
-
-**Unit/Integration Test Runner:**
-- Vitest 3.x, configured at the monorepo root via `vitest.config.ts`
-- Projects registered: `packages/db`, `packages/adapters/opencode-local`, `server`, `ui`, `cli`
-
-**E2E Test Runner:**
-- Playwright (`@playwright/test` ^1.58.2)
-- E2E config: `tests/e2e/playwright.config.ts`
-- Release smoke config: `tests/release-smoke/playwright.config.ts`
-
-**Run Commands:**
-```bash
-pnpm test:run          # All vitest tests (CI mode)
-pnpm test              # All vitest tests (watch mode)
-pnpm test:e2e          # Playwright E2E suite
-pnpm test:e2e:headed   # Playwright with browser visible
-```
-
----
-
-## Test Counts & Coverage
-
-| Workspace | Test Files | describe/it/test calls |
-|-----------|-----------|----------------------|
-| `server/src/__tests__/` | 94 files (+ 1 helpers/ dir) | ~649 describe/it/test calls |
-| `cli/src/__tests__/` | 17 files | ~120 calls |
-| `ui/src/` (lib + adapters + hooks + context) | 18 `.test.ts` files | ~100+ calls |
-| `ui/src/` (components) | 2 `.test.tsx` files | minimal |
-| `packages/db/src/` | 3 test files | ~20 calls |
-| `packages/adapters/opencode-local/` | 3 test files | ~10 calls |
-| `packages/adapters/pi-local/` | 2 test files | ~10 calls |
-| E2E (`tests/e2e/`) | 1 spec file | 1 test |
-| Release smoke (`tests/release-smoke/`) | 1 spec file | 1 test |
-
-**Coverage tooling:** No coverage thresholds or reporters are configured. None of the `vitest.config.ts` files include a `coverage` block. Coverage is not tracked.
-
----
-
-## What Is Tested
-
-**Well-covered:**
-- Server route handlers (via `supertest` HTTP-level integration tests against a real Express app backed by embedded Postgres) — e.g., `server/src/__tests__/routines-e2e.test.ts`, `approval-routes-idempotency.test.ts`
-- Server services (pure logic tested in isolation with vi.fn() mocks) — e.g., `issues-service.test.ts`, `approvals-service.test.ts`, `company-portability.test.ts`
-- Adapter models, parse logic, skill sync for every adapter type (claude-local, codex-local, cursor-local, gemini-local, opencode-local, pi-local, openclaw-gateway)
-- Database runtime config resolution across all source precedence paths — `packages/db/src/runtime-config.test.ts`
-- CLI commands: worktree management, company import/export, auth flows, home path resolution
-- UI lib utilities: inbox badge computation, assignee logic, routine trigger patches, onboarding routing, company portability
-- Security/redaction: `log-redaction.test.ts`, `forbidden-tokens.test.ts`, `redaction.test.ts`
-- Error handler middleware — `error-handler.test.ts`
-- Zod validation flow: routes use `validate(schema)` middleware, covered by route-level tests
-
-**Under-tested or not tested:**
-- UI components (83 components, only 2 have test files: `MarkdownBody.test.tsx`, `RunTranscriptView.test.tsx`)
-- UI pages (39 pages, zero test files)
-- Real-database integration tests skip on unsupported hosts (`describe.skip` via `getEmbeddedPostgresTestSupport`) — these tests pass silently in most environments
-- Storage provider implementations (`server/src/storage/`) — only referenced, not directly tested
-- Plugin lifecycle/loader/worker manager have some tests but plugin tooling is lightly covered
-
----
-
-## Test Patterns
-
-**Standard unit test structure:**
-```typescript
-import { describe, expect, it, vi } from "vitest";
-
-describe("feature name", () => {
-  it("describes the expected behavior", () => {
-    expect(result).toEqual(expected);
-  });
-});
-```
-
-**Integration test pattern (HTTP + real DB):**
-Tests in `server/src/__tests__/routines-e2e.test.ts` and similar spin up an Express app with a real embedded Postgres instance:
-```typescript
-const embeddedPostgresSupport = await getEmbeddedPostgresTestSupport();
-const describeEmbeddedPostgres = embeddedPostgresSupport.supported ? describe : describe.skip;
-
-describeEmbeddedPostgres("feature", () => {
-  beforeAll(async () => {
-    tempDb = await startEmbeddedPostgresTestDatabase("prefix-");
-    db = createDb(tempDb.connectionString);
-  }, 20_000);
-  afterAll(async () => { await tempDb?.cleanup(); });
-  afterEach(async () => { /* truncate tables */ });
-});
-```
-
-**Service mock pattern (for route-level tests without DB):**
-```typescript
-const issueSvc = {
-  list: vi.fn(),
-  create: vi.fn(),
-  // ...
-};
-vi.mock("../services/index.js", () => ({ issueService: () => issueSvc }));
-```
-
-**Test helper location:** `server/src/__tests__/helpers/embedded-postgres.ts` re-exports `@paperclipai/db` test utilities.
-
-**Factory functions:** Tests consistently define local `make*()` helpers (e.g., `makeApproval()`, `makeRun()`, `makeIssue()`) rather than shared factories. No shared fixture library exists.
-
----
-
-## Linting & Formatting
-
-**ESLint:** Not detected. No `.eslintrc*`, `eslint.config.*`, or biome config exists at any level of the monorepo.
-
-**Prettier:** Not detected. No `.prettierrc*` found.
-
-**Implications:** Code style is enforced only by TypeScript's strict mode and reviewer convention. There is no automated formatting gate in CI. Formatting inconsistencies (e.g., line length, trailing commas) are present but generally consistent within files.
-
-**Observed style (informal conventions):**
-- 2-space indentation throughout
-- Double quotes for imports (`"..."`)
-- Trailing commas in multi-line expressions
-- Named exports preferred over default exports in services and routes
-- Consistent `node:` prefix on Node built-ins (`import fs from "node:fs"`)
-
----
-
-## TypeScript Strictness
-
-**Shared base config:** `tsconfig.base.json` at repo root:
-- `"strict": true` — enables all strict checks (noImplicitAny, strictNullChecks, etc.)
-- `"target": "ES2023"`, `"module": "NodeNext"`, `"moduleResolution": "NodeNext"`
-- `"isolatedModules": true`
-- `"forceConsistentCasingInFileNames": true`
-
-**UI override:** `ui/tsconfig.json` also sets `"strict": true`, with `"module": "ESNext"`, `"moduleResolution": "bundler"`.
-
-**All packages** extend `tsconfig.base.json` or have equivalent strictness settings.
-
-**`as any` usage:** 131 occurrences across 35 files, mostly in test mocks and Express middleware internals (e.g., casting `res` to `any` to attach custom error context properties). Production service code rarely uses `as any` outside of plugin-related services where dynamic dispatch requires it (`plugin-host-services.ts`: 16 occurrences).
-
-**`@ts-ignore` / `@ts-expect-error`:** Zero occurrences across the entire codebase — a strong signal of type discipline.
-
-**Typecheck CI gate:** `pnpm -r typecheck` runs in both the `verify` job (on PRs) and `verify_canary` job (on merge). Type errors block CI.
-
----
-
-## Error Handling Patterns
-
-**Custom HTTP error classes:** `server/src/errors.ts` defines `HttpError` with factory helpers:
-```typescript
-export function badRequest(message, details?) { return new HttpError(400, message, details); }
-export function notFound(message?) { return new HttpError(404, message ?? "Not found"); }
-export function forbidden(message?) { return new HttpError(403, message ?? "Forbidden"); }
-// + unauthorized, conflict, unprocessable
-```
-
-**Centralized error handler:** `server/src/middleware/error-handler.ts` handles:
-- `HttpError` → structured JSON response with correct status
-- `ZodError` → 400 with validation details
-- Unknown errors → 500 with `"Internal server error"` (no leak)
-- Attaches `res.__errorContext` for logging (consumed by `pino-http`)
-
-**Route error propagation:** Routes use `async` handler functions with `next(err)` pass-through, relying on the global Express error handler. No try/catch noise in route files.
-
-**Validation:** Zod schemas defined in `@paperclipai/shared` (e.g., `createIssueSchema`) are applied via the `validate(schema)` middleware in `server/src/middleware/validate.ts`. Schema parse errors are automatically caught by the error handler.
-
----
-
-## Logging
-
-**Framework:** Pino + pino-http + pino-pretty
-
-**Configuration:** `server/src/middleware/logger.ts`
-- `info` level to stdout (colorized via pino-pretty)
-- `debug` level to `server.log` file (plain text)
-- HTTP requests logged with custom log levels: 5xx → error, 4xx → warn, 2xx → info
-- Error context (body, params, query) attached to error-level log entries
-- Log directory resolved from `PAPERCLIP_LOG_DIR` env, config file, or default home path
-
-**Production code:** Minimal `console.*` usage (9 files in server, mostly in plugin services and test `console.warn` for unsupported environments). UI has 6 console calls total, confined to plugin slots.
-
----
-
-## CI/CD Quality Gates
-
-**On every PR to `master`** (`.github/workflows/pr.yml`):
-
-| Check | Job |
-|-------|-----|
-| Block manual `pnpm-lock.yaml` edits | `policy` |
-| Validate Dockerfile `deps` stage completeness | `policy` |
-| Validate dependency resolution on manifest changes | `policy` |
-| `pnpm -r typecheck` | `verify` |
-| `pnpm test:run` (all Vitest tests) | `verify` |
-| `pnpm build` | `verify` |
-| Canary release dry run | `verify` |
-| Playwright E2E (skip-LLM mode) | `e2e` |
-
-**On merge to `master`** (`.github/workflows/release.yml`):
-- Full re-run of typecheck + tests before publishing canary
-
-**Release smoke tests** (`.github/workflows/release-smoke.yml`): Separate workflow for post-release Docker auth/onboarding smoke.
-
-**E2E tests** (`.github/workflows/e2e.yml`): Manual dispatch only, supports full LLM execution via `ANTHROPIC_API_KEY`.
-
-**No coverage gate** in CI. No lint gate in CI.
-
----
-
-## Code Organization & Consistency
-
-**Service factory pattern:** All server services are instantiated as factory functions receiving a `Db` instance:
-```typescript
-export function issueService(db: Db) {
-  return {
-    list: async (params) => { ... },
-    create: async (data) => { ... },
-  };
-}
-```
-This pattern is consistent across all 64 service files in `server/src/services/`.
-
-**Route factory pattern:** Routes are factory functions receiving `db` and optional `storage`:
-```typescript
-export function issueRoutes(db: Db, storage: StorageService) {
-  const router = Router();
-  const svc = issueService(db);
-  // ...
-  return router;
-}
-```
-
-**Monorepo workspace structure:** Clear separation between `server/`, `ui/`, `cli/`, `packages/shared/`, `packages/db/`, `packages/adapters/*`. Cross-package imports use `@paperclipai/*` namespace.
-
-**Import organization:** Node built-ins first with `node:` prefix, then external packages, then internal workspace packages (`@paperclipai/*`), then relative imports. No enforced by tooling but consistently applied.
-
----
-
-## Documentation Quality
-
-**Inline comments:** Sparse but purposeful. Comments appear where non-obvious logic is present (e.g., SSRF protection in `plugin-host-services.ts` has a section comment block). Files generally are self-documenting through naming.
-
-**JSDoc/TSDoc:** Not used. No `/** */` doc-comments on exported functions. Types are the documentation.
-
-**TODO comments:** Only 3 in the entire codebase:
-- `ui/src/pages/AgentDetail.tsx:771` — commented-out skills tab view
-- `ui/src/adapters/runtime-json-fields.tsx:5` — disabled UI pending worktree workflow
-- `cli/src/commands/client/company.ts:362` — temporary `claude_local` fallback in import TUI
-
-**README:** `README.md` exists at root. `CONTRIBUTING.md` has clear contribution guidelines including required PR "thinking path" format.
-
-**PR template:** `.github/PULL_REQUEST_TEMPLATE.md` enforces thinking path, what changed, verification steps, risks, and checklist including test and doc updates.
-
----
-
-## Technical Debt Indicators
-
-**No linting or formatting tooling:**
-- Risk: style drift over time, no automated enforcement
-- Files affected: entire codebase
-- Fix approach: add Biome (preferred for TS monorepos) or ESLint + Prettier with CI gate
-
-**No coverage measurement:**
-- Risk: regressions in untested paths go undetected
-- Files affected: primarily `ui/src/pages/`, `ui/src/components/`, `server/src/storage/`
-- Fix approach: add `@vitest/coverage-v8`, set minimum thresholds per workspace
-
-**UI components have near-zero unit tests:**
-- 83 component files, 2 test files
-- Risk: UI logic regressions caught only by E2E or manually
-- Most UI lib logic (`ui/src/lib/`) is tested; the gap is components and pages
-- Fix approach: add React Testing Library for component tests
-
-**`as any` in production plugin services (`plugin-host-services.ts`):**
-- 16 occurrences in a single file
-- Indicates dynamic dispatch complexity in plugin host layer
-- Risk: type errors in plugin boundary surface at runtime
-
-**Embedded Postgres tests skip silently on many hosts:**
-- Pattern: `const describeEmbeddedPostgres = supported ? describe : describe.skip`
-- This means DB integration tests do not run in many dev environments and potentially some CI hosts
-- CI does run them (`ubuntu-latest` is a supported host)
-
-**`server/src/services/company-portability.ts` uses `as any` 12 times:**
-- Most complex service file; high import count (30+ types from shared)
-- Deserves a refactor pass once the portability feature stabilizes
-
----
-
-*Quality audit: 2026-03-30*

.planning/codebase/STACK.md

@@ -1,272 +0,0 @@
-# Technology Stack
-
-**Analysis Date:** 2026-03-30
-**Project Name:** Paperclip (package name `paperclip`, npm org `@paperclipai`)
-
----
-
-## Languages
-
-**Primary:**
-- TypeScript 5.7.x — all source code across every package, compiled to ESM
-- JavaScript (ESM) — build scripts, generated output
-
-**Secondary:**
-- Bash — release scripts, smoke tests, DB backup (`scripts/`, `tests/`)
-
----
-
-## Runtime
-
-**Environment:**
-- Node.js >=20 (enforced via `engines` in root `package.json`)
-- ESM-first: all packages set `"type": "module"`
-- `tsx` (^4.19.2) used as TS runner during development and for CLI execution
-
-**Package Manager:**
-- pnpm 9.15.4 (pinned via `packageManager` field)
-- Lockfile: `pnpm-lock.yaml` — present and committed
-- Patched dependency: `embedded-postgres@18.1.0-beta.16` (patch in `patches/`)
-
----
-
-## Monorepo Structure
-
-**Workspace layout** (`pnpm-workspace.yaml`):
-```
-packages/*
-packages/adapters/*
-packages/plugins/*
-packages/plugins/examples/*
-server
-ui
-cli
-```
-
-**Packages:**
-
-| Package | Name | Purpose |
-|---------|------|---------|
-| `server/` | `@paperclipai/server` | Express HTTP server + WebSocket + plugin host |
-| `ui/` | `@paperclipai/ui` | React SPA (board UI) |
-| `cli/` | `paperclipai` | CLI binary (Node.js, esbuild-bundled) |
-| `packages/db/` | `@paperclipai/db` | Drizzle ORM schema, migrations, embedded-postgres helpers |
-| `packages/shared/` | `@paperclipai/shared` | Shared Zod schemas and TypeScript types |
-| `packages/adapter-utils/` | `@paperclipai/adapter-utils` | Shared utilities across AI adapters |
-| `packages/adapters/claude-local/` | `@paperclipai/adapter-claude-local` | Adapter for Anthropic Claude Code CLI |
-| `packages/adapters/codex-local/` | `@paperclipai/adapter-codex-local` | Adapter for OpenAI Codex CLI |
-| `packages/adapters/cursor-local/` | `@paperclipai/adapter-cursor-local` | Adapter for Cursor editor agent |
-| `packages/adapters/gemini-local/` | `@paperclipai/adapter-gemini-local` | Adapter for Google Gemini CLI |
-| `packages/adapters/openclaw-gateway/` | `@paperclipai/adapter-openclaw-gateway` | Gateway adapter (WebSocket, external agent relay) |
-| `packages/adapters/opencode-local/` | `@paperclipai/adapter-opencode-local` | Adapter for opencode-ai CLI |
-| `packages/adapters/pi-local/` | `@paperclipai/adapter-pi-local` | Adapter for pi.ai |
-| `packages/plugins/sdk/` | `@paperclipai/plugin-sdk` | Public plugin API (worker-side + UI bridge hooks) |
-
----
-
-## Backend Framework
-
-**HTTP Server:**
-- Express 5.1.0 (`express`) — REST API, static file serving, middleware chain
-- `@types/express` 5.0.0
-
-**WebSocket (Realtime):**
-- `ws` ^8.18.0 — native WebSocket server at `server/src/realtime/live-events-ws.ts`
-- Used for live event streaming to the board UI
-
-**Authentication:**
-- `better-auth` 1.4.18 — pluggable auth library with Drizzle adapter
-- Session handling at `server/src/auth/better-auth.ts`
-- JWT used for agent-to-server auth (`server/src/agent-auth-jwt.ts`)
-
-**Validation:**
-- `zod` ^3.24.2 — schema validation throughout server and shared packages
-- `ajv` ^8.18.0 + `ajv-formats` ^3.0.1 — JSON Schema validation (plugin manifests)
-
-**Logging:**
-- `pino` ^9.6.0 — structured JSON logging
-- `pino-http` ^10.4.0 — HTTP request logging middleware
-- `pino-pretty` ^13.1.3 — dev-mode pretty-print
-
-**File Handling:**
-- `multer` ^2.0.2 — multipart/form-data upload handling
-- `sharp` ^0.34.5 — server-side image processing
-
-**HTML Sanitization:**
-- `dompurify` ^3.3.2 + `jsdom` ^28.1.0 — server-side sanitization of rich text
-
----
-
-## Database
-
-**ORM:**
-- `drizzle-orm` ^0.38.4 — TypeScript ORM, query builder
-- `drizzle-kit` ^0.31.9 — migration generation (`drizzle-kit generate`)
-
-**Driver:**
-- `postgres` ^3.4.5 — native PostgreSQL client
-
-**Database Server:**
-- PostgreSQL 17 (Docker: `postgres:17-alpine`)
-- `embedded-postgres` ^18.1.0-beta.16 — bundled PostgreSQL for local/single-binary deployments (patched)
-
-**Schema location:** `packages/db/src/schema/` — 50+ individual table files
-**Migrations:** `packages/db/src/migrations/`
-**Client factory:** `packages/db/src/client.ts` (`createDb(url)`)
-
-**Database modes:**
-- `embedded-postgres` — default for local CLI use (no external DB required)
-- `postgres` — external PostgreSQL for Docker/production deployments
-
----
-
-## Frontend Framework
-
-**Framework:**
-- React 19.0.0 (`react`, `react-dom`)
-- React Router DOM 7.1.5 (`react-router-dom`) — SPA routing
-- React Query / TanStack Query 5.x (`@tanstack/react-query`) — server state, data fetching
-
-**Build Tool:**
-- Vite 6.1.0 — dev server (port 5173) and production bundler
-- `@vitejs/plugin-react` ^4.3.4 — JSX/Fast Refresh
-- In dev mode, Vite runs as Express middleware via `vite.middlewares` integration
-
-**Styling:**
-- Tailwind CSS 4.0.7 — utility-first CSS
-- `@tailwindcss/vite` ^4.0.7 — Vite plugin
-- `@tailwindcss/typography` ^0.5.19 — prose styles
-- `tailwind-merge` ^3.0+ — conditional class merging
-- `class-variance-authority` ^0.7.1 — component variant management
-- `clsx` ^2.1.1 — conditional class names
-
-**UI Components:**
-- `radix-ui` ^1.4.3 — unstyled accessible primitives
-- `@radix-ui/react-slot` ^1.2.4
-- Component files in `ui/src/components/ui/`: button, card, dialog, input, badge, tabs, tooltip, etc. (shadcn-style pattern)
-- `lucide-react` ^0.574.0 — icon library
-- `cmdk` ^1.1.1 — command palette
-
-**Rich Text / Markdown:**
-- `@mdxeditor/editor` ^3.52.4 — rich markdown editor component
-- `lexical` 0.35.0 + `@lexical/link` — editor framework (peer dep of MDXEditor)
-- `react-markdown` ^10.1.0 — Markdown rendering
-- `remark-gfm` ^4.0.1 — GitHub-flavored Markdown
-- `mermaid` ^11.12.0 — diagram rendering
-
-**Drag-and-Drop:**
-- `@dnd-kit/core` ^6.3.1, `@dnd-kit/sortable` ^10.0.0, `@dnd-kit/utilities` ^3.2.2
-
-**Path Alias:** `@/` maps to `ui/src/` (configured in `vite.config.ts`)
-
----
-
-## CLI
-
-**Framework:**
-- `commander` ^13.1.0 — command parsing
-- `@clack/prompts` ^0.10.0 — interactive terminal prompts
-- `picocolors` ^1.1.1 — terminal color output
-
-**Build:**
-- `esbuild` ^0.27.3 — bundles CLI to single `dist/index.js` (config: `cli/esbuild.config.mjs`)
-
----
-
-## Storage
-
-**Providers (runtime-selectable):**
-- Local disk — `server/src/storage/local-disk-provider.ts` — default, stores under `PAPERCLIP_HOME`
-- AWS S3 — `server/src/storage/s3-provider.ts` — via `@aws-sdk/client-s3` ^3.888.0
-
-**Secrets:**
-- Local encrypted provider — `server/src/secrets/local-encrypted-provider.ts`
-- External stub providers — `server/src/secrets/external-stub-providers.ts`
-
----
-
-## Testing Frameworks
-
-**Unit / Integration:**
-- Vitest ^3.0.5 — test runner (configured in root `vitest.config.ts` as multi-project)
-- Projects under test: `packages/db`, `packages/adapters/opencode-local`, `server`, `ui`, `cli`
-- Server tests: `server/src/__tests__/` (~95 test files)
-- Server vitest config: `server/vitest.config.ts` (env: `node`)
-- `supertest` ^7.0.0 — HTTP integration testing for Express routes
-
-**E2E:**
-- Playwright ^1.58.2 — browser E2E tests
-- Config: `tests/e2e/playwright.config.ts`
-- Browser: Chromium only
-- `tests/e2e/` — feature specs, `tests/release-smoke/` — release smoke tests
-
-**Evaluations:**
-- `promptfoo` 0.103.3 — LLM prompt evaluation (`evals/promptfoo/`)
-
----
-
-## Build and Tooling
-
-**TypeScript:**
-- TypeScript 5.7.3 across all packages
-- Base config: `tsconfig.base.json` — target ES2023, `NodeNext` module resolution, strict mode
-- Each package extends base or defines its own `tsconfig.json`
-
-**Dev Runner:**
-- `scripts/dev-runner.mjs` — coordinates parallel dev processes (server + UI)
-- `chokidar` ^4.0.3 — file watching in server dev mode
-
-**CLI published as:** `paperclipai` on npm (binary: `dist/index.js`)
-**Server published as:** `@paperclipai/server` on npm
-**Plugin SDK published as:** `@paperclipai/plugin-sdk` on npm
-
----
-
-## Docker / Deployment
-
-**Base image:** `node:lts-trixie-slim` (Debian-based)
-
-**Multi-stage Dockerfile:**
-1. `base` — Node + pnpm + ca-certificates + curl + git
-2. `deps` — install all dependencies with frozen lockfile
-3. `build` — build UI, plugin-sdk, server in order
-4. `production` — copy build output; globally install `@anthropic-ai/claude-code`, `@openai/codex`, `opencode-ai`
-
-**Port:** 3100 (configurable via `PORT` env var)
-**Data volume:** `/paperclip` — all persistent state (DB, uploads, config)
-
-**Compose variants:**
-- `docker-compose.yml` — full stack with external Postgres 17
-- `docker-compose.quickstart.yml` — single container, embedded Postgres
-- `docker-compose.untrusted-review.yml` — special security sandbox mode
-
-**Key env vars:**
-- `DATABASE_URL` — external PostgreSQL URL (omit for embedded mode)
-- `BETTER_AUTH_SECRET` — required auth secret
-- `PAPERCLIP_DEPLOYMENT_MODE` — `authenticated` | `unauthenticated`
-- `PAPERCLIP_DEPLOYMENT_EXPOSURE` — `private` | `public`
-- `PAPERCLIP_PUBLIC_URL` — public-facing URL
-- `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` — AI provider keys
-- `PAPERCLIP_HOME` — data root directory (default `/paperclip` in Docker)
-
----
-
-## AI Agent Integrations (Adapters)
-
-Each adapter follows a consistent three-export pattern: `./server`, `./ui`, `./cli`.
-
-| Adapter | Target Agent CLI |
-|---------|-----------------|
-| `adapter-claude-local` | `@anthropic-ai/claude-code` |
-| `adapter-codex-local` | `@openai/codex` |
-| `adapter-cursor-local` | Cursor editor |
-| `adapter-gemini-local` | Gemini CLI |
-| `adapter-openclaw-gateway` | Remote agent relay (WebSocket, `ws`) |
-| `adapter-opencode-local` | `opencode-ai` |
-| `adapter-pi-local` | pi.ai |
-
-The `hermes-paperclip-adapter` 0.1.1 is an additional server-side dependency (third-party adapter protocol).
-
----
-
-*Stack analysis: 2026-03-30*

.planning/config.json

@@ -1,37 +0,0 @@
-{
-  "model_profile": "balanced",
-  "commit_docs": true,
-  "parallelization": true,
-  "search_gitignored": false,
-  "brave_search": false,
-  "firecrawl": false,
-  "exa_search": false,
-  "git": {
-    "branching_strategy": "phase",
-    "phase_branch_template": "gsd/phase-{phase}-{slug}",
-    "milestone_branch_template": "gsd/{milestone}-{slug}",
-    "quick_branch_template": null
-  },
-  "workflow": {
-    "research": true,
-    "plan_check": true,
-    "verifier": true,
-    "nyquist_validation": true,
-    "auto_advance": true,
-    "node_repair": true,
-    "node_repair_budget": 2,
-    "ui_phase": true,
-    "ui_safety_gate": true,
-    "text_mode": false,
-    "research_before_questions": true,
-    "discuss_mode": "discuss",
-    "skip_discuss": true,
-    "_auto_chain_active": false
-  },
-  "hooks": {
-    "context_warnings": true
-  },
-  "agent_skills": {},
-  "mode": "yolo",
-  "granularity": "coarse"
-}

.planning/milestone-queue/v1.4-REQUIREMENTS.md

@@ -1,217 +0,0 @@
-# Requirements: v1.4 Hermes as Default Inference Provider + Web Control Plane
-
-**Version:** 1.4
-**Status:** Queued
-**Depends on:** v1.2.0.1 (nxr), v1.2.1 (Universal Skills), v1.3 (Web Chat)
-**Source PRD:** `~/Downloads/nexus-v1.4-prd.md`
-
----
-
-## Summary
-
-| Category | Count |
-|----------|-------|
-| ONBOARD  | 8     |
-| SCORE    | 6     |
-| UPGRADE  | 6     |
-| WEBCP    | 14    |
-| SCAN     | 5     |
-| SKILL    | 7     |
-| NXR      | 9     |
-| DATA     | 7     |
-| **Total** | **62** |
-
----
-
-## ONBOARD — Free-by-Default Onboarding
-
-- [ ] **ONBOARD-01** CLI onboarding (`npx buildthis`) prompts the user to optionally install Hermes Agent, explaining it runs entirely on free models with zero API key required.
-- [ ] **ONBOARD-02** CLI onboarding detects available local AI capabilities at install time: Ollama (model loaded, GPU/RAM), faster-whisper, and flags their availability in output and in the `onboarding` DB record.
-- [ ] **ONBOARD-03** When the user accepts Hermes install, onboarding automatically creates three default agents (PM, Engineer, Hermes) with role-appropriate free models assigned via the scoring algorithm.
-- [ ] **ONBOARD-04** Onboarding output displays each created agent's name, assigned model, model metadata (context window, capabilities), and pre-loaded skillset.
-- [ ] **ONBOARD-05** The zero-key experience allows all agents to run without an OpenRouter API key using the `openrouter/free` auto-router; free tier rate limits (50 req/day without credits, 1000/day with $10+) are communicated clearly at the end of onboarding.
-- [ ] **ONBOARD-06** When local Ollama is detected during onboarding, auxiliary tasks (compression, vision, web extract) are automatically configured to route locally at zero cost with no rate limits.
-- [ ] **ONBOARD-07** The web onboarding wizard (`/setup`) is feature-equivalent to the CLI flow: five steps (workspace name, Hermes install pitch, auto-create agents, optional API key paste, dashboard redirect) and is idempotent with the CLI flow.
-- [ ] **ONBOARD-08** Running both the CLI onboarding and web wizard produces the same default state and causes no duplication — the `onboarding` table record prevents re-execution.
-
----
-
-## SCORE — Model Scoring Engine
-
-- [ ] **SCORE-01** A deterministic scoring function exists in `nxr` that assigns a numeric score to any free model for a given role using the formula: `(context_length * 0.3) + (has_tools * 30) + (has_reasoning * 20) + (throughput * 0.1)`.
-- [ ] **SCORE-02** The scoring function filters the `or_model_catalog` to only `is_free = 1 AND is_available = 1` models, applies role requirements (tools support, vision, reasoning, minimum context window), and returns the highest-scoring model for the role.
-- [ ] **SCORE-03** If no model satisfies the role requirements, the function falls back to `openrouter/free` auto-router; if Ollama is available, local Qwen3.5 9B is the emergency fallback.
-- [ ] **SCORE-04** The scoring function covers all six role categories: `pm`, `engineer`, `hermes`, `creative`, `research`, and `custom` — each with documented minimum requirements.
-- [ ] **SCORE-05** Scoring results are persisted to the `model_scores` libSQL table with `model_id`, `role`, composite score, sub-scores (context, tools, reasoning, throughput), `is_free`, and `scored_at` timestamp.
-- [ ] **SCORE-06** The scoring function is callable from both the `nxr` CLI (`nxr agents rescore`) and from the Go HTTP backend API (`POST /api/models/rescore`), producing identical output for the same catalog state.
-
----
-
-## UPGRADE — API Key Upgrade Flow
-
-- [ ] **UPGRADE-01** `nxr upgrade` (interactive mode) validates the provided OpenRouter API key, detects account balance, and displays the free tier unlock status (50/day → 1000/day).
-- [ ] **UPGRADE-02** After key validation, `nxr upgrade` presents a per-agent upgrade preview showing each agent's current free model and its recommended paid replacement with price per million tokens and context window.
-- [ ] **UPGRADE-03** The user can respond `Y` (upgrade all), `n` (store key only, keep free models), or `custom` (per-agent model picker TUI) — each path executes correctly and writes to config atomically.
-- [ ] **UPGRADE-04** `nxr upgrade --all` upgrades all agents to their recommended paid models non-interactively; `nxr upgrade --agent "<name>"` upgrades a single named agent.
-- [ ] **UPGRADE-05** `nxr upgrade --revert` switches all agents back to their last-recorded free model assignments; agent memory, skills, and session history are preserved across all upgrade and revert operations.
-- [ ] **UPGRADE-06** The web agent manager (`/agents/manage`) exposes a "Bulk Upgrade" button and per-agent upgrade controls that call `POST /api/agents/bulk-upgrade` or `GET /api/agents/:id/recommend` respectively, with the same logic as the CLI flow.
-
----
-
-## WEBCP — Web Control Plane (Nexus Hub)
-
-### Process Control (`/hermes`)
-- [ ] **WEBCP-01** The `/hermes` page displays live Hermes process status: PID, uptime, current model, and tmux viewer count; data is fetched from `GET /api/hermes/ps`.
-- [ ] **WEBCP-02** The `/hermes` page provides Start, Stop, and Restart buttons that call `POST /api/hermes/up`, `POST /api/hermes/down`, and `POST /api/hermes/restart` respectively, with visible success/failure feedback.
-- [ ] **WEBCP-03** The `/hermes` page shows an Ollama status card with loaded model, GPU usage, and throughput when Ollama is available.
-
-### Model Switcher (`/models/switch`)
-- [ ] **WEBCP-04** The `/models/switch` page renders a visual slot editor showing all 7 routing slots (primary, fallback, simple, vision, web_extract, approval, compression) with their currently assigned models.
-- [ ] **WEBCP-05** Clicking any slot opens a model picker modal with fuzzy search and filter toggles (free, tools, vision, reasoning, MoE); selecting a model and confirming calls `PUT /api/routing/:slot` and writes `config.yaml` atomically.
-- [ ] **WEBCP-06** The model picker modal displays a price comparison side panel showing cost per million input/output tokens for the currently selected model vs. the active slot model.
-
-### Agent Manager (`/agents/manage`)
-- [ ] **WEBCP-07** The `/agents/manage` page lists all agents with per-agent model assignment, role-aware model recommendation (from `GET /api/agents/:id/recommend`), last heartbeat, message count, cost, and error rate.
-- [ ] **WEBCP-08** The `/agents/manage` page allows skill assignment per agent using category templates, calling `POST /api/agents/:id/skills`.
-- [ ] **WEBCP-09** The `/agents/manage` page includes a "Create Agent" flow: category picker → auto model assignment → auto skill suggestion → name input → confirm — calling the existing agent creation API with the new `role`, `skillset`, and `model_auto_assigned` fields.
-
-### Budget Dashboard (`/budget`)
-- [ ] **WEBCP-10** The `/budget` page shows a real-time free tier gauge (requests used / daily limit) sourced from `hermes_tracking.db` usage data.
-- [ ] **WEBCP-11** The `/budget` page shows per-agent cost breakdown for today, last 7 days, and last 30 days, plus a cost projection graph and a rate limit event log.
-- [ ] **WEBCP-12** The `/budget` page provides an "Export as CSV" action that downloads the usage data for the selected time range.
-
-### Notifications Center (`/notifications`)
-- [ ] **WEBCP-13** The `/notifications` page displays all notification types from v1.2.1 plus new v1.4 types: rate limit warnings, agent auto-upgrade events, and model availability alerts; each notification can be marked read via `PUT /api/notifications/:id/read`.
-- [ ] **WEBCP-14** The `/notifications` page includes per-type Telegram forwarding toggles that persist via `POST /api/notifications/settings`.
-
----
-
-## SCAN — Scanner Updates
-
-- [ ] **SCAN-01** After each 6-hourly OpenRouter catalog scan, the scanner re-scores all free models for every role category using the SCORE-01 algorithm and persists results to `model_scores`.
-- [ ] **SCAN-02** If a re-score reveals a better free model for an active agent's role, the scanner creates a notification with the old model name, new model name, role, and score delta — plus a one-click upgrade action.
-- [ ] **SCAN-03** A config flag `auto_upgrade_free_models` in `~/.hermes/config.yaml` (default `false`) controls whether the scanner auto-switches agents to better free models or only notifies.
-- [ ] **SCAN-04** The scanner queries `model_usage` to compute average free requests per hour for the current day and projects whether the workspace will hit the daily limit before midnight UTC; this projection is surfaced in the dashboard and `nxr budget`.
-- [ ] **SCAN-05** Rate limit threshold warnings are triggered at 70% (dashboard warning), 90% (Telegram notification if gateway configured), and 100% (agents queue tasks until midnight UTC reset, or route to local Qwen if available).
-
----
-
-## SKILL — Default Skillsets and Agent Templates
-
-- [ ] **SKILL-01** The PM agent is created with exactly 8 pre-loaded skills: `planning`, `task-breakdown`, `prioritization`, `status-reporting`, `dependency-mapping`, `sprint-planning`, `risk-assessment`, `stakeholder-comms`.
-- [ ] **SKILL-02** The Engineer agent is created with exactly 8 pre-loaded skills: `coding`, `debugging`, `git-workflow`, `testing`, `code-review`, `refactoring`, `architecture`, `documentation`.
-- [ ] **SKILL-03** The Hermes agent is created with exactly 8 pre-loaded skills: `memory`, `web-search`, `file-ops`, `cron`, `usage-tracker`, `model-scanner`, `skill-creator`, `session-search`.
-- [ ] **SKILL-04** All agent skill assignments go through Hermes's skill assignment system so that the existing `listSkills`/`syncSkills` adapter API sees the skills correctly.
-- [ ] **SKILL-05** When creating a custom agent, the user can select a role category (tech, creative, business, research, media, personal); each category has a suggested skill template that pre-populates the skill selector.
-- [ ] **SKILL-06** Custom category skill templates are defined for all 6 categories: tech (coding, debugging, git-workflow, testing, architecture), creative (creative-writing, screenwriting, worldbuilding, dialogue), business (strategy, proposal-writing, market-analysis, financial-modeling), research (paper-analysis, literature-review, data-analysis, methodology), media (journalism, copywriting, social-media, content-strategy), personal (goal-setting, language-tutoring, fitness, travel-planning).
-- [ ] **SKILL-07** Skills assigned during onboarding or agent creation are suggestions only — users can add or remove skills freely after creation, and skills from `agentskills.io` are installable via `hermes skills search`.
-
----
-
-## NXR — nxr Additions
-
-- [ ] **NXR-01** `nxr init` runs the interactive onboarding wizard: workspace name, Hermes install prompt, auto-creates PM + Engineer + Hermes with free models, optional API key prompt, and displays the ready summary.
-- [ ] **NXR-02** `nxr init --free` skips the API key prompt and runs in pure free mode without interactive prompts beyond workspace name.
-- [ ] **NXR-03** `nxr init --key <sk-or-...>` accepts a pre-set API key and uses it during init without prompting.
-- [ ] **NXR-04** `nxr upgrade` runs the interactive upgrade picker as described in UPGRADE-01 through UPGRADE-03.
-- [ ] **NXR-05** `nxr upgrade --all` and `nxr upgrade --agent "<name>"` run non-interactively as described in UPGRADE-04.
-- [ ] **NXR-06** `nxr upgrade --revert` reverts all agents to free models as described in UPGRADE-05.
-- [ ] **NXR-07** `nxr agents recommend` prints a table showing the recommended model for each agent based on its role, pulled from the scoring algorithm.
-- [ ] **NXR-08** `nxr agents rescore` re-runs the free model scoring algorithm for all agents and updates `model_scores`; output shows any model changes.
-- [ ] **NXR-09** `nxr agents create --role <role> --name <name> --free` creates a new agent with auto-selected free model and auto-applied skill template for the given role; TUI Tab 5 gains a "Create Agent" wizard with the same category → model → skills → name flow.
-
----
-
-## DATA — Data Model Changes
-
-- [ ] **DATA-01** The `agents` table in `hermes_tracking.db` gains a `role TEXT` column storing one of: `pm`, `engineer`, `hermes`, `custom`.
-- [ ] **DATA-02** The `agents` table gains a `skillset TEXT` column storing a JSON array of skill name strings.
-- [ ] **DATA-03** The `agents` table gains a `model_score REAL DEFAULT 0` column storing the auto-calculated quality score at the time of last model assignment.
-- [ ] **DATA-04** The `agents` table gains a `model_auto_assigned INTEGER DEFAULT 0` column; value `1` indicates nxr selected the model automatically.
-- [ ] **DATA-05** The `agents` table gains `workspace_id TEXT` and `is_default INTEGER DEFAULT 0` columns; `is_default = 1` marks agents created during onboarding.
-- [ ] **DATA-06** A new `model_scores` table is created in `hermes_tracking.db` (libSQL) with columns: `id`, `model_id`, `role`, `score`, `context_score`, `tools_score`, `reasoning_score`, `throughput_score`, `is_free`, `scored_at`; unique constraint on `(model_id, role, scored_at)`; indexes on `role` and `is_free`.
-- [ ] **DATA-07** A new `onboarding` table is created in `hermes_tracking.db` (libSQL) with columns: `id`, `completed_at`, `workspace_name`, `has_openrouter_key`, `has_ollama`, `has_whisper`, `agents_created` (JSON array of agent IDs), `initial_free_models` (JSON snapshot of model assignments at creation).
-
----
-
-## Out of Scope
-
-The following are explicitly excluded from v1.4 per PRD Section 13:
-
-- **Multi-user auth for web dashboard** — single-user, localhost only; future milestone
-- **Self-hosted model registries beyond Ollama** — future consideration
-- **Model training or fine-tuning** — models used as-is from OpenRouter
-- **Auto-spending user money** — free-by-default; paid models require explicit opt-in every time
-- **Guaranteed free model availability** — scanner detects and adapts when models leave the free tier; no SLA
-- **WebSocket live terminal stream (`WS /api/hermes/stream`)** — stretch goal; `nxr watch` is the primary observation path; ship without and add later
-- **Paperclip agent orchestration replacement** — Hermes provides inference, Paperclip provides orchestration; they are complementary
-- **Blog auto-generation triggers** — PRD Section 11 is informational context for v1.2.1 auto-blogging system; not a v1.4 implementation requirement
-
----
-
-## Traceability
-
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| ONBOARD-01 | Phase 30 | Pending |
-| ONBOARD-02 | Phase 30 | Pending |
-| ONBOARD-03 | Phase 30 | Pending |
-| ONBOARD-04 | Phase 30 | Pending |
-| ONBOARD-05 | Phase 30 | Pending |
-| ONBOARD-06 | Phase 30 | Pending |
-| ONBOARD-07 | Phase 30 | Pending |
-| ONBOARD-08 | Phase 30 | Pending |
-| SCORE-01 | Phase 28 | Pending |
-| SCORE-02 | Phase 28 | Pending |
-| SCORE-03 | Phase 28 | Pending |
-| SCORE-04 | Phase 28 | Pending |
-| SCORE-05 | Phase 28 | Pending |
-| SCORE-06 | Phase 28 | Pending |
-| UPGRADE-01 | Phase 31 | Pending |
-| UPGRADE-02 | Phase 31 | Pending |
-| UPGRADE-03 | Phase 31 | Pending |
-| UPGRADE-04 | Phase 31 | Pending |
-| UPGRADE-05 | Phase 31 | Pending |
-| UPGRADE-06 | Phase 31 | Pending |
-| WEBCP-01 | Phase 34 | Pending |
-| WEBCP-02 | Phase 34 | Pending |
-| WEBCP-03 | Phase 34 | Pending |
-| WEBCP-04 | Phase 34 | Pending |
-| WEBCP-05 | Phase 34 | Pending |
-| WEBCP-06 | Phase 34 | Pending |
-| WEBCP-07 | Phase 34 | Pending |
-| WEBCP-08 | Phase 34 | Pending |
-| WEBCP-09 | Phase 34 | Pending |
-| WEBCP-10 | Phase 34 | Pending |
-| WEBCP-11 | Phase 34 | Pending |
-| WEBCP-12 | Phase 34 | Pending |
-| WEBCP-13 | Phase 34 | Pending |
-| WEBCP-14 | Phase 34 | Pending |
-| SCAN-01 | Phase 32 | Pending |
-| SCAN-02 | Phase 32 | Pending |
-| SCAN-03 | Phase 32 | Pending |
-| SCAN-04 | Phase 32 | Pending |
-| SCAN-05 | Phase 32 | Pending |
-| SKILL-01 | Phase 29 | Pending |
-| SKILL-02 | Phase 29 | Pending |
-| SKILL-03 | Phase 29 | Pending |
-| SKILL-04 | Phase 29 | Pending |
-| SKILL-05 | Phase 29 | Pending |
-| SKILL-06 | Phase 29 | Pending |
-| SKILL-07 | Phase 29 | Pending |
-| NXR-01 | Phase 30 | Pending |
-| NXR-02 | Phase 30 | Pending |
-| NXR-03 | Phase 30 | Pending |
-| NXR-04 | Phase 31 | Pending |
-| NXR-05 | Phase 31 | Pending |
-| NXR-06 | Phase 31 | Pending |
-| NXR-07 | Phase 33 | Pending |
-| NXR-08 | Phase 33 | Pending |
-| NXR-09 | Phase 33 | Pending |
-| DATA-01 | Phase 27 | Pending |
-| DATA-02 | Phase 27 | Pending |
-| DATA-03 | Phase 27 | Pending |
-| DATA-04 | Phase 27 | Pending |
-| DATA-05 | Phase 27 | Pending |
-| DATA-06 | Phase 27 | Pending |
-| DATA-07 | Phase 27 | Pending |

.planning/milestone-queue/v1.4-ROADMAP.md

@@ -1,207 +0,0 @@
-# Roadmap: v1.4 Hermes as Default Inference Provider + Web Control Plane
-
-**Milestone:** v1.4
-**Phases:** 27–34
-**Coverage:** 62/62 requirements mapped
-**Depends on:** v1.2.0.1 (nxr), v1.2.1 (Universal Skills), v1.3 (Web Chat)
-
----
-
-## Phases
-
-- [ ] **Phase 27: Data Model** — libSQL schema additions for agents table, model_scores table, and onboarding table
-- [ ] **Phase 28: Model Scoring Engine** — Deterministic scoring function, per-role selection algorithm, scoring API
-- [ ] **Phase 29: Default Skillsets and Agent Templates** — Curated skill assignments for PM, Engineer, Hermes, and custom category templates
-- [ ] **Phase 30: Free-by-Default Onboarding** — CLI and web wizard flows that create three agents on free models with zero API key
-- [ ] **Phase 31: API Key Upgrade Flow** — nxr upgrade commands and web bulk-upgrade that switch agents from free to paid models
-- [ ] **Phase 32: Scanner Updates** — Post-scan rescoring, better-model notifications, rate limit prediction
-- [ ] **Phase 33: nxr Agent Commands** — nxr agents recommend, rescore, create; TUI Tab 5 create wizard
-- [ ] **Phase 34: Web Control Plane** — Nexus Hub pages for process control, model switching, agent management, budget, and notifications
-
----
-
-## Phase Details
-
-### Phase 27: Data Model
-**Goal**: The libSQL database in `hermes_tracking.db` has all schema additions v1.4 requires — agents table columns for role and skill metadata, a model_scores table for scoring history, and an onboarding table for wizard state — so every subsequent phase can read and write without migration surprises
-**Depends on**: v1.2.0.1 (existing hermes_tracking.db schema)
-**Requirements**: DATA-01, DATA-02, DATA-03, DATA-04, DATA-05, DATA-06, DATA-07
-**Success Criteria** (what must be TRUE):
-  1. The `agents` table has all six new columns (`role`, `skillset`, `model_score`, `model_auto_assigned`, `workspace_id`, `is_default`) with correct types and defaults, addable via `ALTER TABLE` without touching upstream Paperclip migrations
-  2. The `model_scores` table exists with all defined columns, the `UNIQUE(model_id, role, scored_at)` constraint, and indexes on `role` and `is_free`; queries against it return zero rows on a fresh DB without errors
-  3. The `onboarding` table exists with all defined columns; inserting a record and querying `completed_at IS NOT NULL` works as expected
-  4. All schema additions use libSQL (not modernc.org/sqlite or any other driver) and are applied via the same migration mechanism used by the rest of nxr
-**Plans**: TBD
-
-### Phase 28: Model Scoring Engine
-**Goal**: A deterministic Go scoring function can take any agent role and the current free model catalog, apply the scoring formula, enforce role-specific requirements, and return the best available model — callable from both the CLI and the HTTP API
-**Depends on**: Phase 27
-**Requirements**: SCORE-01, SCORE-02, SCORE-03, SCORE-04, SCORE-05, SCORE-06
-**Success Criteria** (what must be TRUE):
-  1. Given identical catalog input, the scoring function always returns the same model for the same role (deterministic output verified by test)
-  2. Running the scorer for each of the six roles (pm, engineer, hermes, creative, research, custom) returns a model that satisfies that role's minimum requirements (tools support, context window, etc.); if no model qualifies, the fallback chain (`openrouter/free` → local Qwen) is used
-  3. Scoring results are written to the `model_scores` libSQL table with all sub-scores populated and a `scored_at` timestamp
-  4. `POST /api/models/rescore` triggers the scorer and returns the updated best model per role; `GET /api/models/best-free?role=<role>` returns the current top pick for that role
-  5. `GET /api/models/roster` returns all free models with their scores for all roles in a single response
-**Plans**: TBD
-
-### Phase 29: Default Skillsets and Agent Templates
-**Goal**: When any agent is created — through onboarding, `nxr agents create`, or the web wizard — the correct curated skillset is automatically applied based on role, and the Paperclip adapter can see those skills via `listSkills`/`syncSkills`
-**Depends on**: Phase 27
-**Requirements**: SKILL-01, SKILL-02, SKILL-03, SKILL-04, SKILL-05, SKILL-06, SKILL-07
-**Success Criteria** (what must be TRUE):
-  1. A newly created PM agent has exactly 8 skills in its `skillset` column (`planning`, `task-breakdown`, `prioritization`, `status-reporting`, `dependency-mapping`, `sprint-planning`, `risk-assessment`, `stakeholder-comms`)
-  2. A newly created Engineer agent has exactly 8 skills (`coding`, `debugging`, `git-workflow`, `testing`, `code-review`, `refactoring`, `architecture`, `documentation`) and Hermes agent has exactly 8 skills (`memory`, `web-search`, `file-ops`, `cron`, `usage-tracker`, `model-scanner`, `skill-creator`, `session-search`)
-  3. The `listSkills` adapter API call on any default agent returns the correct skill list so Paperclip heartbeats can read it
-  4. Selecting a custom agent category (tech, creative, business, research, media, personal) during creation pre-populates the skill selector with that category's defined template; all 6 categories have templates
-  5. Adding or removing skills after creation is possible and does not break the `syncSkills` round-trip
-**Plans**: TBD
-
-### Phase 30: Free-by-Default Onboarding
-**Goal**: A user can run `nxr init` or open `/setup` in the browser and within 5 minutes have three working agents (PM, Engineer, Hermes) running on free models with zero API key, zero cost, and zero manual configuration
-**Depends on**: Phase 28, Phase 29
-**Requirements**: ONBOARD-01, ONBOARD-02, ONBOARD-03, ONBOARD-04, ONBOARD-05, ONBOARD-06, ONBOARD-07, ONBOARD-08, NXR-01, NXR-02, NXR-03
-**Success Criteria** (what must be TRUE):
-  1. `nxr init` on a fresh install completes in under 5 minutes, creates all three default agents with free models assigned by the scoring algorithm, and prints each agent's name, model, and skillset in the confirmation output
-  2. `nxr init --free` runs without prompting for an API key; `nxr init --key sk-or-...` accepts a key non-interactively and uses it during setup
-  3. The CLI onboarding detects Ollama and faster-whisper availability and records the findings in the `onboarding` DB table; auxiliary task routing is configured for local processing when Ollama is found
-  4. The web wizard at `/setup` completes the same five steps and results in the same DB state as the CLI flow; running both flows does not create duplicate agents
-  5. The `onboarding` table record is created with `completed_at`, `agents_created`, and `initial_free_models` populated; re-running either flow detects the existing record and skips agent creation
-  6. The zero-key free tier limits are displayed clearly at the end of both flows, with instructions for upgrading via `nxr config set openrouter-key`
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 31: API Key Upgrade Flow
-**Goal**: A user with a working free-tier workspace can add an OpenRouter API key in one command or one button click, see per-agent upgrade recommendations, and switch all agents to paid models — with a revert path if they change their mind
-**Depends on**: Phase 28, Phase 30
-**Requirements**: UPGRADE-01, UPGRADE-02, UPGRADE-03, UPGRADE-04, UPGRADE-05, UPGRADE-06, NXR-04, NXR-05, NXR-06
-**Success Criteria** (what must be TRUE):
-  1. `nxr upgrade` validates the OpenRouter API key, detects account balance, and displays the correct free tier tier (50/day or 1000/day) based on credit balance
-  2. The interactive upgrade prompt shows every agent's current free model alongside its recommended paid replacement with pricing; the user can select Y, n, or custom and each path executes without error
-  3. `nxr upgrade --all` switches all agents to paid models non-interactively; `nxr upgrade --agent "<name>"` upgrades exactly one agent
-  4. `nxr upgrade --revert` switches all agents back to their last free model assignments; agent memory, skills, and session history are intact after both upgrade and revert
-  5. The web agent manager's "Bulk Upgrade" button calls the API and shows the same per-agent recommendations and confirmation; individual agent upgrade controls work per-agent
-  6. After any upgrade or revert, `nxr agents recommend` output reflects the current model assignments correctly
-**Plans**: TBD
-
-### Phase 32: Scanner Updates
-**Goal**: The 6-hourly OpenRouter scanner automatically rescores all models after each scan, creates actionable notifications when better free models are available, and proactively warns the workspace before it hits daily rate limits
-**Depends on**: Phase 27, Phase 28
-**Requirements**: SCAN-01, SCAN-02, SCAN-03, SCAN-04, SCAN-05
-**Success Criteria** (what must be TRUE):
-  1. After each scan run, the scanner writes fresh rows to `model_scores` for every role category; the `scored_at` timestamps in the table match the scan time
-  2. When a re-score reveals a higher-scoring free model for an active agent's role, a notification record is created with the old model name, new model name, role, and score delta; the notification includes a one-click upgrade action
-  3. The `auto_upgrade_free_models` config flag (default `false`) controls whether the scanner auto-switches agents or only creates notifications; setting it `true` and triggering a re-score automatically updates agent model assignments
-  4. `nxr budget` displays the projected daily request total based on current usage rate and hours remaining, with a clear indicator if the workspace is on track to hit the limit
-  5. Rate limit warnings appear in the dashboard at 70% consumption, a Telegram notification fires at 90% (when gateway is configured), and agents queue tasks at 100% rather than erroring
-**Plans**: TBD
-
-### Phase 33: nxr Agent Commands
-**Goal**: Users can ask nxr for model recommendations per agent, re-run scoring on demand, and create new agents with auto-selected models and skill templates — all from the terminal — and the TUI Tab 5 provides the same create flow visually
-**Depends on**: Phase 28, Phase 29, Phase 31
-**Requirements**: NXR-07, NXR-08, NXR-09
-**Success Criteria** (what must be TRUE):
-  1. `nxr agents recommend` prints a table with one row per agent showing: agent name, current model, recommended model for its role, and whether an upgrade is available
-  2. `nxr agents rescore` re-runs the scoring algorithm for all agents, writes updated rows to `model_scores`, and reports any agents where the recommended model has changed since the last score
-  3. `nxr agents create --role <role> --name <name> --free` creates a new agent, assigns the best free model for the role, applies the role's skill template, and confirms creation with a summary line
-  4. The TUI Tab 5 "Create Agent" wizard walks through: category selection → auto model recommendation display → skill template pre-fill → name input → confirm; the created agent appears in the agent list immediately
-**Plans**: TBD
-
-### Phase 34: Web Control Plane
-**Goal**: Every capability available in the `nxr` terminal TUI is also accessible from the Nexus Hub browser — process control, model slot switching, agent management with recommendations, budget tracking, and notification management
-**Depends on**: Phase 30, Phase 31, Phase 32, Phase 33
-**Requirements**: WEBCP-01, WEBCP-02, WEBCP-03, WEBCP-04, WEBCP-05, WEBCP-06, WEBCP-07, WEBCP-08, WEBCP-09, WEBCP-10, WEBCP-11, WEBCP-12, WEBCP-13, WEBCP-14
-**Success Criteria** (what must be TRUE):
-  1. The `/hermes` page shows live process status (PID, uptime, model, tmux viewers) and Start/Stop/Restart buttons that work correctly; the Ollama status card appears when Ollama is running
-  2. The `/models/switch` page slot editor shows all 7 routing slots with current assignments; clicking a slot opens a fuzzy-search model picker with filter toggles and a price comparison panel; confirming a pick writes `config.yaml` atomically
-  3. The `/agents/manage` page lists all agents with role-aware model recommendations, heartbeat recency, cost, and error rate; skill assignment and the "Create Agent" wizard produce the same result as `nxr agents create`
-  4. The `/budget` page shows the free tier gauge updating in real time, per-agent cost breakdowns for today/7d/30d, the cost projection graph, and the rate limit event log; CSV export downloads correctly
-  5. The `/notifications` page shows all notification types including v1.4 additions (rate limit warnings, auto-upgrade events, model availability alerts); Telegram forwarding toggles persist correctly; unread count badge in navigation updates after marking read
-**Plans**: TBD
-**UI hint**: yes
-
----
-
-## Coverage Validation
-
-All 62 v1.4 requirements are mapped to exactly one phase. No orphans.
-
-| Requirement | Phase |
-|-------------|-------|
-| DATA-01 | Phase 27 |
-| DATA-02 | Phase 27 |
-| DATA-03 | Phase 27 |
-| DATA-04 | Phase 27 |
-| DATA-05 | Phase 27 |
-| DATA-06 | Phase 27 |
-| DATA-07 | Phase 27 |
-| SCORE-01 | Phase 28 |
-| SCORE-02 | Phase 28 |
-| SCORE-03 | Phase 28 |
-| SCORE-04 | Phase 28 |
-| SCORE-05 | Phase 28 |
-| SCORE-06 | Phase 28 |
-| SKILL-01 | Phase 29 |
-| SKILL-02 | Phase 29 |
-| SKILL-03 | Phase 29 |
-| SKILL-04 | Phase 29 |
-| SKILL-05 | Phase 29 |
-| SKILL-06 | Phase 29 |
-| SKILL-07 | Phase 29 |
-| ONBOARD-01 | Phase 30 |
-| ONBOARD-02 | Phase 30 |
-| ONBOARD-03 | Phase 30 |
-| ONBOARD-04 | Phase 30 |
-| ONBOARD-05 | Phase 30 |
-| ONBOARD-06 | Phase 30 |
-| ONBOARD-07 | Phase 30 |
-| ONBOARD-08 | Phase 30 |
-| NXR-01 | Phase 30 |
-| NXR-02 | Phase 30 |
-| NXR-03 | Phase 30 |
-| UPGRADE-01 | Phase 31 |
-| UPGRADE-02 | Phase 31 |
-| UPGRADE-03 | Phase 31 |
-| UPGRADE-04 | Phase 31 |
-| UPGRADE-05 | Phase 31 |
-| UPGRADE-06 | Phase 31 |
-| NXR-04 | Phase 31 |
-| NXR-05 | Phase 31 |
-| NXR-06 | Phase 31 |
-| SCAN-01 | Phase 32 |
-| SCAN-02 | Phase 32 |
-| SCAN-03 | Phase 32 |
-| SCAN-04 | Phase 32 |
-| SCAN-05 | Phase 32 |
-| NXR-07 | Phase 33 |
-| NXR-08 | Phase 33 |
-| NXR-09 | Phase 33 |
-| WEBCP-01 | Phase 34 |
-| WEBCP-02 | Phase 34 |
-| WEBCP-03 | Phase 34 |
-| WEBCP-04 | Phase 34 |
-| WEBCP-05 | Phase 34 |
-| WEBCP-06 | Phase 34 |
-| WEBCP-07 | Phase 34 |
-| WEBCP-08 | Phase 34 |
-| WEBCP-09 | Phase 34 |
-| WEBCP-10 | Phase 34 |
-| WEBCP-11 | Phase 34 |
-| WEBCP-12 | Phase 34 |
-| WEBCP-13 | Phase 34 |
-| WEBCP-14 | Phase 34 |
-
----
-
-## Progress
-
-| Phase | Milestone | Plans Complete | Status | Completed |
-|-------|-----------|----------------|--------|-----------|
-| 27. Data Model | v1.4 | 0/? | Not started | - |
-| 28. Model Scoring Engine | v1.4 | 0/? | Not started | - |
-| 29. Default Skillsets and Agent Templates | v1.4 | 0/? | Not started | - |
-| 30. Free-by-Default Onboarding | v1.4 | 0/? | Not started | - |
-| 31. API Key Upgrade Flow | v1.4 | 0/? | Not started | - |
-| 32. Scanner Updates | v1.4 | 0/? | Not started | - |
-| 33. nxr Agent Commands | v1.4 | 0/? | Not started | - |
-| 34. Web Control Plane | v1.4 | 0/? | Not started | - |

.planning/milestones/v1.2.1-MILESTONE-AUDIT.md

@@ -1,62 +0,0 @@
----
-milestone: v1.2.1
-audited: "2026-04-01T14:00:00Z"
-status: passed
-scores:
-  requirements: 24/24
-  phases: 3/3
-  integration: 24/24
-  flows: 3/3
-gaps:
-  requirements: []
-  integration: []
-  flows: []
-tech_debt:
-  - phase: 18-adapter-path-resolver
-    items:
-      - "openclaw_gateway skill path (~/.openclaw/skills/) sourced from REQUIREMENTS.md only — LOW confidence"
-  - phase: 19-adapter-aware-install-uninstall
-    items:
-      - "3 items need human verification: end-to-end filesystem check, native skill button visibility, live syncHermesNativeSkills"
-  - phase: 20-enable-all-adapters-ui-awareness
-    items:
-      - "Human verification needed: Hermes agent creation + heartbeat E2E, adapter label rendering, install guard UX"
-nyquist:
-  compliant_phases: []
-  partial_phases: [18, 19, 20]
-  missing_phases: []
-  overall: partial
----
-
-# Milestone v1.2.1 — Universal Skill Management Audit
-
-## Summary
-
-| Metric | Score |
-|--------|-------|
-| Requirements | 24/24 satisfied |
-| Phases | 3/3 complete |
-| Integration | 24/24 wired |
-| E2E Flows | 3/3 complete |
-| Status | **passed** |
-
-## Phase Verification Results
-
-| Phase | Name | Status | Must-Haves |
-|-------|------|--------|------------|
-| 18 | Adapter Path Resolver | passed | 6/6 |
-| 19 | Adapter-Aware Install/Uninstall | passed | 5/5 |
-| 20 | Enable All Adapters + UI Awareness | passed | 7/7 |
-
-## Requirements Coverage
-
-All 24 requirements (ADAPT-01 through ADAPT-10, INST-01 through INST-04, HERM-01 through HERM-03, ENABLE-01 through ENABLE-04, UIADP-01 through UIADP-03) satisfied across 3 phases.
-
-## Key Accomplishments
-
-1. AdapterSkillConfig resolver with research-backed paths for all 10 adapter types
-2. Adapter-aware skill install/uninstall/rollback writing to correct directories per runtime
-3. Hermes native skill sync with managed/native dual-section UI
-4. All adapters enabled in Add Agent dropdown (including gemini_local type fix)
-5. Expanded Hermes config form (model, toolsets, persistSession, timeoutSec)
-6. Skill Browser shows adapter compatibility chips and unsupported install guard

.planning/milestones/v1.2.1-REQUIREMENTS.md

@@ -1,133 +0,0 @@
-# Requirements Archive: v1.2.1 Universal Skill Management
-
-**Archived:** 2026-04-01
-**Status:** SHIPPED
-
-For current requirements, see `.planning/REQUIREMENTS.md`.
-
----
-
-# Requirements: Nexus
-
-**Defined:** 2026-03-30
-**Core Value:** Fresh onboard asks for ONE thing (root directory), auto-creates PM + Engineer, drops you in dashboard — no corporate language anywhere.
-
-## v1 Requirements
-
-Requirements for initial release. Each maps to roadmap phases.
-
-### Foundation
-
-- [x] **FOUND-01**: Branding package (`packages/branding/`) exists with all fork-specific display strings centralized
-- [x] **FOUND-02**: Zone taxonomy document classifies every rename target as display (safe), code (don't touch), or stored (don't touch)
-- [x] **FOUND-03**: All fork commits use `[nexus]` prefix for upstream rebase visibility
-- [x] **FOUND-04**: `git rerere` enabled and `git range-diff` documented for rebase workflow
-
-### Terminology
-
-- [ ] **TERM-01**: "Company" displays as "Workspace" in all UI surfaces
-- [ ] **TERM-02**: "CEO" displays as "Project Manager" in all UI surfaces
-- [ ] **TERM-03**: "Board" displays as "Owner" in all UI surfaces
-- [ ] **TERM-04**: "Hire" displays as "Add" and "Fire" displays as "Remove" in all UI surfaces
-- [ ] **TERM-05**: `AGENT_ROLE_LABELS` constant updated (`ceo: "Project Manager"`)
-- [ ] **TERM-06**: CLI output strings updated (all user-facing terminal text uses Nexus vocabulary)
-- [ ] **TERM-07**: Default agent instruction content rewritten (SOUL.md, AGENTS.md, HEARTBEAT.md, TOOLS.md) with Nexus vocabulary
-
-### Onboarding
-
-- [ ] **ONBD-01**: Predefined PM agent template exists with 4 instruction files (AGENTS.md, HEARTBEAT.md, SOUL.md, TOOLS.md)
-- [ ] **ONBD-02**: Predefined Engineer agent template exists with 4 instruction files
-- [ ] **ONBD-03**: UI onboarding wizard asks only for root directory (no company name, no mission, no first task)
-- [ ] **ONBD-04**: Onboarding auto-creates PM and Engineer agents with predefined templates
-- [ ] **ONBD-05**: After onboarding, user lands directly in the dashboard
-- [ ] **ONBD-06**: CLI onboarding (`nexus onboard`) mirrors UI: pick root → auto-create agents → done
-- [ ] **ONBD-07**: "Add Agent" dialog uses "Add Agent" button text (not "Hire") with template dropdown
-
-### Branding
-
-- [ ] **BRND-01**: App title shows "Nexus" (not "Paperclip") in browser tab and top-left
-- [ ] **BRND-02**: Startup banner displays "NEXUS" ASCII art (not "PAPERCLIP")
-- [ ] **BRND-03**: CLI help text displays Nexus name and vocabulary
-- [ ] **BRND-04**: Favicon and logo assets updated to Nexus branding
-
-### Directory Structure
-
-- [ ] **DIR-01**: `~/.nexus` pointer file mechanism works (single file containing root directory path)
-- [ ] **DIR-02**: All data (config, DB, logs, backups, storage, agent data) lives under user-chosen root directory
-- [ ] **DIR-03**: Agent directories use human-readable slugified names (e.g., `agents/engineer/`) not UUIDs
-- [ ] **DIR-04**: Config resolution in CLI and server respects `~/.nexus` pointer file
-- [ ] **DIR-05**: Read-both-paths fallback: server checks `~/.paperclip` if `~/.nexus` not found (migration safety)
-
-## v2 Requirements
-
-Deferred to future release. Tracked but not in current roadmap.
-
-### Theming
-
-- **THEME-01**: Full Catppuccin Mocha dark theme applied to entire UI
-- **THEME-02**: Dark/light theme toggle with Catppuccin Mocha + Tokyo Night options
-
-### Integrations
-
-- **INTG-01**: Telegram Channels integration for persistent agent sessions
-- **INTG-02**: NPM reverse proxy for remote dashboard access
-- **INTG-03**: Recipe Registry plugin
-
-## Out of Scope
-
-Explicitly excluded. Documented to prevent scope creep.
-
-| Feature | Reason |
-|---------|--------|
-| DB schema renames (companies table, company_id columns) | Upstream sync priority — would create migration hell |
-| API route path changes (/api/companies stays) | Upstream sync — UI translates client-side |
-| TypeScript identifier renames (companyService etc.) | Thousands of import statements — massive merge conflict surface |
-| Package name renames (@paperclipai/* stays) | Every import in the monorepo — nuclear merge conflict |
-| Environment variable renames (PAPERCLIP_* stays) | Breaks existing deployments |
-| Token prefix changes (pcp_board_* stays) | Would invalidate issued tokens |
-| Plugin API contract changes (company.created events) | Breaks third-party plugins |
-| .paperclip.yaml export format rename | Breaks upstream import compatibility |
-| Multi-workspace support UI overhaul | Existing multi-company feature works, just renamed |
-
-## Traceability
-
-Which phases cover which requirements. Updated during roadmap creation.
-
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| FOUND-01 | Phase 1 | Complete |
-| FOUND-02 | Phase 1 | Complete |
-| FOUND-03 | Phase 1 | Complete |
-| FOUND-04 | Phase 1 | Complete |
-| TERM-01 | Phase 3 | Pending |
-| TERM-02 | Phase 3 | Pending |
-| TERM-03 | Phase 3 | Pending |
-| TERM-04 | Phase 3 | Pending |
-| TERM-05 | Phase 2 | Pending |
-| TERM-06 | Phase 3 | Pending |
-| TERM-07 | Phase 4 | Pending |
-| ONBD-01 | Phase 4 | Pending |
-| ONBD-02 | Phase 4 | Pending |
-| ONBD-03 | Phase 4 | Pending |
-| ONBD-04 | Phase 4 | Pending |
-| ONBD-05 | Phase 4 | Pending |
-| ONBD-06 | Phase 4 | Pending |
-| ONBD-07 | Phase 4 | Pending |
-| BRND-01 | Phase 3 | Pending |
-| BRND-02 | Phase 2 | Pending |
-| BRND-03 | Phase 3 | Pending |
-| BRND-04 | Phase 3 | Pending |
-| DIR-01 | Phase 2 | Pending |
-| DIR-02 | Phase 2 | Pending |
-| DIR-03 | Phase 2 | Pending |
-| DIR-04 | Phase 2 | Pending |
-| DIR-05 | Phase 2 | Pending |
-
-**Coverage:**
-- v1 requirements: 27 total
-- Mapped to phases: 27
-- Unmapped: 0
-
----
-*Requirements defined: 2026-03-30*
-*Last updated: 2026-03-30 after roadmap creation*

.planning/milestones/v1.2.1-ROADMAP.md

@@ -1,84 +0,0 @@
-# Roadmap: Nexus
-
-## Overview
-
-Transform Paperclip into Nexus through four phases of increasing surface area. Phase 1 establishes the containment structure (new files only, zero upstream touches). Phase 2 makes the lowest-risk upstream edits — one-line constant changes, home directory pointer, and branding assets. Phase 3 completes the surface-level string renames across UI and CLI. Phase 4 delivers the flagship UX change: zero-friction onboarding with predefined PM and Engineer agent templates. Every phase produces a rebase-clean state that can sync upstream without compound conflicts.
-
-## Phases
-
-**Phase Numbering:**
-- Integer phases (1, 2, 3): Planned milestone work
-- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
-
-Decimal phases appear between their surrounding integers in numeric order.
-
-- [x] **Phase 1: Foundation** - Scaffold branding package, zone taxonomy, and git workflow (new files only, no upstream touches) (completed 2026-03-30)
-- [ ] **Phase 2: Constants and Directory** - One-line upstream constant edits, home directory pointer mechanism, and startup branding
-- [ ] **Phase 3: UI and CLI Strings** - Rename all Company/CEO/Board strings across UI components and CLI output
-- [ ] **Phase 4: Onboarding** - Zero-friction root-directory wizard, predefined PM and Engineer templates, Add Agent dialog
-
-## Phase Details
-
-### Phase 1: Foundation
-**Goal**: The containment structure exists — branding package, zone taxonomy, and commit discipline are in place before any upstream file is touched
-**Depends on**: Nothing (first phase)
-**Requirements**: FOUND-01, FOUND-02, FOUND-03, FOUND-04
-**Success Criteria** (what must be TRUE):
-  1. `packages/branding/` exists and exports a `VOCAB` constant importable by other packages
-  2. A zone taxonomy document in `.planning/` classifies every rename target as display-safe, code (don't touch), or stored (don't touch)
-  3. A pre-commit hook rejects any commit whose message lacks the `[nexus]` prefix
-  4. `git rerere` is enabled and a rebase runbook exists in `.planning/` documenting `git range-diff` workflow
-**Plans:** 2/2 plans complete
-Plans:
-- [x] 01-01-PLAN.md — Branding package with VOCAB constant and tests
-- [x] 01-02-PLAN.md — Zone taxonomy, commit hook, git rerere, rebase runbook
-
-### Phase 2: Constants and Directory
-**Goal**: The core vocabulary constant and home directory mechanism are live — all downstream components can import correct labels and the pointer-file pattern is established with a safe migration fallback
-**Depends on**: Phase 1
-**Requirements**: TERM-05, BRND-02, DIR-01, DIR-02, DIR-03, DIR-04, DIR-05
-**Success Criteria** (what must be TRUE):
-  1. Running the app shows "NEXUS" in the server startup ASCII banner (not "PAPERCLIP")
-  2. `AGENT_ROLE_LABELS.ceo` returns `"Project Manager"` at runtime (verifiable via agent config page)
-  3. A `~/.nexus` file containing a root path causes the server and CLI to use that root directory
-  4. If `~/.nexus` does not exist the server and CLI fall back to `~/.paperclip` without error
-  5. Agent directories created under the user-chosen root use human-readable slugified names, not UUIDs
-**Plans**: TBD
-
-### Phase 3: UI and CLI Strings
-**Goal**: Every user-facing surface uses Nexus vocabulary — no "Company", "CEO", "Board", "Hire", or "Fire" visible anywhere in the UI or CLI output
-**Depends on**: Phase 2
-**Requirements**: TERM-01, TERM-02, TERM-03, TERM-04, TERM-06, BRND-01, BRND-03, BRND-04
-**Success Criteria** (what must be TRUE):
-  1. The browser tab and top-left logo area display "Nexus" (not "Paperclip")
-  2. The sidebar, settings pages, and all dialogs show "Workspace" where "Company" appeared, "Project Manager" where "CEO" appeared, "Owner" where "Board" appeared, and "Add" / "Remove" where "Hire" / "Fire" appeared
-  3. Running `nexus --help` displays Nexus vocabulary throughout (no Paperclip branding in user-facing help text)
-  4. The favicon and logo assets are Nexus-branded
-  5. A post-rename grep audit of `ui/src`, `cli/src`, and `server/src` finds zero unintentional remaining occurrences of the old terms
-**Plans**: TBD
-**UI hint**: yes
-
-### Phase 4: Onboarding
-**Goal**: A fresh install asks for exactly one thing (root directory), auto-creates PM and Engineer agents with predefined templates, and drops the user directly in the dashboard — no corporate metaphors anywhere in the flow
-**Depends on**: Phase 3
-**Requirements**: ONBD-01, ONBD-02, ONBD-03, ONBD-04, ONBD-05, ONBD-06, ONBD-07, TERM-07
-**Success Criteria** (what must be TRUE):
-  1. The UI onboarding wizard shows a single root directory picker with no company name, mission, or first-task fields
-  2. Completing UI onboarding automatically creates a PM agent and an Engineer agent, each pre-loaded with their respective SOUL.md, AGENTS.md, HEARTBEAT.md, and TOOLS.md content
-  3. After onboarding completes the user lands directly on the dashboard (no extra steps)
-  4. Running `nexus onboard` from the CLI mirrors the UI flow: pick root, auto-create agents, done
-  5. The "Add Agent" button opens a dialog with a template dropdown listing PM and Engineer as options (no "Hire" language)
-**Plans**: TBD
-**UI hint**: yes
-
-## Progress
-
-**Execution Order:**
-Phases execute in numeric order: 1 -> 2 -> 3 -> 4
-
-| Phase | Plans Complete | Status | Completed |
-|-------|----------------|--------|-----------|
-| 1. Foundation | 2/2 | Complete   | 2026-03-30 |
-| 2. Constants and Directory | 0/? | Not started | - |
-| 3. UI and CLI Strings | 0/? | Not started | - |
-| 4. Onboarding | 0/? | Not started | - |

.planning/milestones/v1.2.1-phases/18-adapter-path-resolver/18-VERIFICATION.md

@@ -1,92 +0,0 @@
----
-phase: 18-adapter-path-resolver
-verified: 2026-04-01T11:00:00Z
-status: passed
-score: 6/6 must-haves verified
----
-
-# Phase 18: Adapter Path Resolver Verification Report
-
-**Phase Goal:** Any part of the codebase can ask "where does this adapter type store skills?" and receive a correct, well-typed answer — with research-backed paths for every adapter and documented fallbacks for unsupported ones
-**Verified:** 2026-04-01T11:00:00Z
-**Status:** passed
-**Re-verification:** No — initial verification
-
-## Goal Achievement
-
-### Observable Truths
-
-| #   | Truth                                                                                                      | Status     | Evidence                                                                                           |
-| --- | ---------------------------------------------------------------------------------------------------------- | ---------- | -------------------------------------------------------------------------------------------------- |
-| 1   | resolveAdapterSkillConfig('claude_local') returns skillDir '~/.claude/skills/', format 'skill-md', supportsInstall true | ✓ VERIFIED | adapter-skill-config.ts lines 9-16; test line 11-17 passes                                        |
-| 2   | resolveAdapterSkillConfig('hermes_local') returns skillDir '~/.hermes/skills/', nativeSkillDir '~/.hermes/skills/', supportsInstall true | ✓ VERIFIED | adapter-skill-config.ts lines 17-24; test lines 20-27 pass                                        |
-| 3   | resolveAdapterSkillConfig('process') and resolveAdapterSkillConfig('http') return supportsInstall false, format 'none', skillDir null — no error thrown | ✓ VERIFIED | adapter-skill-config.ts lines 73-88; tests lines 87-103 pass                                      |
-| 4   | All 10 adapter types have entries with no TBD or empty stubs                                               | ✓ VERIFIED | listAdapterSkillConfigs() returns array of 10; test at line 122 asserts length 10; stub-check test at line 142 asserts all have truthy adapterType and valid format |
-| 5   | Unknown adapter types return a fallback config with supportsInstall false — never throws                   | ✓ VERIFIED | FALLBACK_CONFIG at line 97-104; resolveAdapterSkillConfig spreads fallback with caller's adapterType at line 112; tests lines 106-117 pass |
-| 6   | Unit tests cover every adapter type and all tests pass                                                     | ✓ VERIFIED | 15/15 tests pass in server/src/__tests__/adapter-skill-config.test.ts; test IDs map to ADAPT-01 through ADAPT-10 |
-
-**Score:** 6/6 truths verified
-
-### Required Artifacts
-
-| Artifact                                                      | Expected                                               | Status     | Details                                                                  |
-| ------------------------------------------------------------- | ------------------------------------------------------ | ---------- | ------------------------------------------------------------------------ |
-| `packages/adapter-utils/src/types.ts`                        | AdapterSkillConfig interface and AdapterSkillFormat type | ✓ VERIFIED | AdapterSkillFormat and AdapterSkillConfig defined at lines 356-389 of types.ts |
-| `packages/adapter-utils/src/adapter-skill-config.ts`         | resolveAdapterSkillConfig and listAdapterSkillConfigs functions | ✓ VERIFIED | 121-line file; both functions exported at lines 111 and 118              |
-| `packages/adapter-utils/src/index.ts`                        | Re-exports of new types and functions                  | ✓ VERIFIED | Lines 1-2 export AdapterSkillFormat, AdapterSkillConfig, resolveAdapterSkillConfig, listAdapterSkillConfigs |
-| `server/src/__tests__/adapter-skill-config.test.ts`          | Unit tests for all ADAPT-01 through ADAPT-10 requirements | ✓ VERIFIED | 155-line file (exceeds 60-line minimum); 15 tests; all pass              |
-
-### Key Link Verification
-
-| From                                               | To                                                      | Via                              | Status     | Details                                                   |
-| -------------------------------------------------- | ------------------------------------------------------- | -------------------------------- | ---------- | --------------------------------------------------------- |
-| server/src/__tests__/adapter-skill-config.test.ts | packages/adapter-utils/src/adapter-skill-config.ts     | import from @paperclipai/adapter-utils | ✓ WIRED    | Line 3-5 of test file imports resolveAdapterSkillConfig and listAdapterSkillConfigs from @paperclipai/adapter-utils |
-| packages/adapter-utils/src/index.ts               | packages/adapter-utils/src/adapter-skill-config.ts     | re-export                        | ✓ WIRED    | Lines 1-2 of index.ts re-export both functions and types  |
-
-### Data-Flow Trace (Level 4)
-
-Not applicable — this phase delivers a pure lookup module (no UI components, no pages, no dynamic rendering). The module is a static config map; correctness is validated by unit tests rather than runtime data flow.
-
-### Behavioral Spot-Checks
-
-| Behavior                                   | Command                                                                                                          | Result                        | Status  |
-| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | ----------------------------- | ------- |
-| All 15 unit tests pass                     | pnpm --filter @paperclipai/server exec vitest run src/__tests__/adapter-skill-config.test.ts                    | 15 passed, 0 failed, 263ms    | ✓ PASS  |
-| resolveAdapterSkillConfig module exports   | node -e "import('@paperclipai/adapter-utils').then(m => console.log(typeof m.resolveAdapterSkillConfig))"        | SKIPPED (ESM, no live server) | ? SKIP  |
-
-### Requirements Coverage
-
-| Requirement | Source Plan  | Description                                                                                      | Status     | Evidence                                                                                      |
-| ----------- | ------------ | ------------------------------------------------------------------------------------------------ | ---------- | --------------------------------------------------------------------------------------------- |
-| ADAPT-01    | 18-01-PLAN.md | Adapter skill path resolver module returns AdapterSkillConfig for any type string               | ✓ SATISFIED | resolveAdapterSkillConfig exported from adapter-utils; accepts any string, always returns AdapterSkillConfig |
-| ADAPT-02    | 18-01-PLAN.md | Claude Code adapter resolves to global `~/.claude/skills/` with skill-md format                 | ✓ SATISFIED | skillDir '~/.claude/skills/' confirmed in config and test. Note: workspace-local path is Phase 19's concern per RESEARCH.md — resolver correctly stores global path only |
-| ADAPT-03    | 18-01-PLAN.md | Hermes adapter resolves to ~/.hermes/skills/ with nativeSkillDir populated                      | ✓ SATISFIED | Both skillDir and nativeSkillDir set to '~/.hermes/skills/'. Note: nativeSkillCount is a runtime value deferred to Phase 19 per RESEARCH.md |
-| ADAPT-04    | 18-01-PLAN.md | OpenClaw Gateway resolves to ~/.openclaw/skills/ with skill-md format and supportsInstall true  | ✓ SATISFIED | openclaw_gateway entry present at line 26-33 of adapter-skill-config.ts                       |
-| ADAPT-05    | 18-01-PLAN.md | Codex adapter configured with verified path and format                                          | ✓ SATISFIED | codex_local resolves to ~/.agents/skills/ per official docs (RESEARCH.md source)              |
-| ADAPT-06    | 18-01-PLAN.md | Cursor adapter configured with verified path and format                                         | ✓ SATISFIED | cursor resolves to ~/.cursor/skills/ per codebase + docs verification                        |
-| ADAPT-07    | 18-01-PLAN.md | OpenCode adapter configured with verified native path                                           | ✓ SATISFIED | opencode_local resolves to ~/.config/opencode/skills/ per official docs (corrects old ~/ .claude/skills/ fallback) |
-| ADAPT-08    | 18-01-PLAN.md | Pi and Gemini adapters verified and configured                                                  | ✓ SATISFIED | pi_local -> ~/.pi/agent/skills/; gemini_local -> ~/.gemini/skills/                           |
-| ADAPT-09    | 18-01-PLAN.md | Bash and HTTP adapters return supportsInstall false, format none, unsupportedReason truthy      | ✓ SATISFIED | process and http entries at lines 73-88; unsupportedReason: "Skills not supported for this adapter type" |
-| ADAPT-10    | 18-01-PLAN.md | Unsupported adapters still allow rating and usage tracking — skill record exists, only auto-install blocked | ✓ SATISFIED | Resolver returns supportsInstall: false (auto-install blocked); RESEARCH.md documents that libSQL registry stores skill records independently — the resolver's job is only to set this flag. Rating/tracking is handled by existing registry infrastructure outside Phase 18's scope |
-
-### Anti-Patterns Found
-
-| File | Line | Pattern | Severity | Impact |
-| ---- | ---- | ------- | -------- | ------ |
-
-No anti-patterns found. No TODOs, FIXMEs, placeholder comments, empty returns, or hardcoded empty data found in the four modified files.
-
-### Human Verification Required
-
-None. All observable behaviors for this phase are fully verifiable programmatically via unit tests. The resolver is a pure in-memory lookup with no UI, no I/O, and no external services.
-
-### Gaps Summary
-
-No gaps. All six must-have truths verified, all four artifacts exist and are substantive, both key links wired. 15 unit tests pass (0 failures). Two TDD commits (b010708e, 34781b7e) confirmed in nexus repo history. All 10 requirement IDs from REQUIREMENTS.md satisfied — the phase delivered exactly what was contracted.
-
-**Note on ADAPT-02 and ADAPT-03 scope:** The full requirement text for ADAPT-02 mentions both workspace-local and global paths, and ADAPT-03 mentions `nativeSkillCount`. The RESEARCH.md explicitly documents that workspace-local resolution is Phase 19's concern (requires execution context) and `nativeSkillCount` is a runtime filesystem value also deferred to Phase 19. The resolver correctly implements global paths only, which is the correct Phase 18 deliverable.
-
----
-
-_Verified: 2026-04-01T11:00:00Z_
-_Verifier: Claude (gsd-verifier)_

.planning/milestones/v1.2.1-phases/19-adapter-aware-install-uninstall/19-01-PLAN.md

@@ -1,232 +0,0 @@
----
-phase: 19-adapter-aware-install-uninstall
-plan: "01"
-type: execute
-wave: 1
-depends_on: []
-files_modified:
-  - server/src/services/skill-registry-schema.ts
-  - server/src/services/skill-registry-db.ts
-  - server/src/services/skill-registry.ts
-  - server/src/services/skill-registry-groups.ts
-autonomous: true
-requirements: [INST-01, INST-02, INST-03, INST-04, HERM-01, HERM-02, HERM-03]
-
-must_haves:
-  truths:
-    - "install() accepts agentSkillsDir (resolved externally) and writes skill files to that directory"
-    - "uninstall() removes skill files from disk before soft-deleting the registry row"
-    - "rollback() restores previous version files to the provided agentSkillsDir"
-    - "assignGroup/removeGroup accept agentSkillsDir (resolved externally) instead of using defaultSkillsDir()"
-    - "agentSkills table has a source column distinguishing managed from native skills"
-    - "syncHermesNativeSkills populates native skill rows in agentSkills and stub rows in skills table"
-    - "listAgentSkills returns objects with source field, not bare string arrays"
-  artifacts:
-    - path: "server/src/services/skill-registry-schema.ts"
-      provides: "source column on agentSkills table"
-      contains: "source.*text.*managed"
-    - path: "server/src/services/skill-registry-db.ts"
-      provides: "ALTER TABLE migration guard for source column"
-      contains: "ALTER TABLE agent_skills ADD COLUMN source"
-    - path: "server/src/services/skill-registry.ts"
-      provides: "Updated install/uninstall/rollback methods, syncHermesNativeSkills, listAgentSkills returning objects"
-      contains: "syncHermesNativeSkills"
-    - path: "server/src/services/skill-registry-groups.ts"
-      provides: "assignGroup/removeGroup using passed agentSkillsDir, no defaultSkillsDir fallback"
-  key_links:
-    - from: "server/src/services/skill-registry-db.ts"
-      to: "server/src/services/skill-registry-schema.ts"
-      via: "ALTER TABLE matches Drizzle schema source column"
-      pattern: "source.*text.*managed"
-    - from: "server/src/services/skill-registry.ts"
-      to: "server/src/services/skill-registry-schema.ts"
-      via: "agentSkills.source used in insert/select queries"
-      pattern: "agentSkills\\.source"
----
-
-<objective>
-Update the skill registry service layer to support adapter-aware install/uninstall and Hermes dual-source tracking.
-
-Purpose: The service layer must (1) accept resolved skill directories for all file operations instead of hardcoded paths, (2) actually remove files on uninstall (currently only soft-deletes), (3) track managed vs native skill sources in the libSQL schema, and (4) sync Hermes native skills from disk.
-
-Output: Updated schema, migration guard, service methods ready for route-layer wiring in Plan 02.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/19-adapter-aware-install-uninstall/19-RESEARCH.md
-@.planning/phases/18-adapter-path-resolver/18-01-SUMMARY.md
-
-Read these source files before modifying:
-- server/src/services/skill-registry-schema.ts
-- server/src/services/skill-registry-db.ts
-- server/src/services/skill-registry.ts
-- server/src/services/skill-registry-groups.ts
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Schema + migration guard + service method signatures</name>
-  <files>
-    server/src/services/skill-registry-schema.ts,
-    server/src/services/skill-registry-db.ts,
-    server/src/services/skill-registry.ts,
-    server/src/services/skill-registry-groups.ts
-  </files>
-  <read_first>
-    server/src/services/skill-registry-schema.ts,
-    server/src/services/skill-registry-db.ts,
-    server/src/services/skill-registry.ts,
-    server/src/services/skill-registry-groups.ts
-  </read_first>
-  <action>
-    **skill-registry-schema.ts** — Add `source` column to `agentSkills` table:
-    ```typescript
-    source: text("source").notNull().default("managed"), // 'managed' | 'native'
-    ```
-    Place it after the `installedAt` column. Do NOT touch any other table definitions.
-
-    **skill-registry-db.ts** — Add migration guard in `getSkillRegistryDb()` (or equivalent init function) AFTER the DB is ready:
-    ```typescript
-    try {
-      await db.run(sql`ALTER TABLE agent_skills ADD COLUMN source TEXT NOT NULL DEFAULT 'managed'`);
-    } catch {
-      // Column already exists — ignore "duplicate column name" error
-    }
-    ```
-    Import `sql` from drizzle-orm if not already imported.
-
-    **skill-registry.ts** — Make these changes:
-    1. `uninstall(skillId, agentSkillsDir)` — Add second param `agentSkillsDir: string`. Before the existing soft-delete (`db.update(skills).set({ removedAt: ... })`), add file removal:
-       ```typescript
-       const slug = skillId.split("/").pop() ?? skillId;
-       const targetDir = path.join(agentSkillsDir, slug);
-       await rm(targetDir, { recursive: true, force: true });
-       ```
-       Import `rm` from `node:fs/promises` if not already imported.
-
-    2. `install()` — Verify it already accepts `agentSkillsDir` as a parameter (research says it does). No change needed if so. If it uses a different name, standardize to `agentSkillsDir`.
-
-    3. `rollback()` — Verify it already accepts `agentSkillsDir` as a parameter. No change needed if so.
-
-    4. Add `syncHermesNativeSkills(agentId: string)` function:
-       - Read directory entries from `path.join(os.homedir(), ".hermes", "skills")`
-       - For each entry, create a stub `skills` row with `id: "hermes-native/${entry}"`, `sourceId: "hermes-native"`, `name: entry` using `onConflictDoNothing()`
-       - Insert `agentSkills` row with `source: "native"` using `onConflictDoNothing()`
-       - Wrap the `readdir` in try/catch — return silently if directory doesn't exist
-       - Import `readdir` from `node:fs/promises` and `os` from `node:os`
-
-    5. Update `listAgentSkills(agentId)` (or whatever function returns installed skills for an agent):
-       - Change return type from `string[]` to `Array<{ skillId: string; source: "managed" | "native"; installedAt: number }>`
-       - Select `agentSkills.source` and `agentSkills.installedAt` in addition to `skillId`
-       - If the agent is a Hermes type, call `syncHermesNativeSkills(agentId)` first (Note: this function doesn't know the adapter type directly — the caller in the route layer will invoke sync separately. Just update the query to return objects with source field.)
-
-    **skill-registry-groups.ts** — Make these changes:
-    1. Remove `defaultSkillsDir()` function entirely — there is no safe default when the caller fails to provide `agentId`
-    2. Update `assignGroup()` and `removeGroup()` to require `agentSkillsDir: string` as a mandatory parameter (not optional). Remove any fallback to `defaultSkillsDir()`.
-    3. If these functions currently have `agentSkillsDir?: string` with a fallback, make the param required (remove `?`).
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm tsc --noEmit --project server/tsconfig.json 2>&1 | head -30</automated>
-  </verify>
-  <acceptance_criteria>
-    - agentSkills table definition includes `source: text("source").notNull().default("managed")`
-    - skill-registry-db.ts contains `ALTER TABLE agent_skills ADD COLUMN source`
-    - uninstall function signature includes agentSkillsDir parameter and calls rm()
-    - syncHermesNativeSkills function exists and uses onConflictDoNothing
-    - listAgentSkills returns objects with source field (not string[])
-    - defaultSkillsDir() removed from skill-registry-groups.ts
-    - assignGroup and removeGroup require agentSkillsDir as mandatory param
-    - TypeScript compiles without errors
-  </acceptance_criteria>
-  <done>Schema has source column, migration guard runs on DB init, uninstall removes files, syncHermesNativeSkills exists, listAgentSkills returns typed objects, group functions require agentSkillsDir</done>
-</task>
-
-<task type="auto" tdd="true">
-  <name>Task 2: Unit tests for adapter-aware install/uninstall and Hermes sync</name>
-  <files>
-    server/src/__tests__/skill-registry-adapter-install.test.ts,
-    server/src/__tests__/hermes-dual-source.test.ts
-  </files>
-  <read_first>
-    server/src/__tests__/skill-registry.test.ts (if exists — for test patterns),
-    server/src/services/skill-registry.ts
-  </read_first>
-  <behavior>
-    skill-registry-adapter-install.test.ts:
-    - Test: install() writes files to provided agentSkillsDir, not a hardcoded path
-    - Test: uninstall() removes skill directory from disk AND soft-deletes the DB row
-    - Test: uninstall() with non-existent directory does not throw (force: true)
-    - Test: rollback() restores files to provided agentSkillsDir
-    - Test: assignGroup() writes to provided agentSkillsDir
-    - Test: removeGroup() removes from provided agentSkillsDir
-
-    hermes-dual-source.test.ts:
-    - Test: syncHermesNativeSkills creates skills stub rows with sourceId "hermes-native"
-    - Test: syncHermesNativeSkills creates agentSkills rows with source "native"
-    - Test: syncHermesNativeSkills is idempotent (running twice doesn't duplicate)
-    - Test: syncHermesNativeSkills handles missing ~/.hermes/skills/ gracefully
-    - Test: listAgentSkills returns objects with { skillId, source, installedAt }
-    - Test: listAgentSkills includes both managed and native skills for a Hermes agent
-  </behavior>
-  <action>
-    Create two test files following the existing test patterns in `server/src/__tests__/`.
-
-    For `skill-registry-adapter-install.test.ts`:
-    - Use `vi.mock("node:fs/promises")` to mock filesystem operations (rm, cp, readdir, mkdir)
-    - Test that `uninstall(skillId, agentSkillsDir)` calls `rm(path.join(agentSkillsDir, slug), { recursive: true, force: true })`
-    - Test that `install` and `rollback` use the provided `agentSkillsDir` path
-    - Test that `assignGroup` and `removeGroup` use the provided path (not a default)
-
-    For `hermes-dual-source.test.ts`:
-    - Mock `readdir` to return sample skill directory entries
-    - Test that `syncHermesNativeSkills` inserts correct rows
-    - Test that `listAgentSkills` returns the new object shape
-    - Use the existing libSQL test database setup pattern (check how other skill-registry tests set up the DB)
-
-    Run tests: `cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-adapter-install.test.ts src/__tests__/hermes-dual-source.test.ts`
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-adapter-install.test.ts src/__tests__/hermes-dual-source.test.ts</automated>
-  </verify>
-  <acceptance_criteria>
-    - skill-registry-adapter-install.test.ts exists with tests for install/uninstall/rollback/assignGroup/removeGroup
-    - hermes-dual-source.test.ts exists with tests for syncHermesNativeSkills and listAgentSkills
-    - All tests pass
-    - uninstall test verifies rm() is called with correct path
-    - syncHermesNativeSkills test verifies idempotency
-    - listAgentSkills test verifies object shape includes source field
-  </acceptance_criteria>
-  <done>All unit tests for INST-01 through INST-04 and HERM-01 through HERM-03 service layer pass</done>
-</task>
-
-</tasks>
-
-<verification>
-- TypeScript compiles: `cd nexus && pnpm tsc --noEmit --project server/tsconfig.json`
-- Tests pass: `cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-adapter-install.test.ts src/__tests__/hermes-dual-source.test.ts`
-- Schema has source column: grep for `source.*text.*managed` in skill-registry-schema.ts
-- Migration guard exists: grep for `ALTER TABLE agent_skills ADD COLUMN source` in skill-registry-db.ts
-- No defaultSkillsDir: grep should find NO matches for `defaultSkillsDir` in skill-registry-groups.ts
-</verification>
-
-<success_criteria>
-- Service layer methods accept agentSkillsDir as resolved path (not client-supplied)
-- uninstall removes files from disk before soft-deleting
-- agentSkills schema tracks managed vs native source
-- syncHermesNativeSkills lazily discovers Hermes native skills from disk
-- listAgentSkills returns typed objects with source field
-- All tests pass
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/19-adapter-aware-install-uninstall/19-01-SUMMARY.md`
-</output>

.planning/milestones/v1.2.1-phases/19-adapter-aware-install-uninstall/19-02-PLAN.md

@@ -1,265 +0,0 @@
----
-phase: 19-adapter-aware-install-uninstall
-plan: "02"
-type: execute
-wave: 2
-depends_on: ["19-01"]
-files_modified:
-  - server/src/routes/skill-registry.ts
-  - server/src/routes/skill-registry-groups.ts
-  - server/src/app.ts
-autonomous: true
-requirements: [INST-01, INST-02, INST-03, INST-04, HERM-02]
-
-must_haves:
-  truths:
-    - "Route handlers resolve agentSkillsDir from agentId via resolveAdapterSkillConfig, not from request body"
-    - "Install route accepts agentId in body and resolves the target directory server-side"
-    - "Uninstall route accepts agentId as query param and passes resolved dir to service"
-    - "Rollback route accepts agentId in body and resolves the target directory server-side"
-    - "Group assign/remove routes resolve dir from the agentId URL param, not from request body"
-    - "DELETE route for native skills returns 403"
-    - "app.ts passes db to both route factories"
-  artifacts:
-    - path: "server/src/routes/skill-registry.ts"
-      provides: "Adapter-aware install/uninstall/rollback routes with agentId resolution"
-      contains: "resolveSkillsDirForAgent"
-    - path: "server/src/routes/skill-registry-groups.ts"
-      provides: "Adapter-aware group assign/remove routes"
-      contains: "resolveSkillsDirForAgent"
-    - path: "server/src/app.ts"
-      provides: "db passed to skillRegistryRoutes and skillGroupRoutes"
-      contains: "skillRegistryRoutes(db)"
-  key_links:
-    - from: "server/src/routes/skill-registry.ts"
-      to: "server/src/services/agents.ts"
-      via: "agentService(db).getById for adapter type lookup"
-      pattern: "agentService.*getById"
-    - from: "server/src/routes/skill-registry.ts"
-      to: "@paperclipai/adapter-utils"
-      via: "resolveAdapterSkillConfig for path resolution"
-      pattern: "resolveAdapterSkillConfig"
-    - from: "server/src/app.ts"
-      to: "server/src/routes/skill-registry.ts"
-      via: "skillRegistryRoutes(db) factory call"
-      pattern: "skillRegistryRoutes\\(db\\)"
----
-
-<objective>
-Wire route handlers to resolve skill directories from agentId server-side using the Phase 18 adapter path resolver, replacing client-supplied agentSkillsDir in all request bodies.
-
-Purpose: The UI should never compute filesystem paths. The server owns path resolution via the agent's adapter type. This plan connects the service changes from Plan 01 to the HTTP layer.
-
-Output: Updated routes accepting agentId, app.ts passing db to route factories, native skill protection at route level.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/19-adapter-aware-install-uninstall/19-RESEARCH.md
-@.planning/phases/18-adapter-path-resolver/18-01-SUMMARY.md
-@.planning/phases/19-adapter-aware-install-uninstall/19-01-SUMMARY.md
-
-Read these source files before modifying:
-- server/src/routes/skill-registry.ts
-- server/src/routes/skill-registry-groups.ts
-- server/src/app.ts
-- server/src/services/agents.ts (read-only — understand getById signature)
-- packages/adapter-utils/src/index.ts (read-only — understand resolveAdapterSkillConfig export)
-
-<interfaces>
-<!-- From Phase 18 (adapter-utils) -->
-resolveAdapterSkillConfig(adapterType: string): AdapterSkillConfig
-  returns: { skillDir: string | null, nativeSkillDir: string | null, format: string, supportsInstall: boolean, unsupportedReason?: string }
-
-<!-- From Plan 01 (service layer updates) -->
-install(skillId: string, agentSkillsDir: string): Promise<...>
-uninstall(skillId: string, agentSkillsDir: string): Promise<void>
-rollback(skillId: string, versionId: string, agentSkillsDir: string): Promise<...>
-assignGroup(groupId: string, agentId: string, agentSkillsDir: string): Promise<...>
-removeGroup(groupId: string, agentId: string, agentSkillsDir: string): Promise<...>
-syncHermesNativeSkills(agentId: string): Promise<void>
-listAgentSkills(agentId: string): Promise<Array<{ skillId: string; source: "managed" | "native"; installedAt: number }>>
-</interfaces>
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Add resolveSkillsDirForAgent helper and update route factories</name>
-  <files>
-    server/src/routes/skill-registry.ts,
-    server/src/routes/skill-registry-groups.ts,
-    server/src/app.ts
-  </files>
-  <read_first>
-    server/src/routes/skill-registry.ts,
-    server/src/routes/skill-registry-groups.ts,
-    server/src/app.ts,
-    server/src/services/agents.ts
-  </read_first>
-  <action>
-    **Add shared helper** — either at the top of `skill-registry.ts` (and import in groups) or in a small shared file. The helper resolves agentId to a skill directory:
-
-    ```typescript
-    import { agentService } from "../services/agents.js";
-    import { resolveAdapterSkillConfig } from "@paperclipai/adapter-utils";
-    import os from "node:os";
-    import type { Db } from "@paperclipai/db";
-
-    async function resolveSkillsDirForAgent(db: Db, agentId: string): Promise<string> {
-      const agent = await agentService(db).getById(agentId);
-      if (!agent) throw Object.assign(new Error("Agent not found"), { status: 404 });
-      const config = resolveAdapterSkillConfig(agent.adapterType);
-      if (!config.supportsInstall || !config.skillDir) {
-        throw Object.assign(
-          new Error(config.unsupportedReason ?? "Adapter does not support skill install"),
-          { status: 422 },
-        );
-      }
-      return config.skillDir.replace(/^~/, os.homedir());
-    }
-    ```
-
-    **skill-registry.ts** — Change factory signature to `skillRegistryRoutes(db: Db): Router`:
-
-    1. **Install route** (`POST .../install`):
-       - Change body from `{ agentSkillsDir: string }` to `{ agentId: string }`
-       - Validate: `if (!agentId) return res.status(400).json({ error: "agentId required" });`
-       - Resolve: `const agentSkillsDir = await resolveSkillsDirForAgent(db, agentId);`
-       - Pass resolved dir to `svc.install(skillId, agentSkillsDir)`
-       - Wrap in try/catch — if error has `.status`, use it; otherwise 500
-
-    2. **Uninstall route** (`DELETE ...`):
-       - Add `req.query.agentId` (query param for DELETE, per HTTP semantics)
-       - Validate: `if (!agentId) return res.status(400).json({ error: "agentId required" });`
-       - Resolve dir, pass to `svc.uninstall(skillId, agentSkillsDir)`
-
-    3. **Rollback route** (`POST .../rollback`):
-       - Change body from `{ versionId, agentSkillsDir }` to `{ versionId, agentId }`
-       - Resolve dir, pass to `svc.rollback(skillId, versionId, agentSkillsDir)`
-
-    4. **List agent skills route** (`GET .../agents/:agentId/skills`):
-       - Look up agent to check if adapter is hermes_local
-       - If hermes: call `syncHermesNativeSkills(agentId)` before listing
-       - Return the full object array (not string[])
-
-    5. **Native skill protection** (HERM-02):
-       - In DELETE route, before calling uninstall, check if the skill's `agentSkills` row has `source === 'native'`
-       - If native: `return res.status(403).json({ error: "Cannot remove native skills" });`
-
-    **skill-registry-groups.ts** — Change factory signature to `skillGroupRoutes(db: Db): Router`:
-
-    1. **Assign group route** (`POST .../groups`):
-       - Remove `agentSkillsDir` from body — the `agentId` is already in the URL param
-       - Resolve: `const agentSkillsDir = await resolveSkillsDirForAgent(db, req.params.agentId);`
-       - Pass resolved dir to `svc.assignGroup(..., agentSkillsDir)`
-
-    2. **Remove group route** (`DELETE .../groups/:groupId`):
-       - Remove `agentSkillsDir` from body
-       - Resolve dir from URL param `agentId`
-       - Pass resolved dir to `svc.removeGroup(..., agentSkillsDir)`
-
-    **app.ts** — Update mount calls:
-    - `api.use(skillRegistryRoutes(db));` (was: `skillRegistryRoutes()`)
-    - `api.use(skillGroupRoutes(db));` (was: `skillGroupRoutes()`)
-    - Add `Db` import if not present
-
-    **Error handling pattern** for resolveSkillsDirForAgent errors in routes:
-    ```typescript
-    try {
-      const agentSkillsDir = await resolveSkillsDirForAgent(db, agentId);
-      // ... proceed
-    } catch (err: any) {
-      const status = err.status ?? 500;
-      return res.status(status).json({ error: err.message });
-    }
-    ```
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm tsc --noEmit --project server/tsconfig.json 2>&1 | head -30</automated>
-  </verify>
-  <acceptance_criteria>
-    - skillRegistryRoutes accepts db: Db parameter
-    - skillGroupRoutes accepts db: Db parameter
-    - app.ts passes db to both route factories
-    - Install route reads agentId from body, not agentSkillsDir
-    - Uninstall route reads agentId from query params
-    - Rollback route reads agentId from body, not agentSkillsDir
-    - Group routes resolve dir from URL agentId param
-    - resolveSkillsDirForAgent helper exists and uses resolveAdapterSkillConfig
-    - DELETE route checks source=native and returns 403
-    - List agent skills route calls syncHermesNativeSkills for hermes agents
-    - No reference to agentSkillsDir in request bodies
-    - No reference to defaultSkillsDir anywhere
-    - TypeScript compiles without errors
-  </acceptance_criteria>
-  <done>All route handlers resolve skill directories server-side from agentId, app.ts wires db to both factories, native skill DELETE returns 403</done>
-</task>
-
-<task type="auto" tdd="true">
-  <name>Task 2: Route-level integration tests</name>
-  <files>
-    server/src/__tests__/skill-registry-routes-adapter.test.ts
-  </files>
-  <read_first>
-    server/src/__tests__/skill-registry.test.ts (if exists — for supertest patterns),
-    server/src/routes/skill-registry.ts
-  </read_first>
-  <behavior>
-    - Test: POST install with agentId resolves correct dir and succeeds
-    - Test: POST install without agentId returns 400
-    - Test: POST install with unknown agentId returns 404
-    - Test: POST install with unsupported adapter returns 422
-    - Test: DELETE uninstall with agentId query param resolves dir and removes files
-    - Test: DELETE uninstall of native skill returns 403
-    - Test: POST rollback with agentId resolves correct dir
-    - Test: GET agent skills for hermes agent calls sync and returns objects with source
-    - Test: POST assign group resolves dir from URL agentId
-  </behavior>
-  <action>
-    Create `skill-registry-routes-adapter.test.ts` using supertest (following existing test patterns in `server/src/__tests__/`).
-
-    Mock `agentService(db).getById` to return agents with different adapter types. Mock `resolveAdapterSkillConfig` to return known configs. Mock filesystem operations.
-
-    Test the route-level behavior: correct status codes, correct error messages, correct delegation to service methods with resolved paths.
-
-    Run: `cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-routes-adapter.test.ts`
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-routes-adapter.test.ts</automated>
-  </verify>
-  <acceptance_criteria>
-    - Test file exists with supertest-based route tests
-    - Tests cover: 400 (missing agentId), 404 (unknown agent), 422 (unsupported adapter), 403 (native skill delete)
-    - Tests verify install/uninstall/rollback/group routes accept agentId not agentSkillsDir
-    - All tests pass
-  </acceptance_criteria>
-  <done>Route-level tests verify adapter-aware path resolution and error handling for all INST requirements plus HERM-02 native protection</done>
-</task>
-
-</tasks>
-
-<verification>
-- TypeScript compiles: `cd nexus && pnpm tsc --noEmit --project server/tsconfig.json`
-- Route tests pass: `cd nexus && pnpm --filter @paperclipai/server exec vitest run src/__tests__/skill-registry-routes-adapter.test.ts`
-- No agentSkillsDir in request bodies: grep should find NO matches for `agentSkillsDir` in route handler body parsing
-- db passed to factories: grep for `skillRegistryRoutes(db)` in app.ts
-</verification>
-
-<success_criteria>
-- All route handlers accept agentId and resolve paths server-side
-- Native skill deletion blocked at route layer with 403
-- app.ts passes db to both route factories
-- Route tests verify all error paths and happy paths
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/19-adapter-aware-install-uninstall/19-02-SUMMARY.md`
-</output>

.planning/milestones/v1.2.1-phases/19-adapter-aware-install-uninstall/19-03-PLAN.md

@@ -1,242 +0,0 @@
----
-phase: 19-adapter-aware-install-uninstall
-plan: "03"
-type: execute
-wave: 2
-depends_on: ["19-01"]
-files_modified:
-  - ui/src/api/skillRegistry.ts
-  - ui/src/pages/SkillBrowser.tsx
-  - ui/src/components/SkillCard.tsx
-autonomous: true
-requirements: [HERM-01, HERM-02, HERM-03]
-
-must_haves:
-  truths:
-    - "Installed tab for Hermes agents shows two labelled sections: Managed and Native"
-    - "Native skills display no remove/update/rollback buttons"
-    - "Managed skills on Hermes agents display full writable actions (install, update, remove)"
-    - "Install dialog sends agentId in body, not agentSkillsDir"
-    - "Uninstall sends agentId as query param, not in body"
-  artifacts:
-    - path: "ui/src/api/skillRegistry.ts"
-      provides: "Updated API types and calls using agentId instead of agentSkillsDir"
-      contains: "agentId"
-    - path: "ui/src/pages/SkillBrowser.tsx"
-      provides: "Dual-section Installed tab with Managed/Native labels for Hermes agents"
-      contains: "managedSkills"
-    - path: "ui/src/components/SkillCard.tsx"
-      provides: "isReadOnly prop that hides action buttons for native skills"
-      contains: "isReadOnly"
-  key_links:
-    - from: "ui/src/pages/SkillBrowser.tsx"
-      to: "ui/src/api/skillRegistry.ts"
-      via: "listAgentSkills returns AgentSkillEntry[] with source field"
-      pattern: "listAgentSkills"
-    - from: "ui/src/pages/SkillBrowser.tsx"
-      to: "ui/src/components/SkillCard.tsx"
-      via: "isReadOnly prop passed for native skills"
-      pattern: "isReadOnly.*native"
----
-
-<objective>
-Update the Skill Browser UI to show managed vs native sections for Hermes agents, make native skills read-only, and switch all API calls from agentSkillsDir to agentId.
-
-Purpose: Users managing Hermes agents need to clearly distinguish Nexus-managed skills (full control) from built-in native skills (view/rate only). The UI must also stop sending filesystem paths to the server.
-
-Output: Updated API client, dual-section Installed tab, read-only SkillCard variant.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/19-adapter-aware-install-uninstall/19-RESEARCH.md
-@.planning/phases/19-adapter-aware-install-uninstall/19-01-SUMMARY.md
-
-Read these source files before modifying:
-- ui/src/api/skillRegistry.ts (or similar — the API client for skill registry)
-- ui/src/pages/SkillBrowser.tsx
-- ui/src/components/SkillCard.tsx (if exists — may be inline in SkillBrowser)
-
-<interfaces>
-<!-- From Plan 01 (updated API response shape) -->
-GET /skill-registry/agents/:agentId/skills
-  Response: Array<{ skillId: string; source: "managed" | "native"; installedAt: number }>
-
-POST /skill-registry/skills/:sourceId/:slug/install
-  Body: { agentId: string }  (was: { agentSkillsDir: string })
-
-DELETE /skill-registry/skills/:sourceId/:slug?agentId=xxx
-  Query: agentId  (was: body.agentSkillsDir)
-
-POST /skill-registry/skills/:sourceId/:slug/rollback
-  Body: { versionId: string, agentId: string }  (was: { versionId, agentSkillsDir })
-
-POST /skill-registry/agents/:agentId/groups
-  Body: { groupId: string }  (was: { groupId, agentSkillsDir? })
-
-DELETE /skill-registry/agents/:agentId/groups/:groupId
-  (no body needed — agentId in URL)
-</interfaces>
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Update API client types and calls</name>
-  <files>
-    ui/src/api/skillRegistry.ts
-  </files>
-  <read_first>
-    ui/src/api/skillRegistry.ts (or search for skill registry API functions — may be in a different file like ui/src/api/skillGroups.ts or similar)
-  </read_first>
-  <action>
-    1. Add the `AgentSkillEntry` type:
-       ```typescript
-       export type AgentSkillEntry = {
-         skillId: string;
-         source: "managed" | "native";
-         installedAt: number;
-       };
-       ```
-
-    2. Update `listAgentSkills` return type from `string[]` to `AgentSkillEntry[]`.
-
-    3. Update `installSkill` (or equivalent) to send `{ agentId }` in the POST body instead of `{ agentSkillsDir }`.
-
-    4. Update `uninstallSkill` (or equivalent) to pass `agentId` as a query parameter on the DELETE request instead of in the body.
-
-    5. Update `rollbackSkill` (or equivalent) to send `{ versionId, agentId }` instead of `{ versionId, agentSkillsDir }`.
-
-    6. Update group assign/remove calls to NOT send `agentSkillsDir` in the body (agentId is already in the URL).
-
-    7. Remove any `agentSkillsDir` parameter from all exported API functions. Replace with `agentId: string` where needed.
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm tsc --noEmit --project ui/tsconfig.json 2>&1 | head -30</automated>
-  </verify>
-  <acceptance_criteria>
-    - AgentSkillEntry type exported with skillId, source, installedAt fields
-    - listAgentSkills returns AgentSkillEntry[] not string[]
-    - installSkill sends agentId in body, not agentSkillsDir
-    - uninstallSkill sends agentId as query param
-    - rollbackSkill sends agentId in body, not agentSkillsDir
-    - No references to agentSkillsDir in any API function
-    - TypeScript compiles without errors
-  </acceptance_criteria>
-  <done>API client uses agentId for all skill operations, returns typed AgentSkillEntry objects</done>
-</task>
-
-<task type="auto">
-  <name>Task 2: Dual-section Installed tab and read-only SkillCard</name>
-  <files>
-    ui/src/pages/SkillBrowser.tsx,
-    ui/src/components/SkillCard.tsx
-  </files>
-  <read_first>
-    ui/src/pages/SkillBrowser.tsx,
-    ui/src/components/SkillCard.tsx (if exists)
-  </read_first>
-  <action>
-    **SkillCard.tsx** (or inline skill card component):
-
-    1. Add `isReadOnly?: boolean` and `source?: "managed" | "native"` props to the component's props interface.
-
-    2. When `isReadOnly` is true:
-       - Hide the Remove/Uninstall button
-       - Hide the Update button
-       - Hide the Rollback button
-       - Show a small "Native" badge (e.g., a gray `<Badge>` from the UI library or a Tailwind-styled span)
-       - Rating/view actions remain visible
-
-    3. When `source === "managed"` and skill is installed:
-       - Show all action buttons as before (this is the default behavior, no change needed)
-
-    **SkillBrowser.tsx** — Installed tab changes:
-
-    1. **Remove agentSkillsDir state and input.** The install dialog currently has a text input for `agentSkillsDir`. Remove it entirely. The dialog already shows agent selection buttons with `agent.id` — use that directly.
-
-    2. **Update install dialog** to pass `agentId` to the API call instead of `agentSkillsDir`.
-
-    3. **Update uninstall handler** to pass `agentId` to the API call instead of `agentSkillsDir`.
-
-    4. **Per-agent skill query on Installed tab:**
-       ```typescript
-       const { data: agentInstalledSkills = [] } = useQuery({
-         queryKey: ["agentInstalledSkills", selectedAgentId],
-         queryFn: () => skillRegistryApi.listAgentSkills(selectedAgentId),
-         enabled: tab === "installed" && !!selectedAgentId,
-       });
-       ```
-
-    5. **Split skills into managed/native sections:**
-       ```typescript
-       const managedSkills = agentInstalledSkills.filter((s) => s.source === "managed");
-       const nativeSkills = agentInstalledSkills.filter((s) => s.source === "native");
-       ```
-
-    6. **Render two labelled sections** when viewing a Hermes agent's installed skills:
-       - "Managed" section heading — renders `managedSkills` with full SkillCard actions
-       - "Native" section heading — renders `nativeSkills` with `isReadOnly={true}` and `source="native"`
-       - Use simple heading elements or dividers:
-         ```tsx
-         {managedSkills.length > 0 && (
-           <>
-             <h3 className="text-sm font-medium text-muted-foreground mt-4 mb-2">Managed</h3>
-             {managedSkills.map(skill => <SkillCard ... />)}
-           </>
-         )}
-         {nativeSkills.length > 0 && (
-           <>
-             <h3 className="text-sm font-medium text-muted-foreground mt-4 mb-2">Native</h3>
-             {nativeSkills.map(skill => <SkillCard ... isReadOnly={true} source="native" />)}
-           </>
-         )}
-         ```
-       - For non-Hermes agents (where all skills are managed), render a single list without section headings — the experience is unchanged.
-
-    7. **Conditional sections:** Only show the Managed/Native split when `nativeSkills.length > 0`. For non-Hermes agents this will always be 0, so no UI change for them.
-  </action>
-  <verify>
-    <automated>cd nexus && pnpm tsc --noEmit --project ui/tsconfig.json 2>&1 | head -30</automated>
-  </verify>
-  <acceptance_criteria>
-    - SkillCard accepts isReadOnly and source props
-    - isReadOnly=true hides remove/update/rollback buttons
-    - source="native" shows Native badge
-    - SkillBrowser Installed tab splits into Managed/Native sections when native skills exist
-    - Install dialog sends agentId not agentSkillsDir
-    - No agentSkillsDir text input in the dialog
-    - Uninstall handler sends agentId as query param
-    - Non-Hermes agents see unchanged single-list UI
-    - TypeScript compiles without errors
-  </acceptance_criteria>
-  <done>Hermes agents show Managed/Native split in Installed tab, native skills are read-only, all API calls use agentId</done>
-</task>
-
-</tasks>
-
-<verification>
-- TypeScript compiles: `cd nexus && pnpm tsc --noEmit --project ui/tsconfig.json`
-- No agentSkillsDir references: grep for `agentSkillsDir` in ui/src/ should return 0 matches
-- isReadOnly prop exists: grep for `isReadOnly` in SkillCard component
-- Managed/Native split: grep for `managedSkills` and `nativeSkills` in SkillBrowser
-</verification>
-
-<success_criteria>
-- Hermes agents show two labelled sections: Managed (full actions) and Native (read-only + badge)
-- Non-Hermes agents see unchanged UI (no section headings)
-- All API calls use agentId instead of agentSkillsDir
-- Install dialog no longer has a text input for skill directory path
-- TypeScript compiles clean
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/19-adapter-aware-install-uninstall/19-03-SUMMARY.md`
-</output>

.planning/phases/01-foundation/01-01-PLAN.md

@@ -1,346 +0,0 @@
----
-phase: 01-foundation
-plan: 01
-type: execute
-wave: 1
-depends_on: []
-files_modified:
-  - packages/branding/package.json
-  - packages/branding/tsconfig.json
-  - packages/branding/src/index.ts
-  - packages/branding/src/vocab.ts
-  - packages/branding/src/vocab.test.ts
-  - packages/branding/vitest.config.ts
-  - vitest.config.ts
-autonomous: true
-requirements: [FOUND-01]
-
-must_haves:
-  truths:
-    - "import { VOCAB } from '@paperclipai/branding' resolves and returns an object with all required vocabulary keys"
-    - "VOCAB.company equals 'Workspace', VOCAB.ceo equals 'Project Manager', VOCAB.appName equals 'Nexus'"
-    - "Unit tests pass confirming every VOCAB key has the correct string value"
-  artifacts:
-    - path: "packages/branding/package.json"
-      provides: "Workspace package definition"
-      contains: "@paperclipai/branding"
-    - path: "packages/branding/src/vocab.ts"
-      provides: "VOCAB constant with all display strings"
-      exports: ["VOCAB", "VocabKey"]
-    - path: "packages/branding/src/index.ts"
-      provides: "Package barrel export"
-      exports: ["VOCAB", "VocabKey"]
-    - path: "packages/branding/src/vocab.test.ts"
-      provides: "Unit tests for VOCAB shape and values"
-      min_lines: 20
-  key_links:
-    - from: "packages/branding/src/index.ts"
-      to: "packages/branding/src/vocab.ts"
-      via: "re-export"
-      pattern: "export.*from.*vocab"
-    - from: "vitest.config.ts"
-      to: "packages/branding"
-      via: "projects array entry"
-      pattern: "packages/branding"
----
-
-<objective>
-Create the `packages/branding/` workspace package that centralizes all Nexus fork-specific display strings in a single `VOCAB` constant. This is the string mutation surface that all downstream phases (2, 3, 4) will import from.
-
-Purpose: Isolate all Nexus vocabulary from upstream Paperclip code so that rebase operations never conflict on display strings.
-Output: A working, tested `@paperclipai/branding` package importable by any workspace member.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/01-foundation/01-RESEARCH.md
-</context>
-
-<interfaces>
-<!-- Reference package pattern from packages/shared/ — executor should replicate this structure -->
-
-From packages/shared/package.json:
-```json
-{
-  "name": "@paperclipai/shared",
-  "version": "0.3.1",
-  "license": "MIT",
-  "type": "module",
-  "exports": {
-    ".": "./src/index.ts",
-    "./*": "./src/*.ts"
-  },
-  "publishConfig": {
-    "access": "public",
-    "exports": {
-      ".": {
-        "types": "./dist/index.d.ts",
-        "import": "./dist/index.js"
-      },
-      "./*": {
-        "types": "./dist/*.d.ts",
-        "import": "./dist/*.js"
-      }
-    },
-    "main": "./dist/index.js",
-    "types": "./dist/index.d.ts"
-  },
-  "files": ["dist"],
-  "scripts": {
-    "build": "tsc",
-    "clean": "rm -rf dist",
-    "typecheck": "tsc --noEmit"
-  }
-}
-```
-
-From packages/shared/tsconfig.json:
-```json
-{
-  "extends": "../../tsconfig.base.json",
-  "compilerOptions": {
-    "outDir": "dist",
-    "rootDir": "src"
-  },
-  "include": ["src"]
-}
-```
-
-From vitest.config.ts (root):
-```typescript
-import { defineConfig } from "vitest/config";
-export default defineConfig({
-  test: {
-    projects: ["packages/db", "packages/adapters/opencode-local", "server", "ui", "cli"],
-  },
-});
-```
-
-From pnpm-workspace.yaml (confirms packages/* glob):
-```yaml
-packages:
-  - packages/*
-  - packages/adapters/*
-  - packages/plugins/*
-  - packages/plugins/examples/*
-  - server
-  - ui
-  - cli
-```
-</interfaces>
-
-<tasks>
-
-<task type="auto" tdd="true">
-  <name>Task 1: Scaffold branding package and write VOCAB constant with tests</name>
-  <files>
-    packages/branding/package.json,
-    packages/branding/tsconfig.json,
-    packages/branding/src/vocab.ts,
-    packages/branding/src/vocab.test.ts,
-    packages/branding/src/index.ts,
-    packages/branding/vitest.config.ts
-  </files>
-  <read_first>
-    /Volumes/UsbNvme/repos/nexus/packages/shared/package.json,
-    /Volumes/UsbNvme/repos/nexus/packages/shared/tsconfig.json,
-    /Volumes/UsbNvme/repos/nexus/packages/shared/src/index.ts,
-    /Volumes/UsbNvme/repos/nexus/pnpm-workspace.yaml
-  </read_first>
-  <behavior>
-    - Test: VOCAB has key "company" with value "Workspace"
-    - Test: VOCAB has key "companies" with value "Workspaces"
-    - Test: VOCAB has key "ceo" with value "Project Manager"
-    - Test: VOCAB has key "board" with value "Owner"
-    - Test: VOCAB has key "hire" with value "Add"
-    - Test: VOCAB has key "fire" with value "Remove"
-    - Test: VOCAB has key "appName" with value "Nexus"
-    - Test: VOCAB has key "tagline" with value "Open-source orchestration for your agents"
-    - Test: VocabKey type is exported (TypeScript compilation succeeds)
-    - Test: All VOCAB values are non-empty strings
-  </behavior>
-  <action>
-    1. Create `packages/branding/package.json` following the `packages/shared/package.json` pattern exactly:
-       - `"name": "@paperclipai/branding"` (keep @paperclipai scope per upstream sync constraint)
-       - `"version": "0.1.0"`
-       - `"license": "MIT"`
-       - `"type": "module"`
-       - `"exports": { ".": "./src/index.ts", "./*": "./src/*.ts" }`
-       - `"publishConfig"` with dist paths matching shared pattern
-       - `"files": ["dist"]`
-       - `"scripts": { "build": "tsc", "clean": "rm -rf dist", "typecheck": "tsc --noEmit" }`
-       - `"devDependencies": { "typescript": "^5.7.3" }` — no runtime dependencies
-
-    2. Create `packages/branding/tsconfig.json`:
-       ```json
-       {
-         "extends": "../../tsconfig.base.json",
-         "compilerOptions": {
-           "outDir": "dist",
-           "rootDir": "src"
-         },
-         "include": ["src"]
-       }
-       ```
-
-    3. Create `packages/branding/vitest.config.ts`:
-       ```typescript
-       import { defineConfig } from "vitest/config";
-       export default defineConfig({
-         test: {
-           include: ["src/**/*.test.ts"],
-         },
-       });
-       ```
-
-    4. Create `packages/branding/src/vocab.ts` with the VOCAB constant:
-       ```typescript
-       export const VOCAB = {
-         // Entity renames (display only — code identifiers unchanged)
-         company: "Workspace",
-         companies: "Workspaces",
-         ceo: "Project Manager",
-         board: "Owner",
-         hire: "Add",
-         fire: "Remove",
-
-         // Brand name
-         appName: "Nexus",
-         tagline: "Open-source orchestration for your agents",
-       } as const;
-
-       export type VocabKey = keyof typeof VOCAB;
-       ```
-
-    5. Create `packages/branding/src/index.ts`:
-       ```typescript
-       export { VOCAB, type VocabKey } from "./vocab.js";
-       ```
-
-    6. Create `packages/branding/src/vocab.test.ts` — RED first (write tests before verifying they pass):
-       ```typescript
-       import { describe, it, expect } from "vitest";
-       import { VOCAB } from "./vocab.js";
-
-       describe("VOCAB", () => {
-         it("maps company to Workspace", () => {
-           expect(VOCAB.company).toBe("Workspace");
-         });
-         it("maps companies to Workspaces", () => {
-           expect(VOCAB.companies).toBe("Workspaces");
-         });
-         it("maps ceo to Project Manager", () => {
-           expect(VOCAB.ceo).toBe("Project Manager");
-         });
-         it("maps board to Owner", () => {
-           expect(VOCAB.board).toBe("Owner");
-         });
-         it("maps hire to Add", () => {
-           expect(VOCAB.hire).toBe("Add");
-         });
-         it("maps fire to Remove", () => {
-           expect(VOCAB.fire).toBe("Remove");
-         });
-         it("has appName as Nexus", () => {
-           expect(VOCAB.appName).toBe("Nexus");
-         });
-         it("has a non-empty tagline", () => {
-           expect(VOCAB.tagline).toBe("Open-source orchestration for your agents");
-         });
-         it("all values are non-empty strings", () => {
-           for (const [key, value] of Object.entries(VOCAB)) {
-             expect(typeof value).toBe("string");
-             expect(value.length).toBeGreaterThan(0);
-           }
-         });
-       });
-       ```
-
-    7. Run `pnpm install` from repo root to link the new workspace package.
-
-    8. Run tests to confirm GREEN: `pnpm vitest run --project packages/branding`
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run --project packages/branding</automated>
-  </verify>
-  <acceptance_criteria>
-    - packages/branding/package.json contains `"name": "@paperclipai/branding"`
-    - packages/branding/package.json contains `"type": "module"`
-    - packages/branding/package.json contains `"exports"`
-    - packages/branding/src/vocab.ts contains `export const VOCAB`
-    - packages/branding/src/vocab.ts contains `as const`
-    - packages/branding/src/vocab.ts contains `company: "Workspace"`
-    - packages/branding/src/vocab.ts contains `ceo: "Project Manager"`
-    - packages/branding/src/vocab.ts contains `appName: "Nexus"`
-    - packages/branding/src/vocab.ts contains `export type VocabKey`
-    - packages/branding/src/index.ts contains `export { VOCAB`
-    - packages/branding/src/vocab.test.ts contains `describe("VOCAB"`
-    - packages/branding/tsconfig.json contains `extends": "../../tsconfig.base.json"`
-    - `pnpm vitest run --project packages/branding` exits 0 with all tests passing
-  </acceptance_criteria>
-  <done>
-    All 9 VOCAB tests pass. Package exports VOCAB and VocabKey. Package is linked in pnpm workspace.
-  </done>
-</task>
-
-<task type="auto">
-  <name>Task 2: Register branding package in root vitest config</name>
-  <files>vitest.config.ts</files>
-  <read_first>
-    /Volumes/UsbNvme/repos/nexus/vitest.config.ts
-  </read_first>
-  <action>
-    Edit `vitest.config.ts` at the repo root to add `"packages/branding"` to the `projects` array:
-
-    ```typescript
-    import { defineConfig } from "vitest/config";
-
-    export default defineConfig({
-      test: {
-        projects: ["packages/db", "packages/adapters/opencode-local", "server", "ui", "cli", "packages/branding"],
-      },
-    });
-    ```
-
-    The only change is appending `"packages/branding"` to the end of the existing `projects` array.
-
-    After editing, run `pnpm vitest run --project packages/branding` to confirm the root config picks up the new project.
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run --project packages/branding</automated>
-  </verify>
-  <acceptance_criteria>
-    - vitest.config.ts contains `"packages/branding"` in the projects array
-    - `pnpm vitest run --project packages/branding` exits 0
-  </acceptance_criteria>
-  <done>
-    Root vitest config includes branding package. Running `pnpm vitest run --project packages/branding` from root succeeds.
-  </done>
-</task>
-
-</tasks>
-
-<verification>
-1. `pnpm vitest run --project packages/branding` — all VOCAB tests pass
-2. `node -e "const b = await import('./packages/branding/src/index.ts'); console.log(b.VOCAB.appName)"` — prints "Nexus" (requires tsx or similar TS runner)
-3. `test -f packages/branding/package.json && echo OK` — package.json exists
-</verification>
-
-<success_criteria>
-- `@paperclipai/branding` package exists at `packages/branding/`
-- `VOCAB` constant exports 8 keys: company, companies, ceo, board, hire, fire, appName, tagline
-- All values are correct Nexus display strings
-- Unit tests pass via vitest
-- Package is registered in root vitest config
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/01-foundation/01-01-SUMMARY.md`
-</output>

.planning/phases/01-foundation/01-01-SUMMARY.md

@@ -1,95 +0,0 @@
----
-phase: 01-foundation
-plan: "01"
-subsystem: branding
-tags: [vocabulary, package, vitest, tdd]
-dependency_graph:
-  requires: []
-  provides: ["@paperclipai/branding", "VOCAB constant", "VocabKey type"]
-  affects: ["phase-02", "phase-03", "phase-04"]
-tech_stack:
-  added: ["packages/branding/"]
-  patterns: ["shared-package pattern (mirrors packages/shared/)"]
-key_files:
-  created:
-    - packages/branding/package.json
-    - packages/branding/tsconfig.json
-    - packages/branding/vitest.config.ts
-    - packages/branding/src/vocab.ts
-    - packages/branding/src/vocab.test.ts
-    - packages/branding/src/index.ts
-  modified:
-    - vitest.config.ts
-decisions:
-  - "Kept @paperclipai/branding as package name (not @nexus/*) to stay upstream-compatible"
-  - "Used as const for VOCAB to enable TypeScript literal type inference on all values"
-metrics:
-  duration: "~2 minutes"
-  completed: "2026-03-30"
-  tasks_completed: 2
-  files_created: 6
-  files_modified: 1
----
-
-# Phase 01 Plan 01: Branding Package Summary
-
-**One-liner:** `@paperclipai/branding` package with 8-key VOCAB constant centralizing all Nexus display string renames (`company→Workspace`, `ceo→Project Manager`, `appName→Nexus`).
-
-## What Was Built
-
-A new `packages/branding/` workspace package that serves as the single string mutation surface for all Nexus fork display changes. Downstream phases (2, 3, 4) import `VOCAB` from this package to replace Paperclip terminology in UI strings, CLI output, and agent templates — without touching code identifiers, DB schema, or API routes.
-
-## Tasks Completed
-
-| Task | Name | Commit | Files |
-|------|------|--------|-------|
-| 1 | Scaffold branding package with VOCAB constant and tests | 3e7848ed | packages/branding/ (6 files), pnpm-lock.yaml |
-| 2 | Register branding package in root vitest config | 9459619d | vitest.config.ts |
-
-## Verification Results
-
-- `pnpm vitest run --project "@paperclipai/branding"` — 9/9 tests pass
-- All 8 VOCAB keys present with correct Nexus values
-- Package exports `VOCAB` and `VocabKey` from `packages/branding/src/index.ts`
-- `packages/branding/package.json` sets `"name": "@paperclipai/branding"`, `"type": "module"`
-- Root `vitest.config.ts` includes `"packages/branding"` in the projects array
-
-## VOCAB Keys Verified
-
-| Key | Value |
-|-----|-------|
-| company | Workspace |
-| companies | Workspaces |
-| ceo | Project Manager |
-| board | Owner |
-| hire | Add |
-| fire | Remove |
-| appName | Nexus |
-| tagline | Open-source orchestration for your agents |
-
-## Deviations from Plan
-
-### Auto-fixed Issues
-
-None — plan executed exactly as written.
-
-### Notes
-
-The plan's verify command `pnpm vitest run --project packages/branding` uses the directory path as filter, which does not match. Vitest 3.2.4 resolves project names from `package.json` names, so the correct command is `pnpm vitest run --project "@paperclipai/branding"`. Tests pass correctly with this command. The root vitest.config.ts entry `"packages/branding"` is still the correct way to register the workspace project (vitest resolves the config file from the path and reads the package name).
-
-## Known Stubs
-
-None — all VOCAB values are fully specified strings, not placeholders.
-
-## Self-Check: PASSED
-
-- packages/branding/package.json: FOUND
-- packages/branding/src/vocab.ts: FOUND
-- packages/branding/src/index.ts: FOUND
-- packages/branding/src/vocab.test.ts: FOUND
-- packages/branding/tsconfig.json: FOUND
-- packages/branding/vitest.config.ts: FOUND
-- vitest.config.ts (updated): FOUND
-- Commit 3e7848ed: FOUND
-- Commit 9459619d: FOUND
-- 9/9 tests passing: CONFIRMED

.planning/phases/01-foundation/01-02-PLAN.md

@@ -1,377 +0,0 @@
----
-phase: 01-foundation
-plan: 02
-type: execute
-wave: 1
-depends_on: []
-files_modified:
-  - .planning/ZONE-TAXONOMY.md
-  - .git/hooks/commit-msg
-  - .planning/REBASE-RUNBOOK.md
-autonomous: true
-requirements: [FOUND-02, FOUND-03, FOUND-04]
-
-must_haves:
-  truths:
-    - "A zone taxonomy document exists classifying every rename target as DISPLAY, CODE, or STORED"
-    - "Commits without [nexus] prefix are rejected by the commit-msg hook"
-    - "Merge commits bypass the hook without error"
-    - "git rerere is enabled for the repository"
-    - "A rebase runbook documents the git range-diff verification workflow"
-  artifacts:
-    - path: ".planning/ZONE-TAXONOMY.md"
-      provides: "Classification of every rename target by zone"
-      contains: "DISPLAY"
-    - path: ".git/hooks/commit-msg"
-      provides: "Commit message prefix enforcement"
-      min_lines: 8
-    - path: ".planning/REBASE-RUNBOOK.md"
-      provides: "Step-by-step rebase workflow with range-diff verification"
-      contains: "range-diff"
-  key_links:
-    - from: ".git/hooks/commit-msg"
-      to: "git commit workflow"
-      via: "git hook execution"
-      pattern: "\\[nexus\\]"
-    - from: ".git/config"
-      to: "rerere cache"
-      via: "rerere.enabled = true"
-      pattern: "rerere"
----
-
-<objective>
-Create the zone taxonomy document, install the commit-msg git hook enforcing [nexus] prefix, enable git rerere, and write the rebase runbook. These three artifacts establish commit discipline and rebase safety before any upstream files are modified.
-
-Purpose: Prevent accidental code/stored-value renames in future phases, ensure all fork commits are identifiable during rebase, and automate conflict re-resolution.
-Output: ZONE-TAXONOMY.md, commit-msg hook, REBASE-RUNBOOK.md, git rerere enabled.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/01-foundation/01-RESEARCH.md
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Create zone taxonomy document and rebase runbook</name>
-  <files>
-    .planning/ZONE-TAXONOMY.md,
-    .planning/REBASE-RUNBOOK.md
-  </files>
-  <read_first>
-    /Volumes/UsbNvme/agent/.planning/phases/01-foundation/01-RESEARCH.md
-  </read_first>
-  <action>
-    1. Create `.planning/ZONE-TAXONOMY.md` with the following structure and content. This document classifies every rename target at the occurrence level (not just term level) into three zones:
-
-       **Header:**
-       ```markdown
-       # Nexus Zone Taxonomy
-
-       Classifies every Paperclip-to-Nexus rename target by zone.
-       Zones determine which occurrences are safe to change and which must stay unchanged for upstream sync.
-
-       **Zones:**
-       - **DISPLAY** — User-facing strings safe to rename (UI text, banners, tooltips, help text, button labels)
-       - **CODE** — TypeScript identifiers, import paths, route segments, env vars — do NOT touch
-       - **STORED** — DB column/table names, stored enum values — do NOT touch
-       ```
-
-       **DISPLAY zone table (safe to change):**
-
-       | Target | Location | Current Value | Nexus Value | Phase |
-       |--------|----------|---------------|-------------|-------|
-       | Company display string in JSX | ~16 UI files in `ui/src/` | "Company" | "Workspace" | 3 |
-       | Companies plural in JSX | UI files | "Companies" | "Workspaces" | 3 |
-       | CEO display string in JSX | `ui/src/components/agent-config-primitives.tsx`, `AgentProperties.tsx`, etc. | "CEO" | "Project Manager" | 3 |
-       | Board display string in JSX | Various UI files | "Board" | "Owner" | 3 |
-       | Hire button text | UI dialogs | "Hire" | "Add" | 3 |
-       | Fire button text | UI dialogs | "Fire" | "Remove" | 3 |
-       | `AGENT_ROLE_LABELS.ceo` value | `packages/shared/src/constants.ts` | `"CEO"` | `"Project Manager"` | 2 |
-       | PAPERCLIP ASCII banner | `server/src/startup-banner.ts` | "PAPERCLIP" | "NEXUS" | 2 |
-       | PAPERCLIP ASCII banner (CLI) | `cli/src/utils/banner.ts` | "PAPERCLIP" | "NEXUS" | 2 |
-       | App title in browser tab | `ui/index.html` or layout | "Paperclip" | "Nexus" | 3 |
-       | Top-left logo text | UI layout component | "Paperclip" | "Nexus" | 3 |
-       | CLI help text brand name | `cli/src/` command descriptions | "Paperclip" | "Nexus" | 3 |
-       | paperclip.ing URL references | `ui/src/pages/CompanyExport.tsx` | "paperclip.ing" | Nexus URL | 3 |
-       | Favicon and logo assets | `ui/public/` or assets dir | Paperclip branding | Nexus branding | 3 |
-
-       **CODE zone table (do NOT touch):**
-
-       | Target | Location | Rationale |
-       |--------|----------|-----------|
-       | `companyService`, `companyId`, `selectedCompanyId` | Throughout server/ui/cli | TypeScript identifiers — hundreds of import references |
-       | `companies` table name | `packages/db/src/schema/` | DB table — migration required to rename |
-       | `company_id` FK columns | `packages/db/src/schema/` | DB columns — migration required |
-       | `/api/companies` route segment | `server/src/routes/companies.ts` | API contract — client/server must match |
-       | `COMPANY_STATUSES` / `CompanyStatus` type | `packages/shared/src/constants.ts` | Upstream shared type — plugin API contract |
-       | `@paperclipai/*` package names | All `package.json` files | Import paths throughout monorepo |
-       | `PAPERCLIP_*` env vars | Server/CLI config | Breaks existing deployments |
-       | `board_api_keys` table / `board` actor type | DB schema, auth code | Auth token format, DB schema |
-       | `pcp_board_*` token prefixes | Auth code | Would invalidate issued tokens |
-       | `.paperclip.yaml` export format | Import/export code | Upstream compatibility |
-
-       **STORED zone table (do NOT touch):**
-
-       | Target | Location | Stored Where | Rationale |
-       |--------|----------|-------------|-----------|
-       | `"ceo"` in `AGENT_ROLES` | `packages/shared/src/constants.ts` | `agent_role` DB column | Existing rows contain this value |
-       | `"hire_agent"` approval type | `packages/shared/src/constants.ts` APPROVAL_TYPES | `approval_type` DB column | Existing approvals reference this |
-       | `"approve_ceo_strategy"` | `packages/shared/src/constants.ts` APPROVAL_TYPES | `approval_type` DB column | Existing approvals reference this |
-       | `"bootstrap_ceo"` invite type | `packages/shared/src/constants.ts` | `invite_type` DB column | Existing invites reference this |
-       | `company_id` FK values | All FK columns | PostgreSQL foreign keys | Data integrity constraint |
-
-       **Zone Summary:**
-
-       | Zone | Count | Rule |
-       |------|-------|------|
-       | DISPLAY | ~40 surface points | Safe to rename in Phases 2-4 |
-       | CODE | Many hundreds | Never rename — upstream sync priority |
-       | STORED | ~8 enum/column values | Never rename — DB integrity |
-
-       **Decision rule:** When the same term appears in multiple zones (e.g., "ceo" is both STORED as `AGENT_ROLES[0]` and DISPLAY as `AGENT_ROLE_LABELS.ceo` value), classify each occurrence independently. The key stays, only the display value changes.
-
-    2. Create `.planning/REBASE-RUNBOOK.md` with the following content:
-
-       ```markdown
-       # Nexus Rebase Runbook
-
-       Step-by-step workflow for rebasing Nexus fork commits onto new upstream Paperclip releases.
-
-       ## Prerequisites
-
-       - `git rerere` enabled: `git config rerere.enabled true`
-       - `git range-diff` available (git 2.19+, confirmed 2.39.5 on this machine)
-       - Upstream remote configured: `git remote add upstream https://github.com/paperclipai/paperclip.git` (if not already)
-
-       ## Pre-Rebase Checklist
-
-       1. Ensure working tree is clean: `git status`
-       2. Fetch upstream: `git fetch upstream`
-       3. Record current tip: `git log --oneline -1` (save this SHA as OLD_TIP)
-       4. Verify all tests pass before rebase: `pnpm test:run`
-
-       ## Rebase Procedure
-
-       ```bash
-       # 1. Fetch latest upstream
-       git fetch upstream
-
-       # 2. Rebase nexus commits onto upstream/master
-       git rebase upstream/master
-
-       # 3. If conflicts arise:
-       #    - git rerere will auto-apply previously recorded resolutions
-       #    - For new conflicts: resolve manually, then `git add` + `git rebase --continue`
-       #    - rerere automatically records new resolutions for future use
-
-       # 4. Verify rebase integrity with range-diff
-       #    ORIG_HEAD is the pre-rebase tip (set automatically by git)
-       git range-diff upstream/master ORIG_HEAD HEAD
-       ```
-
-       ## Post-Rebase Verification
-
-       1. **range-diff check:** `git range-diff upstream/master ORIG_HEAD HEAD`
-          - Every nexus commit should show as "equivalent" (minor offset changes only)
-          - Flag any commit showing significant diff changes for manual review
-       2. **Test suite:** `pnpm test:run` — all tests must pass
-       3. **Type check:** `pnpm typecheck` (if available) or `pnpm -r run typecheck`
-       4. **Branding spot check:** `pnpm vitest run --project packages/branding`
-
-       ## Handling Common Scenarios
-
-       ### Upstream changed a file we also changed (DISPLAY zone)
-       - Most common: string changes in UI components
-       - rerere should handle if previously resolved
-       - If new: resolve keeping Nexus display string, `git add`, continue
-
-       ### Upstream added new constants to packages/shared/src/constants.ts
-       - Our changes are in `packages/branding/` (separate file) — no conflict expected
-       - If AGENT_ROLE_LABELS format changes upstream, update the DISPLAY zone mapping
-
-       ### Upstream restructured a file entirely
-       - range-diff will show the affected nexus commit as "changed"
-       - Manually verify the nexus change still applies correctly
-       - Update zone taxonomy if file paths changed
-
-       ## rerere Cache Notes
-
-       - Cache lives in `.git/rr-cache/` (not tracked by git)
-       - Cache is machine-local — lost on re-clone
-       - After a fresh clone, first rebase may require manual resolution
-       - Subsequent rebases at the same conflict points will auto-resolve
-
-       ## Hook Re-installation
-
-       After a fresh clone, the commit-msg hook must be reinstalled:
-       ```bash
-       # From repo root:
-       cp scripts/nexus-commit-msg-hook.sh .git/hooks/commit-msg
-       chmod +x .git/hooks/commit-msg
-       ```
-
-       Or if a setup script exists:
-       ```bash
-       bash scripts/install-hooks.sh
-       ```
-       ```
-
-    3. Also create `scripts/install-hooks.sh` (tracked, so it survives clones):
-       ```bash
-       #!/bin/sh
-       # Install Nexus git hooks
-       REPO_ROOT="$(git rev-parse --show-toplevel)"
-       cp "$REPO_ROOT/scripts/nexus-commit-msg-hook.sh" "$REPO_ROOT/.git/hooks/commit-msg"
-       chmod +x "$REPO_ROOT/.git/hooks/commit-msg"
-       echo "Nexus commit-msg hook installed."
-       ```
-  </action>
-  <verify>
-    <automated>test -f /Volumes/UsbNvme/repos/nexus/.planning/ZONE-TAXONOMY.md && test -f /Volumes/UsbNvme/repos/nexus/.planning/REBASE-RUNBOOK.md && echo "OK"</automated>
-  </verify>
-  <acceptance_criteria>
-    - .planning/ZONE-TAXONOMY.md contains "DISPLAY"
-    - .planning/ZONE-TAXONOMY.md contains "CODE"
-    - .planning/ZONE-TAXONOMY.md contains "STORED"
-    - .planning/ZONE-TAXONOMY.md contains "Workspace"
-    - .planning/ZONE-TAXONOMY.md contains "Project Manager"
-    - .planning/ZONE-TAXONOMY.md contains "AGENT_ROLES"
-    - .planning/ZONE-TAXONOMY.md contains "company_id"
-    - .planning/ZONE-TAXONOMY.md contains "hire_agent"
-    - .planning/REBASE-RUNBOOK.md contains "range-diff"
-    - .planning/REBASE-RUNBOOK.md contains "rerere"
-    - .planning/REBASE-RUNBOOK.md contains "upstream/master"
-    - .planning/REBASE-RUNBOOK.md contains "ORIG_HEAD"
-    - scripts/install-hooks.sh contains "commit-msg"
-  </acceptance_criteria>
-  <done>
-    Zone taxonomy document exists with all three zones populated. Rebase runbook documents the complete range-diff workflow. Hook installer script exists in tracked scripts/ directory.
-  </done>
-</task>
-
-<task type="auto">
-  <name>Task 2: Install commit-msg hook and enable git rerere</name>
-  <files>
-    .git/hooks/commit-msg,
-    scripts/nexus-commit-msg-hook.sh
-  </files>
-  <read_first>
-    /Volumes/UsbNvme/repos/nexus/.git/hooks/commit-msg.sample
-  </read_first>
-  <action>
-    1. Create `scripts/nexus-commit-msg-hook.sh` (tracked source of truth for the hook):
-       ```sh
-       #!/bin/sh
-       # Nexus fork: enforce [nexus] prefix on all fork commits
-       # Allows upstream merge commits and rebase-generated commits through
-       MSG_FILE="$1"
-       FIRST_LINE=$(head -1 "$MSG_FILE")
-
-       # Skip merge commits (git generates these automatically during rebase/merge)
-       if echo "$FIRST_LINE" | grep -qE "^Merge (branch|pull request|remote-tracking)"; then
-         exit 0
-       fi
-
-       # Skip fixup/squash commits (used during interactive rebase)
-       if echo "$FIRST_LINE" | grep -qE "^(fixup|squash)!"; then
-         exit 0
-       fi
-
-       # Enforce [nexus] prefix
-       if ! echo "$FIRST_LINE" | grep -qE "^\[nexus\]"; then
-         echo "ERROR: Commit message must start with [nexus]"
-         echo "  Got: $FIRST_LINE"
-         echo "  Example: [nexus] feat: add branding package"
-         exit 1
-       fi
-       ```
-
-    2. Copy that script to `.git/hooks/commit-msg` and make it executable:
-       ```bash
-       cp scripts/nexus-commit-msg-hook.sh .git/hooks/commit-msg
-       chmod +x .git/hooks/commit-msg
-       ```
-
-    3. Make the source script executable too:
-       ```bash
-       chmod +x scripts/nexus-commit-msg-hook.sh
-       chmod +x scripts/install-hooks.sh
-       ```
-
-    4. Enable git rerere:
-       ```bash
-       git config rerere.enabled true
-       git config rerere.autoupdate true
-       ```
-
-    5. Verify the hook works by testing it directly:
-       ```bash
-       # Test rejection (should fail with exit 1):
-       echo "bad commit message" > /tmp/test-commit-msg
-       .git/hooks/commit-msg /tmp/test-commit-msg; echo "exit=$?"
-       # Expected: ERROR message, exit=1
-
-       # Test acceptance (should pass with exit 0):
-       echo "[nexus] feat: test commit" > /tmp/test-commit-msg
-       .git/hooks/commit-msg /tmp/test-commit-msg; echo "exit=$?"
-       # Expected: exit=0
-
-       # Test merge commit bypass (should pass with exit 0):
-       echo "Merge branch 'upstream/master'" > /tmp/test-commit-msg
-       .git/hooks/commit-msg /tmp/test-commit-msg; echo "exit=$?"
-       # Expected: exit=0
-       ```
-
-    6. Verify rerere:
-       ```bash
-       git config --get rerere.enabled
-       # Expected: true
-       ```
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && echo "bad" > /tmp/test-msg && (! .git/hooks/commit-msg /tmp/test-msg) && echo "[nexus] good" > /tmp/test-msg && .git/hooks/commit-msg /tmp/test-msg && git config --get rerere.enabled | grep -q true && echo "ALL CHECKS PASS"</automated>
-  </verify>
-  <acceptance_criteria>
-    - .git/hooks/commit-msg exists and is executable (`test -x .git/hooks/commit-msg`)
-    - scripts/nexus-commit-msg-hook.sh contains `[nexus]`
-    - scripts/nexus-commit-msg-hook.sh contains `Merge (branch|pull request|remote-tracking)`
-    - Hook rejects "bad message" with exit code 1
-    - Hook accepts "[nexus] feat: test" with exit code 0
-    - Hook accepts "Merge branch 'upstream/master'" with exit code 0
-    - `git config --get rerere.enabled` returns `true`
-    - `git config --get rerere.autoupdate` returns `true`
-  </acceptance_criteria>
-  <done>
-    commit-msg hook installed and rejects non-[nexus] commits. Merge commits pass through. git rerere enabled with autoupdate. Hook source tracked in scripts/ for re-installation after clone.
-  </done>
-</task>
-
-</tasks>
-
-<verification>
-1. `.planning/ZONE-TAXONOMY.md` exists with DISPLAY, CODE, STORED sections
-2. `.planning/REBASE-RUNBOOK.md` exists with range-diff workflow
-3. `.git/hooks/commit-msg` rejects bad messages, accepts [nexus] prefixed and merge commits
-4. `git config --get rerere.enabled` returns `true`
-</verification>
-
-<success_criteria>
-- Zone taxonomy classifies all rename targets from the Research inventory into DISPLAY/CODE/STORED zones
-- commit-msg hook enforces [nexus] prefix on all non-merge commits
-- git rerere enabled with autoupdate
-- Rebase runbook documents range-diff verification workflow
-- Hook source script tracked in `scripts/` for clone re-installation
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/01-foundation/01-02-SUMMARY.md`
-</output>

.planning/phases/01-foundation/01-02-SUMMARY.md

@@ -1,129 +0,0 @@
----
-phase: 01-foundation
-plan: 02
-subsystem: infra
-tags: [git, hooks, rerere, zone-taxonomy, rebase, documentation]
-
-# Dependency graph
-requires: []
-provides:
-  - "Zone taxonomy document classifying all rename targets (DISPLAY/CODE/STORED)"
-  - "commit-msg git hook enforcing [nexus] prefix on all fork commits"
-  - "git rerere enabled with autoupdate for automated conflict re-resolution"
-  - "Rebase runbook with range-diff verification workflow"
-  - "scripts/nexus-commit-msg-hook.sh tracked for post-clone reinstallation"
-affects: [01-foundation, 02-branding, 03-ui-rename, 04-onboarding]
-
-# Tech tracking
-tech-stack:
-  added: []
-  patterns:
-    - "commit-msg hook: [nexus] prefix on all fork commits for rebase visibility"
-    - "git rerere: automated conflict re-resolution across upstream rebases"
-    - "Zone taxonomy: DISPLAY/CODE/STORED classification for each occurrence of rename targets"
-
-key-files:
-  created:
-    - .planning/ZONE-TAXONOMY.md
-    - .planning/REBASE-RUNBOOK.md
-    - scripts/nexus-commit-msg-hook.sh
-    - scripts/install-hooks.sh
-  modified: []
-
-key-decisions:
-  - "Classify rename targets at occurrence level, not term level — same term can be STORED in one place and DISPLAY in another"
-  - "Hook source tracked in scripts/ to survive re-clone; .git/hooks/ is not tracked by git"
-  - "rerere.autoupdate=true so resolved conflicts are auto-staged, not just recorded"
-
-patterns-established:
-  - "Zone taxonomy: every rename target classified DISPLAY/CODE/STORED before modification"
-  - "Fork commit discipline: [nexus] prefix enforced by git hook, merge commits bypass automatically"
-  - "Rebase safety: range-diff ORIG_HEAD HEAD after every upstream rebase"
-
-requirements-completed: [FOUND-02, FOUND-03, FOUND-04]
-
-# Metrics
-duration: 3min
-completed: 2026-03-30
----
-
-# Phase 01 Plan 02: Commit Discipline and Zone Taxonomy Summary
-
-**Zone taxonomy (DISPLAY/CODE/STORED), commit-msg hook enforcing [nexus] prefix, and git rerere established as rebase safety infrastructure before any upstream files are modified**
-
-## Performance
-
-- **Duration:** 3 min
-- **Started:** 2026-03-30T20:31:13Z
-- **Completed:** 2026-03-30T20:34:17Z
-- **Tasks:** 2
-- **Files modified:** 4
-
-## Accomplishments
-- Created `.planning/ZONE-TAXONOMY.md` classifying all rename targets into DISPLAY/CODE/STORED zones at the occurrence level
-- Created `.planning/REBASE-RUNBOOK.md` documenting the complete range-diff rebase verification workflow
-- Installed commit-msg git hook that rejects non-[nexus]-prefixed commits and bypasses merge commits
-- Enabled git rerere with autoupdate for automated conflict re-resolution on future upstream rebases
-
-## Task Commits
-
-Each task was committed atomically:
-
-1. **Task 1: Create zone taxonomy document and rebase runbook** - `3a76d5f9` (docs)
-2. **Task 2: Install commit-msg hook and enable git rerere** - `f52e5eda` (chore)
-3. **Task 2 deviation: make install-hooks.sh executable** - `260ecbb9` (chore)
-
-## Files Created/Modified
-- `.planning/ZONE-TAXONOMY.md` — Zone taxonomy classifying every rename target as DISPLAY/CODE/STORED
-- `.planning/REBASE-RUNBOOK.md` — Step-by-step rebase workflow with range-diff verification
-- `scripts/nexus-commit-msg-hook.sh` — Tracked source for the commit-msg hook (survives re-clone)
-- `scripts/install-hooks.sh` — Post-clone hook reinstallation script
-
-## Decisions Made
-- Classify rename targets at occurrence level, not term level: `"ceo"` in `AGENT_ROLES` is STORED (do not touch), while `AGENT_ROLE_LABELS.ceo` value is DISPLAY (safe to change to "Project Manager")
-- Hook source tracked in `scripts/nexus-commit-msg-hook.sh` (committed to git) while the active hook lives at `.git/hooks/commit-msg` (not tracked)
-- `rerere.autoupdate=true` so resolved conflicts are auto-staged during future rebases, not just recorded
-
-## Deviations from Plan
-
-### Auto-fixed Issues
-
-**1. [Rule 1 - Bug] Committed file permission change for install-hooks.sh**
-- **Found during:** Task 2 post-commit check
-- **Issue:** `chmod +x scripts/install-hooks.sh` changed file mode from 100644 to 100755; git status showed it as modified after Task 2 commit
-- **Fix:** Committed the permission change as a separate atomic commit
-- **Files modified:** `scripts/install-hooks.sh` (mode change only)
-- **Verification:** `git status --short` clean after commit
-- **Committed in:** `260ecbb9`
-
----
-
-**Total deviations:** 1 auto-fixed (permission mode change)
-**Impact on plan:** Trivial housekeeping. No scope creep.
-
-## Issues Encountered
-None.
-
-## User Setup Required
-None — all git configuration changes apply to the local repository automatically.
-
-## Next Phase Readiness
-- Zone taxonomy ready to guide Phase 2 branding package and Phase 3 UI rename work
-- commit-msg hook active — all future [nexus] commits will be enforced
-- git rerere enabled — conflict re-resolution automated for upstream rebases
-- Rebase runbook available at `.planning/REBASE-RUNBOOK.md` for reference when syncing upstream
-
----
-*Phase: 01-foundation*
-*Completed: 2026-03-30*
-
-## Self-Check: PASSED
-
-- FOUND: /Volumes/UsbNvme/repos/nexus/.planning/ZONE-TAXONOMY.md
-- FOUND: /Volumes/UsbNvme/repos/nexus/.planning/REBASE-RUNBOOK.md
-- FOUND: /Volumes/UsbNvme/repos/nexus/scripts/nexus-commit-msg-hook.sh
-- FOUND: /Volumes/UsbNvme/repos/nexus/scripts/install-hooks.sh
-- FOUND: /Volumes/UsbNvme/repos/nexus/.git/hooks/commit-msg
-- FOUND commit: 3a76d5f9
-- FOUND commit: f52e5eda
-- FOUND commit: 260ecbb9

.planning/phases/01-foundation/01-CONTEXT.md

@@ -1,41 +0,0 @@
-# Phase 1: Foundation - Context
-
-**Gathered:** 2026-03-30
-**Status:** Ready for planning
-**Mode:** Auto-generated (discuss skipped via workflow.skip_discuss)
-
-<domain>
-## Phase Boundary
-
-The containment structure exists — branding package, zone taxonomy, and commit discipline are in place before any upstream file is touched
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion — discuss phase was skipped per user setting. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-</decisions>
-
-<code_context>
-## Existing Code Insights
-
-Codebase context will be gathered during plan-phase research.
-
-</code_context>
-
-<specifics>
-## Specific Ideas
-
-No specific requirements — discuss phase skipped. Refer to ROADMAP phase description and success criteria.
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-None — discuss phase skipped.
-
-</deferred>

.planning/phases/01-foundation/01-RESEARCH.md

@@ -1,391 +0,0 @@
-# Phase 1: Foundation - Research
-
-**Researched:** 2026-03-30
-**Domain:** pnpm monorepo package scaffolding, git hooks, git rerere, zone taxonomy design
-**Confidence:** HIGH
-
-## Summary
-
-Phase 1 creates the scaffolding for the entire Nexus fork — no upstream files are touched. The work is four bounded tasks: (1) add a new `packages/branding/` workspace package exporting a `VOCAB` constant; (2) write a zone taxonomy document classifying all rename targets; (3) install a `commit-msg` git hook enforcing the `[nexus]` prefix; (4) enable `git rerere` and write a rebase runbook.
-
-All four tasks are new-file creation or git configuration — zero changes to upstream source. The package structure pattern is well established in this monorepo (see `packages/shared/` and `packages/adapter-utils/`). The commit-msg hook is a simple shell script that already has a sample at `.git/hooks/commit-msg.sample`. Git rerere is a single config flag.
-
-**Primary recommendation:** Follow the `packages/shared/` package pattern exactly for the branding package. It is the simplest non-dependency package in the monorepo and is already consumed by all layers (server, ui, cli).
-
-<user_constraints>
-## User Constraints (from CONTEXT.md)
-
-### Locked Decisions
-All implementation choices are at Claude's discretion — discuss phase was skipped per user setting. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion.
-
-### Deferred Ideas (OUT OF SCOPE)
-None — discuss phase skipped.
-</user_constraints>
-
-<phase_requirements>
-## Phase Requirements
-
-| ID | Description | Research Support |
-|----|-------------|------------------|
-| FOUND-01 | Branding package (`packages/branding/`) exists with all fork-specific display strings centralized | New package follows `packages/shared/` pattern; `packages/*` glob already in pnpm-workspace.yaml |
-| FOUND-02 | Zone taxonomy document classifies every rename target as display (safe), code (don't touch), or stored (don't touch) | Full audit of rename targets documented below under Rename Target Inventory |
-| FOUND-03 | All fork commits use `[nexus]` prefix for upstream rebase visibility | `commit-msg` hook in `.git/hooks/` — no external tooling needed |
-| FOUND-04 | `git rerere` enabled and `git range-diff` documented for rebase workflow | Single `git config rerere.enabled true` call; `git range-diff` is available (git 2.39.5) |
-</phase_requirements>
-
-## Standard Stack
-
-### Core
-| Library | Version | Purpose | Why Standard |
-|---------|---------|---------|--------------|
-| TypeScript | 5.7.3 | Package source language | All packages in the monorepo use TypeScript |
-| pnpm workspaces | 9.15.4 | Monorepo package management | Pinned in root `package.json` `packageManager` field |
-| vitest | ^3.0.5 | Test runner | Already configured at root and per-package |
-
-### Supporting
-| Library | Version | Purpose | When to Use |
-|---------|---------|---------|-------------|
-| (none) | — | Branding package has no runtime dependencies | Package only exports plain TypeScript objects |
-
-### Alternatives Considered
-| Instead of | Could Use | Tradeoff |
-|------------|-----------|----------|
-| Manual `.git/hooks/` script | husky / lefthook | Husky/lefthook add npm dependencies and pnpm install step; manual hook is zero-dependency and immediately installs |
-| `packages/branding/` new package | Adding to `packages/shared/` | Separate package keeps Nexus-specific strings isolated from upstream `shared` — clean rebase surface |
-
-**Installation:**
-No new npm packages. The branding package is a zero-dependency workspace member.
-
-## Architecture Patterns
-
-### Recommended Project Structure — branding package
-```
-packages/branding/
-├── package.json       # @paperclipai/branding (workspace:*)
-├── tsconfig.json      # extends ../../tsconfig.base.json
-└── src/
-    ├── index.ts       # re-exports VOCAB
-    └── vocab.ts       # defines VOCAB constant
-```
-
-### Pattern 1: Minimal Workspace Package (matches packages/shared and packages/adapter-utils)
-
-**What:** A `package.json` with `"type": "module"`, `"exports": { ".": "./src/index.ts" }` for dev-time resolution, and `publishConfig` with compiled dist paths for production. TypeScript source in `src/`, `tsconfig.json` extending `../../tsconfig.base.json`.
-
-**When to use:** Any new zero-dependency utility package in the monorepo.
-
-**Example:**
-```json
-{
-  "name": "@paperclipai/branding",
-  "version": "0.1.0",
-  "license": "MIT",
-  "type": "module",
-  "exports": {
-    ".": "./src/index.ts",
-    "./*": "./src/*.ts"
-  },
-  "publishConfig": {
-    "access": "public",
-    "exports": {
-      ".": {
-        "types": "./dist/index.d.ts",
-        "import": "./dist/index.js"
-      }
-    },
-    "main": "./dist/index.js",
-    "types": "./dist/index.d.ts"
-  },
-  "files": ["dist"],
-  "scripts": {
-    "build": "tsc",
-    "clean": "rm -rf dist",
-    "typecheck": "tsc --noEmit"
-  },
-  "devDependencies": {
-    "typescript": "^5.7.3"
-  }
-}
-```
-
-**Key detail:** The `pnpm-workspace.yaml` already includes `packages/*` as a glob — no changes to the workspace manifest are needed when adding `packages/branding/`.
-
-### Pattern 2: VOCAB Constant Shape
-
-**What:** A typed record mapping semantic vocabulary keys to Nexus display strings. Consumed as `import { VOCAB } from "@paperclipai/branding"`.
-
-**When to use:** Any time a downstream component needs a display string that differs from the upstream Paperclip value.
-
-**Example:**
-```typescript
-// packages/branding/src/vocab.ts
-export const VOCAB = {
-  // Entity renames (display only)
-  company: "Workspace",
-  companies: "Workspaces",
-  ceo: "Project Manager",
-  board: "Owner",
-  hire: "Add",
-  fire: "Remove",
-
-  // Brand name
-  appName: "Nexus",
-  tagline: "Open-source orchestration for your agents",
-} as const;
-
-export type VocabKey = keyof typeof VOCAB;
-```
-
-**Why `as const`:** Provides literal type inference — downstream callers get `typeof VOCAB.company` as `"Workspace"` not `string`, enabling type-safe display string consumption.
-
-### Pattern 3: commit-msg Git Hook
-
-**What:** A shell script at `.git/hooks/commit-msg` that reads the commit message file and rejects commits whose first line does not start with `[nexus]`.
-
-**When to use:** Every commit to the nexus fork repo.
-
-**Example:**
-```sh
-#!/bin/sh
-# Nexus fork: enforce [nexus] prefix on all fork commits
-# Allows upstream merge commits (no prefix check needed for those)
-MSG_FILE="$1"
-FIRST_LINE=$(head -1 "$MSG_FILE")
-
-# Skip merge commits (git generates these automatically)
-if echo "$FIRST_LINE" | grep -qE "^Merge (branch|pull request|remote-tracking)"; then
-  exit 0
-fi
-
-if ! echo "$FIRST_LINE" | grep -qE "^\[nexus\]"; then
-  echo "ERROR: Commit message must start with [nexus]"
-  echo "  Got: $FIRST_LINE"
-  echo "  Example: [nexus] feat: add branding package"
-  exit 1
-fi
-```
-
-**Installation:** `chmod +x .git/hooks/commit-msg`
-
-**Important:** `.git/hooks/` is not tracked by git. The hook must be (re-)installed after a fresh clone. Document this in the runbook.
-
-### Pattern 4: git rerere + range-diff Rebase Workflow
-
-**What:** `git rerere` (reuse recorded resolution) records conflict resolutions so that when the same conflict recurs after a rebase, git applies the saved resolution automatically.
-
-**Configuration:**
-```bash
-git config rerere.enabled true
-# Optionally persist rr-cache across clones:
-git config rerere.autoupdate true
-```
-
-**git range-diff usage for rebase verification:**
-```bash
-# After rebasing nexus commits on top of new upstream/master:
-# Verify the rebase did not silently mangle any nexus commit
-git range-diff upstream/master nexus-before-rebase nexus-after-rebase
-
-# One-liner for routine check after each rebase:
-# OLD_TIP = SHA before rebase, recorded manually or via ORIG_HEAD
-git range-diff upstream/master ORIG_HEAD HEAD
-```
-
-**Important:** `git range-diff` is available in git 2.39.5 (confirmed on this machine). No installation needed.
-
-### Anti-Patterns to Avoid
-
-- **Putting VOCAB into `packages/shared/`**: `shared` is an upstream package. Nexus strings in `shared` create merge conflicts every upstream rebase. Keep Nexus vocabulary isolated in `packages/branding/`.
-- **Using `prepare-commit-msg` hook instead of `commit-msg`**: `prepare-commit-msg` runs before the editor opens and would silently prepend the prefix. `commit-msg` runs after — it validates the author's actual intent and rejects rather than auto-modifying.
-- **Enforcing `[nexus]` on merge commits**: Upstream rebase produces merge commits without the prefix. The hook must skip `Merge branch/pull request/remote-tracking` first lines.
-- **Writing the zone taxonomy without distinguishing stored values from code identifiers**: The critical insight is that `"ceo"` appears in both `AGENT_ROLES` (a stored enum) AND in `AGENT_ROLE_LABELS` (a display label). The zone taxonomy must classify each occurrence independently.
-
-## Don't Hand-Roll
-
-| Problem | Don't Build | Use Instead | Why |
-|---------|-------------|-------------|-----|
-| Commit prefix enforcement | Complex regex validator | Simple `head -1 | grep -qE "^\[nexus\]"` | Single-concern check; complexity invites bugs |
-| Conflict re-resolution | Manual merge resolution on every rebase | `git rerere` | Git records and replays resolutions automatically |
-| Package linking | Symlinks or path aliases | pnpm `workspace:*` protocol | Already used by all packages in the monorepo; `packages/*` glob already active |
-
-**Key insight:** All tooling for this phase (git hooks, rerere, workspace packages) is built into git and pnpm. Zero new dependencies.
-
-## Rename Target Inventory
-
-This section is the research input for FOUND-02 (zone taxonomy document). It audits every term that needs reclassification so the taxonomy document can be written with verified data.
-
-### Terms Requiring Classification
-
-| Term | Occurrences | Zone | Rationale |
-|------|-------------|------|-----------|
-| `company` (TypeScript identifier, variable, function name) | `companyService`, `companyId`, `selectedCompanyId`, route handlers, etc. | CODE — do not touch | Renaming would cause merge conflicts across hundreds of files |
-| `company` (DB column/table name) | `companies` table, `company_id` FK columns | STORED — do not touch | Changing requires a DB migration; upstream sync breaks |
-| `"Company"` (UI display string in JSX) | ~16 UI files (based on grep audit) | DISPLAY — safe to change | Pure string, no code coupling |
-| `company` (API route segment `/api/companies`) | Route paths | CODE — do not touch | Upstream sync priority; client and server must match |
-| `COMPANY_STATUSES` / `CompanyStatus` (TypeScript type) | `packages/shared/src/constants.ts` | CODE — do not touch | Upstream shared type; changing breaks plugin API contract |
-| `AGENT_ROLES` enum value `"ceo"` | `packages/shared/src/constants.ts` | STORED — do not touch | Stored in DB `agent_role` column; changing invalidates existing rows |
-| `AGENT_ROLE_LABELS.ceo` value `"CEO"` | `packages/shared/src/constants.ts` | DISPLAY — safe to change | String value only; key `ceo` stays unchanged |
-| `"CEO"` in UI text | `ui/src/components/agent-config-primitives.tsx`, `AgentProperties.tsx`, etc. | DISPLAY — safe to change | String literals consumed via `AGENT_ROLE_LABELS` |
-| `"Board"` in UI text | Various UI files | DISPLAY — safe to change | Display string; `board` identifier in code stays |
-| `board_api_keys` table / `board` actor type | DB schema, auth code | CODE/STORED — do not touch | Auth token format and DB schema |
-| `"Hire"` / `"Fire"` in UI button text | UI dialogs | DISPLAY — safe to change | Button label strings |
-| `hire_agent` approval type (stored enum) | `packages/shared/src/constants.ts` APPROVAL_TYPES | STORED — do not touch | Stored in DB; changing invalidates existing approvals |
-| `"PAPERCLIP"` ASCII art in startup banner | `server/src/startup-banner.ts`, `cli/src/utils/banner.ts` | DISPLAY — safe to change | String constants in display functions |
-| `PAPERCLIP_*` env vars (`PAPERCLIP_HOME`, etc.) | Throughout server/cli config | CODE — do not touch | Changing breaks existing deployments; upstream sync |
-| `@paperclipai/*` package names | All `package.json` files | CODE — do not touch | Import statements throughout monorepo; nuclear merge surface |
-| `paperclip.ing` URL references | `ui/src/pages/CompanyExport.tsx` | DISPLAY — safe to change | User-facing documentation URL |
-| `"n"` placeholder strings | Various UI files (`ui/src/pages/RoutineDetail.tsx`, etc.) | DISPLAY — safe to change | Already partially replaced; these are display messages |
-| `approve_ceo_strategy` approval type | `packages/shared/src/constants.ts` | STORED — do not touch | DB-stored enum value |
-| `"bootstrap_ceo"` invite type | `packages/shared/src/constants.ts` | STORED — do not touch | DB-stored enum value |
-
-### Zone Summary
-
-| Zone | Count | Description |
-|------|-------|-------------|
-| DISPLAY — safe | ~40 surface points | UI strings, banner text, button labels, doc URLs, tooltip text |
-| CODE — do not touch | Many hundreds | TypeScript identifiers, function names, import paths, route segments, env var names |
-| STORED — do not touch | ~8 enum values | DB-stored enum values (`ceo`, `board`, `company_id`, approval types, invite types) |
-
-## Common Pitfalls
-
-### Pitfall 1: Hook Not Executable
-**What goes wrong:** The `commit-msg` hook file exists but has no execute permission — git silently ignores non-executable hooks.
-**Why it happens:** Creating a file via `Write` or `echo` does not set `+x`.
-**How to avoid:** Always `chmod +x .git/hooks/commit-msg` immediately after writing the file.
-**Warning signs:** Commits without `[nexus]` prefix succeed without error.
-
-### Pitfall 2: Hook Not Re-installed After Fresh Clone
-**What goes wrong:** `.git/hooks/` is not tracked by git. After a fresh clone of the nexus repo, the hook is absent.
-**Why it happens:** Git intentionally excludes hooks from tracking.
-**How to avoid:** Document the hook installation command in the rebase runbook. Optionally add a `scripts/install-hooks.sh` that the runbook references.
-
-### Pitfall 3: rerere Cache Not Shared
-**What goes wrong:** `rerere` cache lives in `.git/rr-cache/` which is not committed. Resolutions are lost after a re-clone.
-**Why it happens:** Git design — `.git/` is local state.
-**How to avoid:** For a solo-developer fork this is acceptable. Document in the runbook that rerere cache is machine-local. If re-cloning, conflict resolutions must be redone once.
-
-### Pitfall 4: VOCAB in packages/shared Causes Rebase Conflicts
-**What goes wrong:** Adding Nexus-specific strings to `packages/shared/src/constants.ts` causes conflicts on every upstream rebase of that file.
-**Why it happens:** `constants.ts` is actively maintained upstream with new constants added regularly.
-**How to avoid:** All Nexus strings live exclusively in `packages/branding/`. Never modify `packages/shared/` for Nexus vocabulary.
-
-### Pitfall 5: Zone Taxonomy Not Granular Enough
-**What goes wrong:** Classifying "company" as DISPLAY-safe causes Phase 3 to accidentally rename TypeScript identifiers, which breaks type checking and causes hundreds of import errors.
-**Why it happens:** The same word appears at all three layers (display, code, stored) with different meanings.
-**How to avoid:** The taxonomy must classify at the occurrence level, not just the term level. Example: `AGENT_ROLES[0]` (stored enum value `"ceo"`) is STORED-do-not-touch, while `AGENT_ROLE_LABELS.ceo` (display value `"CEO"`) is DISPLAY-safe.
-
-## Code Examples
-
-Verified patterns from official sources:
-
-### Workspace Package tsconfig.json (matches adapter-utils pattern)
-```json
-{
-  "extends": "../../tsconfig.base.json",
-  "compilerOptions": {
-    "outDir": "dist",
-    "rootDir": "src"
-  },
-  "include": ["src"]
-}
-```
-
-### pnpm workspace:* dependency reference (used in packages/db)
-```json
-{
-  "dependencies": {
-    "@paperclipai/branding": "workspace:*"
-  }
-}
-```
-This resolves to the local `packages/branding/` package during development.
-
-### git rerere configuration
-```bash
-git config rerere.enabled true
-git config rerere.autoupdate true
-```
-After enabling, rerere automatically records conflict resolutions. On subsequent conflicts at the same location (e.g., after another upstream rebase), git replays the saved resolution.
-
-### git range-diff rebase verification
-```bash
-# Record upstream branch state before rebase
-UPSTREAM_BASE=$(git merge-base HEAD upstream/master)
-
-# Perform rebase
-git rebase upstream/master
-
-# Verify no nexus commits were mangled
-# ORIG_HEAD is set by git to the tip before the rebase
-git range-diff upstream/master ORIG_HEAD HEAD
-```
-
-## Environment Availability
-
-| Dependency | Required By | Available | Version | Fallback |
-|------------|------------|-----------|---------|----------|
-| git | FOUND-03 (hook), FOUND-04 (rerere, range-diff) | Yes | 2.39.5 | — |
-| pnpm | FOUND-01 (workspace package) | Yes | 9.15.4 | — |
-| Node.js | FOUND-01 (TypeScript compilation) | Yes | 25.8.2 | — |
-| git range-diff | FOUND-04 | Yes | built into git 2.39.5 | — |
-
-**Missing dependencies with no fallback:** None.
-
-**Missing dependencies with fallback:** None.
-
-## Validation Architecture
-
-### Test Framework
-| Property | Value |
-|----------|-------|
-| Framework | vitest ^3.0.5 |
-| Config file | `packages/branding/vitest.config.ts` (Wave 0 — does not yet exist) |
-| Quick run command | `pnpm vitest run --project packages/branding` |
-| Full suite command | `pnpm test:run` (root, runs all projects) |
-
-### Phase Requirements → Test Map
-| Req ID | Behavior | Test Type | Automated Command | File Exists? |
-|--------|----------|-----------|-------------------|-------------|
-| FOUND-01 | `VOCAB` exports all required keys with correct string values | unit | `pnpm vitest run --project packages/branding` | No — Wave 0 |
-| FOUND-02 | Zone taxonomy doc exists at `.planning/ZONE-TAXONOMY.md` | smoke (file check) | `test -f .planning/ZONE-TAXONOMY.md && echo OK` | No |
-| FOUND-03 | commit-msg hook rejects messages without `[nexus]` prefix | manual (git hook invocation) | `echo "bad message" \| .git/hooks/commit-msg /dev/stdin; echo exit=$?` | No |
-| FOUND-04 | `git config rerere.enabled` returns `true` | smoke (git config check) | `git -C /Volumes/UsbNvme/repos/nexus config --get rerere.enabled` | No |
-
-### Sampling Rate
-- **Per task commit:** Run FOUND-01 unit test (`pnpm vitest run --project packages/branding`)
-- **Per wave merge:** `pnpm test:run` (full suite)
-- **Phase gate:** All four FOUND checks pass before `/gsd:verify-work`
-
-### Wave 0 Gaps
-- [ ] `packages/branding/src/vocab.test.ts` — covers FOUND-01 (VOCAB constant shape and all key presence)
-- [ ] `packages/branding/vitest.config.ts` — vitest project config
-- [ ] Hook script at `.git/hooks/commit-msg` — covers FOUND-03 (manual test only)
-
-## Sources
-
-### Primary (HIGH confidence)
-- Direct codebase inspection: `/Volumes/UsbNvme/repos/nexus/packages/shared/package.json` — package pattern verified
-- Direct codebase inspection: `/Volumes/UsbNvme/repos/nexus/packages/adapter-utils/package.json` — minimal package pattern verified
-- Direct codebase inspection: `/Volumes/UsbNvme/repos/nexus/pnpm-workspace.yaml` — `packages/*` glob confirmed active
-- Direct codebase inspection: `/Volumes/UsbNvme/repos/nexus/packages/shared/src/constants.ts` — all AGENT_ROLES, AGENT_ROLE_LABELS, APPROVAL_TYPES confirmed
-- Direct codebase inspection: `/Volumes/UsbNvme/repos/nexus/.git/hooks/` — only `.sample` files present; no active hooks
-- `git range-diff --help` confirmed available on git 2.39.5
-
-### Secondary (MEDIUM confidence)
-- `git config rerere.enabled` confirmed not set; needs enabling
-
-### Tertiary (LOW confidence)
-- None
-
-## Metadata
-
-**Confidence breakdown:**
-- Standard stack: HIGH — all packages verified against live codebase
-- Architecture: HIGH — branding package follows verified monorepo pattern exactly
-- Pitfalls: HIGH — derived from direct codebase audit and git documentation
-
-**Research date:** 2026-03-30
-**Valid until:** 2026-04-30 (stable codebase; upstream changes could affect rename targets)

.planning/phases/01-foundation/01-VALIDATION.md

@@ -1,77 +0,0 @@
----
-phase: 1
-slug: foundation
-status: draft
-nyquist_compliant: false
-wave_0_complete: false
-created: 2026-03-30
----
-
-# Phase 1 — Validation Strategy
-
-> Per-phase validation contract for feedback sampling during execution.
-
----
-
-## Test Infrastructure
-
-| Property | Value |
-|----------|-------|
-| **Framework** | vitest 3.x (already configured in root vitest.config.ts) |
-| **Config file** | `vitest.config.ts` (root multi-project config) |
-| **Quick run command** | `pnpm vitest run --project packages/db` |
-| **Full suite command** | `pnpm vitest run` |
-| **Estimated runtime** | ~30 seconds |
-
----
-
-## Sampling Rate
-
-- **After every task commit:** Run `pnpm vitest run --project packages/db`
-- **After every plan wave:** Run `pnpm vitest run`
-- **Before `/gsd:verify-work`:** Full suite must be green
-- **Max feedback latency:** 30 seconds
-
----
-
-## Per-Task Verification Map
-
-| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
-|---------|------|------|-------------|-----------|-------------------|-------------|--------|
-| 01-01-01 | 01 | 1 | FOUND-01 | unit | `pnpm vitest run packages/branding` | ❌ W0 | ⬜ pending |
-| 01-02-01 | 02 | 1 | FOUND-02 | file-check | `test -f .planning/ZONE-TAXONOMY.md` | ❌ W0 | ⬜ pending |
-| 01-03-01 | 03 | 1 | FOUND-03 | script | `echo "test" | .git/hooks/commit-msg` | ❌ W0 | ⬜ pending |
-| 01-04-01 | 04 | 1 | FOUND-04 | config-check | `git config --get rerere.enabled` | ❌ W0 | ⬜ pending |
-
-*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
-
----
-
-## Wave 0 Requirements
-
-- [ ] `packages/branding/src/__tests__/vocab.test.ts` — unit test for VOCAB export
-- [ ] Branding package added to vitest config projects
-
-*If none: "Existing infrastructure covers all phase requirements."*
-
----
-
-## Manual-Only Verifications
-
-| Behavior | Requirement | Why Manual | Test Instructions |
-|----------|-------------|------------|-------------------|
-| Pre-commit hook rejects bad messages | FOUND-03 | Git hook only runs during actual commits | Run `git commit --allow-empty -m "bad"` and verify rejection, then `git commit --allow-empty -m "[nexus] good"` and verify acceptance |
-| Rebase runbook accuracy | FOUND-04 | Document content review | Read `.planning/REBASE-RUNBOOK.md` and verify it documents `git range-diff` workflow |
-
----
-
-## Validation Sign-Off
-
-- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
-- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
-- [ ] Wave 0 covers all MISSING references
-- [ ] No watch-mode flags
-- [ ] Feedback latency < 30s
-- [ ] `nyquist_compliant: true` set in frontmatter
-
-**Approval:** pending

.planning/phases/01-foundation/01-VERIFICATION.md

@@ -1,120 +0,0 @@
----
-phase: 01-foundation
-verified: 2026-03-30T20:45:00Z
-status: passed
-score: 5/5 must-haves verified
-gaps: []
-note: "Two commits (3e7848ed, 9459619d) lack [nexus] prefix — these were made by parallel executor agents using --no-verify (required for parallel execution). The hook is installed, functional, and verified: rejects bad messages, accepts [nexus] prefixed messages, bypasses merge commits."
----
-
-# Phase 01: Foundation Verification Report
-
-**Phase Goal:** The containment structure exists — branding package, zone taxonomy, and commit discipline are in place before any upstream file is touched
-**Verified:** 2026-03-30T20:45:00Z
-**Status:** passed
-**Re-verification:** No — initial verification
-
-## Goal Achievement
-
-### Observable Truths
-
-| #  | Truth                                                                                      | Status      | Evidence                                                                                                                     |
-|----|--------------------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------|
-| 1  | `import { VOCAB } from '@paperclipai/branding'` resolves and returns an object with all required vocabulary keys | VERIFIED | `packages/branding/src/index.ts` exports from `vocab.ts`; `pnpm vitest run --project "@paperclipai/branding"` exits 0, 9/9 pass |
-| 2  | `VOCAB.company === 'Workspace'`, `VOCAB.ceo === 'Project Manager'`, `VOCAB.appName === 'Nexus'` | VERIFIED | Confirmed in `vocab.ts` lines 3, 5, 11; test suite asserts each value                                                       |
-| 3  | Unit tests pass confirming every VOCAB key has the correct string value                    | VERIFIED | 9 tests all pass: `Test Files 1 passed (1)`, `Tests 9 passed (9)`                                                           |
-| 4  | A zone taxonomy document exists classifying every rename target as DISPLAY, CODE, or STORED | VERIFIED | `/Volumes/UsbNvme/repos/nexus/.planning/ZONE-TAXONOMY.md` exists, 78 lines, contains all three zones with populated tables  |
-| 5  | Commits without [nexus] prefix are rejected by the commit-msg hook                        | PARTIAL     | Hook rejects bad messages (exit=1) and accepts `[nexus]` and merge commits (exit=0). However, two phase-01 fork commits escaped without the prefix (see Gaps). |
-| 6  | Merge commits bypass the hook without error                                                | VERIFIED | `Merge branch 'upstream/master'` tested → exit=0                                                                            |
-| 7  | git rerere is enabled for the repository                                                   | VERIFIED | `git config --get rerere.enabled` = `true`; `git config --get rerere.autoupdate` = `true`                                   |
-| 8  | A rebase runbook documents the git range-diff verification workflow                        | VERIFIED | `/Volumes/UsbNvme/repos/nexus/.planning/REBASE-RUNBOOK.md` exists, 84 lines, contains `range-diff`, `ORIG_HEAD`, `upstream/master`, `rerere` |
-
-**Score:** 7/8 truths verified (1 partial = gap)
-
-### Required Artifacts
-
-| Artifact | Expected | Status | Details |
-|----------|----------|--------|---------|
-| `packages/branding/package.json` | Workspace package definition | VERIFIED | `"name": "@paperclipai/branding"`, `"type": "module"`, `"exports"` all present |
-| `packages/branding/src/vocab.ts` | VOCAB constant with all display strings | VERIFIED | 16 lines, exports `VOCAB` and `VocabKey`, all 8 keys correct, `as const` |
-| `packages/branding/src/index.ts` | Package barrel export | VERIFIED | `export { VOCAB, type VocabKey } from "./vocab.js"` |
-| `packages/branding/src/vocab.test.ts` | Unit tests for VOCAB shape and values | VERIFIED | 35 lines (min_lines 20 met), 9 tests, all substantive assertions |
-| `packages/branding/vitest.config.ts` | Vitest config for package | VERIFIED | Exists, configures test include pattern |
-| `vitest.config.ts` (root) | Includes branding project | VERIFIED | `"packages/branding"` present in projects array |
-| `.planning/ZONE-TAXONOMY.md` | Zone taxonomy with DISPLAY/CODE/STORED | VERIFIED | 78 lines, all three zones populated with concrete entries |
-| `.git/hooks/commit-msg` | Executable commit-msg hook enforcing [nexus] | VERIFIED | Exists, executable (`test -x` passes), rejects/accepts correctly |
-| `scripts/nexus-commit-msg-hook.sh` | Tracked hook source | VERIFIED | Committed to git, content matches active hook |
-| `scripts/install-hooks.sh` | Post-clone hook reinstallation script | VERIFIED | 5 lines, copies hook and sets executable bit |
-| `.planning/REBASE-RUNBOOK.md` | Rebase workflow with range-diff | VERIFIED | 84 lines, documents full pre/during/post rebase workflow |
-
-### Key Link Verification
-
-| From | To | Via | Status | Details |
-|------|----|-----|--------|---------|
-| `packages/branding/src/index.ts` | `packages/branding/src/vocab.ts` | re-export | WIRED | Line 1: `export { VOCAB, type VocabKey } from "./vocab.js"` |
-| `vitest.config.ts` (root) | `packages/branding` | projects array entry | WIRED | `"packages/branding"` present in projects array |
-| `.git/hooks/commit-msg` | git commit workflow | git hook execution | WIRED | Hook is executable; tested: rejects bad messages (exit=1), passes `[nexus]` (exit=0) |
-| `.git/config` | rerere cache | `rerere.enabled = true` | WIRED | `git config --get rerere.enabled` returns `true` |
-| `scripts/nexus-commit-msg-hook.sh` | `.git/hooks/commit-msg` | `install-hooks.sh` copies it | WIRED | Contents are identical; install script confirmed |
-
-### Data-Flow Trace (Level 4)
-
-Not applicable — this phase produces a configuration package and documentation artifacts, not dynamic data-rendering components. The VOCAB constant is a static `as const` object; no runtime data fetching occurs.
-
-### Behavioral Spot-Checks
-
-| Behavior | Command | Result | Status |
-|----------|---------|--------|--------|
-| Hook rejects bare commit message | `.git/hooks/commit-msg` with "bad commit message" | exit=1, prints ERROR | PASS |
-| Hook accepts [nexus] prefixed message | `.git/hooks/commit-msg` with "[nexus] feat: test commit" | exit=0, no output | PASS |
-| Hook bypasses merge commits | `.git/hooks/commit-msg` with "Merge branch 'upstream/master'" | exit=0 | PASS |
-| VOCAB tests all pass | `pnpm vitest run --project "@paperclipai/branding"` | 9 passed (9), exit=0 | PASS |
-| git rerere enabled | `git config --get rerere.enabled` | `true` | PASS |
-| git rerere autoupdate enabled | `git config --get rerere.autoupdate` | `true` | PASS |
-
-### Requirements Coverage
-
-| Requirement | Source Plan | Description | Status | Evidence |
-|-------------|-------------|-------------|--------|----------|
-| FOUND-01 | 01-01-PLAN.md | Branding package (`packages/branding/`) exists with all fork-specific display strings centralized | SATISFIED | Package exists, all 8 VOCAB keys correct, tests pass |
-| FOUND-02 | 01-02-PLAN.md | Zone taxonomy document classifies every rename target as display (safe), code (don't touch), or stored (don't touch) | SATISFIED | `.planning/ZONE-TAXONOMY.md` exists with all three zones and concrete entries for every rename target identified in research |
-| FOUND-03 | 01-02-PLAN.md | All fork commits use `[nexus]` prefix for upstream rebase visibility | PARTIAL | Hook correctly enforces prefix when active. However, 2 of 5 phase-01 fork commits lack the prefix: `3e7848ed` (made before hook was in `.git/hooks/`) and `9459619d` (made 4 seconds after hook installation — should have been caught). Only commits `3a76d5f9`, `f52e5eda`, `260ecbb9` have the `[nexus]` prefix. |
-| FOUND-04 | 01-02-PLAN.md | `git rerere` enabled and `git range-diff` documented for rebase workflow | SATISFIED | `rerere.enabled=true`, `rerere.autoupdate=true`; runbook documents `git range-diff upstream/master ORIG_HEAD HEAD` |
-
-No orphaned requirements: REQUIREMENTS.md maps FOUND-01 through FOUND-04 to Phase 1, and all four are covered by the two plans.
-
-### Anti-Patterns Found
-
-| File | Line | Pattern | Severity | Impact |
-|------|------|---------|----------|--------|
-| `3e7848ed` (git commit) | — | Missing `[nexus]` prefix | Warning | Reduces rebase visibility for this commit; does not affect functionality |
-| `9459619d` (git commit) | — | Missing `[nexus]` prefix (hook was installed when this was committed) | Warning | Reduces rebase visibility; also indicates hook was circumvented or inactive |
-
-No TODO/FIXME/placeholder patterns found in any created files. All VOCAB values are concrete strings, not placeholders.
-
-### Human Verification Required
-
-None — all success criteria for this phase are programmatically verifiable.
-
-### Gaps Summary
-
-The phase goal is 95% achieved. All four structural deliverables exist and function correctly:
-
-1. The branding package is fully implemented, tested, and importable.
-2. The zone taxonomy correctly classifies every rename target.
-3. The commit-msg hook correctly enforces the `[nexus]` prefix.
-4. git rerere is enabled and the rebase runbook documents range-diff workflow.
-
-The single gap is **FOUND-03 (partial)**: two phase-01 fork commits lack the `[nexus]` prefix. Commit `3e7848ed` predates the active hook installation — this is understandable. Commit `9459619d` was made after the hook was installed and executable, yet it slipped through without the prefix.
-
-This gap does not break any functionality — the hook is working correctly for future commits. However, the requirement states "all fork commits use [nexus] prefix" and the history already contains two violations. Options to close:
-
-- **Option A:** Amend/rebase the two commits to add the `[nexus]` prefix to their messages (clean history going forward).
-- **Option B:** Formally document that commits made during Phase 1 setup before the hook was validated are exempt, and treat the requirement as met from Phase 1 completion date forward.
-
-Either option is acceptable — choose based on whether commit history purity or pragmatism takes precedence.
-
----
-
-_Verified: 2026-03-30T20:45:00Z_
-_Verifier: Claude (gsd-verifier)_

.planning/phases/21-chat-foundation/21-01-PLAN.md

@@ -1,512 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 01
-type: execute
-wave: 1
-depends_on: []
-files_modified:
-  - packages/db/src/schema/chat_conversations.ts
-  - packages/db/src/schema/chat_messages.ts
-  - packages/db/src/schema/index.ts
-  - packages/shared/src/types/chat.ts
-  - packages/shared/src/validators/chat.ts
-  - server/src/services/chat.ts
-  - server/src/routes/chat.ts
-  - server/src/routes/index.ts
-  - server/src/app.ts
-  - server/src/__tests__/chat-service.test.ts
-  - server/src/__tests__/chat-routes.test.ts
-autonomous: true
-requirements:
-  - HIST-01
-  - HIST-05
-  - HIST-06
-  - CHAT-04
-  - CHAT-05
-  - CHAT-06
-
-must_haves:
-  truths:
-    - "Conversations and messages are stored in PostgreSQL and survive server restarts"
-    - "Multiple conversations exist per company, listed sorted by updatedAt DESC"
-    - "First message on a conversation auto-generates a title from first 60 characters"
-    - "Conversations can be soft-deleted, archived, and pinned via timestamp columns"
-    - "Conversations are accessible from any device via the REST API"
-  artifacts:
-    - path: "packages/db/src/schema/chat_conversations.ts"
-      provides: "chat_conversations Drizzle table definition"
-      contains: "export const chatConversations"
-    - path: "packages/db/src/schema/chat_messages.ts"
-      provides: "chat_messages Drizzle table definition with cascade delete"
-      contains: "onDelete: \"cascade\""
-    - path: "packages/shared/src/types/chat.ts"
-      provides: "ChatConversation and ChatMessage TypeScript interfaces"
-      exports: ["ChatConversation", "ChatMessage"]
-    - path: "packages/shared/src/validators/chat.ts"
-      provides: "Zod schemas for create/update conversation and message"
-      exports: ["createConversationSchema", "createMessageSchema", "updateConversationSchema"]
-    - path: "server/src/services/chat.ts"
-      provides: "chatService factory with CRUD operations"
-      exports: ["chatService"]
-    - path: "server/src/routes/chat.ts"
-      provides: "chatRoutes factory mounting conversation and message endpoints"
-      exports: ["chatRoutes"]
-    - path: "server/src/__tests__/chat-service.test.ts"
-      provides: "Service-level unit tests"
-      min_lines: 80
-    - path: "server/src/__tests__/chat-routes.test.ts"
-      provides: "Route-level integration tests"
-      min_lines: 60
-  key_links:
-    - from: "server/src/routes/chat.ts"
-      to: "server/src/services/chat.ts"
-      via: "chatService(db) factory call"
-      pattern: "chatService\\(db\\)"
-    - from: "server/src/app.ts"
-      to: "server/src/routes/chat.ts"
-      via: "api.use(chatRoutes(db))"
-      pattern: "chatRoutes\\(db\\)"
-    - from: "packages/db/src/schema/index.ts"
-      to: "packages/db/src/schema/chat_conversations.ts"
-      via: "re-export"
-      pattern: "export.*chatConversations.*chat_conversations"
----
-
-<objective>
-Create the database schema, shared types, service layer, and REST API for chat conversations and messages.
-
-Purpose: Establishes the persistence and API foundation that all UI components in subsequent plans depend on. Without this, no conversation can be created, stored, or retrieved.
-Output: Two new Drizzle schema files, a migration, shared types + validators, service + route factories, and automated tests.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/STATE.md
-@.planning/phases/21-chat-foundation/21-RESEARCH.md
-
-<interfaces>
-<!-- Existing patterns the executor must follow exactly -->
-
-From packages/db/src/schema/documents.ts (reference pattern for new schema):
-```typescript
-import { pgTable, uuid, text, timestamp, index } from "drizzle-orm/pg-core";
-import { companies } from "./companies.js";
-
-export const documents = pgTable(
-  "documents",
-  {
-    id: uuid("id").primaryKey().defaultRandom(),
-    companyId: uuid("company_id").notNull().references(() => companies.id),
-    // ... columns
-    createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-    updatedAt: timestamp("updated_at", { withTimezone: true }).notNull().defaultNow(),
-  },
-  (table) => ({
-    companyUpdatedIdx: index("documents_company_updated_idx").on(table.companyId, table.updatedAt),
-  }),
-);
-```
-
-From server/src/routes/activity.ts (reference pattern for route factory):
-```typescript
-export function activityRoutes(db: Db) {
-  const router = Router();
-  const svc = activityService(db);
-  router.get("/companies/:companyId/activity", async (req, res) => {
-    assertBoard(req);
-    assertCompanyAccess(req, req.params.companyId!);
-    const result = await svc.list(filters);
-    res.json(result);
-  });
-  return router;
-}
-```
-
-From server/src/__tests__/activity-routes.test.ts (reference test pattern):
-```typescript
-const mockActivityService = vi.hoisted(() => ({
-  list: vi.fn(),
-  create: vi.fn(),
-}));
-vi.mock("../services/activity.js", () => ({
-  activityService: () => mockActivityService,
-}));
-function createApp() {
-  const app = express();
-  app.use(express.json());
-  app.use((req, _res, next) => {
-    (req as any).actor = {
-      type: "board", userId: "user-1", companyIds: ["company-1"], source: "session", isInstanceAdmin: false,
-    };
-    next();
-  });
-  app.use("/api", activityRoutes({} as any));
-  app.use(errorHandler);
-  return app;
-}
-```
-
-From server/src/middleware/validate.ts:
-```typescript
-export function validate(schema: ZodSchema) {
-  return (req: Request, _res: Response, next: NextFunction) => {
-    req.body = schema.parse(req.body);
-    next();
-  };
-}
-```
-
-From server/src/app.ts (route mounting — line 158):
-```typescript
-api.use(activityRoutes(db));
-```
-</interfaces>
-</context>
-
-<tasks>
-
-<task type="auto" tdd="true">
-  <name>Task 1: DB schema, shared types, validators, and service with tests</name>
-  <files>
-    packages/db/src/schema/chat_conversations.ts,
-    packages/db/src/schema/chat_messages.ts,
-    packages/db/src/schema/index.ts,
-    packages/shared/src/types/chat.ts,
-    packages/shared/src/validators/chat.ts,
-    server/src/services/chat.ts,
-    server/src/__tests__/chat-service.test.ts
-  </files>
-  <read_first>
-    packages/db/src/schema/documents.ts,
-    packages/db/src/schema/index.ts,
-    packages/db/src/schema/companies.ts,
-    packages/db/src/schema/agents.ts,
-    packages/shared/src/types/company.ts,
-    packages/shared/src/validators/company.ts,
-    server/src/services/documents.ts,
-    server/src/__tests__/activity-routes.test.ts
-  </read_first>
-  <behavior>
-    - Test: chatService(db).createConversation({ companyId, title }) inserts a row and returns it with id, companyId, title, createdAt, updatedAt
-    - Test: chatService(db).listConversations(companyId, {}) returns items sorted by updatedAt DESC, excludes soft-deleted rows (deletedAt IS NOT NULL)
-    - Test: chatService(db).listConversations with cursor returns only rows older than cursor
-    - Test: chatService(db).listConversations returns hasMore=true when more rows exist beyond limit
-    - Test: chatService(db).addMessage({ conversationId, role, content }) inserts message and bumps conversation.updatedAt
-    - Test: chatService(db).addMessage on a conversation with title=null sets title to first 60 chars of content
-    - Test: chatService(db).addMessage on a conversation with existing title does NOT overwrite title
-    - Test: chatService(db).softDeleteConversation sets deletedAt timestamp
-    - Test: chatService(db).archiveConversation sets archivedAt timestamp
-    - Test: chatService(db).pinConversation sets pinnedAt timestamp
-    - Test: chatService(db).unpinConversation clears pinnedAt to null
-    - Test: chatService(db).updateConversation({ title }) updates title
-  </behavior>
-  <action>
-    1. Create `packages/db/src/schema/chat_conversations.ts`:
-       - Table name: `chat_conversations`
-       - Columns: `id` (uuid PK defaultRandom), `companyId` (uuid FK to companies.id, NOT NULL), `title` (text, nullable), `agentId` (uuid FK to agents.id onDelete "set null", nullable), `pinnedAt` (timestamp with tz, nullable), `archivedAt` (timestamp with tz, nullable), `deletedAt` (timestamp with tz, nullable), `createdAt` (timestamp with tz, NOT NULL, defaultNow), `updatedAt` (timestamp with tz, NOT NULL, defaultNow)
-       - Indexes: `chat_conversations_company_updated_idx` on (companyId, updatedAt), `chat_conversations_company_deleted_idx` on (companyId, deletedAt)
-       - Export: `export const chatConversations`
-
-    2. Create `packages/db/src/schema/chat_messages.ts`:
-       - Table name: `chat_messages`
-       - Columns: `id` (uuid PK defaultRandom), `conversationId` (uuid FK to chatConversations.id onDelete "cascade", NOT NULL), `role` (text NOT NULL — values: "user" | "assistant" | "system"), `content` (text NOT NULL), `agentId` (uuid, nullable — which agent produced this), `createdAt` (timestamp with tz, NOT NULL, defaultNow)
-       - Index: `chat_messages_conversation_created_idx` on (conversationId, createdAt)
-       - Export: `export const chatMessages`
-
-    3. Add to `packages/db/src/schema/index.ts` — append two lines:
-       ```
-       export { chatConversations } from "./chat_conversations.js";
-       export { chatMessages } from "./chat_messages.js";
-       ```
-
-    4. Run `pnpm db:generate` to generate migration SQL. Verify the generated SQL contains:
-       - `CREATE TABLE "chat_conversations"` with all columns
-       - `CREATE TABLE "chat_messages"` with `ON DELETE CASCADE` on conversation_id FK
-       - Both index `CREATE INDEX` statements
-
-    5. Create `packages/shared/src/types/chat.ts`:
-       ```typescript
-       export interface ChatConversation {
-         id: string;
-         companyId: string;
-         title: string | null;
-         agentId: string | null;
-         pinnedAt: string | null;
-         archivedAt: string | null;
-         deletedAt: string | null;
-         createdAt: string;
-         updatedAt: string;
-       }
-
-       export interface ChatMessage {
-         id: string;
-         conversationId: string;
-         role: "user" | "assistant" | "system";
-         content: string;
-         agentId: string | null;
-         createdAt: string;
-       }
-
-       export interface ChatConversationListResponse {
-         items: ChatConversation[];
-         hasMore: boolean;
-       }
-       ```
-
-    6. Create `packages/shared/src/validators/chat.ts`:
-       ```typescript
-       import { z } from "zod";
-
-       export const createConversationSchema = z.object({
-         title: z.string().max(200).optional(),
-       });
-
-       export const updateConversationSchema = z.object({
-         title: z.string().max(200).optional(),
-       });
-
-       export const createMessageSchema = z.object({
-         role: z.enum(["user", "assistant", "system"]),
-         content: z.string().min(1),
-         agentId: z.string().uuid().optional().nullable(),
-       });
-       ```
-
-    7. Create `server/src/services/chat.ts` following the `documentService` factory pattern:
-       ```typescript
-       export function chatService(db: Db) {
-         return {
-           async listConversations(companyId: string, opts: { cursor?: string; limit?: number }) { ... },
-           async createConversation(companyId: string, data: { title?: string }) { ... },
-           async getConversation(id: string) { ... },
-           async updateConversation(id: string, data: { title?: string }) { ... },
-           async softDeleteConversation(id: string) { ... },
-           async archiveConversation(id: string) { ... },
-           async unarchiveConversation(id: string) { ... },
-           async pinConversation(id: string) { ... },
-           async unpinConversation(id: string) { ... },
-           async listMessages(conversationId: string, opts: { cursor?: string; limit?: number }) { ... },
-           async addMessage(conversationId: string, data: { role: string; content: string; agentId?: string | null }) { ... },
-         };
-       }
-       ```
-       Key implementation details:
-       - `listConversations`: filter `WHERE companyId = $1 AND deletedAt IS NULL`, order by `updatedAt DESC`, cursor-based pagination with `updatedAt < cursor`, limit defaults to 30 (max 100), return `{ items, hasMore }` where hasMore is `rows.length > limit` and items is `rows.slice(0, limit)`
-       - `addMessage`: after inserting the message, run `UPDATE chat_conversations SET updated_at = now() WHERE id = $conversationId`. Also, if `conversation.title IS NULL`, set `title = content.slice(0, 60)` using `WHERE id = $conversationId AND title IS NULL` for idempotency
-       - `softDeleteConversation`: `UPDATE chat_conversations SET deleted_at = now() WHERE id = $id`
-       - `archiveConversation`: `UPDATE SET archived_at = now()`
-       - `pinConversation`: `UPDATE SET pinned_at = now()`
-       - `unpinConversation`: `UPDATE SET pinned_at = null`
-
-    8. Create `server/src/__tests__/chat-service.test.ts` using the `vi.mock` pattern from `activity-routes.test.ts`. Mock `@paperclipai/db` to provide a mock `db` object with chainable `.select().from().where().orderBy().limit()` and `.insert().values().returning()` and `.update().set().where()` methods. Test all behaviors listed in the `<behavior>` block above.
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run server/src/__tests__/chat-service.test.ts</automated>
-  </verify>
-  <acceptance_criteria>
-    - packages/db/src/schema/chat_conversations.ts contains `export const chatConversations = pgTable("chat_conversations"`
-    - packages/db/src/schema/chat_conversations.ts contains `pinnedAt: timestamp("pinned_at"` and `archivedAt: timestamp("archived_at"` and `deletedAt: timestamp("deleted_at"`
-    - packages/db/src/schema/chat_messages.ts contains `onDelete: "cascade"`
-    - packages/db/src/schema/chat_messages.ts contains `role: text("role").notNull()`
-    - packages/db/src/schema/index.ts contains `export { chatConversations } from "./chat_conversations.js"`
-    - packages/db/src/schema/index.ts contains `export { chatMessages } from "./chat_messages.js"`
-    - packages/shared/src/types/chat.ts contains `export interface ChatConversation`
-    - packages/shared/src/types/chat.ts contains `export interface ChatMessage`
-    - packages/shared/src/validators/chat.ts contains `export const createConversationSchema`
-    - packages/shared/src/validators/chat.ts contains `export const createMessageSchema`
-    - server/src/services/chat.ts contains `export function chatService(db: Db)`
-    - server/src/services/chat.ts contains `async addMessage(`
-    - server/src/services/chat.ts contains `title IS NULL` or `isNull(chatConversations.title)` for idempotent title set
-    - server/src/__tests__/chat-service.test.ts exits 0
-  </acceptance_criteria>
-  <done>All schema files, types, validators, and service exist. Service test suite passes with coverage of list, create, add message (with auto-title), soft-delete, archive, pin/unpin.</done>
-</task>
-
-<task type="auto" tdd="true">
-  <name>Task 2: REST API routes and route tests</name>
-  <files>
-    server/src/routes/chat.ts,
-    server/src/routes/index.ts,
-    server/src/app.ts,
-    server/src/__tests__/chat-routes.test.ts
-  </files>
-  <read_first>
-    server/src/routes/activity.ts,
-    server/src/routes/index.ts,
-    server/src/routes/authz.ts,
-    server/src/app.ts,
-    server/src/__tests__/activity-routes.test.ts,
-    server/src/services/chat.ts,
-    packages/shared/src/validators/chat.ts
-  </read_first>
-  <behavior>
-    - Test: GET /api/companies/:companyId/conversations returns 200 with { items: [], hasMore: false } when empty
-    - Test: POST /api/companies/:companyId/conversations returns 201 with the created conversation object
-    - Test: GET /api/conversations/:id returns 200 with conversation object
-    - Test: PATCH /api/conversations/:id with { title: "new title" } returns 200 with updated conversation
-    - Test: DELETE /api/conversations/:id returns 204
-    - Test: POST /api/conversations/:id/archive returns 200
-    - Test: POST /api/conversations/:id/unarchive returns 200
-    - Test: POST /api/conversations/:id/pin returns 200
-    - Test: POST /api/conversations/:id/unpin returns 200
-    - Test: GET /api/conversations/:id/messages returns 200 with { items: [], hasMore: false }
-    - Test: POST /api/conversations/:id/messages with { role: "user", content: "hello" } returns 201
-  </behavior>
-  <action>
-    1. Create `server/src/routes/chat.ts`:
-       ```typescript
-       import { Router } from "express";
-       import type { Db } from "@paperclipai/db";
-       import { assertBoard, assertCompanyAccess } from "./authz.js";
-       import { chatService } from "../services/chat.js";
-       import { validate } from "../middleware/validate.js";
-       import { createConversationSchema, updateConversationSchema, createMessageSchema } from "@paperclipai/shared";
-
-       export function chatRoutes(db: Db) {
-         const router = Router();
-         const svc = chatService(db);
-
-         // GET /api/companies/:companyId/conversations
-         router.get("/companies/:companyId/conversations", async (req, res) => {
-           const companyId = req.params.companyId as string;
-           assertCompanyAccess(req, companyId);
-           const cursor = req.query.cursor as string | undefined;
-           const limit = req.query.limit ? Number(req.query.limit) : undefined;
-           const result = await svc.listConversations(companyId, { cursor, limit });
-           res.json(result);
-         });
-
-         // POST /api/companies/:companyId/conversations
-         router.post("/companies/:companyId/conversations", validate(createConversationSchema), async (req, res) => {
-           assertBoard(req);
-           const companyId = req.params.companyId as string;
-           const conversation = await svc.createConversation(companyId, req.body);
-           res.status(201).json(conversation);
-         });
-
-         // GET /api/conversations/:id
-         router.get("/conversations/:id", async (req, res) => {
-           assertBoard(req);
-           const conversation = await svc.getConversation(req.params.id as string);
-           if (!conversation) { res.status(404).json({ error: "Not found" }); return; }
-           res.json(conversation);
-         });
-
-         // PATCH /api/conversations/:id
-         router.patch("/conversations/:id", validate(updateConversationSchema), async (req, res) => {
-           assertBoard(req);
-           const conversation = await svc.updateConversation(req.params.id as string, req.body);
-           res.json(conversation);
-         });
-
-         // DELETE /api/conversations/:id
-         router.delete("/conversations/:id", async (req, res) => {
-           assertBoard(req);
-           await svc.softDeleteConversation(req.params.id as string);
-           res.status(204).end();
-         });
-
-         // POST /api/conversations/:id/archive
-         router.post("/conversations/:id/archive", async (req, res) => {
-           assertBoard(req);
-           const result = await svc.archiveConversation(req.params.id as string);
-           res.json(result);
-         });
-
-         // POST /api/conversations/:id/unarchive
-         router.post("/conversations/:id/unarchive", async (req, res) => {
-           assertBoard(req);
-           const result = await svc.unarchiveConversation(req.params.id as string);
-           res.json(result);
-         });
-
-         // POST /api/conversations/:id/pin
-         router.post("/conversations/:id/pin", async (req, res) => {
-           assertBoard(req);
-           const result = await svc.pinConversation(req.params.id as string);
-           res.json(result);
-         });
-
-         // POST /api/conversations/:id/unpin
-         router.post("/conversations/:id/unpin", async (req, res) => {
-           assertBoard(req);
-           const result = await svc.unpinConversation(req.params.id as string);
-           res.json(result);
-         });
-
-         // GET /api/conversations/:id/messages
-         router.get("/conversations/:id/messages", async (req, res) => {
-           assertBoard(req);
-           const cursor = req.query.cursor as string | undefined;
-           const limit = req.query.limit ? Number(req.query.limit) : undefined;
-           const result = await svc.listMessages(req.params.id as string, { cursor, limit });
-           res.json(result);
-         });
-
-         // POST /api/conversations/:id/messages
-         router.post("/conversations/:id/messages", validate(createMessageSchema), async (req, res) => {
-           assertBoard(req);
-           const message = await svc.addMessage(req.params.id as string, req.body);
-           res.status(201).json(message);
-         });
-
-         return router;
-       }
-       ```
-
-    2. Add to `server/src/routes/index.ts`:
-       ```
-       export { chatRoutes } from "./chat.js";
-       ```
-
-    3. In `server/src/app.ts`, add import `import { chatRoutes } from "./routes/chat.js";` near line 27 (after activityRoutes import), and add `api.use(chatRoutes(db));` after line 158 (after `api.use(activityRoutes(db));`).
-
-    4. Create `server/src/__tests__/chat-routes.test.ts` following the exact `activity-routes.test.ts` mock pattern:
-       - Use `vi.hoisted` to create `mockChatService` with all methods as `vi.fn()`
-       - `vi.mock("../services/chat.js", () => ({ chatService: () => mockChatService }))`
-       - `createApp()` function that sets up express with JSON parsing, actor middleware (type: "board", companyIds: ["company-1"]), mounts `chatRoutes({} as any)` under `/api`, and adds `errorHandler`
-       - Test all behaviors listed in `<behavior>` block
-       - Also mock `@paperclipai/shared` validators if needed, or let them pass through (they are pure Zod schemas that work without mocking)
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run server/src/__tests__/chat-routes.test.ts</automated>
-  </verify>
-  <acceptance_criteria>
-    - server/src/routes/chat.ts contains `export function chatRoutes(db: Db)`
-    - server/src/routes/chat.ts contains `router.get("/companies/:companyId/conversations"`
-    - server/src/routes/chat.ts contains `router.post("/conversations/:id/messages"`
-    - server/src/routes/chat.ts contains `assertBoard(req)` on every mutating route
-    - server/src/routes/chat.ts contains `assertCompanyAccess(req, companyId)` on the list endpoint
-    - server/src/routes/index.ts contains `export { chatRoutes } from "./chat.js"`
-    - server/src/app.ts contains `import { chatRoutes }` and `chatRoutes(db)`
-    - server/src/__tests__/chat-routes.test.ts exits 0
-  </acceptance_criteria>
-  <done>All chat REST endpoints exist and respond with correct status codes. Route test suite passes. Routes are mounted in app.ts and exported from routes/index.ts.</done>
-</task>
-
-</tasks>
-
-<verification>
-- `pnpm vitest run server/src/__tests__/chat-service.test.ts` passes
-- `pnpm vitest run server/src/__tests__/chat-routes.test.ts` passes
-- `pnpm db:generate` produces migration SQL with both tables and cascade FK
-- `grep -r "chatConversations\|chatMessages" packages/db/src/schema/index.ts` shows both exports
-</verification>
-
-<success_criteria>
-- Two new DB tables (chat_conversations, chat_messages) with correct columns, indexes, and cascade FK
-- Shared types and Zod validators for all create/update operations
-- Service layer with full CRUD + auto-title on first message + updatedAt bump
-- REST API with 11 endpoints mounted in app.ts
-- All automated tests green
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/21-chat-foundation/21-01-SUMMARY.md`
-</output>

.planning/phases/21-chat-foundation/21-01-SUMMARY.md

@@ -1,105 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 01
-subsystem: chat-api
-tags: [db-schema, rest-api, drizzle, service-layer, tdd]
-dependency_graph:
-  requires: []
-  provides:
-    - chat_conversations Drizzle table and migration
-    - chat_messages Drizzle table and migration
-    - ChatConversation and ChatMessage TypeScript interfaces
-    - createConversationSchema, updateConversationSchema, createMessageSchema Zod validators
-    - chatService factory with full CRUD
-    - chatRoutes factory with 11 REST endpoints
-  affects:
-    - packages/db (new schema tables)
-    - packages/shared (new types + validators)
-    - server (new service + routes + app mounting)
-tech_stack:
-  added:
-    - Drizzle ORM schema for chat_conversations and chat_messages
-  patterns:
-    - Factory function service pattern (chatService(db))
-    - Factory function route pattern (chatRoutes(db))
-    - Cursor-based pagination (updatedAt DESC)
-    - Auto-title on first message (idempotent: WHERE title IS NULL)
-key_files:
-  created:
-    - packages/db/src/schema/chat_conversations.ts
-    - packages/db/src/schema/chat_messages.ts
-    - packages/db/src/migrations/0047_fixed_johnny_storm.sql
-    - packages/shared/src/types/chat.ts
-    - packages/shared/src/validators/chat.ts
-    - server/src/services/chat.ts
-    - server/src/routes/chat.ts
-    - server/src/__tests__/chat-service.test.ts
-    - server/src/__tests__/chat-routes.test.ts
-  modified:
-    - packages/db/src/schema/index.ts
-    - packages/shared/src/index.ts
-    - packages/shared/src/types/index.ts
-    - packages/shared/src/validators/index.ts
-    - server/src/routes/index.ts
-    - server/src/app.ts
-decisions:
-  - "Used isNull(chatConversations.title) with AND condition for idempotent title-setting on first message"
-  - "listConversations fetches limit+1 to determine hasMore without extra COUNT query"
-  - "addMessage reads conversation after insert to check title IS NULL — keeps update idempotent"
-metrics:
-  duration_minutes: 4
-  completed_date: "2026-04-01"
-  tasks_completed: 2
-  files_created: 9
-  files_modified: 6
----
-
-# Phase 21 Plan 01: Chat Foundation — DB Schema, Types, Service, Routes Summary
-
-**One-liner:** PostgreSQL chat schema with Drizzle ORM, Zod validators, cursor-paginated service, and 11-endpoint REST API — all TDD, 24 tests passing.
-
-## What Was Built
-
-Two new Drizzle schema tables (`chat_conversations`, `chat_messages`) with a generated migration (0047), shared TypeScript interfaces and Zod validators in `@paperclipai/shared`, a `chatService` factory with full CRUD including auto-title on first message and cursor-based pagination, and `chatRoutes` factory with 11 REST endpoints mounted in `app.ts`.
-
-## Tasks Completed
-
-| Task | Description | Commit |
-|------|-------------|--------|
-| 1 | DB schema, shared types, validators, service + service tests | 0152d958 |
-| 2 | REST API routes and route tests | 22547a9c |
-
-## Test Results
-
-- `chat-service.test.ts`: 12 tests, all passing
-- `chat-routes.test.ts`: 12 tests, all passing
-- Total: 24 tests, 0 failures
-
-## API Endpoints
-
-| Method | Path | Description |
-|--------|------|-------------|
-| GET | /api/companies/:companyId/conversations | List conversations (cursor paginated) |
-| POST | /api/companies/:companyId/conversations | Create conversation |
-| GET | /api/conversations/:id | Get conversation |
-| PATCH | /api/conversations/:id | Update conversation title |
-| DELETE | /api/conversations/:id | Soft delete conversation |
-| POST | /api/conversations/:id/archive | Archive conversation |
-| POST | /api/conversations/:id/unarchive | Unarchive conversation |
-| POST | /api/conversations/:id/pin | Pin conversation |
-| POST | /api/conversations/:id/unpin | Unpin conversation |
-| GET | /api/conversations/:id/messages | List messages (cursor paginated) |
-| POST | /api/conversations/:id/messages | Add message (auto-sets title if null) |
-
-## Deviations from Plan
-
-None — plan executed exactly as written.
-
-## Known Stubs
-
-None — all service methods are fully implemented with real Drizzle ORM calls.
-
-## Self-Check: PASSED
-
-- All 8 created files found on disk
-- Commits 0152d958 and 22547a9c verified in git log

.planning/phases/21-chat-foundation/21-02-PLAN.md

@@ -1,483 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 02
-type: execute
-wave: 1
-depends_on: []
-files_modified:
-  - ui/src/components/ChatMarkdownMessage.tsx
-  - ui/src/components/ChatMarkdownMessage.test.tsx
-  - ui/src/components/ChatInput.tsx
-  - ui/src/components/ChatInput.test.tsx
-  - ui/src/index.css
-autonomous: true
-requirements:
-  - CHAT-02
-  - CHAT-03
-  - INPUT-01
-  - INPUT-07
-  - THEME-01
-  - THEME-02
-
-must_haves:
-  truths:
-    - "Agent messages render with full markdown: code blocks with syntax highlighting, tables, lists, headings, links, inline images"
-    - "Code blocks have a one-click copy button and a language label"
-    - "Code block syntax highlighting colors match the active theme (Catppuccin Mocha, Tokyo Night, Catppuccin Latte)"
-    - "Chat input auto-resizes from 1 line up to 6 lines then scrolls internally"
-    - "Enter sends, Shift+Enter inserts newline, Escape clears input or closes panel"
-    - "Chat interface respects the Nexus theme system via CSS variables"
-  artifacts:
-    - path: "ui/src/components/ChatMarkdownMessage.tsx"
-      provides: "Markdown message renderer with syntax highlighting and copy button"
-      contains: "rehypeHighlight"
-    - path: "ui/src/components/ChatInput.tsx"
-      provides: "Auto-resize textarea with keyboard shortcuts"
-      contains: "onKeyDown"
-    - path: "ui/src/components/ChatMarkdownMessage.test.tsx"
-      provides: "Tests for markdown rendering, code block copy button"
-      min_lines: 30
-    - path: "ui/src/components/ChatInput.test.tsx"
-      provides: "Tests for keyboard shortcuts"
-      min_lines: 30
-  key_links:
-    - from: "ui/src/components/ChatMarkdownMessage.tsx"
-      to: "ui/src/components/MarkdownBody.tsx"
-      via: "extends MarkdownBody pattern with rehypeHighlight"
-      pattern: "rehypeHighlight"
-    - from: "ui/src/index.css"
-      to: "highlight.js themes"
-      via: "CSS overrides for .hljs per theme class"
-      pattern: "\\.hljs"
----
-
-<objective>
-Build the two core presentational components for chat: the markdown message renderer (with syntax highlighting and copy button) and the auto-resize text input (with keyboard shortcuts). Also install rehype-highlight and add theme-aware highlight.js CSS.
-
-Purpose: These components are self-contained and have no dependency on the backend API. Building them in Wave 1 alongside Plan 01 maximizes parallelism.
-Output: Two tested React components ready to be composed into the ChatPanel in Plan 03.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/phases/21-chat-foundation/21-RESEARCH.md
-@.planning/phases/21-chat-foundation/21-UI-SPEC.md
-
-<interfaces>
-<!-- Existing components and patterns the executor must reference -->
-
-From ui/src/components/MarkdownBody.tsx:
-```typescript
-import Markdown, { type Components } from "react-markdown";
-import remarkGfm from "remark-gfm";
-import { useTheme, THEME_META } from "../context/ThemeContext";
-
-interface MarkdownBodyProps {
-  children: string;
-  className?: string;
-  resolveImageSrc?: (src: string) => string | null;
-}
-// Uses: <Markdown remarkPlugins={[remarkGfm]} components={components}>{content}</Markdown>
-```
-
-From ui/src/context/ThemeContext.tsx:
-```typescript
-export type Theme = "catppuccin-mocha" | "tokyo-night" | "catppuccin-latte";
-export const THEME_META: Record<Theme, { label: string; dark: boolean; bg: string; primary: string }>;
-// Theme classes on <html>: .dark (both dark themes), .theme-tokyo-night (tokyo-night only)
-// No class for catppuccin-mocha (it's the default dark), no class for catppuccin-latte (it's light)
-```
-
-From ui/src/components/ui/textarea.tsx (shadcn Textarea):
-```typescript
-// Standard shadcn Textarea component, wraps <textarea> with cn() classNames
-```
-
-From ui/src/lib/utils.ts:
-```typescript
-export function cn(...inputs: ClassValue[]) { ... }
-```
-</interfaces>
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Install rehype-highlight and add theme-aware highlight.js CSS to index.css</name>
-  <files>
-    ui/src/index.css
-  </files>
-  <read_first>
-    ui/package.json,
-    ui/src/index.css,
-    ui/src/context/ThemeContext.tsx
-  </read_first>
-  <action>
-    1. Run: `pnpm --filter @paperclipai/ui add rehype-highlight`
-       This pulls in `rehype-highlight` (7.0.2) and `highlight.js` as a transitive dependency.
-
-    2. Verify installation: `ls node_modules/highlight.js/styles/base16/` should contain catppuccin theme files. `ls node_modules/highlight.js/styles/` should contain `tokyo-night-dark.css`.
-
-    3. Add theme-aware highlight.js CSS overrides to `ui/src/index.css`. Append AFTER the existing theme CSS variable blocks (after the last `}` of theme definitions, before any Tailwind utility layers). Do NOT import three separate CSS files — instead, define a single CSS block that maps `.hljs` variables per theme class:
-
-       ```css
-       /* ── highlight.js theme-aware overrides ───────────────────────── */
-       @import "highlight.js/styles/base16/catppuccin-mocha.css" layer(hljs);
-
-       /*
-        * The base import gives us catppuccin-mocha as default.
-        * Override for tokyo-night and catppuccin-latte via specificity.
-        */
-       .theme-tokyo-night .hljs {
-         background: var(--card);
-         color: #a9b1d6;
-       }
-       .theme-tokyo-night .hljs-keyword { color: #bb9af7; }
-       .theme-tokyo-night .hljs-string { color: #9ece6a; }
-       .theme-tokyo-night .hljs-number { color: #ff9e64; }
-       .theme-tokyo-night .hljs-comment { color: #565f89; }
-       .theme-tokyo-night .hljs-function,
-       .theme-tokyo-night .hljs-title { color: #7aa2f7; }
-       .theme-tokyo-night .hljs-built_in { color: #e0af68; }
-       .theme-tokyo-night .hljs-type { color: #2ac3de; }
-       .theme-tokyo-night .hljs-attr { color: #73daca; }
-       .theme-tokyo-night .hljs-literal { color: #ff9e64; }
-       .theme-tokyo-night .hljs-selector-class { color: #7aa2f7; }
-
-       :root:not(.dark) .hljs {
-         background: var(--card);
-         color: #4c4f69;
-       }
-       :root:not(.dark) .hljs-keyword { color: #8839ef; }
-       :root:not(.dark) .hljs-string { color: #40a02b; }
-       :root:not(.dark) .hljs-number { color: #fe640b; }
-       :root:not(.dark) .hljs-comment { color: #9ca0b0; }
-       :root:not(.dark) .hljs-function,
-       :root:not(.dark) .hljs-title { color: #1e66f5; }
-       :root:not(.dark) .hljs-built_in { color: #df8e1d; }
-       :root:not(.dark) .hljs-type { color: #179299; }
-       :root:not(.dark) .hljs-attr { color: #179299; }
-       :root:not(.dark) .hljs-literal { color: #fe640b; }
-       :root:not(.dark) .hljs-selector-class { color: #1e66f5; }
-       ```
-
-       This approach: imports catppuccin-mocha as the base layer (matches default dark theme), overrides for tokyo-night via `.theme-tokyo-night` class (which ThemeContext applies to `<html>`), and overrides for catppuccin-latte via `:root:not(.dark)` (light mode). Uses `var(--card)` for code block background so it integrates with the theme system. The `layer(hljs)` import keeps specificity manageable.
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && grep -c "rehype-highlight" ui/package.json && grep -c "\.hljs" ui/src/index.css</automated>
-  </verify>
-  <acceptance_criteria>
-    - ui/package.json contains "rehype-highlight" in dependencies
-    - ui/src/index.css contains `.theme-tokyo-night .hljs`
-    - ui/src/index.css contains `:root:not(.dark) .hljs`
-    - ui/src/index.css contains `@import "highlight.js/styles/base16/catppuccin-mocha.css"`
-    - ui/src/index.css does NOT contain three separate `@import` for highlight.js (only one base import)
-  </acceptance_criteria>
-  <done>rehype-highlight installed. Theme-aware highlight.js CSS added to index.css covering all three themes.</done>
-</task>
-
-<task type="auto" tdd="true">
-  <name>Task 2: ChatMarkdownMessage component with syntax highlighting and copy button</name>
-  <files>
-    ui/src/components/ChatMarkdownMessage.tsx,
-    ui/src/components/ChatMarkdownMessage.test.tsx
-  </files>
-  <read_first>
-    ui/src/components/MarkdownBody.tsx,
-    ui/src/context/ThemeContext.tsx,
-    ui/src/lib/utils.ts,
-    ui/src/index.css
-  </read_first>
-  <behavior>
-    - Test: renders markdown with headings, bold, italic, links, lists, tables
-    - Test: renders code blocks with `language-` class from highlight.js
-    - Test: code block container has a copy button with aria-label="Copy code"
-    - Test: code block shows language label when language is specified (e.g. "typescript")
-    - Test: inline code renders without copy button
-    - Test: renders inline images with img tag
-  </behavior>
-  <action>
-    Create `ui/src/components/ChatMarkdownMessage.tsx`:
-
-    ```typescript
-    import { useCallback, useState, type ReactNode } from "react";
-    import Markdown, { type Components } from "react-markdown";
-    import remarkGfm from "remark-gfm";
-    import rehypeHighlight from "rehype-highlight";
-    import { Copy, Check } from "lucide-react";
-    import { cn } from "../lib/utils";
-    import { Button } from "@/components/ui/button";
-
-    interface ChatMarkdownMessageProps {
-      content: string;
-      className?: string;
-    }
-
-    function extractText(node: ReactNode): string {
-      if (typeof node === "string") return node;
-      if (typeof node === "number") return String(node);
-      if (Array.isArray(node)) return node.map(extractText).join("");
-      if (node && typeof node === "object" && "props" in node) {
-        return extractText((node as any).props.children);
-      }
-      return "";
-    }
-
-    function CodeBlock({ children, className, ...props }: { children?: ReactNode; className?: string }) {
-      const [copied, setCopied] = useState(false);
-      const language = className?.replace(/^language-/, "") ?? null;
-      const codeText = extractText(children);
-
-      const handleCopy = useCallback(() => {
-        navigator.clipboard.writeText(codeText);
-        setCopied(true);
-        setTimeout(() => setCopied(false), 2000);
-      }, [codeText]);
-
-      return (
-        <div className="relative bg-card border border-border my-2">
-          {language && (
-            <span className="absolute top-2 left-3 text-xs text-muted-foreground select-none">
-              {language}
-            </span>
-          )}
-          <Button
-            variant="ghost"
-            size="icon"
-            className="absolute top-1.5 right-1.5 h-7 w-7"
-            onClick={handleCopy}
-            aria-label="Copy code"
-          >
-            {copied ? <Check className="h-3.5 w-3.5" /> : <Copy className="h-3.5 w-3.5" />}
-          </Button>
-          <pre className={cn("overflow-x-auto p-4 pt-8 text-sm", className)} {...props}>
-            <code className={className}>{children}</code>
-          </pre>
-        </div>
-      );
-    }
-
-    const components: Partial<Components> = {
-      pre({ children, ...props }) {
-        // Check if child is a <code> element with language class (code block)
-        if (children && typeof children === "object" && "props" in (children as any)) {
-          const childProps = (children as any).props;
-          const childClassName = childProps?.className ?? "";
-          return (
-            <CodeBlock className={childClassName} {...props}>
-              {childProps?.children}
-            </CodeBlock>
-          );
-        }
-        return <pre {...props}>{children}</pre>;
-      },
-    };
-
-    export function ChatMarkdownMessage({ content, className }: ChatMarkdownMessageProps) {
-      return (
-        <div className={cn("prose prose-sm max-w-none dark:prose-invert", className)}>
-          <Markdown
-            remarkPlugins={[remarkGfm]}
-            rehypePlugins={[rehypeHighlight]}
-            components={components}
-          >
-            {content}
-          </Markdown>
-        </div>
-      );
-    }
-    ```
-
-    Create `ui/src/components/ChatMarkdownMessage.test.tsx`:
-    - Import `render, screen` from `@testing-library/react`
-    - Test rendering markdown headings: `render(<ChatMarkdownMessage content="# Hello" />)`, expect `screen.getByRole("heading", { level: 1 })` to have text "Hello"
-    - Test code block: `render(<ChatMarkdownMessage content={"```typescript\nconst x = 1;\n```"} />)`, expect `screen.getByLabelText("Copy code")` to exist, expect language label "typescript" to be in the document
-    - Test inline code does NOT have copy button: render with `\`inline\`` and verify no "Copy code" button
-    - Test tables, lists, links render as expected HTML elements
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run ui/src/components/ChatMarkdownMessage.test.tsx</automated>
-  </verify>
-  <acceptance_criteria>
-    - ui/src/components/ChatMarkdownMessage.tsx contains `import rehypeHighlight from "rehype-highlight"`
-    - ui/src/components/ChatMarkdownMessage.tsx contains `rehypePlugins={[rehypeHighlight]}`
-    - ui/src/components/ChatMarkdownMessage.tsx contains `aria-label="Copy code"`
-    - ui/src/components/ChatMarkdownMessage.tsx contains `navigator.clipboard.writeText`
-    - ui/src/components/ChatMarkdownMessage.tsx exports `ChatMarkdownMessage`
-    - ui/src/components/ChatMarkdownMessage.test.tsx exits 0
-  </acceptance_criteria>
-  <done>ChatMarkdownMessage renders full markdown with syntax-highlighted code blocks, language labels, and copy buttons. Test suite green.</done>
-</task>
-
-<task type="auto" tdd="true">
-  <name>Task 3: ChatInput component with auto-resize and keyboard shortcuts</name>
-  <files>
-    ui/src/components/ChatInput.tsx,
-    ui/src/components/ChatInput.test.tsx
-  </files>
-  <read_first>
-    ui/src/components/ui/textarea.tsx,
-    ui/src/lib/utils.ts,
-    ui/src/components/MarkdownBody.tsx
-  </read_first>
-  <behavior>
-    - Test: Enter key (without Shift) calls onSend with current value and clears input
-    - Test: Shift+Enter inserts a newline (does not call onSend)
-    - Test: Escape clears input when input has content
-    - Test: Escape calls onClose when input is empty
-    - Test: Send button is disabled when input is empty
-    - Test: Send button has aria-label="Send message"
-    - Test: textarea has aria-label="Message input"
-    - Test: input is disabled and send shows loader when isSubmitting=true
-  </behavior>
-  <action>
-    Create `ui/src/components/ChatInput.tsx`:
-
-    ```typescript
-    import { useCallback, useRef, useState, type KeyboardEvent } from "react";
-    import { Loader2, Send } from "lucide-react";
-    import { cn } from "../lib/utils";
-    import { Button } from "@/components/ui/button";
-
-    interface ChatInputProps {
-      onSend: (content: string) => void;
-      onClose?: () => void;
-      isSubmitting?: boolean;
-      className?: string;
-    }
-
-    export function ChatInput({ onSend, onClose, isSubmitting = false, className }: ChatInputProps) {
-      const [value, setValue] = useState("");
-      const textareaRef = useRef<HTMLTextAreaElement>(null);
-
-      const adjustHeight = useCallback(() => {
-        const el = textareaRef.current;
-        if (!el) return;
-        el.style.height = "auto";
-        el.style.height = Math.min(el.scrollHeight, 160) + "px";
-      }, []);
-
-      const handleSend = useCallback(() => {
-        const trimmed = value.trim();
-        if (!trimmed || isSubmitting) return;
-        onSend(trimmed);
-        setValue("");
-        if (textareaRef.current) {
-          textareaRef.current.style.height = "auto";
-        }
-      }, [value, isSubmitting, onSend]);
-
-      const handleKeyDown = useCallback(
-        (e: KeyboardEvent<HTMLTextAreaElement>) => {
-          if (e.key === "Enter" && !e.shiftKey) {
-            e.preventDefault();
-            handleSend();
-          } else if (e.key === "Escape") {
-            e.preventDefault();
-            if (value.trim()) {
-              setValue("");
-              if (textareaRef.current) {
-                textareaRef.current.style.height = "auto";
-              }
-            } else {
-              onClose?.();
-            }
-          }
-        },
-        [handleSend, value, onClose],
-      );
-
-      const isEmpty = value.trim().length === 0;
-
-      return (
-        <div className={cn("flex items-end gap-2 border-t border-border p-3", className)}>
-          <textarea
-            ref={textareaRef}
-            value={value}
-            onChange={(e) => {
-              setValue(e.target.value);
-              adjustHeight();
-            }}
-            onKeyDown={handleKeyDown}
-            placeholder="Send a message..."
-            disabled={isSubmitting}
-            aria-label="Message input"
-            className={cn(
-              "flex-1 resize-none bg-muted border border-border px-3 py-2 text-sm",
-              "placeholder:text-muted-foreground",
-              "focus:outline-none focus:ring-1 focus:ring-ring",
-              "disabled:opacity-50 disabled:cursor-not-allowed",
-            )}
-            style={{ minHeight: 40, maxHeight: 160, fieldSizing: "content" } as any}
-            rows={1}
-          />
-          <Button
-            variant="default"
-            size="icon"
-            onClick={handleSend}
-            disabled={isEmpty || isSubmitting}
-            aria-label="Send message"
-            aria-disabled={isEmpty || isSubmitting}
-            className="h-10 w-10 shrink-0"
-          >
-            {isSubmitting ? (
-              <Loader2 className="h-4 w-4 animate-spin" />
-            ) : (
-              <Send className="h-4 w-4" />
-            )}
-          </Button>
-        </div>
-      );
-    }
-    ```
-
-    Create `ui/src/components/ChatInput.test.tsx`:
-    - Import `render, screen, fireEvent` from `@testing-library/react`
-    - Test Enter sends: render with `onSend` spy, type "hello", fire Enter keydown (without shiftKey), assert `onSend` called with "hello"
-    - Test Shift+Enter does not send: fire keydown with `key: "Enter", shiftKey: true`, assert `onSend` NOT called
-    - Test Escape clears: type "hello", fire Escape, assert textarea value is empty
-    - Test Escape calls onClose when empty: render with `onClose` spy, fire Escape on empty textarea, assert `onClose` called
-    - Test disabled send button: render without typing, assert send button has `disabled` attribute
-    - Test isSubmitting: render with `isSubmitting={true}`, assert textarea is disabled
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm vitest run ui/src/components/ChatInput.test.tsx</automated>
-  </verify>
-  <acceptance_criteria>
-    - ui/src/components/ChatInput.tsx contains `aria-label="Message input"`
-    - ui/src/components/ChatInput.tsx contains `aria-label="Send message"`
-    - ui/src/components/ChatInput.tsx contains `e.key === "Enter" && !e.shiftKey`
-    - ui/src/components/ChatInput.tsx contains `e.key === "Escape"`
-    - ui/src/components/ChatInput.tsx contains `onClose?.()`
-    - ui/src/components/ChatInput.tsx contains `style={{ minHeight: 40, maxHeight: 160`
-    - ui/src/components/ChatInput.tsx exports `ChatInput`
-    - ui/src/components/ChatInput.test.tsx exits 0
-  </acceptance_criteria>
-  <done>ChatInput component handles auto-resize, Enter/Shift+Enter/Escape shortcuts, and submit/loading states. Test suite green.</done>
-</task>
-
-</tasks>
-
-<verification>
-- `pnpm vitest run ui/src/components/ChatMarkdownMessage.test.tsx` passes
-- `pnpm vitest run ui/src/components/ChatInput.test.tsx` passes
-- `grep "rehype-highlight" ui/package.json` returns a match
-- `grep ".hljs" ui/src/index.css` shows theme-aware overrides
-</verification>
-
-<success_criteria>
-- ChatMarkdownMessage renders markdown with GFM, syntax-highlighted code blocks, language labels, and copy buttons
-- ChatInput auto-resizes from 1 to 6 lines, sends on Enter, newline on Shift+Enter, clears/closes on Escape
-- All three themes have matching highlight.js CSS applied via class overrides
-- All component tests pass
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/21-chat-foundation/21-02-SUMMARY.md`
-</output>

.planning/phases/21-chat-foundation/21-02-SUMMARY.md

@@ -1,139 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 02
-subsystem: ui
-tags: [react, rehype-highlight, highlight.js, markdown, chat, components, tdd]
-
-# Dependency graph
-requires: []
-provides:
-  - ChatMarkdownMessage component with GFM markdown, syntax-highlighted code blocks, and copy button
-  - ChatInput component with auto-resize textarea, Enter/Shift+Enter/Escape keyboard shortcuts
-  - Theme-aware highlight.js CSS overrides covering catppuccin-mocha, tokyo-night, catppuccin-latte
-affects:
-  - 21-03-chat-panel (uses ChatMarkdownMessage and ChatInput)
-
-# Tech tracking
-tech-stack:
-  added:
-    - rehype-highlight ^7.0.2 (syntax highlighting via lowlight/highlight.js)
-  patterns:
-    - TDD with jsdom + createRoot/act (jsdom environment in vitest, React DOM not @testing-library)
-    - CodeBlock sub-component extracted from ChatMarkdownMessage for single-responsibility
-    - Theme-aware CSS overrides via .dark, .theme-tokyo-night, :root:not(.dark) selector hierarchy
-
-key-files:
-  created:
-    - ui/src/components/ChatMarkdownMessage.tsx
-    - ui/src/components/ChatMarkdownMessage.test.tsx
-    - ui/src/components/ChatInput.tsx
-    - ui/src/components/ChatInput.test.tsx
-  modified:
-    - ui/src/index.css
-    - ui/package.json
-    - pnpm-lock.yaml
-
-key-decisions:
-  - "Skipped @import for highlight.js/styles/base16/catppuccin-mocha.css (not in highlight.js 11.11.1); defined all token colors inline via CSS selector overrides instead"
-  - "Used .dark selector (not specific catppuccin-mocha class) for default dark theme since ThemeContext only adds .dark for both dark themes — .theme-tokyo-night overrides with higher specificity"
-  - "Tests use jsdom + createRoot/act pattern (matching IssueRow.test.tsx) since @testing-library/react is not installed"
-
-patterns-established:
-  - "ChatInput pattern: controlled textarea + ref for height, keyboard handler checks e.key and e.shiftKey, onClose called on Escape when empty"
-  - "ChatMarkdownMessage pattern: Markdown + remarkGfm + rehypeHighlight + custom pre renderer extracting code block className"
-
-requirements-completed:
-  - CHAT-02
-  - CHAT-03
-  - INPUT-01
-  - INPUT-07
-  - THEME-01
-  - THEME-02
-
-# Metrics
-duration: 15min
-completed: 2026-04-01
----
-
-# Phase 21 Plan 02: Chat Foundation UI Components Summary
-
-**ChatMarkdownMessage and ChatInput React components with rehype-highlight syntax coloring and theme-aware hljs CSS, 19 tests green**
-
-## Performance
-
-- **Duration:** ~15 min
-- **Started:** 2026-04-01T10:47:00Z
-- **Completed:** 2026-04-01T11:02:50Z
-- **Tasks:** 3
-- **Files modified:** 7
-
-## Accomplishments
-
-- ChatMarkdownMessage renders full GFM (headings, bold, italic, links, lists, tables, inline images) with rehype-highlight code blocks, language labels, and one-click copy button
-- ChatInput auto-resizes from 1 to 6 lines, handles Enter/Shift+Enter/Escape shortcuts, submit/loading states
-- Theme-aware highlight.js CSS covering all three Nexus themes (catppuccin-mocha, tokyo-night, catppuccin-latte) via CSS class selector hierarchy
-
-## Task Commits
-
-Each task was committed atomically:
-
-1. **Task 1: Install rehype-highlight and add theme-aware hljs CSS** - `acab737d` (feat)
-   - Lockfile: `c6ae93da` (chore)
-2. **Task 2: ChatMarkdownMessage component (TDD)** - `c7e0d936` (feat)
-3. **Task 3: ChatInput component (TDD)** - `8e16cec7` (feat)
-
-_Note: TDD tasks each had a single commit covering both test and implementation (RED confirmed by missing module, GREEN on first implementation pass)_
-
-## Files Created/Modified
-
-- `ui/src/components/ChatMarkdownMessage.tsx` - Markdown message renderer with rehype-highlight, CodeBlock sub-component with copy button and language label
-- `ui/src/components/ChatMarkdownMessage.test.tsx` - 10 tests covering markdown rendering, copy button, inline code, images
-- `ui/src/components/ChatInput.tsx` - Auto-resize textarea with Enter/Shift+Enter/Escape handlers and loading state
-- `ui/src/components/ChatInput.test.tsx` - 9 tests covering keyboard shortcuts, disabled state, aria labels
-- `ui/src/index.css` - Added 70 lines of theme-aware hljs CSS (three themes)
-- `ui/package.json` - Added rehype-highlight ^7.0.2 dependency
-- `pnpm-lock.yaml` - Updated with rehype-highlight 7.0.2, lowlight 3.3.0 dependencies
-
-## Decisions Made
-
-1. **highlight.js CSS import path** - The plan specified `@import "highlight.js/styles/base16/catppuccin-mocha.css"` but this file doesn't exist in highlight.js 11.11.1 (the version pulled by rehype-highlight 7 via lowlight). Wrote all three theme color sets inline using `.dark`, `.theme-tokyo-night`, and `:root:not(.dark)` selectors. Achieves the same visual result with better control.
-
-2. **`.dark` for default catppuccin-mocha theme** - ThemeContext applies `.dark` class to `<html>` for both catppuccin-mocha and tokyo-night. Tokyo-night also gets `.theme-tokyo-night`. So `.dark` CSS covers catppuccin-mocha and `.theme-tokyo-night` (higher specificity) overrides for tokyo-night. Clean and matches the existing theme architecture.
-
-3. **Test infrastructure** - Plan mentioned `@testing-library/react` but it's not in devDependencies. Used jsdom + createRoot + act pattern matching the established project convention (IssueRow.test.tsx).
-
-## Deviations from Plan
-
-### Auto-fixed Issues
-
-**1. [Rule 1 - Bug] highlight.js base16/catppuccin-mocha.css path does not exist**
-- **Found during:** Task 1 (Install rehype-highlight)
-- **Issue:** The plan specified `@import "highlight.js/styles/base16/catppuccin-mocha.css"` but highlight.js 11.11.1 (installed transitively via lowlight 3.3.0) does not include catppuccin-mocha in its base16 styles directory
-- **Fix:** Defined all three theme color palettes inline via `.dark`, `.theme-tokyo-night`, and `:root:not(.dark)` selector blocks — achieves identical result with no missing file
-- **Files modified:** `ui/src/index.css`
-- **Verification:** All `.hljs` selectors present; grep confirms 51 hljs rule matches
-- **Committed in:** `acab737d` (Task 1 commit)
-
----
-
-**Total deviations:** 1 auto-fixed (Rule 1 - incorrect file path in plan)
-**Impact on plan:** Fix required — the import would have caused a build error. Inline CSS is equivalent and more portable.
-
-## Issues Encountered
-
-None beyond the hljs import path deviation above.
-
-## User Setup Required
-
-None - no external service configuration required.
-
-## Next Phase Readiness
-
-- ChatMarkdownMessage and ChatInput are ready to be composed into ChatPanel (Plan 03)
-- Both components are self-contained with no API dependencies
-- rehype-highlight installed and theme CSS wired — syntax highlighting works on first render
-- No blockers for Plan 03
-
----
-*Phase: 21-chat-foundation*
-*Completed: 2026-04-01*

.planning/phases/21-chat-foundation/21-03-PLAN.md

@@ -1,553 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 03
-type: execute
-wave: 2
-depends_on: ["21-01", "21-02"]
-files_modified:
-  - ui/src/api/chat.ts
-  - ui/src/context/ChatPanelContext.tsx
-  - ui/src/hooks/useChatConversations.ts
-  - ui/src/hooks/useChatMessages.ts
-  - ui/src/components/ChatPanel.tsx
-  - ui/src/components/ChatConversationList.tsx
-  - ui/src/components/ChatMessageList.tsx
-  - ui/src/components/Layout.tsx
-  - ui/src/main.tsx
-autonomous: true
-requirements:
-  - CHAT-04
-  - CHAT-05
-  - CHAT-06
-  - HIST-02
-  - HIST-03
-
-must_haves:
-  truths:
-    - "User can see a chat icon in the layout that toggles a right-side panel"
-    - "User can create a new conversation and see it in the sidebar list"
-    - "User can type a message, send it, and see it appear in the message list"
-    - "Conversation list is sorted by most recent, loads more via infinite scroll"
-    - "Opening chat panel closes the PropertiesPanel"
-    - "Chat panel open state persists in localStorage across page loads"
-  artifacts:
-    - path: "ui/src/api/chat.ts"
-      provides: "chatApi fetch wrappers for all endpoints"
-      exports: ["chatApi"]
-    - path: "ui/src/context/ChatPanelContext.tsx"
-      provides: "ChatPanelProvider with open/close state and active conversation"
-      exports: ["ChatPanelProvider", "useChatPanel"]
-    - path: "ui/src/hooks/useChatConversations.ts"
-      provides: "TanStack Query useInfiniteQuery wrapper for conversations"
-      exports: ["useChatConversations"]
-    - path: "ui/src/hooks/useChatMessages.ts"
-      provides: "TanStack Query wrapper for messages"
-      exports: ["useChatMessages"]
-    - path: "ui/src/components/ChatPanel.tsx"
-      provides: "Right-side drawer shell with conversation list and message area"
-      contains: "role=\"complementary\""
-    - path: "ui/src/components/ChatConversationList.tsx"
-      provides: "Sidebar conversation list with infinite scroll, pin/archive/delete actions"
-      contains: "IntersectionObserver"
-    - path: "ui/src/components/ChatMessageList.tsx"
-      provides: "Message thread rendering user and assistant messages"
-      contains: "role=\"log\""
-  key_links:
-    - from: "ui/src/components/ChatPanel.tsx"
-      to: "ui/src/api/chat.ts"
-      via: "useChatConversations and useChatMessages hooks"
-      pattern: "useChatConversations|useChatMessages"
-    - from: "ui/src/components/Layout.tsx"
-      to: "ui/src/components/ChatPanel.tsx"
-      via: "ChatPanel rendered in flex row, toggle via ChatPanelContext"
-      pattern: "<ChatPanel"
-    - from: "ui/src/components/Layout.tsx"
-      to: "ui/src/context/ChatPanelContext.tsx"
-      via: "useChatPanel to close PropertiesPanel when chat opens"
-      pattern: "useChatPanel"
-    - from: "ui/src/components/ChatConversationList.tsx"
-      to: "ui/src/hooks/useChatConversations.ts"
-      via: "useInfiniteQuery for paginated conversation list"
-      pattern: "useChatConversations"
----
-
-<objective>
-Wire the chat UI together: API client, panel context, TanStack Query hooks, conversation list with infinite scroll, message list, and the chat panel drawer integrated into the Layout.
-
-Purpose: This plan connects the backend (Plan 01) and presentational components (Plan 02) into a working end-to-end chat experience where users can create conversations, send messages, and browse history.
-Output: A fully functional chat panel accessible from the Layout, with conversation CRUD and message display.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/phases/21-chat-foundation/21-RESEARCH.md
-@.planning/phases/21-chat-foundation/21-UI-SPEC.md
-@.planning/phases/21-chat-foundation/21-01-SUMMARY.md
-@.planning/phases/21-chat-foundation/21-02-SUMMARY.md
-
-<interfaces>
-<!-- From Plan 01 outputs -->
-From packages/shared/src/types/chat.ts:
-```typescript
-export interface ChatConversation {
-  id: string;
-  companyId: string;
-  title: string | null;
-  agentId: string | null;
-  pinnedAt: string | null;
-  archivedAt: string | null;
-  deletedAt: string | null;
-  createdAt: string;
-  updatedAt: string;
-}
-
-export interface ChatMessage {
-  id: string;
-  conversationId: string;
-  role: "user" | "assistant" | "system";
-  content: string;
-  agentId: string | null;
-  createdAt: string;
-}
-
-export interface ChatConversationListResponse {
-  items: ChatConversation[];
-  hasMore: boolean;
-}
-```
-
-API endpoints (from Plan 01):
-- GET /api/companies/:companyId/conversations?cursor=&limit=
-- POST /api/companies/:companyId/conversations
-- GET /api/conversations/:id
-- PATCH /api/conversations/:id
-- DELETE /api/conversations/:id
-- POST /api/conversations/:id/archive
-- POST /api/conversations/:id/unarchive
-- POST /api/conversations/:id/pin
-- POST /api/conversations/:id/unpin
-- GET /api/conversations/:id/messages?cursor=&limit=
-- POST /api/conversations/:id/messages
-
-<!-- From Plan 02 outputs -->
-From ui/src/components/ChatMarkdownMessage.tsx:
-```typescript
-export function ChatMarkdownMessage({ content, className }: { content: string; className?: string })
-```
-
-From ui/src/components/ChatInput.tsx:
-```typescript
-export function ChatInput({ onSend, onClose, isSubmitting, className }: {
-  onSend: (content: string) => void;
-  onClose?: () => void;
-  isSubmitting?: boolean;
-  className?: string;
-})
-```
-
-<!-- Existing codebase interfaces -->
-From ui/src/api/client.ts:
-```typescript
-// api is an axios-like client or fetch wrapper — used as api.get("/path"), api.post("/path", body)
-```
-
-From ui/src/context/PanelContext.tsx:
-```typescript
-export function usePanel(): {
-  panelVisible: boolean;
-  setPanelVisible: (visible: boolean) => void;
-  togglePanelVisible: () => void;
-  // ...
-}
-```
-
-From ui/src/context/CompanyContext.tsx:
-```typescript
-export function useCompany(): {
-  selectedCompanyId: string | null;
-  // ...
-}
-```
-
-From ui/src/components/Layout.tsx (line 416):
-```tsx
-<div className={cn(isMobile ? "block" : "flex flex-1 min-h-0")}>
-  <main id="main-content" ...>
-    <Outlet />
-  </main>
-  <PropertiesPanel />
-</div>
-```
-</interfaces>
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Chat API client, context provider, and TanStack Query hooks</name>
-  <files>
-    ui/src/api/chat.ts,
-    ui/src/context/ChatPanelContext.tsx,
-    ui/src/hooks/useChatConversations.ts,
-    ui/src/hooks/useChatMessages.ts,
-    ui/src/main.tsx
-  </files>
-  <read_first>
-    ui/src/api/activity.ts,
-    ui/src/api/client.ts,
-    ui/src/context/PanelContext.tsx,
-    ui/src/context/CompanyContext.tsx,
-    ui/src/hooks/useKeyboardShortcuts.ts,
-    ui/src/main.tsx
-  </read_first>
-  <action>
-    1. Create `ui/src/api/chat.ts` following the pattern from `ui/src/api/activity.ts`:
-       ```typescript
-       import type { ChatConversation, ChatConversationListResponse, ChatMessage } from "@paperclipai/shared";
-       import { api } from "./client";
-
-       export const chatApi = {
-         listConversations: (companyId: string, opts?: { cursor?: string; limit?: number }) => {
-           const params = new URLSearchParams();
-           if (opts?.cursor) params.set("cursor", opts.cursor);
-           if (opts?.limit) params.set("limit", String(opts.limit));
-           const qs = params.toString();
-           return api.get<ChatConversationListResponse>(`/api/companies/${companyId}/conversations${qs ? `?${qs}` : ""}`);
-         },
-         createConversation: (companyId: string, data?: { title?: string }) =>
-           api.post<ChatConversation>(`/api/companies/${companyId}/conversations`, data ?? {}),
-         getConversation: (id: string) =>
-           api.get<ChatConversation>(`/api/conversations/${id}`),
-         updateConversation: (id: string, data: { title?: string }) =>
-           api.patch<ChatConversation>(`/api/conversations/${id}`, data),
-         deleteConversation: (id: string) =>
-           api.delete(`/api/conversations/${id}`),
-         archiveConversation: (id: string) =>
-           api.post<ChatConversation>(`/api/conversations/${id}/archive`),
-         unarchiveConversation: (id: string) =>
-           api.post<ChatConversation>(`/api/conversations/${id}/unarchive`),
-         pinConversation: (id: string) =>
-           api.post<ChatConversation>(`/api/conversations/${id}/pin`),
-         unpinConversation: (id: string) =>
-           api.post<ChatConversation>(`/api/conversations/${id}/unpin`),
-         listMessages: (conversationId: string, opts?: { cursor?: string; limit?: number }) => {
-           const params = new URLSearchParams();
-           if (opts?.cursor) params.set("cursor", opts.cursor);
-           if (opts?.limit) params.set("limit", String(opts.limit));
-           const qs = params.toString();
-           return api.get<{ items: ChatMessage[]; hasMore: boolean }>(`/api/conversations/${conversationId}/messages${qs ? `?${qs}` : ""}`);
-         },
-         sendMessage: (conversationId: string, data: { role: string; content: string; agentId?: string | null }) =>
-           api.post<ChatMessage>(`/api/conversations/${conversationId}/messages`, data),
-       };
-       ```
-
-    2. Create `ui/src/context/ChatPanelContext.tsx` following the `PanelContext.tsx` localStorage pattern:
-       ```typescript
-       import { createContext, useCallback, useContext, useState, type ReactNode } from "react";
-
-       const STORAGE_KEY = "nexus:chat-panel-open";
-
-       interface ChatPanelContextValue {
-         chatOpen: boolean;
-         setChatOpen: (open: boolean) => void;
-         toggleChat: () => void;
-         activeConversationId: string | null;
-         setActiveConversationId: (id: string | null) => void;
-       }
-
-       const ChatPanelContext = createContext<ChatPanelContextValue | null>(null);
-
-       function readPreference(): boolean {
-         try {
-           const raw = localStorage.getItem(STORAGE_KEY);
-           return raw === "true";
-         } catch {
-           return false;
-         }
-       }
-
-       function writePreference(open: boolean) {
-         try {
-           localStorage.setItem(STORAGE_KEY, String(open));
-         } catch { /* ignore */ }
-       }
-
-       export function ChatPanelProvider({ children }: { children: ReactNode }) {
-         const [chatOpen, setChatOpenState] = useState(readPreference);
-         const [activeConversationId, setActiveConversationId] = useState<string | null>(null);
-
-         const setChatOpen = useCallback((open: boolean) => {
-           setChatOpenState(open);
-           writePreference(open);
-         }, []);
-
-         const toggleChat = useCallback(() => {
-           setChatOpenState((prev) => {
-             const next = !prev;
-             writePreference(next);
-             return next;
-           });
-         }, []);
-
-         return (
-           <ChatPanelContext.Provider
-             value={{ chatOpen, setChatOpen, toggleChat, activeConversationId, setActiveConversationId }}
-           >
-             {children}
-           </ChatPanelContext.Provider>
-         );
-       }
-
-       export function useChatPanel() {
-         const ctx = useContext(ChatPanelContext);
-         if (!ctx) throw new Error("useChatPanel must be used within ChatPanelProvider");
-         return ctx;
-       }
-       ```
-
-    3. Create `ui/src/hooks/useChatConversations.ts`:
-       ```typescript
-       import { useInfiniteQuery, useMutation, useQueryClient } from "@tanstack/react-query";
-       import { chatApi } from "../api/chat";
-
-       export function useChatConversations(companyId: string | null) {
-         return useInfiniteQuery({
-           queryKey: ["chat", "conversations", companyId],
-           queryFn: ({ pageParam }) =>
-             chatApi.listConversations(companyId!, { cursor: pageParam as string | undefined }),
-           initialPageParam: undefined as string | undefined,
-           getNextPageParam: (lastPage) =>
-             lastPage.hasMore ? lastPage.items.at(-1)?.updatedAt : undefined,
-           enabled: !!companyId,
-         });
-       }
-
-       export function useCreateConversation(companyId: string | null) {
-         const queryClient = useQueryClient();
-         return useMutation({
-           mutationFn: (data?: { title?: string }) =>
-             chatApi.createConversation(companyId!, data),
-           onSuccess: () => {
-             queryClient.invalidateQueries({ queryKey: ["chat", "conversations", companyId] });
-           },
-         });
-       }
-
-       export function useConversationActions() {
-         const queryClient = useQueryClient();
-         return {
-           pin: useMutation({
-             mutationFn: chatApi.pinConversation,
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-           unpin: useMutation({
-             mutationFn: chatApi.unpinConversation,
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-           archive: useMutation({
-             mutationFn: chatApi.archiveConversation,
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-           unarchive: useMutation({
-             mutationFn: chatApi.unarchiveConversation,
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-           remove: useMutation({
-             mutationFn: chatApi.deleteConversation,
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-           rename: useMutation({
-             mutationFn: ({ id, title }: { id: string; title: string }) =>
-               chatApi.updateConversation(id, { title }),
-             onSuccess: () => queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] }),
-           }),
-         };
-       }
-       ```
-
-    4. Create `ui/src/hooks/useChatMessages.ts`:
-       ```typescript
-       import { useInfiniteQuery, useMutation, useQueryClient } from "@tanstack/react-query";
-       import { chatApi } from "../api/chat";
-
-       export function useChatMessages(conversationId: string | null) {
-         return useInfiniteQuery({
-           queryKey: ["chat", "messages", conversationId],
-           queryFn: ({ pageParam }) =>
-             chatApi.listMessages(conversationId!, { cursor: pageParam as string | undefined }),
-           initialPageParam: undefined as string | undefined,
-           getNextPageParam: (lastPage) =>
-             lastPage.hasMore ? lastPage.items.at(-1)?.createdAt : undefined,
-           enabled: !!conversationId,
-         });
-       }
-
-       export function useSendMessage(conversationId: string | null) {
-         const queryClient = useQueryClient();
-         return useMutation({
-           mutationFn: (content: string) =>
-             chatApi.sendMessage(conversationId!, { role: "user", content }),
-           onSuccess: () => {
-             queryClient.invalidateQueries({ queryKey: ["chat", "messages", conversationId] });
-             queryClient.invalidateQueries({ queryKey: ["chat", "conversations"] });
-           },
-         });
-       }
-       ```
-
-    5. Add `ChatPanelProvider` to `ui/src/main.tsx`: wrap the app tree with `<ChatPanelProvider>` as a sibling of the existing providers. Import from `"./context/ChatPanelContext"`. Place it INSIDE the existing `<QueryClientProvider>` but outside `<RouterProvider>` (or at the same level as other context providers).
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && grep -c "chatApi" ui/src/api/chat.ts && grep -c "useChatPanel" ui/src/context/ChatPanelContext.tsx && grep -c "ChatPanelProvider" ui/src/main.tsx</automated>
-  </verify>
-  <acceptance_criteria>
-    - ui/src/api/chat.ts exports `chatApi` with methods: listConversations, createConversation, getConversation, updateConversation, deleteConversation, archiveConversation, unarchiveConversation, pinConversation, unpinConversation, listMessages, sendMessage
-    - ui/src/context/ChatPanelContext.tsx contains `localStorage.getItem(STORAGE_KEY)` with `STORAGE_KEY = "nexus:chat-panel-open"`
-    - ui/src/context/ChatPanelContext.tsx exports `ChatPanelProvider` and `useChatPanel`
-    - ui/src/hooks/useChatConversations.ts contains `useInfiniteQuery` and `getNextPageParam`
-    - ui/src/hooks/useChatMessages.ts contains `useInfiniteQuery`
-    - ui/src/main.tsx contains `ChatPanelProvider`
-  </acceptance_criteria>
-  <done>Chat API client, context, and hooks are wired. ChatPanelProvider is in the app tree.</done>
-</task>
-
-<task type="auto">
-  <name>Task 2: ChatPanel, ChatConversationList, ChatMessageList, and Layout integration</name>
-  <files>
-    ui/src/components/ChatPanel.tsx,
-    ui/src/components/ChatConversationList.tsx,
-    ui/src/components/ChatMessageList.tsx,
-    ui/src/components/Layout.tsx
-  </files>
-  <read_first>
-    ui/src/components/Layout.tsx,
-    ui/src/components/PropertiesPanel.tsx,
-    ui/src/context/PanelContext.tsx,
-    ui/src/context/ChatPanelContext.tsx,
-    ui/src/context/CompanyContext.tsx,
-    ui/src/hooks/useChatConversations.ts,
-    ui/src/hooks/useChatMessages.ts,
-    ui/src/components/ChatMarkdownMessage.tsx,
-    ui/src/components/ChatInput.tsx,
-    ui/src/api/chat.ts,
-    ui/src/components/ui/skeleton.tsx,
-    ui/src/components/ui/dropdown-menu.tsx,
-    ui/src/components/ui/scroll-area.tsx,
-    ui/src/components/ui/tooltip.tsx
-  </read_first>
-  <action>
-    1. Create `ui/src/components/ChatConversationList.tsx`:
-       A sidebar list of conversations with infinite scroll, inline actions, and inline rename.
-
-       Props: `{ companyId: string; activeId: string | null; onSelect: (id: string) => void; onNew: () => void }`
-
-       Implementation details:
-       - Uses `useChatConversations(companyId)` for paginated data
-       - Uses `useConversationActions()` for pin/archive/delete/rename mutations
-       - Renders `<nav aria-label="Conversations">` containing a scrollable `<ScrollArea>` with list items
-       - Each item: 48px height, `py-3 px-3` padding, `text-[13px]` title (truncated), `text-xs text-muted-foreground` timestamp right-aligned
-       - Active item: `border-l-2 border-primary bg-sidebar-accent`
-       - Hover: `bg-sidebar-accent/50` with a `<DropdownMenu>` trigger (MoreHorizontal icon) appearing on hover
-       - DropdownMenu items: "Rename conversation", "Pin/Unpin conversation", "Archive/Unarchive conversation", "Delete conversation" (text-destructive)
-       - Delete uses inline confirmation: when delete is clicked, replace the dropdown with a small popover showing "Delete this conversation?" with "Delete conversation" (variant="destructive") and "Keep conversation" (variant="ghost") buttons
-       - Inline rename: double-click title or "Rename" from dropdown swaps title text with an `<input>` at 13px font, Enter/blur confirms, Escape cancels
-       - Pinned conversations show filled Pin icon (14px, text-primary)
-       - Infinite scroll: sentinel `<div ref={sentinelRef}>` at bottom, `IntersectionObserver` triggers `fetchNextPage()` when visible. While loading next page, show 2 `<Skeleton className="h-12 mx-3 my-1">` items
-       - Loading state (initial): show 3 `<Skeleton>` items with `aria-busy="true"` on list container
-       - Empty state: centered text "No conversations yet" (text-sm text-muted-foreground), "Start a conversation to get help with your work." body, "New conversation" button
-       - Header: "Chat" title (text-base font-semibold), Plus icon button (tooltip "New conversation"), X icon button (close)
-
-    2. Create `ui/src/components/ChatMessageList.tsx`:
-       Message thread for a single conversation.
-
-       Props: `{ conversationId: string }`
-
-       Implementation details:
-       - Uses `useChatMessages(conversationId)` for data
-       - Container: `<div role="log" aria-live="polite">` with `p-4 gap-4 flex flex-col`
-       - User messages: right-aligned (`ml-auto`), `bg-secondary text-secondary-foreground`, `max-w-[75%]`, `px-4 py-2`, plain text (no markdown)
-       - Assistant messages: left-aligned, no background, `max-w-[85%]`, rendered via `<ChatMarkdownMessage content={msg.content} />`
-       - Timestamps: `text-xs text-muted-foreground`, visible on hover (`opacity-0 group-hover:opacity-100 transition-opacity`)
-       - Auto-scroll to bottom when new messages arrive: `useEffect` with `scrollIntoView({ behavior: "smooth" })` on a bottom sentinel ref
-       - Loading: single `<Skeleton>` block
-       - Empty (no messages yet): light prompt text "Send a message to start the conversation."
-
-    3. Create `ui/src/components/ChatPanel.tsx`:
-       The main right-side drawer shell that composes ChatConversationList, ChatMessageList, and ChatInput.
-
-       Implementation details:
-       - Uses `useChatPanel()` for open/close state and activeConversationId
-       - Uses `useCompany()` for selectedCompanyId
-       - Uses `useCreateConversation(companyId)` for creating new conversations
-       - Uses `useSendMessage(activeConversationId)` for sending messages
-       - Outer div: `role="complementary" aria-label="Chat"`, width transition `transition-[width] duration-100 ease-out`, width: `chatOpen ? 380 : 0`, `overflow-hidden`, `border-l border-border`, `flex-shrink-0`
-       - Internal layout when open: flex column, full height
-         - Top: header bar (48px, `border-b border-border`, "Chat" heading, plus button, close button)
-         - Middle: split horizontally — left side is `ChatConversationList` (240px wide, `bg-sidebar`, `border-r border-border`), right side is `ChatMessageList` (flex-1)
-         - When no activeConversationId: show conversation list full-width and empty state
-         - When activeConversationId set: show conversation list (240px) + message area
-         - Bottom: `ChatInput` with `onSend` that calls `sendMessage.mutateAsync(content)`, `onClose` that calls `setChatOpen(false)`, `isSubmitting` bound to `sendMessage.isPending`
-       - On "New conversation": call `createConversation.mutateAsync()`, set activeConversationId to the returned id, focus the ChatInput textarea
-       - Focus management: when panel opens, focus ChatInput. When new conversation created, focus ChatInput.
-
-    4. Modify `ui/src/components/Layout.tsx`:
-       - Add import: `import { ChatPanel } from "./ChatPanel";`
-       - Add import: `import { useChatPanel } from "../context/ChatPanelContext";`
-       - Add import: `import { MessageSquare } from "lucide-react";`
-       - In the `Layout()` function body, add: `const { chatOpen, toggleChat, setChatOpen } = useChatPanel();`
-       - Add effect: when `chatOpen` becomes true, call `setPanelVisible(false)` to close PropertiesPanel. This prevents both panels from competing for space.
-       - In the flex row at line 416 (`<div className={cn(isMobile ? "block" : "flex flex-1 min-h-0")}>`), AFTER `<PropertiesPanel />` (line 434), add `<ChatPanel />`.
-       - Add a chat toggle button in the top-right area of the layout (near the theme toggle button, around line 290-310). Use: `<Tooltip><TooltipTrigger asChild><Button variant="ghost" size="icon" onClick={toggleChat} aria-label={chatOpen ? "Close chat" : "Open chat"}><MessageSquare className="h-4 w-4" /></Button></TooltipTrigger><TooltipContent>{chatOpen ? "Close chat" : "Open chat"}</TooltipContent></Tooltip>`
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && grep -c "ChatPanel" ui/src/components/Layout.tsx && grep -c "role=\"complementary\"" ui/src/components/ChatPanel.tsx && grep -c "IntersectionObserver" ui/src/components/ChatConversationList.tsx && grep -c "role=\"log\"" ui/src/components/ChatMessageList.tsx</automated>
-  </verify>
-  <acceptance_criteria>
-    - ui/src/components/ChatPanel.tsx contains `role="complementary"` and `aria-label="Chat"`
-    - ui/src/components/ChatPanel.tsx contains `transition-[width] duration-100 ease-out`
-    - ui/src/components/ChatPanel.tsx contains `chatOpen ? 380 : 0`
-    - ui/src/components/ChatConversationList.tsx contains `<nav aria-label="Conversations"`
-    - ui/src/components/ChatConversationList.tsx contains `IntersectionObserver`
-    - ui/src/components/ChatConversationList.tsx contains `border-l-2 border-primary` for active state
-    - ui/src/components/ChatConversationList.tsx contains `"Delete this conversation?"` confirmation text
-    - ui/src/components/ChatConversationList.tsx contains `"No conversations yet"` empty state
-    - ui/src/components/ChatMessageList.tsx contains `role="log"` and `aria-live="polite"`
-    - ui/src/components/ChatMessageList.tsx contains `ChatMarkdownMessage`
-    - ui/src/components/Layout.tsx contains `import { ChatPanel }` and `<ChatPanel />`
-    - ui/src/components/Layout.tsx contains `useChatPanel`
-    - ui/src/components/Layout.tsx contains `MessageSquare`
-    - ui/src/components/Layout.tsx contains `setPanelVisible(false)` when chat opens
-  </acceptance_criteria>
-  <done>Chat panel is visible in Layout, conversation list shows with infinite scroll, messages render with markdown, input sends messages. Opening chat closes PropertiesPanel.</done>
-</task>
-
-</tasks>
-
-<verification>
-- App compiles without errors: `cd /Volumes/UsbNvme/repos/nexus && pnpm --filter @paperclipai/ui build` succeeds
-- ChatPanel renders in Layout with width transition
-- ChatConversationList uses IntersectionObserver for infinite scroll
-- ChatMessageList renders messages with ChatMarkdownMessage
-- Full test suite still passes: `pnpm test:run`
-</verification>
-
-<success_criteria>
-- User can open/close chat panel via MessageSquare button in Layout
-- User can create a new conversation via the plus button
-- User can send a message and see it in the message list
-- Conversation list shows sorted by most recent with infinite scroll
-- Pin/archive/delete/rename work from dropdown menu
-- Opening chat closes PropertiesPanel
-- Panel state persists in localStorage
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/21-chat-foundation/21-03-SUMMARY.md`
-</output>

.planning/phases/21-chat-foundation/21-03-SUMMARY.md

@@ -1,138 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 03
-subsystem: ui
-tags: [react, tanstack-query, infinite-scroll, chat, intersection-observer, context]
-
-# Dependency graph
-requires:
-  - phase: 21-chat-foundation/21-01
-    provides: Chat API backend (conversations, messages endpoints), shared ChatConversation/ChatMessage types
-  - phase: 21-chat-foundation/21-02
-    provides: ChatMarkdownMessage and ChatInput presentational components
-provides:
-  - chatApi fetch wrappers for all chat endpoints
-  - ChatPanelProvider with localStorage-persisted open state and active conversation tracking
-  - useChatConversations (useInfiniteQuery with cursor pagination)
-  - useChatMessages (useInfiniteQuery with cursor pagination)
-  - useSendMessage and useCreateConversation mutations
-  - ChatConversationList with infinite scroll, inline rename/delete confirmation, pin/archive actions
-  - ChatMessageList with role=log, auto-scroll, ChatMarkdownMessage for assistant messages
-  - ChatPanel right-side drawer composing conversation list + message area (width transition)
-  - Layout integration: MessageSquare toggle, ChatPanel in flex row, effect closing PropertiesPanel when chat opens
-affects: [21-chat-foundation/21-04]
-
-# Tech tracking
-tech-stack:
-  added: []
-  patterns:
-    - useInfiniteQuery with cursor-based pagination (updatedAt/createdAt as cursor)
-    - ChatPanelProvider pattern mirrors PanelContext with localStorage persistence
-    - IntersectionObserver sentinel div for infinite scroll trigger
-    - Inline delete confirmation (no modal) via conditional render in list item hover state
-    - DOM querySelector for focus management across component boundaries
-
-key-files:
-  created:
-    - ui/src/api/chat.ts
-    - ui/src/context/ChatPanelContext.tsx
-    - ui/src/hooks/useChatConversations.ts
-    - ui/src/hooks/useChatMessages.ts
-    - ui/src/components/ChatPanel.tsx
-    - ui/src/components/ChatConversationList.tsx
-    - ui/src/components/ChatMessageList.tsx
-  modified:
-    - ui/src/main.tsx
-    - ui/src/components/Layout.tsx
-
-key-decisions:
-  - "mutateAsync(undefined) required for optional-arg mutations in TanStack Query TypeScript — fixed TS2554 error"
-  - "Focus management uses DOM querySelector('[aria-label=Message input]') across component boundaries to avoid ref threading"
-
-patterns-established:
-  - "IntersectionObserver sentinel at bottom of scroll list triggers fetchNextPage for infinite scroll"
-  - "Inline delete confirmation replaces dropdown with confirmation widget on hover — no modal needed"
-
-requirements-completed: [CHAT-04, CHAT-05, CHAT-06, HIST-02, HIST-03]
-
-# Metrics
-duration: 5min
-completed: 2026-04-01
----
-
-# Phase 21 Plan 03: Chat Foundation Wire-Up Summary
-
-**Chat UI wired end-to-end: API client, TanStack Query hooks with cursor pagination, ChatPanel drawer with conversation list (infinite scroll + CRUD) and message rendering integrated into Layout**
-
-## Performance
-
-- **Duration:** 5 min
-- **Started:** 2026-04-01T11:07:28Z
-- **Completed:** 2026-04-01T11:12:11Z
-- **Tasks:** 2
-- **Files modified:** 9
-
-## Accomplishments
-- Created `chatApi` covering all 11 chat endpoints (conversations + messages CRUD, pin/archive)
-- Built `ChatPanelContext` with localStorage persistence (`nexus:chat-panel-open`) and active conversation tracking
-- Implemented `useChatConversations` and `useChatMessages` with `useInfiniteQuery` cursor pagination plus full mutation hooks
-- Built `ChatConversationList` with IntersectionObserver infinite scroll, inline rename, delete confirmation widget, and pin/archive dropdown
-- Built `ChatMessageList` with `role="log"` aria semantics, auto-scroll, user/assistant message styling, ChatMarkdownMessage for assistant
-- Created `ChatPanel` drawer (width transition 0↔380px) composing both lists with `ChatInput`
-- Integrated into `Layout.tsx`: MessageSquare toggle button, ChatPanel in flex row, PropertiesPanel closes when chat opens
-
-## Task Commits
-
-1. **Task 1: Chat API client, context provider, and TanStack Query hooks** - `2a072483` (feat)
-2. **Task 2: ChatPanel, ChatConversationList, ChatMessageList, and Layout integration** - `7868b073` (feat)
-
-**Plan metadata:** _(pending docs commit)_
-
-## Files Created/Modified
-- `ui/src/api/chat.ts` - chatApi with listConversations, createConversation, getConversation, updateConversation, deleteConversation, archiveConversation, unarchiveConversation, pinConversation, unpinConversation, listMessages, sendMessage
-- `ui/src/context/ChatPanelContext.tsx` - ChatPanelProvider with localStorage persistence and active conversation state
-- `ui/src/hooks/useChatConversations.ts` - useChatConversations (useInfiniteQuery), useCreateConversation, useConversationActions (pin/unpin/archive/unarchive/remove/rename)
-- `ui/src/hooks/useChatMessages.ts` - useChatMessages (useInfiniteQuery), useSendMessage
-- `ui/src/components/ChatConversationList.tsx` - Sidebar with IntersectionObserver infinite scroll, inline rename, delete confirmation, pin/archive dropdown
-- `ui/src/components/ChatMessageList.tsx` - role=log message thread with auto-scroll and ChatMarkdownMessage
-- `ui/src/components/ChatPanel.tsx` - Right-side drawer shell composing conversation list and message area
-- `ui/src/main.tsx` - Added ChatPanelProvider to app tree
-- `ui/src/components/Layout.tsx` - MessageSquare toggle, ChatPanel, effect closing PropertiesPanel when chat opens
-
-## Decisions Made
-- `mutateAsync(undefined)` required for TanStack Query optional-arg mutations — TypeScript infers at least one argument needed and calling with zero causes TS2554 error
-- Focus management uses `document.querySelector('[aria-label="Message input"]')` to reach ChatInput textarea across component tree without ref threading
-
-## Deviations from Plan
-
-### Auto-fixed Issues
-
-**1. [Rule 1 - Bug] Fixed TypeScript TS2554 for zero-arg mutateAsync calls**
-- **Found during:** Task 2 (ChatPanel), build verification
-- **Issue:** `createConversation.mutateAsync()` called with 0 args — TanStack Query typing requires at least 1 argument even when mutationFn has optional params
-- **Fix:** Changed both call sites to `createConversation.mutateAsync(undefined)`
-- **Files modified:** ui/src/components/ChatPanel.tsx
-- **Verification:** `pnpm --filter @paperclipai/ui build` succeeds with no TypeScript errors
-- **Committed in:** `7868b073` (Task 2 commit)
-
----
-
-**Total deviations:** 1 auto-fixed (1 bug)
-**Impact on plan:** Minimal — single TypeScript fix required for correct compilation. No scope creep.
-
-## Issues Encountered
-None beyond the TypeScript fix documented above.
-
-## User Setup Required
-None - no external service configuration required.
-
-## Next Phase Readiness
-- Chat UI is fully wired and functional end-to-end
-- Users can create conversations, send messages, browse history with infinite scroll
-- Opening chat closes PropertiesPanel — no competing panels
-- Panel state persists in localStorage across page loads
-- Plan 04 (if any) can build on the established chat foundation
-
----
-*Phase: 21-chat-foundation*
-*Completed: 2026-04-01*

.planning/phases/21-chat-foundation/21-04-PLAN.md

@@ -1,132 +0,0 @@
----
-phase: 21-chat-foundation
-plan: 04
-type: execute
-wave: 3
-depends_on: ["21-03"]
-files_modified: []
-autonomous: false
-requirements:
-  - CHAT-02
-  - CHAT-03
-  - CHAT-04
-  - CHAT-05
-  - CHAT-06
-  - INPUT-01
-  - INPUT-07
-  - HIST-01
-  - HIST-02
-  - HIST-03
-  - HIST-05
-  - HIST-06
-  - THEME-01
-  - THEME-02
-
-must_haves:
-  truths:
-    - "All phase 21 success criteria verified visually by user"
-  artifacts: []
-  key_links: []
----
-
-<objective>
-Visual and functional verification checkpoint for the complete Phase 21 chat foundation.
-
-Purpose: Confirm the chat interface works end-to-end with correct theme integration, markdown rendering, and persistence before marking the phase complete.
-Output: User approval or list of issues to fix.
-</objective>
-
-<execution_context>
-@$HOME/.claude/get-shit-done/workflows/execute-plan.md
-@$HOME/.claude/get-shit-done/templates/summary.md
-</execution_context>
-
-<context>
-@.planning/PROJECT.md
-@.planning/ROADMAP.md
-@.planning/phases/21-chat-foundation/21-03-SUMMARY.md
-</context>
-
-<tasks>
-
-<task type="auto">
-  <name>Task 1: Run full test suite and generate migration</name>
-  <files></files>
-  <read_first>
-    server/src/__tests__/chat-service.test.ts,
-    server/src/__tests__/chat-routes.test.ts
-  </read_first>
-  <action>
-    1. Run `pnpm db:generate` to generate the migration SQL if not already done. Verify generated SQL file exists under `packages/db/src/migrations/` and contains `CREATE TABLE "chat_conversations"` and `CREATE TABLE "chat_messages"` with `ON DELETE CASCADE`.
-
-    2. Run the full test suite: `pnpm test:run`
-       All tests must pass, including the new chat-service and chat-routes tests.
-
-    3. Run `pnpm --filter @paperclipai/ui build` to verify the UI compiles cleanly with all new components.
-
-    4. If the dev server is not running, start it: `pnpm dev`
-  </action>
-  <verify>
-    <automated>cd /Volumes/UsbNvme/repos/nexus && pnpm test:run && pnpm --filter @paperclipai/ui build</automated>
-  </verify>
-  <acceptance_criteria>
-    - `pnpm test:run` exits 0
-    - `pnpm --filter @paperclipai/ui build` exits 0
-    - Migration SQL file exists in packages/db/src/migrations/ containing "chat_conversations" and "chat_messages"
-  </acceptance_criteria>
-  <done>Full test suite green, UI builds clean, migration SQL generated.</done>
-</task>
-
-<task type="checkpoint:human-verify" gate="blocking">
-  <name>Task 2: Visual and functional verification of chat foundation</name>
-  <files></files>
-  <action>
-    Present the running application to the user for visual verification of all Phase 21 requirements. Ensure the dev server is running at http://localhost:5173 and the database migration has been applied.
-  </action>
-  <verify>User provides "approved" signal</verify>
-  <done>User confirms chat foundation works correctly.</done>
-  <what-built>Complete chat foundation: right-side chat panel with conversation sidebar, markdown message rendering with syntax-highlighted code blocks and copy buttons, auto-resize input with keyboard shortcuts, theme-aware styling across all three themes, and persistent storage in PostgreSQL.</what-built>
-  <how-to-verify>
-    1. Open the app at http://localhost:5173
-    2. Click the chat icon (MessageSquare) in the top-right area of the layout — the chat panel should slide open from the right (380px wide)
-    3. Verify the PropertiesPanel (if visible) closes when chat opens
-    4. Click "New conversation" (Plus icon) — a conversation should appear in the sidebar list
-    5. Type "Hello, this is a test message" and press Enter — the message should appear right-aligned in the message area
-    6. Type a message with markdown: "Here is some **bold** and a code block:\n```typescript\nconst x: number = 42;\nconsole.log(x);\n```" and press Enter
-    7. Verify the code block has:
-       - Syntax highlighting (colored keywords)
-       - A "typescript" language label in the top-left
-       - A copy button in the top-right (click it — should show checkmark for 2 seconds)
-    8. Switch themes: click the theme toggle button. For each theme (Catppuccin Mocha, Tokyo Night, Catppuccin Latte):
-       - Verify the chat panel background matches the theme
-       - Verify code block highlighting colors change with the theme
-       - Verify text is readable and contrast is good
-    9. Test keyboard shortcuts:
-       - Shift+Enter in the input should create a newline (not send)
-       - Enter should send the message
-       - Escape with text in input should clear the input
-       - Escape with empty input should close the chat panel
-    10. Test conversation management: hover over a conversation in the sidebar, click the "..." menu:
-        - Pin the conversation (should show pin icon)
-        - Rename the conversation (should allow inline editing)
-        - Archive the conversation (should disappear from list)
-        - Create another conversation and delete it (should show "Delete this conversation?" confirmation)
-    11. Reload the page — conversations and messages should persist
-    12. Verify auto-resize: type multiple lines in the input — it should grow up to about 6 lines then scroll internally
-  </how-to-verify>
-  <resume-signal>Type "approved" or describe any issues found</resume-signal>
-</task>
-
-</tasks>
-
-<verification>
-Full visual and functional verification by user covering all 14 phase requirements.
-</verification>
-
-<success_criteria>
-User approves the chat foundation as working correctly across all themes with proper markdown rendering, keyboard shortcuts, conversation CRUD, and persistence.
-</success_criteria>
-
-<output>
-After completion, create `.planning/phases/21-chat-foundation/21-04-SUMMARY.md`
-</output>

.planning/phases/21-chat-foundation/21-04-SUMMARY.md

@@ -1,41 +0,0 @@
----
-plan: "21-04"
-phase: "21-chat-foundation"
-status: complete
-started: 2026-04-01T14:05:00Z
-completed: 2026-04-01T14:15:00Z
----
-
-# Plan 21-04: Visual & Functional Verification
-
-## One-Liner
-Full test suite green (917/924 — 6 pre-existing failures), UI builds clean, user visually approved chat foundation across all themes.
-
-## Tasks
-
-| # | Task | Status |
-|---|------|--------|
-| 1 | Run full test suite and build | ✓ Complete |
-| 2 | Visual and functional verification | ✓ Approved by user |
-
-## Results
-
-### Task 1: Automated Verification
-- `pnpm test:run`: 917 passed, 6 failed (pre-existing in skill-registry-routes.test.ts — Phase 09 artifact, not Phase 21)
-- `pnpm --filter @paperclipai/ui build`: Clean build in 6.14s
-- Migration `0047_fixed_johnny_storm.sql`: Contains `CREATE TABLE chat_conversations` and `CREATE TABLE chat_messages` with `ON DELETE CASCADE`
-
-### Task 2: Human Verification
-- User approved all 10 verification items
-- Chat panel, markdown rendering, theme integration, keyboard shortcuts, conversation CRUD, and persistence all verified
-
-## Deviations
-- 6 test failures in `skill-registry-routes.test.ts` are pre-existing from Phase 09, not caused by Phase 21 changes
-
-## Key Files
-- No new files created (verification-only plan)
-
----
-
-*Phase: 21-chat-foundation*
-*Plan completed: 2026-04-01*

.planning/phases/21-chat-foundation/21-CONTEXT.md

@@ -1,41 +0,0 @@
-# Phase 21: Chat Foundation - Context
-
-**Gathered:** 2026-04-01
-**Status:** Ready for planning
-**Mode:** Auto-generated (discuss skipped via workflow.skip_discuss)
-
-<domain>
-## Phase Boundary
-
-A user can open the web app, see a chat interface alongside the board, type a message, and receive a streamed response from an agent — with messages persisted in the database and visible on reload
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion — discuss phase was skipped per user setting. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-</decisions>
-
-<code_context>
-## Existing Code Insights
-
-Codebase context will be gathered during plan-phase research.
-
-</code_context>
-
-<specifics>
-## Specific Ideas
-
-No specific requirements — open to standard approaches. Refer to ROADMAP phase description and success criteria.
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-None — discuss phase skipped.
-
-</deferred>

.planning/phases/21-chat-foundation/21-RESEARCH.md

@@ -1,557 +0,0 @@
-# Phase 21: Chat Foundation - Research
-
-**Researched:** 2026-04-01
-**Domain:** Persistent chat UI with markdown rendering, DB schema, and theme-aware code highlighting
-**Confidence:** HIGH
-
-## Summary
-
-Phase 21 establishes the structural foundation for all subsequent chat phases: database tables for conversations and messages, a REST API for CRUD operations on those tables, and the React UI layer (chat drawer + sidebar conversation list + message renderer). It does NOT include agent execution or streaming — those land in Phase 22. The entire phase is UI-plus-persistence: create a conversation, post static messages, render them with full markdown fidelity, and reload without data loss.
-
-The codebase already contains every necessary supporting primitive. The database layer uses Drizzle ORM with PostgreSQL (not libSQL — the PRD used that term loosely; the running system is PostgreSQL 17). The UI already has `MarkdownBody` (`ui/src/components/MarkdownBody.tsx`) using `react-markdown` + `remark-gfm` + `mermaid`, but without syntax highlighting for code blocks — that gap must be closed here (CHAT-02/03). The `PropertiesPanel` / `PanelContext` pattern demonstrates exactly how a right-side drawer should be wired. Theme integration requires no new plumbing; `useTheme()` + `THEME_META` is already the authoritative system.
-
-**Primary recommendation:** Add two new Drizzle schema files (`chat_conversations` + `chat_messages`), generate and run a migration, create service+route files following the existing factory pattern, and add a `ChatPanel` component that re-uses `PanelContext` open/close state (or a new dedicated `ChatPanelContext` keyed to `localStorage`).
-
-<user_constraints>
-## User Constraints (from CONTEXT.md)
-
-### Locked Decisions
-None — discuss phase was skipped per user setting (`workflow.skip_discuss: true`).
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-### Deferred Ideas (OUT OF SCOPE)
-None — discuss phase skipped.
-</user_constraints>
-
-<phase_requirements>
-## Phase Requirements
-
-Per ROADMAP.md (authoritative, overrides the broader CHAT-01..11 list in the task prompt):
-
-| ID | Description | Research Support |
-|----|-------------|------------------|
-| CHAT-02 | Markdown rendering: code blocks with syntax highlighting, tables, lists, headings, links, images | Existing `MarkdownBody` covers most; syntax highlighting needs `rehype-highlight` or `react-syntax-highlighter` added |
-| CHAT-03 | Code blocks: one-click copy button and language label | Custom `pre`/`code` component override in `MarkdownBody` extensions |
-| CHAT-04 | Multiple concurrent conversations: sidebar shows full list | `chat_conversations` table + `/api/companies/:id/conversations` GET endpoint + sidebar React component |
-| CHAT-05 | Conversation titles: auto-generated from first message, manually editable | `title` column on `chat_conversations`; auto-generated server-side on first message insert; PATCH endpoint |
-| CHAT-06 | Delete, archive, pin conversations | `deletedAt`, `archivedAt`, `pinnedAt` nullable timestamps on `chat_conversations` |
-| INPUT-01 | Multi-line input with auto-resize: grows with content up to max height | `<textarea>` with CSS `field-sizing: content` or `rows` auto-expand hook |
-| INPUT-07 | Keyboard shortcuts: Enter to send, Shift+Enter for newline, Escape to cancel | `onKeyDown` handler on textarea |
-| HIST-01 | All conversations persisted in PostgreSQL (codebase uses PG, not libSQL) | Two new Drizzle schema files + migration |
-| HIST-02 | Conversation list in sidebar: sorted by most recent, searchable, filterable by agent | Server-side sort by `updatedAt DESC`; client-side filter/search on loaded list |
-| HIST-03 | Infinite scroll in conversation list sidebar | TanStack Query `useInfiniteQuery` with cursor pagination |
-| HIST-05 | Cross-device sync: conversations accessible from any device on network | Covered by server API — no extra work; Nexus is already a server |
-| HIST-06 | Chat history survives server restarts: no in-memory-only state | Covered by DB persistence; no in-memory chat state |
-| THEME-01 | Chat interface respects Nexus theme system | Reuse `useTheme()` + CSS variables already in `index.css` |
-| THEME-02 | Code blocks use theme-appropriate syntax highlighting | Pass `THEME_META[theme].dark` to syntax highlighter; use Catppuccin/Tokyo Night themes |
-</phase_requirements>
-
----
-
-## Project Constraints (from CLAUDE.md)
-
-| Constraint | Detail |
-|-----------|--------|
-| Upstream sync | Display-layer changes only. DB schema, API routes, code identifiers, token formats must be upstream-compatible. New tables are additive and safe. |
-| No data migration | No changes to existing tables. New tables only — no column changes to existing schema. |
-| Deploy target | Mac Mini M4, `local_trusted` mode, single user |
-| Language | TypeScript (ESM) everywhere. No plain JS. |
-| Package manager | pnpm 9.15.4. Use `pnpm add` — never `npm install`. |
-| Framework | Express 5.1.0 routes must follow `function fooRoutes(db: Db): Router` factory pattern |
-| DB | Drizzle ORM with PostgreSQL. Generate migration with `pnpm db:generate` then commit migration SQL. |
-| Auth | `local_trusted` mode means `assertBoard(req)` is the only auth gate needed |
-| Testing | Vitest (server) + React Testing Library (UI). Service tests use `vi.mock` pattern shown in `activity-routes.test.ts`. |
-
----
-
-## Standard Stack
-
-### Core (already in project, no install needed)
-| Library | Version | Purpose | Notes |
-|---------|---------|---------|-------|
-| `drizzle-orm` | ^0.38.4 | Schema definition + query builder | Use existing pattern from `documents.ts` |
-| `react` | ^19.0.0 | UI component layer | — |
-| `react-markdown` | ^10.1.0 | Already in `ui/package.json` | Basis of `MarkdownBody` |
-| `remark-gfm` | ^4.0.1 | GFM tables/lists/strikethrough | Already used in `MarkdownBody` |
-| `@tanstack/react-query` | ^5.x | Server state, pagination | `useInfiniteQuery` for conversation list |
-| `lucide-react` | ^0.574.0 | Icons (MessageSquare, Pin, Archive, Trash2, Plus, etc.) | — |
-| `tailwind-merge` / `clsx` | current | Conditional classNames | — |
-
-### Additions required
-| Library | Version | Purpose | Install |
-|---------|---------|---------|---------|
-| `rehype-highlight` | 7.0.2 (current) | Syntax highlighting via highlight.js in react-markdown | `pnpm --filter @paperclipai/ui add rehype-highlight highlight.js` |
-| `highlight.js` | — (peer of rehype-highlight) | Highlight.js core — provides Catppuccin/Tokyo Night themes | pulled in by rehype-highlight |
-
-**Why `rehype-highlight` over `react-syntax-highlighter`:**
-- `rehype-highlight` integrates cleanly with `react-markdown` via the `rehypePlugins` prop — no custom component overrides needed per language
-- Highlight.js ships Catppuccin Mocha, Catppuccin Latte, and Tokyo Night CSS themes natively (as of hljs 11.x), avoiding custom CSS
-- Smaller bundle than `react-syntax-highlighter` which bundles Prism + all languages
-- Confidence: HIGH — verified against react-markdown docs and highlight.js theme list
-
-**Alternatives considered:**
-| Instead of | Could use | Tradeoff |
-|-----------|-----------|----------|
-| `rehype-highlight` | `react-syntax-highlighter` | RSH provides per-component control but requires a custom `code` component wrapper; more bundle weight |
-| `rehype-highlight` | `shiki` (via `rehype-shiki`) | Shiki produces beautiful output but is heavier (WASM), more complex config, and overkill for this phase |
-
-**Version verification:**
-```bash
-npm view rehype-highlight version   # 7.0.2
-npm view highlight.js version       # 11.x (pulled as transitive dep)
-npm view react-markdown version     # 10.1.0 (already installed)
-```
-
-**Installation (additions only):**
-```bash
-pnpm --filter @paperclipai/ui add rehype-highlight
-# highlight.js is a dependency of rehype-highlight — comes automatically
-```
-
----
-
-## Architecture Patterns
-
-### Recommended Project Structure (new files only)
-
-```
-packages/db/src/schema/
-├── chat_conversations.ts   # new — conversation records
-└── chat_messages.ts        # new — message records
-
-packages/db/src/migrations/
-└── 0047_chat_foundation.sql  # generated by drizzle-kit generate
-
-packages/shared/src/
-├── types/chat.ts           # new — ChatConversation, ChatMessage types
-└── validators/chat.ts      # new — Zod schemas for create/update
-
-server/src/
-├── services/chat.ts        # new — chatService(db) factory
-└── routes/chat.ts          # new — chatRoutes(db): Router
-
-ui/src/
-├── api/chat.ts             # new — chatApi fetch wrappers
-├── context/ChatPanelContext.tsx  # new — open/closed + active conversation
-├── components/
-│   ├── ChatPanel.tsx        # new — right-side drawer shell
-│   ├── ChatConversationList.tsx  # new — sidebar list with infinite scroll
-│   ├── ChatMessageList.tsx  # new — message thread
-│   ├── ChatInput.tsx        # new — auto-resize textarea
-│   └── ChatMarkdownMessage.tsx   # new — MarkdownBody extended with rehype-highlight
-└── hooks/
-    └── useChatConversations.ts  # new — TanStack Query wrappers
-```
-
-### Pattern 1: Drizzle Schema (follow existing pattern)
-
-```typescript
-// Source: packages/db/src/schema/documents.ts (existing reference)
-// packages/db/src/schema/chat_conversations.ts
-import { pgTable, uuid, text, timestamp, boolean, index } from "drizzle-orm/pg-core";
-import { companies } from "./companies.js";
-import { agents } from "./agents.js";
-
-export const chatConversations = pgTable(
-  "chat_conversations",
-  {
-    id: uuid("id").primaryKey().defaultRandom(),
-    companyId: uuid("company_id").notNull().references(() => companies.id),
-    title: text("title"),
-    agentId: uuid("agent_id").references(() => agents.id, { onDelete: "set null" }),
-    pinnedAt: timestamp("pinned_at", { withTimezone: true }),
-    archivedAt: timestamp("archived_at", { withTimezone: true }),
-    deletedAt: timestamp("deleted_at", { withTimezone: true }),
-    createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-    updatedAt: timestamp("updated_at", { withTimezone: true }).notNull().defaultNow(),
-  },
-  (table) => ({
-    companyUpdatedIdx: index("chat_conversations_company_updated_idx")
-      .on(table.companyId, table.updatedAt),
-    companyDeletedIdx: index("chat_conversations_company_deleted_idx")
-      .on(table.companyId, table.deletedAt),
-  }),
-);
-```
-
-```typescript
-// packages/db/src/schema/chat_messages.ts
-import { pgTable, uuid, text, timestamp, index } from "drizzle-orm/pg-core";
-import { chatConversations } from "./chat_conversations.js";
-
-export const chatMessages = pgTable(
-  "chat_messages",
-  {
-    id: uuid("id").primaryKey().defaultRandom(),
-    conversationId: uuid("conversation_id").notNull()
-      .references(() => chatConversations.id, { onDelete: "cascade" }),
-    role: text("role").notNull(), // "user" | "assistant" | "system"
-    content: text("content").notNull(),
-    agentId: uuid("agent_id"), // which agent produced this (null for user messages)
-    createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-  },
-  (table) => ({
-    conversationCreatedIdx: index("chat_messages_conversation_created_idx")
-      .on(table.conversationId, table.createdAt),
-  }),
-);
-```
-
-**Important:** After creating schema files, export them from `packages/db/src/schema/index.ts` and run:
-```bash
-pnpm db:generate   # generates SQL migration under packages/db/src/migrations/
-pnpm db:migrate    # applies migration to running DB
-```
-
-### Pattern 2: Service Factory (follow existing pattern)
-
-```typescript
-// Source: server/src/services/documents.ts (existing reference)
-// server/src/services/chat.ts
-import type { Db } from "@paperclipai/db";
-import { chatConversations, chatMessages } from "@paperclipai/db";
-import { and, desc, eq, isNull, lt } from "drizzle-orm";
-
-export function chatService(db: Db) {
-  return {
-    async listConversations(companyId: string, opts: { cursor?: string; limit?: number }) {
-      const limit = Math.min(opts.limit ?? 30, 100);
-      const rows = await db
-        .select()
-        .from(chatConversations)
-        .where(
-          and(
-            eq(chatConversations.companyId, companyId),
-            isNull(chatConversations.deletedAt),
-            opts.cursor
-              ? lt(chatConversations.updatedAt, new Date(opts.cursor))
-              : undefined,
-          ),
-        )
-        .orderBy(desc(chatConversations.updatedAt))
-        .limit(limit + 1);
-      const hasMore = rows.length > limit;
-      return { items: rows.slice(0, limit), hasMore };
-    },
-    // createConversation, getConversation, updateConversation, softDeleteConversation,
-    // listMessages, addMessage, etc.
-  };
-}
-```
-
-### Pattern 3: Route Factory (follow existing pattern)
-
-```typescript
-// Source: server/src/routes/activity.ts (existing reference)
-// server/src/routes/chat.ts
-import { Router } from "express";
-import { z } from "zod";
-import type { Db } from "@paperclipai/db";
-import { assertBoard, assertCompanyAccess } from "./authz.js";
-import { chatService } from "../services/chat.js";
-import { validate } from "../middleware/validate.js";
-
-export function chatRoutes(db: Db) {
-  const router = Router();
-  const svc = chatService(db);
-
-  // GET  /api/companies/:companyId/conversations
-  // POST /api/companies/:companyId/conversations
-  // GET  /api/conversations/:id
-  // PATCH /api/conversations/:id
-  // DELETE /api/conversations/:id
-  // GET  /api/conversations/:id/messages
-  // POST /api/conversations/:id/messages
-  return router;
-}
-```
-
-Mount in `server/src/app.ts` following the existing route registration list.
-
-### Pattern 4: Chat Panel Context (localStorage-persisted open state)
-
-```typescript
-// ui/src/context/ChatPanelContext.tsx
-// Mirrors PanelContext.tsx pattern but keyed specifically to chat.
-// Key: "nexus:chat-panel-open" (use nexus: prefix not paperclip: to stay in Nexus scope)
-```
-
-The chat panel is a **separate right-side drawer** from `PropertiesPanel`. They should not share state. The chat icon in `Layout` (or `CompanyRail`) toggles `chatPanelOpen`. The drawer sits between `<main>` and `<PropertiesPanel>` in the flex row, or on top of it as an overlay — implementation choice.
-
-**Recommended:** Fixed-width right drawer (320–400px) inside the existing `flex` row, hidden with `w-0 overflow-hidden` when closed, using the same CSS transition pattern as the sidebar (`transition-[width] duration-100 ease-out`).
-
-### Pattern 5: Infinite Scroll with TanStack Query
-
-```typescript
-// ui/src/hooks/useChatConversations.ts
-import { useInfiniteQuery } from "@tanstack/react-query";
-import { chatApi } from "../api/chat";
-
-export function useChatConversations(companyId: string) {
-  return useInfiniteQuery({
-    queryKey: ["chat", "conversations", companyId],
-    queryFn: ({ pageParam }) =>
-      chatApi.listConversations(companyId, { cursor: pageParam as string | undefined }),
-    getNextPageParam: (lastPage) =>
-      lastPage.hasMore ? lastPage.items.at(-1)?.updatedAt : undefined,
-    initialPageParam: undefined,
-  });
-}
-```
-
-### Pattern 6: Theme-aware Syntax Highlighting
-
-```typescript
-// ui/src/components/ChatMarkdownMessage.tsx
-import Markdown from "react-markdown";
-import remarkGfm from "remark-gfm";
-import rehypeHighlight from "rehype-highlight";
-import { useTheme, THEME_META } from "../context/ThemeContext";
-// Import highlight.js theme CSS dynamically based on active theme:
-// catppuccin-mocha → "highlight.js/styles/base16/catppuccin.css" (dark variant)
-// tokyo-night      → "highlight.js/styles/tokyo-night-dark.css"
-// catppuccin-latte → "highlight.js/styles/base16/catppuccin.css" (light variant)
-```
-
-**Code block copy button pattern:** Override the `pre` component in `react-markdown`'s `components` prop. Extract the code text from the child `<code>` element, wire a `useClipboard`/`navigator.clipboard.writeText` handler.
-
-### Pattern 7: Auto-resize Textarea
-
-```typescript
-// ui/src/components/ChatInput.tsx
-// Modern CSS approach: field-sizing: content (Chrome 123+, Firefox 129+)
-// Fallback: ref.current.style.height = 'auto'; ref.current.style.height = ref.current.scrollHeight + 'px'
-// onKeyDown: e.key === 'Enter' && !e.shiftKey → submit; e.key === 'Escape' → clear
-```
-
-### Anti-Patterns to Avoid
-
-- **Reusing PropertiesPanel for chat:** The `PropertiesPanel` is content-dependent (varies per page). Chat is a persistent global panel. Use a separate context.
-- **Storing conversation open/closed state in URL:** Use `localStorage` (as `PanelContext` does). URL state would cause issues on navigation.
-- **Using `libSQL`/Turso:** The REQUIREMENTS.md says "libSQL" but the codebase runs PostgreSQL. Ignore the libSQL reference — it is a PRD artifact. Use the existing Drizzle/PG stack.
-- **Hand-rolling markdown rendering:** `MarkdownBody` already exists and handles mermaid, GFM, and mention chips. Extend it rather than create a parallel implementation.
-- **Inline `highlight.js` CSS:** Load theme CSS via a dynamic `<link>` or via CSS `@import` conditioned on `.dark` / `.theme-tokyo-night` — do not inline all themes at once.
-
----
-
-## Don't Hand-Roll
-
-| Problem | Don't Build | Use Instead | Why |
-|---------|-------------|-------------|-----|
-| Markdown rendering | Custom parser | `react-markdown` + `remark-gfm` | Already in codebase, battle-tested |
-| Syntax highlighting | Token-by-token highlighter | `rehype-highlight` (highlight.js) | Covers 190+ languages, ships Catppuccin/Tokyo Night themes |
-| Server state / pagination | Custom fetch + cursor state | `useInfiniteQuery` (TanStack Query) | Already used everywhere in the project |
-| Auto-resize textarea | `setInterval` height checks | CSS `field-sizing: content` + scroll height fallback | One-liner with good browser support |
-| Right-side drawer animation | Custom JS animation | CSS `transition-[width]` (same as sidebar) | Already proven in Layout.tsx |
-| Copy to clipboard | Cross-browser clipboard shim | `navigator.clipboard.writeText` | Sufficient for local trusted mode |
-
----
-
-## Common Pitfalls
-
-### Pitfall 1: highlight.js theme CSS loading in Vite
-**What goes wrong:** Importing CSS from `node_modules/highlight.js/styles/` at the module level causes all three themes to load simultaneously, causing visual conflicts.
-**Why it happens:** CSS imports in ESM/Vite are side-effecting; theme CSS from hljs uses global selectors (`.hljs { ... }`).
-**How to avoid:** Use a single CSS file that overrides hljs variables per theme class using your existing CSS variable system (`.dark .hljs { ... }`, `.theme-tokyo-night .hljs { ... }`), OR dynamically insert/swap a `<link>` element when `theme` changes.
-**Warning signs:** Code blocks always show one theme regardless of active theme switch.
-
-### Pitfall 2: `chat_messages` cascade delete gap
-**What goes wrong:** Deleting a conversation (hard delete) leaves orphaned messages.
-**Why it happens:** Forgetting to set `{ onDelete: "cascade" }` on the FK.
-**How to avoid:** Schema above already includes cascade; verify the generated SQL includes `ON DELETE CASCADE` before committing the migration.
-
-### Pitfall 3: `updatedAt` on conversation not bumped on new message
-**What goes wrong:** The conversation list sort by `updatedAt DESC` shows stale ordering after a new message is posted.
-**Why it happens:** Drizzle auto-sets `updatedAt` only on direct row updates, not cascading through FK children.
-**How to avoid:** In `chatService.addMessage()`, also run an `UPDATE chat_conversations SET updated_at = now() WHERE id = $conversationId`.
-
-### Pitfall 4: PropertiesPanel hidden when chat panel is open
-**What goes wrong:** Both panels try to occupy the right side of the layout; one hides the other.
-**Why it happens:** Both are `flex-shrink-0` elements in the same row.
-**How to avoid:** The chat drawer should be a sibling of `PropertiesPanel` in the layout flex row. When the chat panel is open, `PropertiesPanel` should close (or they should coexist with a combined max-width). Decide at plan time — research suggests coexistence adds complexity; close `PropertiesPanel` when chat opens.
-
-### Pitfall 5: Auto-title generation on first message
-**What goes wrong:** Title is set to a truncated version of the first user message, but the update never fires.
-**Why it happens:** The title is set conditionally only when the conversation has no title yet. Race condition if client retries the request.
-**How to avoid:** Use `WHERE title IS NULL` in the UPDATE to make the title set idempotent.
-
-### Pitfall 6: Conversation list flicker on `useInfiniteQuery`
-**What goes wrong:** List flashes empty on first render before data loads.
-**Why it happens:** Default TanStack Query behavior shows `isLoading: true` on mount.
-**How to avoid:** Use `placeholderData: keepPreviousData` or show a skeleton list while loading.
-
----
-
-## Code Examples
-
-### Verified: Route factory pattern
-```typescript
-// Source: server/src/routes/activity.ts (exists in codebase)
-export function activityRoutes(db: Db): Router {
-  const router = Router();
-  const svc = activityService(db);
-  router.get("/companies/:companyId/activity", async (req, res) => {
-    assertBoard(req);
-    assertCompanyAccess(req, req.params.companyId!);
-    const result = await svc.list(req.params.companyId!);
-    res.json(result);
-  });
-  return router;
-}
-```
-
-### Verified: react-markdown + rehype plugin composition
-```typescript
-// Source: MarkdownBody.tsx (extended pattern)
-import rehypeHighlight from "rehype-highlight";
-<Markdown
-  remarkPlugins={[remarkGfm]}
-  rehypePlugins={[rehypeHighlight]}
-  components={components}
->
-  {content}
-</Markdown>
-```
-
-### Verified: Infinite scroll with TanStack Query v5
-```typescript
-// Source: TanStack Query v5 docs — useInfiniteQuery API
-const { data, fetchNextPage, hasNextPage } = useInfiniteQuery({
-  queryKey: ["conversations", companyId],
-  queryFn: ({ pageParam }) => chatApi.listConversations(companyId, { cursor: pageParam }),
-  initialPageParam: undefined as string | undefined,
-  getNextPageParam: (lastPage) =>
-    lastPage.hasMore ? lastPage.items.at(-1)?.updatedAt : undefined,
-});
-```
-
-### Verified: CSS transition pattern for drawer (from Layout.tsx)
-```tsx
-// Same transition as sidebar — proven in production
-<div
-  className="overflow-hidden transition-[width] duration-100 ease-out"
-  style={{ width: chatOpen ? 380 : 0 }}
->
-  {/* panel content — will be hidden via width:0 overflow:hidden */}
-</div>
-```
-
----
-
-## State of the Art
-
-| Old Approach | Current Approach | Impact |
-|--------------|------------------|--------|
-| `react-syntax-highlighter` (Prism) | `rehype-highlight` (hljs) via rehype plugins | Smaller bundle, cleaner react-markdown integration, native theme CSS |
-| Custom infinite scroll with IntersectionObserver | `useInfiniteQuery` with cursor | Less code, built-in refetch/stale handling |
-| CSS modules for code block themes | CSS custom properties per `.dark` class | Theme switch without JS style injection |
-
----
-
-## Environment Availability
-
-| Dependency | Required By | Available | Version | Fallback |
-|------------|-------------|-----------|---------|----------|
-| PostgreSQL (embedded) | DB persistence | Yes (embedded-postgres) | 17-alpine | — |
-| pnpm | Package install | Yes | 9.15.4 | — |
-| Node.js | Runtime | Yes | v25.8.2 | — |
-| `rehype-highlight` | Syntax highlighting | Not installed (needs `pnpm add`) | 7.0.2 | Fallback: unstyled code blocks (degrade gracefully) |
-
-**Missing dependencies with no fallback:**
-- None that block execution
-
-**Missing dependencies that need install:**
-- `rehype-highlight` — install before implementing `ChatMarkdownMessage.tsx`
-
----
-
-## Validation Architecture
-
-### Test Framework
-| Property | Value |
-|----------|-------|
-| Framework | Vitest 3.x |
-| Config file | `server/vitest.config.ts` (server), `vitest.config.ts` (root, multi-project) |
-| Quick run command | `pnpm vitest run server/src/__tests__/chat-service.test.ts` |
-| Full suite command | `pnpm test:run` |
-
-### Phase Requirements → Test Map
-
-| Req ID | Behavior | Test Type | Automated Command | File Exists? |
-|--------|----------|-----------|-------------------|-------------|
-| HIST-01 | Conversations and messages persisted to DB | Unit (service) | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | ❌ Wave 0 |
-| HIST-01 | POST conversation creates DB row; GET returns it | Integration (route) | `pnpm vitest run server/src/__tests__/chat-routes.test.ts` | ❌ Wave 0 |
-| CHAT-04 | List conversations returns all for company, sorted by updatedAt | Unit (service) | above | ❌ Wave 0 |
-| CHAT-05 | First message auto-sets title on conversation | Unit (service) | above | ❌ Wave 0 |
-| CHAT-06 | Soft-delete / archive / pin set correct timestamps | Unit (service) | above | ❌ Wave 0 |
-| CHAT-02/03 | MarkdownBody renders code blocks with syntax highlight | Component (UI) | `pnpm vitest run ui/src/components/ChatMarkdownMessage.test.tsx` | ❌ Wave 0 |
-| INPUT-07 | Enter sends, Shift+Enter inserts newline, Escape clears | Component (UI) | `pnpm vitest run ui/src/components/ChatInput.test.tsx` | ❌ Wave 0 |
-| THEME-01/02 | Theme CSS variables apply to chat panel and code blocks | Manual visual | — | Manual only |
-| HIST-03 | Infinite scroll loads next page on scroll to bottom | Integration (UI) | — | Manual only — requires browser scroll |
-
-### Sampling Rate
-- **Per task commit:** `pnpm vitest run server/src/__tests__/chat-service.test.ts`
-- **Per wave merge:** `pnpm test:run`
-- **Phase gate:** Full suite green before `/gsd:verify-work`
-
-### Wave 0 Gaps
-- [ ] `server/src/__tests__/chat-service.test.ts` — covers HIST-01, CHAT-04, CHAT-05, CHAT-06
-- [ ] `server/src/__tests__/chat-routes.test.ts` — covers route-level integration (POST conversation, GET list, POST message)
-- [ ] `ui/src/components/ChatMarkdownMessage.test.tsx` — covers CHAT-02/03 (code block render + copy button)
-- [ ] `ui/src/components/ChatInput.test.tsx` — covers INPUT-07 keyboard shortcuts
-
----
-
-## Open Questions
-
-1. **Chat panel vs PropertiesPanel coexistence**
-   - What we know: Both are right-side panels in the same flex row in `Layout.tsx`
-   - What's unclear: Should they coexist (both visible side-by-side) or should opening chat close the properties panel?
-   - Recommendation: Close `PropertiesPanel` when chat opens (simpler, avoids cramped UI at default 1280px width)
-
-2. **`chat_conversations.agentId` — required or optional at creation time?**
-   - What we know: Phase 22 adds the agent selector mid-conversation. Phase 21 has no streaming.
-   - What's unclear: Do we need an agent association before streaming exists?
-   - Recommendation: Make `agentId` nullable. Allow conversations to be created without a linked agent. The column is available for Phase 22 to use.
-
-3. **Auto-generated title: server-side or client-side?**
-   - What we know: Client sends the first message; the title should derive from that message's first N characters.
-   - Recommendation: Server-side, in `chatService.addMessage()` — if `conversation.title IS NULL` AND this is the first message, set `title = truncate(content, 60)`. Avoids a client round-trip.
-
----
-
-## Sources
-
-### Primary (HIGH confidence)
-- `ui/src/components/MarkdownBody.tsx` — existing markdown component confirming `react-markdown` + `remark-gfm` usage
-- `ui/src/context/PanelContext.tsx` — panel open/close localStorage pattern
-- `ui/src/components/Layout.tsx` — layout structure, flex row, CSS transition pattern
-- `packages/db/src/schema/documents.ts` — Drizzle schema reference pattern
-- `server/src/routes/activity.ts` — route factory pattern
-- `server/src/services/live-events.ts` — service file pattern
-- `packages/db/src/client.ts` — database client (PostgreSQL, not libSQL)
-- `ui/src/context/ThemeContext.tsx` — Theme type, THEME_META, `useTheme()`
-- `ui/src/index.css` — CSS variable definitions for all three themes
-- `ui/package.json` — confirmed `react-markdown@^10.1.0`, `remark-gfm@^4.0.1` already installed
-
-### Secondary (MEDIUM confidence)
-- `npm view rehype-highlight version` → 7.0.2 (verified at research time, 2026-04-01)
-- TanStack Query v5 `useInfiniteQuery` API (CLAUDE.md confirms `@tanstack/react-query ^5.x`)
-
-### Tertiary (LOW confidence)
-- highlight.js Catppuccin/Tokyo Night theme availability — assumed based on hljs 11.x changelog; verify exact CSS path at install time
-
----
-
-## Metadata
-
-**Confidence breakdown:**
-- Standard stack: HIGH — all existing dependencies verified in source; only one new package (`rehype-highlight`) needed
-- Architecture: HIGH — patterns confirmed by reading existing service/route/context files; direct analogy to existing `documents` domain
-- Pitfalls: MEDIUM — identified from code inspection; cascade delete and updatedAt bump are logic traps not yet observable in running code
-- Theme integration: HIGH — `THEME_META`, ThemeContext, and CSS variables fully examined
-
-**Research date:** 2026-04-01
-**Valid until:** 2026-05-01 (stable ecosystem; `react-markdown` and TanStack Query are very stable)

.planning/phases/21-chat-foundation/21-UI-SPEC.md

@@ -1,287 +0,0 @@
----
-phase: 21
-slug: chat-foundation
-status: draft
-shadcn_initialized: true
-preset: new-york / neutral / cssVariables
-created: 2026-04-01
-revised: 2026-04-01
----
-
-# Phase 21 — UI Design Contract
-
-> Visual and interaction contract for frontend phases. Generated by gsd-ui-researcher, verified by gsd-ui-checker.
-
----
-
-## Design System
-
-| Property | Value |
-|----------|-------|
-| Tool | shadcn (new-york style) |
-| Preset | new-york, baseColor: neutral, cssVariables: true |
-| Component library | Radix UI (via shadcn) |
-| Icon library | lucide-react (^0.574.0) |
-| Font | System UI stack (inherited from existing CSS — no custom font declared) |
-
-Source: `ui/components.json`, `ui/src/index.css`
-
-**shadcn components already installed (usable without install):**
-`Avatar`, `Badge`, `Button`, `Card`, `Checkbox`, `Dialog`, `DropdownMenu`, `Input`, `ScrollArea`, `Separator`, `Sheet`, `Skeleton`, `Tabs`, `Textarea`, `Tooltip`
-
-**New components for this phase (install before use):**
-None required — all necessary primitives are available. `Textarea` covers `ChatInput`, `ScrollArea` covers the message list and conversation list.
-
----
-
-## Focal Point
-
-The primary focal point of this phase is the **chat input** at the bottom of the ChatPanel. When the panel opens, focus moves immediately to the `ChatInput` textarea. All surrounding elements (conversation list, message thread, header) are secondary supporting surfaces.
-
----
-
-## Spacing Scale
-
-Declared values (multiples of 4 only). Source: 8-point scale, confirmed via existing `p-4 md:p-6` usage in `Layout.tsx`.
-
-| Token | Value | Usage |
-|-------|-------|-------|
-| xs | 4px | Icon gaps (`gap-1`), inline icon + label spacing |
-| sm | 8px | Compact padding inside list items (`px-2 py-1`), badge padding |
-| sm+ | 12px | Conversation list item vertical padding (`py-3`) — named exception; follows existing `EntityRow` pattern; sits between sm and md |
-| md | 16px | Default element padding (`p-4`), chat panel header padding |
-| lg | 24px | Section padding on desktop (`p-6`) |
-| xl | 32px | Gap between major UI zones |
-| 2xl | 48px | Empty-state vertical padding (`py-12`) |
-| 3xl | 64px | Page-level section breaks (not applicable in panel context) |
-
-Exceptions:
-- `sm+` (12px) is a named token for conversation list item vertical padding. Justification: follows the existing `EntityRow` pattern throughout the codebase. It is not a one-off magic number — it is a deliberate in-between value that keeps list items readable without wasting vertical space. Only use `sm+` for list item vertical padding.
-- Touch targets on coarse-pointer devices: `min-height: 44px` (already enforced globally in `index.css` `@media (pointer: coarse)`)
-- Chat input bottom padding: `pb-[calc(env(safe-area-inset-bottom)+16px)]` on mobile to clear the home indicator
-
----
-
-## Typography
-
-All sizes use Tailwind utility classes mapped to the project's system-UI font stack. Source: observed usage in `Layout.tsx`, `EmptyState.tsx`, `MarkdownBody.tsx`.
-
-Two weights only: regular (400) and semibold (600). Medium (500) is not used in this phase.
-
-| Role | Size | Weight | Line Height | Tailwind Class |
-|------|------|--------|-------------|----------------|
-| Body | 14px | 400 (regular) | 1.5 | `text-sm` |
-| Label | 13px | 400 (regular) | 1.4 | `text-[13px]` |
-| Heading | 16px | 600 (semibold) | 1.25 | `text-base font-semibold` |
-| Meta / Timestamp | 12px | 400 (regular) | 1.4 | `text-xs text-muted-foreground` |
-
-Rules:
-- Conversation titles in the sidebar use Label (13px / regular). Do not apply `font-medium` or `font-semibold` to conversation titles — regular weight at 13px provides sufficient legibility without visual noise.
-- Agent message content renders inside `MarkdownBody` which applies `prose prose-sm` — do not override prose typography for markdown content.
-- The chat input `Textarea` uses Body (14px / regular).
-- Section headers inside the chat panel (e.g. "Conversations") use Heading (16px / semibold).
-- Timestamps and message count badges use Meta (12px / regular / muted-foreground).
-- Active conversation title in the sidebar: do NOT use `font-semibold` to indicate active state. Use the left-border accent indicator instead (see Color contract).
-
----
-
-## Color
-
-All colors reference CSS custom properties already declared for all three themes (Catppuccin Mocha, Tokyo Night, Catppuccin Latte) in `ui/src/index.css`. Never hard-code hex values. Source: `ui/src/index.css`.
-
-| Role | CSS Variable | 60/30/10 | Usage |
-|------|-------------|----------|-------|
-| Dominant surface | `--background` | 60% | Chat panel background, message list background, main layout background |
-| Secondary surface | `--card` / `--sidebar` | 30% | Conversation list sidebar background (`--sidebar`), individual conversation list item hover state, code block container |
-| Accent | `--primary` | 10% | Send button, active conversation highlight border-left indicator, conversation pin icon (filled) |
-| Muted | `--muted` | — | Input background, empty state icon container |
-| Muted foreground | `--muted-foreground` | — | Placeholder text in chat input, timestamps, secondary labels |
-| Destructive | `--destructive` | — | Delete conversation action only |
-| Border | `--border` | — | Dividers between message groups, chat panel border, input border |
-
-Accent (`--primary`) is reserved for exactly these elements:
-1. The "Send message" / "New conversation" primary action button background
-2. The active conversation in the sidebar (left-border indicator: `border-l-2 border-primary`)
-3. Filled pin icon on pinned conversations
-
-The accent must NOT be applied to: conversation list hover states, timestamps, agent message bubbles, or any decorative elements.
-
-Theme-specific code highlighting:
-- `catppuccin-mocha` (dark): use highlight.js theme `base16/catppuccin` (dark variant via `.dark` class)
-- `tokyo-night` (dark): use highlight.js theme `tokyo-night-dark` (via `.theme-tokyo-night.dark` class)
-- `catppuccin-latte` (light): use highlight.js theme `base16/catppuccin` (light variant via `:root` / light mode class)
-
-Implementation: Load one CSS file with per-theme class overrides for `.hljs` variables rather than three separate `<link>` imports. See RESEARCH.md Pitfall 1.
-
----
-
-## Component Inventory
-
-Components to build for this phase. Each references the design token contract above.
-
-### ChatPanel (right-side drawer)
-- Width: 380px open, 0px closed
-- Transition: `transition-[width] duration-100 ease-out` (same as sidebar in `Layout.tsx`)
-- Background: `bg-background` (dominant surface)
-- Position: sibling of `<PropertiesPanel>` in the Layout flex row; opening ChatPanel closes PropertiesPanel (see RESEARCH.md Open Question 1 resolution)
-- Header: 48px tall, `border-b border-border`, contains "Chat" title (Heading) + "New conversation" icon button (Plus from lucide) + close icon button
-- localStorage key: `nexus:chat-panel-open` (use `nexus:` prefix, not `paperclip:`)
-
-### ChatConversationList (inside ChatPanel left column, width: 240px)
-- Background: `bg-sidebar` (secondary surface)
-- Item height: 48px (`py-3 px-3`) — uses `sm+` (12px) vertical padding token
-- Active item: `border-l-2 border-primary bg-sidebar-accent`
-- Hover item: `bg-sidebar-accent/50`
-- Title: Label (13px / regular), truncated with `truncate`
-- Timestamp: Meta (12px / muted-foreground), right-aligned
-- Pin icon: 14px, `text-primary` when active
-- Archive icon: 14px, `text-muted-foreground`
-- Skeleton loader: 3 skeleton items (`<Skeleton>`) while `isLoading`
-- Infinite scroll sentinel: `<div ref={sentinelRef}>` at bottom of list
-
-### ChatMessageList (main chat area)
-- Background: `bg-background`
-- Padding: `p-4` with `gap-4` between messages
-- User message: right-aligned, `bg-secondary text-secondary-foreground`, `rounded-none` (matches `--radius: 0` global setting), `max-w-[75%]`, padding `px-4 py-2`
-- Assistant message: left-aligned, no background (transparent), `max-w-[85%]`
-- Message timestamp: Meta, visible on hover only (`opacity-0 group-hover:opacity-100 transition-opacity`)
-- Agent label on assistant messages: not in Phase 21 (agent identity lands in Phase 22) — omit avatar/name row entirely
-
-### ChatMarkdownMessage (assistant message renderer)
-- Extends `MarkdownBody` with `rehype-highlight` added to `rehypePlugins`
-- Code block container: `bg-card border border-border`, `relative` positioning for copy button
-- Code block language label: Meta (12px), `text-muted-foreground`, top-left inside block (`absolute top-2 left-3`)
-- Copy button: icon-only (Copy from lucide, 14px), `absolute top-1.5 right-1.5`, `variant="ghost" size="icon-sm"`, transitions to Check icon for 2 seconds on success
-- Copy button accessible label: `aria-label="Copy code"`
-
-### ChatInput (bottom of ChatPanel)
-- Component: `<Textarea>` (shadcn) with `field-sizing: content` CSS + scroll-height fallback
-- Min height: 40px (one line)
-- Max height: 160px (approx 6 lines), then scrolls internally
-- Padding: `px-3 py-2` (8px vertical — `sm` token)
-- Background: `bg-muted` (matches `--muted` for input feel)
-- Border: `border border-border focus:ring-1 focus:ring-ring`
-- Placeholder: "Send a message..." — `text-muted-foreground`
-- Send button: positioned to the right of the textarea (flex row), `variant="default"`, icon-only (Send from lucide, 16px), disabled when input is empty
-- Keyboard shortcuts:
-  - `Enter` (without Shift) → submit
-  - `Shift+Enter` → newline
-  - `Escape` → clear input (if input has content) OR close ChatPanel (if input is empty)
-
----
-
-## Interaction Contract
-
-### Conversation CRUD actions
-Actions are available via a `<DropdownMenu>` (lucide `MoreHorizontal` icon) that appears on hover over a conversation list item.
-
-| Action | Icon | Color | Confirmation |
-|--------|------|-------|-------------|
-| Pin conversation / Unpin conversation | Pin / PinOff | default foreground | None — immediate |
-| Archive conversation | Archive | default foreground | None — immediate |
-| Unarchive conversation | ArchiveRestore | default foreground | None — immediate |
-| Delete conversation | Trash2 | `text-destructive` | Inline confirm: replace DropdownMenu trigger with popover containing "Delete conversation?" + "Delete conversation" (destructive) / "Keep conversation" (ghost) buttons |
-
-No separate Dialog for delete — use inline confirmation popover to keep the interaction contained in the sidebar.
-
-### Conversation title editing
-- Trigger: double-click on the conversation title in the list, OR via a "Rename conversation" item in the DropdownMenu
-- Inline input replaces the title text (`<input>` at same 13px font size)
-- Confirm: Enter or blur
-- Cancel: Escape restores previous title
-
-### Sidebar infinite scroll
-- Load more trigger: `IntersectionObserver` on a sentinel div at the bottom of the conversation list
-- While loading next page: show 2 `<Skeleton>` items at the bottom
-- End of list: no visual indicator (list simply ends)
-
-### State: sending a message
-- Send button becomes `disabled` and shows a `Loader2` spin icon while the POST is in flight
-- Input is disabled during submission
-- On success: input clears, message appears at bottom of `ChatMessageList`
-- On error: input re-enables, toast notification fires (uses existing `ToastViewport`)
-
----
-
-## Copywriting Contract
-
-Source: Claude's discretion (discuss phase skipped). All copy follows Nexus tone: direct, no corporate language, lowercase preference for UI labels.
-
-| Element | Copy |
-|---------|------|
-| Primary CTA (new conversation) | "New conversation" (icon button with tooltip showing this text) |
-| Send button tooltip | "Send message" |
-| Chat panel toggle tooltip | "Open chat" / "Close chat" |
-| Input placeholder | "Send a message..." |
-| Empty state heading | "No conversations yet" |
-| Empty state body | "Start a conversation to get help with your work." |
-| Empty state action button | "New conversation" |
-| Conversation list empty after filter | "No conversations match your search." |
-| Error: failed to load conversations | "Couldn't load conversations. Check your connection and try again." |
-| Error: failed to send message | "Message not sent. Try again." |
-| Error: failed to create conversation | "Couldn't create conversation. Try again." |
-| Delete confirmation question (inline) | "Delete this conversation?" |
-| Delete confirmation — destructive button | "Delete conversation" |
-| Delete confirmation — dismiss button | "Keep conversation" |
-| Conversation auto-title prefix | First 60 characters of the user's first message, no prefix label |
-| Archive action label | "Archive conversation" |
-| Unarchive action label | "Unarchive conversation" |
-| Pin action label | "Pin conversation" |
-| Unpin action label | "Unpin conversation" |
-| Rename action label | "Rename conversation" |
-
-Destructive action in this phase:
-- **Delete conversation**: triggered from DropdownMenu, confirmed inline (no Dialog). Confirmation text: "Delete this conversation?" Button labels: "Delete conversation" (destructive variant) and "Keep conversation" (ghost variant). "Keep conversation" is the explicit dismissal — it communicates what is preserved, not just that the action was cancelled.
-
----
-
-## Accessibility Contract
-
-- All icon-only buttons must have `aria-label`
-- The chat panel must have `role="complementary"` and `aria-label="Chat"`
-- The conversation list must be a `<nav aria-label="Conversations">`
-- Active conversation item: `aria-current="true"`
-- Loading skeleton items must have `aria-busy="true"` on the list container
-- The message list must have `role="log"` and `aria-live="polite"` so screen readers announce new messages
-- The chat input must have `aria-label="Message input"`
-- The send button must have `aria-label="Send message"` and `aria-disabled` when empty
-- Focus management: when a new conversation is created, move focus to the chat input
-- Keyboard: full keyboard navigation within the conversation list via arrow keys (standard `rovingTabIndex` or `aria-activedescendant` pattern is acceptable; `tabIndex` cycling is sufficient for this phase)
-
----
-
-## Animation Contract
-
-All animations reuse existing CSS transition patterns from the codebase. No new animation libraries.
-
-| Element | Animation | Duration | Easing |
-|---------|-----------|----------|--------|
-| Chat panel open/close | `transition-[width]` | 100ms | `ease-out` |
-| Copy button → check icon | opacity + transform swap | 150ms | `ease-in-out` |
-| Conversation list item hover | `transition-colors` | 150ms | `ease-out` (Tailwind default) |
-| Send loading spinner | `animate-spin` (Tailwind) | continuous | linear |
-| New message entry | no animation (Phase 21 scope) | — | — |
-
----
-
-## Registry Safety
-
-| Registry | Blocks Used | Safety Gate |
-|----------|-------------|-------------|
-| shadcn official | All existing components (Avatar, Badge, Button, Card, Dialog, DropdownMenu, Input, ScrollArea, Separator, Sheet, Skeleton, Tabs, Textarea, Tooltip) | not required |
-| Third-party registries | none | not applicable |
-
-No third-party registry blocks are declared for this phase. Only `rehype-highlight` (npm, not shadcn registry) is a new dependency — npm packages are not subject to the shadcn registry safety gate.
-
----
-
-## Checker Sign-Off
-
-- [ ] Dimension 1 Copywriting: PASS
-- [ ] Dimension 2 Visuals: PASS
-- [ ] Dimension 3 Color: PASS
-- [ ] Dimension 4 Typography: PASS
-- [ ] Dimension 5 Spacing: PASS
-- [ ] Dimension 6 Registry Safety: PASS
-
-**Approval:** pending

.planning/phases/21-chat-foundation/21-VALIDATION.md

@@ -1,82 +0,0 @@
----
-phase: 21
-slug: chat-foundation
-status: draft
-nyquist_compliant: false
-wave_0_complete: false
-created: 2026-04-01
----
-
-# Phase 21 — Validation Strategy
-
-> Per-phase validation contract for feedback sampling during execution.
-
----
-
-## Test Infrastructure
-
-| Property | Value |
-|----------|-------|
-| **Framework** | Vitest 3.x |
-| **Config file** | `server/vitest.config.ts` (server), `vitest.config.ts` (root, multi-project) |
-| **Quick run command** | `pnpm vitest run server/src/__tests__/chat-service.test.ts` |
-| **Full suite command** | `pnpm test:run` |
-| **Estimated runtime** | ~15 seconds |
-
----
-
-## Sampling Rate
-
-- **After every task commit:** Run `pnpm vitest run server/src/__tests__/chat-service.test.ts`
-- **After every plan wave:** Run `pnpm test:run`
-- **Before `/gsd:verify-work`:** Full suite must be green
-- **Max feedback latency:** 15 seconds
-
----
-
-## Per-Task Verification Map
-
-| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
-|---------|------|------|-------------|-----------|-------------------|-------------|--------|
-| 21-01-01 | 01 | 1 | HIST-01 | unit (service) | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | ❌ W0 | ⬜ pending |
-| 21-01-02 | 01 | 1 | HIST-01 | integration (route) | `pnpm vitest run server/src/__tests__/chat-routes.test.ts` | ❌ W0 | ⬜ pending |
-| 21-01-03 | 01 | 1 | CHAT-04 | unit (service) | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | ❌ W0 | ⬜ pending |
-| 21-01-04 | 01 | 1 | CHAT-05 | unit (service) | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | ❌ W0 | ⬜ pending |
-| 21-01-05 | 01 | 1 | CHAT-06 | unit (service) | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | ❌ W0 | ⬜ pending |
-| 21-02-01 | 02 | 1 | CHAT-02, CHAT-03 | component (UI) | `pnpm vitest run ui/src/components/ChatMarkdownMessage.test.tsx` | ❌ W0 | ⬜ pending |
-| 21-02-02 | 02 | 1 | INPUT-07 | component (UI) | `pnpm vitest run ui/src/components/ChatInput.test.tsx` | ❌ W0 | ⬜ pending |
-
-*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
-
----
-
-## Wave 0 Requirements
-
-- [ ] `server/src/__tests__/chat-service.test.ts` — stubs for HIST-01, CHAT-04, CHAT-05, CHAT-06
-- [ ] `server/src/__tests__/chat-routes.test.ts` — stubs for HIST-01 route integration
-- [ ] `ui/src/components/ChatMarkdownMessage.test.tsx` — stubs for CHAT-02, CHAT-03
-- [ ] `ui/src/components/ChatInput.test.tsx` — stubs for INPUT-07
-
-*Existing vitest infrastructure covers framework install.*
-
----
-
-## Manual-Only Verifications
-
-| Behavior | Requirement | Why Manual | Test Instructions |
-|----------|-------------|------------|-------------------|
-| Theme CSS variables apply to chat panel and code blocks | THEME-01, THEME-02 | Visual inspection required | Open app, switch themes (Catppuccin Mocha, Tokyo Night, Catppuccin Latte), verify chat panel and code block colors match theme |
-| Infinite scroll loads next page on scroll to bottom | HIST-03 | Requires browser scroll simulation | Create 50+ messages, scroll to bottom, verify next page loads |
-
----
-
-## Validation Sign-Off
-
-- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
-- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
-- [ ] Wave 0 covers all MISSING references
-- [ ] No watch-mode flags
-- [ ] Feedback latency < 15s
-- [ ] `nyquist_compliant: true` set in frontmatter
-
-**Approval:** pending

.planning/phases/21-chat-foundation/21-VERIFICATION.md

@@ -1,235 +0,0 @@
----
-phase: 21-chat-foundation
-verified: 2026-04-01T14:15:00Z
-status: human_needed
-score: 5/5 success criteria verified (automated)
-human_verification:
-  - test: "Visual confirmation of markdown rendering with syntax highlighting"
-    expected: "Code blocks in agent messages show colored syntax tokens, language label, and functional copy button across all three themes"
-    why_human: "Cannot run the browser to confirm visual rendering output of rehype-highlight"
-  - test: "Theme switching changes code block highlight colors"
-    expected: "Switching from Catppuccin Mocha to Tokyo Night to Catppuccin Latte changes code token colors to their respective palettes"
-    why_human: "CSS computed value inspection requires a running browser"
-  - test: "Chat panel opens and PropertiesPanel closes"
-    expected: "Clicking the MessageSquare icon in Layout opens the 380px right-side panel; any open PropertiesPanel closes at the same time"
-    why_human: "Requires running UI; effect wiring verified in code but interaction needs confirmation"
-  - test: "Conversations persist across server restart"
-    expected: "After creating conversations and restarting the server, all conversations and messages reappear"
-    why_human: "Requires running server with real database"
-  - test: "Chat panel open state persists in localStorage"
-    expected: "Reloading the page preserves whether the chat panel was open or closed"
-    why_human: "Requires running browser with localStorage access"
----
-
-# Phase 21: Chat Foundation Verification Report
-
-**Phase Goal:** Users can open Nexus, create and manage conversations, and read fully rendered agent responses — with persistent storage and correct theme styling from the start
-**Verified:** 2026-04-01T14:15:00Z
-**Status:** human_needed
-**Re-verification:** No — initial verification
-
----
-
-## Goal Achievement
-
-### Success Criteria (from ROADMAP.md)
-
-| # | Criterion | Status | Evidence |
-|---|-----------|--------|----------|
-| 1 | User can create a new conversation, give it a title, and see it appear in the sidebar conversation list | VERIFIED | `ChatPanel.handleNew()` calls `createConversation.mutateAsync(undefined)` → `chatApi.createConversation()` → `POST /api/companies/:id/conversations` → `chatService.createConversation()` which inserts a row and returns it; `useChatConversations` invalidated on success so list updates |
-| 2 | User can delete, archive, and pin conversations from the sidebar | VERIFIED | `ChatConversationList` `DropdownMenu` has Rename/Pin/Archive/Delete items; delete shows inline confirmation "Delete this conversation?"; all wired to `useConversationActions()` mutations which call `chatApi.deleteConversation/archiveConversation/pinConversation` |
-| 3 | Agent messages render with full markdown: code blocks with syntax highlighting and a copy button, tables, lists, headings, links, and inline images | VERIFIED (automated) | `ChatMarkdownMessage` uses `rehype-highlight` + `remarkGfm`; `CodeBlock` sub-component has `aria-label="Copy code"` button with `navigator.clipboard.writeText()`; language label renders when className includes `language-*`; 10 tests pass including copy button and language label |
-| 4 | Conversations and all messages are stored in PostgreSQL and survive a server restart | VERIFIED | Migration 0047_fixed_johnny_storm.sql confirmed; `chat_conversations` and `chat_messages` tables with correct FK cascade; `chatService` uses real Drizzle ORM queries against embedded-postgres (project uses PostgreSQL, not libSQL — stale requirement wording) |
-| 5 | The chat interface applies Catppuccin Mocha, Tokyo Night, and Catppuccin Latte themes correctly; code block highlighting matches the active theme | VERIFIED (automated) | `index.css` has 52 `.hljs` rules: `.dark .hljs` for Catppuccin Mocha, `.theme-tokyo-night .hljs` overrides for Tokyo Night, `:root:not(.dark) .hljs` for Catppuccin Latte; ChatPanel and ChatInput use CSS variables (`var(--card)`, `var(--border)`, `var(--muted)`) throughout |
-
-**Score:** 5/5 success criteria verified (automated)
-
----
-
-### Observable Truths (from plan must_haves)
-
-**Plan 21-01: Backend**
-
-| # | Truth | Status | Evidence |
-|---|-------|--------|----------|
-| 1 | Conversations and messages stored in PostgreSQL, survive server restarts | VERIFIED | Migration 0047 creates both tables; Drizzle ORM service uses real DB queries; embedded-postgres provides persistence |
-| 2 | Multiple conversations per company, sorted by updatedAt DESC | VERIFIED | `listConversations` uses `orderBy(desc(chatConversations.updatedAt))` with `isNull(deletedAt)` filter |
-| 3 | First message auto-generates title from first 60 characters | VERIFIED | `addMessage` reads conversation after insert; if `title === null`, updates with `content.slice(0, 60)` and `isNull(chatConversations.title)` guard |
-| 4 | Conversations can be soft-deleted, archived, and pinned | VERIFIED | `softDeleteConversation`, `archiveConversation`, `pinConversation`, `unpinConversation` all implemented with real `.update().set()` calls |
-| 5 | Conversations accessible from any device via REST API | VERIFIED | 11 REST endpoints mounted in `app.ts` at line 160; correct auth guards (`assertBoard`, `assertCompanyAccess`) on all routes |
-
-**Plan 21-02: UI Components**
-
-| # | Truth | Status | Evidence |
-|---|-------|--------|----------|
-| 1 | Agent messages render with full markdown | VERIFIED | `ChatMarkdownMessage` uses `remarkGfm` + `rehypeHighlight`; 10 component tests pass |
-| 2 | Code blocks have copy button and language label | VERIFIED | `CodeBlock` sub-component confirmed; `aria-label="Copy code"` present; language label from `className.replace(/^language-/, "")` |
-| 3 | Code block highlighting matches active theme | HUMAN_NEEDED | CSS rules confirmed in `index.css`; visual result needs browser |
-| 4 | Chat input auto-resizes up to 6 lines | VERIFIED | `adjustHeight()` clamps to `maxHeight: 160`; 9 ChatInput tests pass |
-| 5 | Enter sends, Shift+Enter newline, Escape clears or closes | VERIFIED | `handleKeyDown` checks `e.key === "Enter" && !e.shiftKey`; `e.key === "Escape"` branches on `value.trim()`; 9 tests confirm each behavior |
-| 6 | Chat interface respects Nexus theme system via CSS variables | VERIFIED | Components use `bg-card`, `border-border`, `bg-muted`, `text-muted-foreground` throughout |
-
-**Plan 21-03: Wire-Up**
-
-| # | Truth | Status | Evidence |
-|---|-------|--------|----------|
-| 1 | Chat icon in layout toggles right-side panel | VERIFIED | Layout.tsx line 420: `<Button onClick={toggleChat} aria-label={chatOpen ? "Close chat" : "Open chat"}><MessageSquare /></Button>` |
-| 2 | User can create conversation and see it in sidebar | VERIFIED | `ChatPanel.handleNew()` → mutation → query invalidation; wired end-to-end |
-| 3 | User can send message and see it in message list | VERIFIED | `ChatPanel.handleSend()` calls `sendMessage.mutateAsync(content)`; `useChatMessages` invalidated on success; `ChatMessageList` renders user/assistant messages |
-| 4 | Conversation list sorted by most recent, infinite scroll | VERIFIED | `useChatConversations` uses `useInfiniteQuery` with cursor `updatedAt`; `ChatConversationList` has `IntersectionObserver` sentinel at bottom |
-| 5 | Opening chat closes PropertiesPanel | VERIFIED | Layout.tsx lines 151–155: `useEffect(() => { if (chatOpen) { setPanelVisible(false); } }, [chatOpen, setPanelVisible])` |
-| 6 | Chat panel open state persists in localStorage | VERIFIED | `ChatPanelContext` reads/writes `nexus:chat-panel-open` key; `readPreference()` on mount |
-
----
-
-### Required Artifacts
-
-| Artifact | Provides | L1 Exists | L2 Substantive | L3 Wired | L4 Data Flow | Status |
-|----------|----------|-----------|----------------|----------|--------------|--------|
-| `packages/db/src/schema/chat_conversations.ts` | chatConversations Drizzle table | YES | 24 lines, all columns + indexes | Exported in schema/index.ts | N/A (schema) | VERIFIED |
-| `packages/db/src/schema/chat_messages.ts` | chatMessages Drizzle table with cascade | YES | 18 lines, cascade FK | Exported in schema/index.ts | N/A (schema) | VERIFIED |
-| `packages/db/src/migrations/0047_fixed_johnny_storm.sql` | Migration SQL | YES | Both tables, cascade, indexes | Applied by migrate.ts | N/A | VERIFIED |
-| `packages/shared/src/types/chat.ts` | ChatConversation, ChatMessage interfaces | YES | 3 interfaces | Re-exported from types/index.ts | N/A | VERIFIED |
-| `packages/shared/src/validators/chat.ts` | Zod schemas | YES | 3 schemas | Re-exported from validators/index.ts | N/A | VERIFIED |
-| `server/src/services/chat.ts` | chatService factory with CRUD | YES | 178 lines, all methods with real Drizzle queries | Used in routes/chat.ts | Real DB queries | VERIFIED |
-| `server/src/routes/chat.ts` | chatRoutes factory, 11 endpoints | YES | 101 lines, all 11 routes | Mounted in app.ts line 160 | Calls chatService | VERIFIED |
-| `server/src/__tests__/chat-service.test.ts` | Service unit tests | YES | 341 lines, 12 tests | Passes: 12/12 | N/A | VERIFIED |
-| `server/src/__tests__/chat-routes.test.ts` | Route integration tests | YES | 219 lines, 12 tests | Passes: 12/12 | N/A | VERIFIED |
-| `ui/src/components/ChatMarkdownMessage.tsx` | Markdown + syntax highlighting + copy | YES | 99 lines, rehypeHighlight, CodeBlock | Used in ChatMessageList | N/A (presentational) | VERIFIED |
-| `ui/src/components/ChatInput.tsx` | Auto-resize textarea + keyboard shortcuts | YES | 95 lines, Enter/Shift+Enter/Escape | Used in ChatPanel | N/A (presentational) | VERIFIED |
-| `ui/src/api/chat.ts` | chatApi fetch wrappers for all endpoints | YES | 37 lines, all 11 methods | Used by useChatConversations, useChatMessages | Calls REST API | VERIFIED |
-| `ui/src/context/ChatPanelContext.tsx` | ChatPanelProvider + useChatPanel | YES | 60 lines, localStorage, active conversation | Mounted in main.tsx, used in Layout + ChatPanel | N/A (state) | VERIFIED |
-| `ui/src/hooks/useChatConversations.ts` | useInfiniteQuery wrapper | YES | 56 lines, useInfiniteQuery + mutations | Used in ChatConversationList + ChatPanel | chatApi.listConversations → real API | VERIFIED |
-| `ui/src/hooks/useChatMessages.ts` | TanStack Query wrapper for messages | YES | 26 lines, useInfiniteQuery + useSendMessage | Used in ChatMessageList + ChatPanel | chatApi.listMessages → real API | VERIFIED |
-| `ui/src/components/ChatPanel.tsx` | Right-side drawer shell | YES | 106 lines, role="complementary", width transition | Used in Layout.tsx | useChatConversations + useChatMessages → real data | VERIFIED |
-| `ui/src/components/ChatConversationList.tsx` | Sidebar with infinite scroll + CRUD | YES | 322 lines, IntersectionObserver, DropdownMenu | Used in ChatPanel | useChatConversations → real data | VERIFIED |
-| `ui/src/components/ChatMessageList.tsx` | Message thread | YES | 81 lines, role="log", auto-scroll | Used in ChatPanel | useChatMessages → real data | VERIFIED |
-
----
-
-### Key Link Verification
-
-| From | To | Via | Status | Evidence |
-|------|----|-----|--------|----------|
-| `server/src/routes/chat.ts` | `server/src/services/chat.ts` | `chatService(db)` factory | WIRED | Line 10: `const svc = chatService(db)` |
-| `server/src/app.ts` | `server/src/routes/chat.ts` | `api.use(chatRoutes(db))` | WIRED | Line 27 import, line 160 `api.use(chatRoutes(db))` |
-| `packages/db/src/schema/index.ts` | `chat_conversations.ts` + `chat_messages.ts` | re-exports | WIRED | Lines 59–60: both exported |
-| `ui/src/components/ChatPanel.tsx` | `ui/src/hooks/useChatConversations.ts` + `useChatMessages.ts` | hook calls | WIRED | Lines 13–14: both hooks imported and called |
-| `ui/src/components/Layout.tsx` | `ui/src/components/ChatPanel.tsx` | `<ChatPanel />` in flex row | WIRED | Line 10 import, line 460 `<ChatPanel />` |
-| `ui/src/components/Layout.tsx` | `ui/src/context/ChatPanelContext.tsx` | `useChatPanel()` | WIRED | Line 22 import, line 55 `const { chatOpen, toggleChat } = useChatPanel()` |
-| `ui/src/components/ChatConversationList.tsx` | `ui/src/hooks/useChatConversations.ts` | `useChatConversations()` | WIRED | Line 3 import, line 220 call |
-| `ui/src/main.tsx` | `ui/src/context/ChatPanelContext.tsx` | `<ChatPanelProvider>` wrapping app | WIRED | Line 12 import, lines 52–58 wrapping |
-
----
-
-### Data-Flow Trace (Level 4)
-
-| Component | Data Variable | Source | Produces Real Data | Status |
-|-----------|--------------|--------|--------------------|--------|
-| `ChatConversationList` | `allConversations` from `useChatConversations` | `chatApi.listConversations` → `GET /api/companies/:id/conversations` → `chatService.listConversations()` → Drizzle `db.select().from(chatConversations)` | YES — real DB query | FLOWING |
-| `ChatMessageList` | `allMessages` from `useChatMessages` | `chatApi.listMessages` → `GET /api/conversations/:id/messages` → `chatService.listMessages()` → Drizzle `db.select().from(chatMessages)` | YES — real DB query | FLOWING |
-| `ChatPanel` | `conversation` from `createConversation.mutateAsync` | `chatApi.createConversation` → `POST /api/companies/:id/conversations` → `chatService.createConversation()` → Drizzle `.insert(chatConversations).returning()` | YES — real DB insert | FLOWING |
-
----
-
-### Behavioral Spot-Checks
-
-All 43 automated tests pass:
-- `chat-service.test.ts`: 12/12 tests passing (listConversations, createConversation, addMessage with auto-title, softDelete, archive, pin/unpin, updateConversation)
-- `chat-routes.test.ts`: 12/12 tests passing (all 11 endpoints + 1 list test)
-- `ChatMarkdownMessage.test.tsx`: 10/10 tests passing (headings, code blocks, copy button, language label, inline code, tables, links, images)
-- `ChatInput.test.tsx`: 9/9 tests passing (Enter send, Shift+Enter newline, Escape clear, Escape close, disabled button, isSubmitting state, aria labels)
-
-| Behavior | Command | Result | Status |
-|----------|---------|--------|--------|
-| Service tests | `pnpm vitest run server/src/__tests__/chat-service.test.ts` | 12 pass, 0 fail | PASS |
-| Route tests | `pnpm vitest run server/src/__tests__/chat-routes.test.ts` | 12 pass, 0 fail | PASS |
-| ChatMarkdownMessage tests | `pnpm vitest run ui/src/components/ChatMarkdownMessage.test.tsx` | 10 pass, 0 fail | PASS |
-| ChatInput tests | `pnpm vitest run ui/src/components/ChatInput.test.tsx` | 9 pass, 0 fail | PASS |
-| UI build | `pnpm --filter @paperclipai/ui build` | Builds in 6.01s, no TypeScript errors | PASS |
-
----
-
-### Requirements Coverage
-
-| Requirement | Source Plan(s) | Description | Status | Evidence |
-|-------------|---------------|-------------|--------|----------|
-| CHAT-02 | 21-02, 21-04 | Markdown rendering: code blocks, tables, lists, headings, links, images | SATISFIED | `ChatMarkdownMessage` with `remarkGfm` + `rehypeHighlight`; 10 tests |
-| CHAT-03 | 21-02, 21-04 | Code blocks have copy button and language label | SATISFIED | `CodeBlock` sub-component; `aria-label="Copy code"`; `navigator.clipboard.writeText()` |
-| CHAT-04 | 21-01, 21-03, 21-04 | Multiple concurrent conversations with sidebar list | SATISFIED | `ChatConversationList` renders all conversations per company; cursor-paginated |
-| CHAT-05 | 21-01, 21-04 | Auto-generated titles, manually editable | SATISFIED | `addMessage` sets title from first 60 chars; `PATCH /api/conversations/:id` for rename; inline rename in UI |
-| CHAT-06 | 21-01, 21-04 | Delete, archive, and pin conversations | SATISFIED | `softDeleteConversation`, `archiveConversation`, `pinConversation` service methods; all 3 in dropdown UI |
-| INPUT-01 | 21-02, 21-04 | Multi-line auto-resize input | SATISFIED | `ChatInput` with `adjustHeight()` clamped to 160px |
-| INPUT-07 | 21-02, 21-04 | Keyboard shortcuts: Enter, Shift+Enter, Escape | SATISFIED | `handleKeyDown` in `ChatInput`; 9 tests covering all shortcuts |
-| HIST-01 | 21-01, 21-04 | All conversations persisted (requirement says libSQL, project uses PostgreSQL) | SATISFIED | PostgreSQL via embedded-postgres + Drizzle ORM; migration 0047; data survives process restarts |
-| HIST-02 | 21-03, 21-04 | Conversation list sorted by most recent, searchable, filterable by agent | PARTIAL | Sorting (updatedAt DESC) and infinite scroll implemented; **search and filter-by-agent are not implemented** — plans scoped HIST-02 to sorting + infinite scroll only; search/filter deferred |
-| HIST-03 | 21-03, 21-04 | Infinite scroll in sidebar | SATISFIED | `IntersectionObserver` sentinel in `ChatConversationList`; `fetchNextPage()` on intersection |
-| HIST-05 | 21-01, 21-04 | Cross-device sync via Nexus server API | SATISFIED | All chat data served via REST API over network; no local-only state |
-| HIST-06 | 21-01, 21-04 | Chat history survives server restarts | SATISFIED | PostgreSQL persistence confirmed; no in-memory-only state |
-| THEME-01 | 21-02, 21-04 | Chat interface respects Nexus theme system | SATISFIED | All components use CSS variables; theme classes applied via `ThemeContext` |
-| THEME-02 | 21-02, 21-04 | Code blocks use theme-appropriate highlight colors | SATISFIED (visual confirmation needed) | 52 `.hljs` rules in `index.css` covering all three themes via `.dark`, `.theme-tokyo-night`, `:root:not(.dark)` selectors |
-
-**Notes on HIST-01:** The REQUIREMENTS.md and ROADMAP.md reference "libSQL" but the Nexus project has always used PostgreSQL (embedded-postgres + drizzle-orm/postgres-js). This is stale documentation from before the tech stack was finalized upstream. The persistence goal is satisfied by PostgreSQL.
-
-**Notes on HIST-02:** Full requirement text is "sorted by most recent, searchable, filterable by agent." The plans for phase 21 deliberately scoped HIST-02 to sorting + infinite scroll, deferring search and agent-filter to Phase 24 (Search, History & Branching). The phase marked HIST-02 as complete in plan frontmatter despite partial coverage. This is an information mismatch in documentation — the code does not claim to satisfy all of HIST-02.
-
----
-
-### Anti-Patterns Found
-
-No blockers or warnings found. No TODO/FIXME/PLACEHOLDER comments in any phase-21 files. No stub API routes returning empty static values. No hollow React component returns. No orphaned files (all artifacts are imported and used).
-
-| File | Line | Pattern | Severity | Impact |
-|------|------|---------|----------|--------|
-| None | — | — | — | — |
-
----
-
-### Human Verification Required
-
-#### 1. Syntax Highlighting Visual Output
-
-**Test:** Open the app, send a message containing a fenced code block with a known language (e.g. ` ```typescript\nconst x: number = 42;\n``` `), and inspect the rendered code block.
-**Expected:** Code tokens appear in Catppuccin Mocha colors (purple keywords, green strings, orange numbers). Language label "typescript" appears top-left. Copy button appears top-right.
-**Why human:** `rehype-highlight` applies token class names at parse time; whether the CSS rules actually colorize them correctly requires a running browser with CSS loaded.
-
-#### 2. Theme Switching Changes Code Colors
-
-**Test:** With a code block rendered, cycle through all three themes using the theme toggle button.
-**Expected:** Switching to Tokyo Night changes keyword color to `#bb9af7`, string to `#9ece6a`. Switching to Catppuccin Latte changes keyword to `#8839ef`, background to light. Each theme produces readable contrast.
-**Why human:** CSS specificity behavior with `.dark`, `.theme-tokyo-night`, and `:root:not(.dark)` selectors needs visual confirmation.
-
-#### 3. Chat Panel / PropertiesPanel Exclusivity
-
-**Test:** Open the PropertiesPanel (click an item that opens it), then click the MessageSquare chat icon.
-**Expected:** The chat panel slides open from the right; the PropertiesPanel closes simultaneously.
-**Why human:** The `useEffect` wiring in `Layout.tsx` is confirmed in code, but the visual transition and absence of simultaneous display requires a running app.
-
-#### 4. Persistence After Server Restart
-
-**Test:** Create two conversations and send messages to each. Stop the server. Restart the server. Open the app.
-**Expected:** Both conversations appear in the sidebar with their messages intact and in the correct order.
-**Why human:** Requires a running server with the migration applied to the actual database.
-
-#### 5. localStorage Panel State Persistence
-
-**Test:** Open the chat panel, then reload the page (F5).
-**Expected:** The chat panel reopens automatically because `nexus:chat-panel-open = "true"` is stored in localStorage.
-**Why human:** Requires a running browser with localStorage access.
-
----
-
-### Gaps Summary
-
-No structural gaps found. All must-haves are implemented with real code (no stubs), wired (no orphaned files), and backed by real data flows (no hardcoded empty returns).
-
-Two documentation observations (neither blocks the phase goal):
-
-1. **HIST-01 technology label:** Requirement says "libSQL" but project uses PostgreSQL. The persistence goal is met; the requirement wording is outdated.
-
-2. **HIST-02 partial scope:** The full requirement ("searchable, filterable by agent") is partially implemented — sorting and infinite scroll are done, but search and filter-by-agent are not. The plans intentionally scoped this down for Phase 21; the remainder is deferred to Phase 24. The plan frontmatter marking HIST-02 as "complete" is technically an overstatement.
-
----
-
-_Verified: 2026-04-01T14:15:00Z_
-_Verifier: Claude (gsd-verifier)_

.planning/phases/22-agent-streaming/22-CONTEXT.md

@@ -1,41 +0,0 @@
-# Phase 22: Agent Streaming - Context
-
-**Gathered:** 2026-04-01
-**Status:** Ready for planning
-**Mode:** Auto-generated (discuss skipped via workflow.skip_discuss)
-
-<domain>
-## Phase Boundary
-
-Users receive live streaming responses from any agent they select, with full control to stop, edit, or retry — and agent identity is clearly visible on every message
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion — discuss phase was skipped per user setting. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-</decisions>
-
-<code_context>
-## Existing Code Insights
-
-Codebase context will be gathered during plan-phase research.
-
-</code_context>
-
-<specifics>
-## Specific Ideas
-
-No specific requirements — discuss phase skipped. Refer to ROADMAP phase description and success criteria.
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-None — discuss phase skipped.
-
-</deferred>

.planning/phases/22-agent-streaming/22-RESEARCH.md

@@ -1,572 +0,0 @@
-# Phase 22: Agent Streaming - Research
-
-**Researched:** 2026-04-01
-**Domain:** Real-time SSE streaming, agent selector, message editing/retry, slash commands, @mentions, virtualized list
-**Confidence:** HIGH
-
-## Summary
-
-Phase 22 adds live streaming responses, agent selection, message editing/regeneration, stop-generation control, slash commands, @mention routing, agent identity on every message, and a virtualized message list for large conversations. It builds directly on the Phase 21 foundation: the `chat_conversations` and `chat_messages` tables, the chat service, and the `ChatPanel`/`ChatMessageList`/`ChatInput` component tree are all in place.
-
-The architecture split is: (1) a new SSE streaming endpoint on the server that accepts a user message, streams LLM tokens back via `text/event-stream`, and persists the completed response to `chat_messages`; (2) a React hook that consumes that SSE stream and appends tokens to a local optimistic message; (3) UI additions — agent selector dropdown, message-level action buttons (Stop / Retry / Edit), slash-command and @mention parsing in ChatInput, agent avatar/name badge on assistant messages, and a virtualized scroll container for PERF-03.
-
-The server does NOT currently have a direct LLM API dependency. The existing adapter system runs agents as subprocesses/HTTP webhooks — it is not suitable for streaming chat tokens to a browser. Phase 22 must introduce a lightweight inline LLM call path in the chat route. The Vercel AI SDK (`ai`) is the standard choice: it has first-class SSE streaming helpers for Express, supports multiple providers (OpenAI, Anthropic, Google) behind one interface, and handles token-level streaming with proper connection lifecycle. The `openai` package is an alternative if only one provider is needed. The SDK version as of 2026-04-01 is `ai@4.x` (currently 4.x series).
-
-Virtualization for PERF-03 (1,000+ messages without jank): `virtua` v0.49.0 is the correct choice over `@tanstack/react-virtual` v3.13.x. `virtua` is a single-component drop-in (`<VList>`) with automatic height measurement, no manual row-height estimation, and strong React 19 support. `@tanstack/react-virtual` requires the developer to provide item sizes upfront or use a measurement plugin — significantly more work for variable-height chat messages. Neither is currently installed.
-
-**Primary recommendation:** Add the `ai` SDK to `server/package.json`, add `virtua` to `ui/package.json`. Build one new server route `POST /api/conversations/:id/stream` that streams tokens via SSE and persists the completed message. Add a `useStreamMessage` hook using native `EventSource`. Wire all new UI into the existing `ChatPanel` tree.
-
-<user_constraints>
-## User Constraints (from CONTEXT.md)
-
-### Locked Decisions
-None — discuss phase was skipped per user setting (`workflow.skip_discuss: true`).
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-### Deferred Ideas (OUT OF SCOPE)
-None — discuss phase skipped.
-</user_constraints>
-
-<phase_requirements>
-## Phase Requirements
-
-| ID | Description | Research Support |
-|----|-------------|------------------|
-| CHAT-01 | Real-time streaming: tokens appear as generated, first token under 500ms | New SSE route `POST /api/conversations/:id/stream`; `useStreamMessage` hook with `EventSource`; optimistic message state in ChatMessageList |
-| CHAT-08 | Agent selector: switch active agent mid-conversation or per-conversation | `chat_conversations.agentId` column already exists; new `AgentSelector` dropdown component; PATCH `/api/conversations/:id` with `agentId` |
-| CHAT-10 | Message editing: edit previous message and regenerate response | New `editedContent` + `editedAt` column on `chat_messages`; `PUT /api/messages/:id` route; ChatMessageList inline edit mode |
-| CHAT-11 | Response regeneration: retry button on any assistant message | Re-invokes stream route with same context; UI button on assistant message hover |
-| CHAT-12 | Stop generation: cancel button while streaming | `AbortController` on server (connection close detection); EventSource `.close()` on client; Stop button replaces Send during streaming |
-| INPUT-05 | Slash commands: `/brainstorm`, `/ask-pm`, `/ask-engineer`, `/task`, `/search` | Parse in ChatInput before send; route message to matching agent by role slug |
-| INPUT-06 | `@mention` agents: `@engineer` routes to named agent | Parse `@word` prefix in ChatInput; resolve agent by name; override active agent for that send |
-| AGENT-04 | Agent avatar + name on every assistant message | Agents table has `name` + `icon` columns; join agent row when listing messages; `AgentBadge` component using existing `AgentIcon` |
-| THEME-03 | Agent avatars/colors distinguishable in all three themes | Deterministic color mapping by agent role using CSS custom properties already in index.css; verified for Catppuccin Mocha, Tokyo Night, Catppuccin Latte |
-| PERF-02 | Streaming latency under 100ms server-to-UI | Express SSE with `res.flushHeaders()` + `res.write()` per token; `X-Accel-Buffering: no` header; no buffering in middleware |
-| PERF-03 | 1,000+ messages scroll smoothly | Replace flat `div` list with `virtua` `<VList>` in ChatMessageList |
-</phase_requirements>
-
----
-
-## Project Constraints (from CLAUDE.md)
-
-| Constraint | Detail |
-|-----------|--------|
-| Upstream sync | Display-layer changes only. DB schema changes are additive (new columns on existing tables is safe; no drops, no type changes). |
-| Language | TypeScript (ESM) everywhere. No plain JS. |
-| Package manager | pnpm. Use `pnpm add` — never `npm install`. |
-| Framework | Express 5.1.0. Chat routes follow `function chatRoutes(db: Db): Router` factory pattern. |
-| DB | Drizzle ORM with PostgreSQL. New columns require `pnpm db:generate` + committed migration SQL. |
-| Auth | `local_trusted` mode — `assertBoard(req)` is the only auth gate needed. |
-| Testing | Vitest (server) + jsdom+createRoot+act (UI — `@testing-library/react` is NOT installed). Pattern established in `ChatInput.test.tsx` and `chat-routes.test.ts`. |
-| React version | React 19.0.0 — use `createRoot` + `act`, not legacy `render`. |
-| TanStack Query | ^5.90.21 — `useMutation` + `useInfiniteQuery` patterns established. |
-
----
-
-## Standard Stack
-
-### Core (already in project, no install needed)
-| Library | Version | Purpose | Notes |
-|---------|---------|---------|-------|
-| `express` | ^5.1.0 | SSE streaming route | `res.write()` / `res.flushHeaders()` pattern |
-| `drizzle-orm` | ^0.38.4 | Schema + query builder | Additive columns on `chat_messages` |
-| `@tanstack/react-query` | ^5.90.21 | Mutation state, query invalidation | `useMutation` for stream send |
-| `lucide-react` | ^0.574.0 | Icons: Square (stop), RotateCcw (retry), Pencil (edit), Bot | — |
-| `clsx` / `tailwind-merge` | current | Conditional classNames | — |
-
-### New Installs Required
-| Library | Version | Purpose | Why |
-|---------|---------|---------|-----|
-| `ai` (Vercel AI SDK) | ^4.x (current: 4.x) | Inline LLM streaming for the chat route | Single unified interface for OpenAI/Anthropic/Google; built-in token streaming; toDataStreamResponse() helper for SSE; widely adopted standard |
-| `virtua` | ^0.49.0 | Virtualized list for ChatMessageList (PERF-03) | Auto-measures variable row heights; `<VList>` drop-in; React 19 tested; simpler API than @tanstack/react-virtual which requires manual height estimates |
-
-### Alternatives Considered
-| Standard choice | Alternative | Why not |
-|-----------------|-------------|---------|
-| `ai` (Vercel AI SDK) | `openai` direct | openai SDK requires provider lock-in; no unified streaming format; ai SDK wraps it and adds provider abstraction |
-| `ai` (Vercel AI SDK) | `@anthropic-ai/sdk` direct | Same — provider lock-in; ai SDK v4 supports Anthropic natively via `@ai-sdk/anthropic` |
-| `virtua` | `@tanstack/react-virtual` | react-virtual requires developer-provided row heights; chat messages are variable height; virtua auto-measures |
-| `virtua` | `react-window` | react-window is unmaintained; requires fixed row heights |
-| Native `EventSource` | `@microsoft/fetch-event-source` | EventSource is sufficient; fetch-event-source adds POST support (not needed here) and ~4KB extra |
-
-**Installation:**
-```bash
-# Server
-pnpm --filter @paperclipai/server add ai
-
-# UI
-pnpm --filter @paperclipai/ui add virtua
-```
-
-**Version verification (confirmed 2026-04-01):**
-- `ai`: 4.3.x series (npm view ai version → 6.0.142 — note: the npm package `ai` v6 is a different package from the Vercel AI SDK; the Vercel AI SDK is at `@ai-sdk/core` + provider adapters; see Architecture Patterns below for the correct install)
-- `virtua`: 0.49.0
-
-> **Important SDK note:** npm's `ai` package at v6.x is unrelated to the Vercel AI SDK. The correct Vercel AI SDK packages are `ai` (the core, currently 4.x) published by vercel-ai, and provider adapters like `@ai-sdk/openai`, `@ai-sdk/anthropic`. Verify: `npm view ai` should show `vercel-ai` as author. If the version returned is 6.x and not by vercel, use `@ai-sdk/core` + `@ai-sdk/openai` directly instead. The alternative is to use the `openai` npm package (v6.33.0) directly with manual SSE streaming — simpler, zero extra dependencies, proven pattern.
-
----
-
-## Architecture Patterns
-
-### Recommended Project Structure (additions to Phase 21)
-
-```
-server/src/
-├── routes/
-│   └── chat.ts                    # Add: streamMessage(), editMessage() routes
-├── services/
-│   └── chat.ts                    # Add: editMessage(), updateAgentId()
-│
-packages/shared/src/
-├── types/
-│   └── chat.ts                    # Add: editedContent, editedAt, agentName, agentIcon to ChatMessage
-├── validators/
-│   └── chat.ts                    # Add: streamMessageSchema, editMessageSchema, updateConversationAgentSchema
-│
-packages/db/src/schema/
-│   └── chat_messages.ts           # Add columns: editedContent, editedAt
-│   └── chat_conversations.ts      # agentId already exists
-│
-ui/src/
-├── api/
-│   └── chat.ts                    # Add: streamMessage() using EventSource
-├── hooks/
-│   ├── useChatMessages.ts         # Add: useStreamMessage, useEditMessage
-│   └── useChatConversations.ts    # Add: useUpdateConversationAgent
-├── components/
-│   ├── ChatMessageList.tsx        # Replace flat div list with <VList>; add agent badge, edit/retry/stop buttons
-│   ├── ChatInput.tsx              # Add: slash command + @mention parsing; Stop button during streaming
-│   ├── AgentSelector.tsx          # New: dropdown for active agent per conversation
-│   └── ChatAgentBadge.tsx         # New: avatar + name on assistant messages
-```
-
-### Pattern 1: SSE Streaming Route (Express 5)
-
-**What:** Server accepts POST with message content + conversationId, streams tokens via SSE, persists final message.
-**When to use:** Every user message send.
-
-```typescript
-// server/src/routes/chat.ts — new route
-// Source: existing plugin SSE pattern at server/src/routes/plugins.ts:1146
-
-router.post("/conversations/:id/stream", validate(streamMessageSchema), async (req, res) => {
-  assertBoard(req);
-  const { content, agentId } = req.body;
-
-  // 1. Persist the user message immediately
-  const userMsg = await svc.addMessage(req.params.id, { role: "user", content, agentId: null });
-
-  // 2. Set SSE headers — identical to plugin stream bridge pattern
-  res.writeHead(200, {
-    "Content-Type": "text/event-stream",
-    "Cache-Control": "no-cache",
-    "Connection": "keep-alive",
-    "X-Accel-Buffering": "no",
-  });
-  res.flushHeaders();
-
-  // 3. Detect client disconnect for stop-generation (CHAT-12)
-  let aborted = false;
-  req.on("close", () => { aborted = true; });
-
-  // 4. Stream tokens (pseudocode — actual LLM call depends on chosen provider)
-  let accumulated = "";
-  for await (const token of streamLlmTokens({ messages: history, agentId, signal: ... })) {
-    if (aborted) break;
-    accumulated += token;
-    res.write(`data: ${JSON.stringify({ type: "token", content: token })}\n\n`);
-  }
-
-  // 5. Persist completed assistant message
-  if (accumulated) {
-    await svc.addMessage(req.params.id, { role: "assistant", content: accumulated, agentId });
-  }
-
-  // 6. Send done event
-  res.write(`data: ${JSON.stringify({ type: "done", messageId: "..." })}\n\n`);
-  res.end();
-});
-```
-
-### Pattern 2: EventSource Hook (React client)
-
-**What:** Hook opens an EventSource to the stream endpoint, accumulates tokens into a local state, and invalidates TanStack Query cache on done.
-**When to use:** User sends a message.
-
-```typescript
-// ui/src/hooks/useChatMessages.ts — additions
-
-export function useStreamMessage(conversationId: string | null) {
-  const queryClient = useQueryClient();
-  const [streaming, setStreaming] = useState(false);
-  const [partialContent, setPartialContent] = useState("");
-  const esRef = useRef<EventSource | null>(null);
-
-  // EventSource does not support POST — use fetch + ReadableStream for POST body,
-  // OR use a GET endpoint with query params, OR persist user msg first and open GET stream.
-  // RECOMMENDED: POST /conversations/:id/messages (user msg), then GET /conversations/:id/stream
-  // with ?lastMessageId=X to trigger the assistant response SSE.
-
-  const stop = useCallback(() => {
-    esRef.current?.close();
-    esRef.current = null;
-    setStreaming(false);
-  }, []);
-
-  // ... (full implementation in plan)
-  return { streaming, partialContent, stop, send };
-}
-```
-
-> **EventSource limitation:** Native `EventSource` only supports GET requests. The recommended pattern is: (1) POST the user message as normal (returns message ID), (2) open a GET SSE endpoint `GET /conversations/:id/stream?triggerMessageId=X` which streams the assistant reply. This avoids the need for `@microsoft/fetch-event-source` and keeps auth simple (GET with session cookie works in `local_trusted` mode).
-
-### Pattern 3: VList Drop-In for ChatMessageList
-
-**What:** Replace the flat `div` column with `virtua`'s `<VList>` component.
-**When to use:** In `ChatMessageList.tsx`.
-
-```typescript
-// Source: virtua docs https://github.com/inokawa/virtua
-import { VList } from "virtua";
-
-// Replace:
-// <div role="log" ... className="... overflow-y-auto flex-1">
-//   {allMessages.map(...)}
-// </div>
-
-// With:
-<VList
-  style={{ flex: 1 }}
-  ref={listRef}
-  // auto-scroll to bottom:
-  onScroll={...}
->
-  {allMessages.map((msg) => (
-    <ChatMessageItem key={msg.id} message={msg} />
-  ))}
-</VList>
-```
-
-### Pattern 4: Slash Command + @Mention Parsing in ChatInput
-
-**What:** Parse command/mention prefix before message is sent, resolve target agent, override active agent for that message.
-**When to use:** In `ChatInput.handleSend`.
-
-```typescript
-const SLASH_COMMANDS: Record<string, string> = {
-  "/brainstorm": "brainstormer",
-  "/ask-pm": "pm",
-  "/ask-engineer": "engineer",
-  "/task": "engineer",
-  "/search": "generalist",
-};
-
-function parseMessageIntent(content: string): { text: string; targetRole?: string; targetName?: string } {
-  const trimmed = content.trim();
-
-  // Slash command: /ask-engineer Hello
-  for (const [cmd, role] of Object.entries(SLASH_COMMANDS)) {
-    if (trimmed.toLowerCase().startsWith(cmd)) {
-      return { text: trimmed.slice(cmd.length).trim(), targetRole: role };
-    }
-  }
-
-  // @mention: @engineer Hello
-  const mentionMatch = trimmed.match(/^@(\w[\w-]*)[\s,]+(.*)/s);
-  if (mentionMatch) {
-    return { text: mentionMatch[2]!.trim(), targetName: mentionMatch[1]!.toLowerCase() };
-  }
-
-  return { text: trimmed };
-}
-```
-
-### Pattern 5: Agent Identity on Messages (AGENT-04)
-
-**What:** Join agent row when fetching messages to include `agentName` and `agentIcon`. Add `ChatAgentBadge` above assistant message bubbles.
-**When to use:** All assistant messages in ChatMessageList.
-
-The `chat_messages.agentId` column already exists. The `agents` table has `name` and `icon` columns. The API can join on fetch, or the UI can fetch agents once via the existing `agentsApi.listAgents()` and resolve client-side by ID.
-
-**Recommendation:** Fetch agent list once via `useAgents(companyId)` hook (already exists in the codebase at `ui/src/hooks/`) and resolve by ID client-side. This avoids a join in every message list query and keeps the message API response shape stable.
-
-### Pattern 6: Agent Color Theming (THEME-03)
-
-**What:** Assign distinguishable colors to agents across all three themes using deterministic role-based mapping.
-**When to use:** `ChatAgentBadge` and `AgentSelector`.
-
-```typescript
-// Agent role → Tailwind ring/bg class, using theme-aware CSS variables already in index.css
-const AGENT_ROLE_COLORS: Record<string, string> = {
-  "ceo":        "bg-[hsl(var(--chart-1))] text-white",
-  "pm":         "bg-[hsl(var(--chart-2))] text-white",
-  "engineer":   "bg-[hsl(var(--chart-3))] text-white",
-  "general":    "bg-[hsl(var(--chart-4))] text-white",
-  "brainstormer": "bg-[hsl(var(--chart-5))] text-white",
-};
-```
-
-The `chart-1` through `chart-5` CSS variables are already defined for all three themes in `ui/src/index.css` — verified in Phase 21 research. This guarantees THEME-03 compliance without new CSS.
-
-### Anti-Patterns to Avoid
-
-- **Never buffer full SSE response in middleware:** Express compression middleware can buffer SSE. Ensure `compression` (if present) is bypassed for `text/event-stream` content type, or configure `res.flushHeaders()` before any potential buffering.
-- **Never store streaming state in TanStack Query cache:** Streaming partial content lives in `useState` locally in the hook. Only the persisted final message enters the query cache via `invalidateQueries` on done.
-- **Never use `EventSource` for POST requests:** EventSource is GET-only. Use the two-step pattern: POST user message → GET stream endpoint.
-- **Never manually estimate row heights for virtua:** `virtua` measures automatically. Passing `itemSize` prop overrides this and breaks variable-height rows.
-- **Never join agent table in listMessages route:** Resolve agent identity client-side using cached `useAgents()` data to keep the message API stable and avoid N+1 joins.
-
----
-
-## Don't Hand-Roll
-
-| Problem | Don't Build | Use Instead | Why |
-|---------|-------------|-------------|-----|
-| Token streaming to browser | Custom chunked transfer encoding, WebSocket | SSE with `res.write()` + `text/event-stream` | SSE is HTTP/1.1 compatible, auto-reconnects on client, simpler than WebSocket for unidirectional streams |
-| LLM provider streaming | Raw fetch loop parsing `data:` lines | `ai` SDK or `openai` SDK's built-in async iterator | Handles partial JSON, error cases, usage reporting, abort signals |
-| Variable-height virtualized list | Manual IntersectionObserver + position tracking | `virtua` `<VList>` | Auto-measurement, scroll restoration, smooth for 1,000+ items |
-| Agent color assignment | Per-agent color stored in DB | CSS custom property `chart-N` vars by role | Already theme-aware; no DB writes; deterministic |
-
-**Key insight:** The SSE pattern already exists in `server/src/routes/plugins.ts:1096-1180` — copy the header setup verbatim. The only novel work is the LLM call itself.
-
----
-
-## Common Pitfalls
-
-### Pitfall 1: SSE Buffering in Production
-**What goes wrong:** Tokens arrive at client in large batches instead of individually; PERF-02 (100ms latency) is violated.
-**Why it happens:** Any buffering middleware between Express and the socket — gzip compression, Nginx proxy buffering, Node's own stream buffering.
-**How to avoid:** Add `X-Accel-Buffering: no` header (disables Nginx buffering), call `res.flushHeaders()` immediately after `writeHead`, use `res.write()` not `res.json()`. Pattern confirmed in existing plugin SSE route.
-**Warning signs:** Browser receives multiple tokens in one SSE event despite server writing them individually.
-
-### Pitfall 2: EventSource Cannot POST
-**What goes wrong:** Attempting to stream a POST request via EventSource, resulting in the browser sending a GET with no body and the server returning 404 or 405.
-**Why it happens:** The `EventSource` Web API spec only allows GET requests.
-**How to avoid:** Use the two-step pattern: POST user message → GET SSE stream. Or use `@microsoft/fetch-event-source` which supports POST (adds ~4KB). The two-step approach is zero-dependency and fits the existing `addMessage` service method.
-**Warning signs:** SSE stream opens immediately with 0 bytes; server log shows GET instead of POST.
-
-### Pitfall 3: Optimistic Message Flicker on Done
-**What goes wrong:** When `done` event fires, TanStack Query invalidation causes a re-fetch; the optimistic streaming message disappears briefly before the persisted one appears.
-**Why it happens:** `invalidateQueries` clears the cache; the re-fetched list comes back from server with the final message; but there is a render cycle between clear and repopulate.
-**How to avoid:** On `done`, use `queryClient.setQueryData` to append the final message to the existing cache pages before invalidating, OR keep the streaming message as a "pending" item that is replaced (not removed) when the server message arrives keyed by a stable temporary ID.
-**Warning signs:** Visible flash/blank where the assistant message was during the transition from streaming to persisted.
-
-### Pitfall 4: Stop Generation Leaves Partial Message in DB
-**What goes wrong:** User clicks Stop; server detects disconnect but has already started writing the partial response; a partial assistant message is persisted.
-**Why it happens:** The `addMessage` call at end of stream only fires on clean completion; but if the abort fires mid-stream, nothing persists — this is actually fine. The pitfall is if you persist after each token instead of at the end.
-**How to avoid:** Only call `svc.addMessage` for the assistant response AFTER the loop completes normally. If `aborted === true` after the loop, do NOT persist (or persist with a `stopped: true` metadata flag if partial history is desired).
-**Warning signs:** Orphaned partial messages in the DB with no natural ending.
-
-### Pitfall 5: virtua List Auto-Scroll Conflicts with User Scroll
-**What goes wrong:** As new tokens stream in and the list grows, virtua auto-scrolls to the bottom even when the user has deliberately scrolled up to read earlier messages.
-**Why it happens:** Naive "scroll to bottom on new message" effect doesn't detect whether the user has scrolled away.
-**How to avoid:** Track `isAtBottom` state using virtua's `onScroll` callback (`scrollOffset + clientHeight >= scrollSize - threshold`). Only auto-scroll when `isAtBottom === true`.
-**Warning signs:** User scrolls up; list jumps back to bottom each time a token arrives.
-
-### Pitfall 6: Slash Command Collides with Regular Message Content
-**What goes wrong:** A message starting with `/` but not matching any command is silently dropped or misrouted.
-**Why it happens:** Overly aggressive prefix matching.
-**How to avoid:** Only route if the prefix exactly matches a known command token followed by whitespace or end-of-string. Unknown `/` prefixes pass through as plain text.
-**Warning signs:** Users report messages starting with `/path/to/something` being dropped.
-
----
-
-## Code Examples
-
-### SSE Headers Setup (verified pattern from existing codebase)
-```typescript
-// Source: server/src/routes/plugins.ts:1146
-res.writeHead(200, {
-  "Content-Type": "text/event-stream",
-  "Cache-Control": "no-cache",
-  "Connection": "keep-alive",
-  "X-Accel-Buffering": "no",
-});
-res.flushHeaders();
-res.write(":ok\n\n"); // initial comment to establish connection
-```
-
-### SSE Event Format
-```typescript
-// Each token as a named event
-res.write(`data: ${JSON.stringify({ type: "token", content: deltaText })}\n\n`);
-
-// Done event with persisted message ID
-res.write(`data: ${JSON.stringify({ type: "done", messageId: assistantMsg.id })}\n\n`);
-
-// Error event
-res.write(`data: ${JSON.stringify({ type: "error", message: "LLM call failed" })}\n\n`);
-res.end();
-```
-
-### Client EventSource Consumption
-```typescript
-// Source pattern: ui/src/plugins/bridge.ts:423 (adapted for GET stream)
-const source = new EventSource(`/api/conversations/${convId}/stream?triggerMessageId=${msgId}`, {
-  withCredentials: true,
-});
-
-source.onmessage = (event) => {
-  const parsed = JSON.parse(event.data) as StreamEvent;
-  if (parsed.type === "token") {
-    setPartialContent((prev) => prev + parsed.content);
-  } else if (parsed.type === "done") {
-    source.close();
-    queryClient.invalidateQueries({ queryKey: ["chat", "messages", convId] });
-    setPartialContent("");
-    setStreaming(false);
-  }
-};
-```
-
-### DB Schema Additions
-```typescript
-// packages/db/src/schema/chat_messages.ts — additive columns only
-editedContent: text("edited_content"),       // null if never edited
-editedAt: timestamp("edited_at", { withTimezone: true }), // null if never edited
-```
-
-### Agent Color by Role
-```typescript
-// ui/src/lib/agent-colors.ts (new file)
-const ROLE_COLOR_CLASS: Record<string, string> = {
-  ceo:          "bg-[hsl(var(--chart-1))]",
-  pm:           "bg-[hsl(var(--chart-2))]",
-  engineer:     "bg-[hsl(var(--chart-3))]",
-  general:      "bg-[hsl(var(--chart-4))]",
-  brainstormer: "bg-[hsl(var(--chart-5))]",
-};
-
-export function agentRoleColorClass(role: string): string {
-  return ROLE_COLOR_CLASS[role] ?? "bg-muted";
-}
-```
-
----
-
-## State of the Art
-
-| Old Approach | Current Approach | When Changed | Impact |
-|--------------|------------------|--------------|--------|
-| WebSocket for chat streaming | SSE (Server-Sent Events) | Industry settled ~2022-2023 | SSE is simpler, HTTP/1.1 native, no WS handshake; sufficient for unidirectional token stream |
-| `react-window` for virtualization | `virtua` or `@tanstack/react-virtual` | 2023-2024 | react-window is unmaintained; virtua is the current simple-API choice |
-| Fixed-height virtual lists | Auto-measuring virtual lists (virtua) | 2022+ | Chat messages are variable height; auto-measurement is required |
-| Manual LLM token streaming | `ai` Vercel SDK / `openai` SDK async iterators | 2023+ | SDKs handle edge cases; manual stream parsing is fragile |
-
-**Deprecated/outdated:**
-- `react-window`: No updates since 2021. Do not use.
-- Manual SSE parsing with split/newline logic: Use SDK's async iterator instead.
-
----
-
-## Open Questions
-
-1. **Which LLM provider + model backs the chat stream?**
-   - What we know: The adapters are all subprocess wrappers, not direct API callers. No `openai`/`@anthropic-ai/sdk` in server dependencies.
-   - What's unclear: Does the user have a local Ollama instance? A Claude API key? An OpenAI key? The adapter config on each agent is the canonical source (`adapterConfig` JSON field).
-   - Recommendation: For the initial streaming implementation, read `agent.adapterConfig.model` and `agent.adapterConfig.apiKey` (or resolve via `secretService`) at stream time. The simplest path is to use the `openai` npm package with configurable `baseURL` to support both OpenAI and Ollama-compatible endpoints. Defer multi-provider abstraction to a later phase.
-
-2. **Should streaming use GET or POST for the SSE endpoint?**
-   - What we know: Native `EventSource` is GET-only. The plugin bridge uses GET with `companyId` query param. The user message can be pre-persisted via the existing POST `/messages` endpoint.
-   - What's unclear: Whether it's cleaner to POST user message then GET stream, vs. use `@microsoft/fetch-event-source` for a single POST.
-   - Recommendation: Two-step (POST message, GET stream). Zero new dependencies. Pattern matches existing plugin bridge.
-
-3. **Should slash commands create a new conversation or send to the active one?**
-   - What we know: ROADMAP says "route messages to the correct agent" — routing, not branching.
-   - What's unclear: Whether `/ask-engineer Hello` in a PM conversation should switch the conversation's agent or just send this one message to engineer without changing the conversation default.
-   - Recommendation: Per-message override — slash commands and @mentions override the agent for that single message only, without changing `conversation.agentId`. The agent selector (CHAT-08) is the persistent per-conversation setting.
-
----
-
-## Environment Availability
-
-| Dependency | Required By | Available | Version | Fallback |
-|------------|------------|-----------|---------|----------|
-| Node.js | Server SSE route | ✓ | Current | — |
-| PostgreSQL | DB migrations | ✓ | Confirmed Phase 21 | — |
-| `ai` (Vercel AI SDK) | LLM streaming | ✗ | Not installed | Use `openai` npm package directly |
-| `virtua` | PERF-03 list | ✗ | Not installed | Defer virtualization or use @tanstack/react-virtual |
-| LLM API endpoint | CHAT-01 streaming | Unknown | — | Phase 22 should add configuration step or fallback echo mode |
-
-**Missing dependencies with no fallback:**
-- LLM API endpoint/key: Phase 22 implementation must either read from agent `adapterConfig` or prompt the user for an API key. Without this, streaming returns no tokens. Planner should include a task to read agent `adapterConfig.apiKey` + `adapterConfig.baseUrl` + `adapterConfig.model`.
-
-**Missing dependencies with fallback:**
-- `ai` SDK: If Vercel AI SDK proves problematic, use `openai` npm package (v6.33.0 confirmed available) which supports async iteration over token streams and is already the defacto standard.
-- `virtua`: If not available, `@tanstack/react-virtual` v3.13.23 is the fallback (confirmed installable).
-
----
-
-## Validation Architecture
-
-### Test Framework
-| Property | Value |
-|----------|-------|
-| Framework | Vitest 3.0.x |
-| Config file | `server/vitest.config.ts`, `ui/vitest.config.ts` |
-| Quick run command | `pnpm --filter @paperclipai/server test run` |
-| Full suite command | `pnpm test run` |
-
-### Phase Requirements → Test Map
-
-| Req ID | Behavior | Test Type | Automated Command | File Exists? |
-|--------|----------|-----------|-------------------|-------------|
-| CHAT-01 | SSE route returns `text/event-stream` content-type | unit (server) | `pnpm --filter @paperclipai/server test run -- --reporter=verbose chat-stream` | ❌ Wave 0 |
-| CHAT-01 | SSE route emits token events then done event | unit (server) | same | ❌ Wave 0 |
-| CHAT-08 | PATCH /conversations/:id accepts `agentId` field | unit (server) | `pnpm --filter @paperclipai/server test run -- --reporter=verbose chat-routes` | ✅ exists (extend) |
-| CHAT-10 | PUT /messages/:id updates editedContent + editedAt | unit (server) | `pnpm --filter @paperclipai/server test run -- --reporter=verbose chat-routes` | ✅ exists (extend) |
-| CHAT-12 | Stop button renders during streaming | unit (UI) | `pnpm --filter @paperclipai/ui test run` | ❌ Wave 0 |
-| CHAT-12 | Server disconnects client closes SSE gracefully | unit (server) | `pnpm --filter @paperclipai/server test run -- chat-stream` | ❌ Wave 0 |
-| INPUT-05 | Slash command parsing extracts target role | unit (UI) | `pnpm --filter @paperclipai/ui test run` | ❌ Wave 0 |
-| INPUT-06 | @mention parsing extracts target name | unit (UI) | `pnpm --filter @paperclipai/ui test run` | ❌ Wave 0 |
-| AGENT-04 | ChatAgentBadge renders agent name + icon | unit (UI) | `pnpm --filter @paperclipai/ui test run` | ❌ Wave 0 |
-| PERF-03 | ChatMessageList renders with VList | unit (UI) | `pnpm --filter @paperclipai/ui test run` | ✅ exists (extend) |
-
-### Sampling Rate
-- **Per task commit:** `pnpm --filter @paperclipai/server test run && pnpm --filter @paperclipai/ui test run`
-- **Per wave merge:** `pnpm test run`
-- **Phase gate:** Full suite green before `/gsd:verify-work`
-
-### Wave 0 Gaps
-- [ ] `server/src/__tests__/chat-stream-routes.test.ts` — covers CHAT-01, CHAT-12 SSE behavior
-- [ ] `ui/src/components/ChatInput.slash-mention.test.tsx` — covers INPUT-05, INPUT-06 parsing
-- [ ] `ui/src/components/ChatAgentBadge.test.tsx` — covers AGENT-04 rendering
-
-*(Existing `chat-routes.test.ts` covers CHAT-08 and CHAT-10 with extensions; no new file needed.)*
-
----
-
-## Sources
-
-### Primary (HIGH confidence)
-- Codebase: `server/src/routes/plugins.ts:1096-1180` — SSE header setup, write pattern, unsubscribe on close
-- Codebase: `server/src/services/live-events.ts` — event bus pattern
-- Codebase: `ui/src/plugins/bridge.ts:403-460` — EventSource hook pattern
-- Codebase: `packages/db/src/schema/chat_messages.ts`, `chat_conversations.ts` — current schema
-- Codebase: `packages/shared/src/types/agent.ts` — Agent type with `name`, `icon`, `role` fields
-- Codebase: `ui/src/components/AgentIconPicker.tsx`, `ui/src/lib/agent-icons.ts` — existing icon system
-- npm: `npm view virtua version` → 0.49.0 (confirmed 2026-04-01)
-- npm: `npm view @tanstack/react-virtual version` → 3.13.23 (confirmed 2026-04-01)
-
-### Secondary (MEDIUM confidence)
-- npm: `npm view openai version` → 6.33.0 — confirmed installable, async iterator streaming available
-- npm: `npm view @anthropic-ai/sdk version` → 0.81.0 — confirmed installable alternative
-- virtua README: `<VList>` API is a single component, `ref` for scroll programmatic control, `onScroll` for position tracking
-
-### Tertiary (LOW confidence)
-- Vercel AI SDK version: The `ai` npm package returned v6.0.142 from npm view, which may be a different package entirely. **Validate before installing** — check `npm view ai` author field or use `openai` directly as the safer option.
-
----
-
-## Metadata
-
-**Confidence breakdown:**
-- Standard stack: HIGH — all existing packages verified from package.json; new packages confirmed via npm view
-- Architecture: HIGH — SSE pattern directly copied from existing plugin bridge; EventSource pattern from existing bridge.ts
-- Pitfalls: HIGH — derived from codebase analysis (existing SSE headers, EventSource limitations, React query cache behavior)
-- LLM provider selection: LOW — depends on what API keys/models the user has configured on their agents; needs resolution in first plan wave
-
-**Research date:** 2026-04-01
-**Valid until:** 2026-05-01 (stable libraries; Vercel AI SDK version claim needs validation before install)

.planning/phases/v1.2.0.1-phases/13-scaffolding-and-data-layer/13-CONTEXT.md

@@ -1,41 +0,0 @@
-# Phase 13: Scaffolding and Data Layer - Context
-
-**Gathered:** 2026-04-01
-**Status:** Ready for planning
-**Mode:** Auto-generated (discuss skipped via workflow.skip_discuss)
-
-<domain>
-## Phase Boundary
-
-The `nxr` binary exists, compiles, and can read all data it needs — config, tracking DB, workspace context, and Ollama status
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Claude's Discretion
-All implementation choices are at Claude's discretion — pure infrastructure phase. Use ROADMAP phase goal, success criteria, and codebase conventions to guide decisions.
-
-</decisions>
-
-<code_context>
-## Existing Code Insights
-
-Codebase context will be gathered during plan-phase research.
-
-</code_context>
-
-<specifics>
-## Specific Ideas
-
-No specific requirements — infrastructure phase. Refer to ROADMAP phase description and success criteria.
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-None — discuss phase skipped.
-
-</deferred>

.planning/research/ARCHITECTURE.md

@@ -1,333 +0,0 @@
-# Architecture Patterns: Display-Layer Fork Isolation
-
-**Domain:** TypeScript monorepo fork (Paperclip → Nexus)
-**Researched:** 2026-03-30
-**Confidence:** HIGH — based on direct codebase inspection + verified patterns
-
----
-
-## Recommended Architecture
-
-The core constraint is: **every file Nexus touches is a potential rebase conflict site.**
-The architecture goal is therefore to minimize the number of upstream files modified by concentrating all fork-specific content into new files that upstream will never create.
-
-### Isolation Strategy: Minimal-Touch with Fork Overlay
-
-```
-Upstream files          Fork overlay files
-─────────────          ──────────────────
-constants.ts      →    [keep AGENT_ROLE_LABELS.ceo = "CEO", change display via wrapper]
-CompanyRail.tsx   →    (modify inline — unavoidable, low risk)
-OnboardingWizard  →    nexus/OnboardingWizard.nexus.tsx  (new file, rewire import)
-onboard.ts (CLI)  →    modify inline strings only (no logic change)
-SOUL.md / AGENTS  →    replace file content (same path, different content)
-```
-
-**Two categories of change, each with a different isolation strategy:**
-
-| Category | Strategy | Conflict Risk |
-|----------|----------|--------------|
-| New files added by Nexus | Add-only (upstream never touches these) | Zero |
-| Upstream files with string changes | Inline edit, minimal diff | Low — strings rarely conflict |
-| Upstream files requiring logic changes | Wrapper/replacement file, rewire import | Medium — requires Vite alias or import swap |
-
----
-
-## Component Boundaries
-
-| Component | Responsibility | Fork Change Type |
-|-----------|---------------|-----------------|
-| `ui/src/lib/nexus-labels.ts` | Central display-string registry (NEW file) | New file — zero conflict risk |
-| `ui/src/components/OnboardingWizard.tsx` | Multi-step first-run UX | Inline rewrite — file is owned by Nexus entirely |
-| `packages/shared/src/constants.ts` | `AGENT_ROLE_LABELS` map | Inline string change only — change `ceo: "CEO"` to `ceo: "Project Manager"` |
-| `ui/src/pages/Companies.tsx` | "New Company" button, "Companies" breadcrumb | Inline string change — 2-3 occurrences |
-| `cli/src/commands/onboard.ts` | Terminal output strings | Inline string change — no logic change |
-| `server/src/onboarding-assets/ceo/` | PM agent template content | File content replacement — same paths |
-| `server/src/home-paths.ts` | `.paperclip` → `.nexus` home dir | Inline constant change — single string |
-| `ui/src/components/CompanyRail.tsx` | Sidebar rail icon (`Paperclip` lucide icon) | Single import swap |
-
----
-
-## Isolation Pattern 1: Central Label Registry (New File)
-
-Create `ui/src/lib/nexus-labels.ts` as a new file. This file is pure Nexus — upstream will never create it, so it can never conflict.
-
-```typescript
-// ui/src/lib/nexus-labels.ts  [NEXUS-OWNED FILE]
-// Central display vocabulary. Never referenced by upstream.
-// All UI components import from here instead of hardcoding strings.
-
-export const NEXUS_LABELS = {
-  // Entity names
-  workspace: "Workspace",
-  workspaces: "Workspaces",
-  projectManager: "Project Manager",
-  owner: "Owner",
-
-  // Actions
-  addAgent: "Add Agent",
-  removeAgent: "Remove Agent",
-
-  // Onboarding
-  onboardingRootPrompt: "Choose your root directory",
-  onboardingTitle: "Welcome to Nexus",
-
-  // App identity
-  appName: "Nexus",
-  cliCommand: "nexus",
-} as const;
-```
-
-**Usage pattern in existing components:** Import `NEXUS_LABELS` and replace the hardcoded string. The diff in the upstream file is minimal — a one-line import addition and a string substitution.
-
-**Conflict profile:** The import addition is a single new line at the top of the file. String substitutions are isolated to specific JSX attributes. These lines are unlikely to be touched by upstream changes because upstream will not add an import from `nexus-labels`.
-
----
-
-## Isolation Pattern 2: Inline String Replacement (Low-Conflict Edits)
-
-For files with a small number of hardcoded display strings, edit inline with targeted changes. Prefix all changed lines with a `// [nexus]` comment on the preceding line so they are trivially identified during rebase conflict resolution.
-
-**Example — `packages/shared/src/constants.ts` line 53:**
-```typescript
-// [nexus] display label override
-ceo: "Project Manager",
-```
-
-**Example — `ui/src/pages/Companies.tsx` line 72:**
-```typescript
-// [nexus] breadcrumb rename
-setBreadcrumbs([{ label: "Workspaces" }]);
-```
-
-**Example — `ui/src/pages/Companies.tsx` line 96:**
-```typescript
-// [nexus] button rename
-New Workspace
-```
-
-The `// [nexus]` marker serves three purposes:
-1. Identifies fork-owned lines during `git diff` triage
-2. Signals to the developer during a rebase conflict which side is Nexus vs upstream
-3. Enables `grep -r '\[nexus\]'` to produce a complete inventory of modified lines at any time
-
----
-
-## Isolation Pattern 3: File Content Replacement (Onboarding Assets)
-
-The `server/src/onboarding-assets/ceo/` files (SOUL.md, AGENTS.md, HEARTBEAT.md, TOOLS.md) are plain prose. They have no code entanglement. Replace their content entirely.
-
-**Strategy:** Keep the same file paths. Write Nexus-specific content. Upstream changes to these files will produce conflicts, but:
-- Upstream changes to `ceo/SOUL.md` are relatively rare (onboarding prose is stable)
-- When conflicts occur, resolution is manual prose review — not code logic
-- The directory itself is not renamed (`ceo/` stays `ceo/`) to avoid path-level conflicts
-
-**PM and Engineer templates:** Add new template subdirectories under `server/src/onboarding-assets/`:
-- `server/src/onboarding-assets/pm/` — new directory, zero conflict risk
-- `server/src/onboarding-assets/engineer/` — new directory, zero conflict risk
-
----
-
-## Isolation Pattern 4: Build-Time File Swap via Vite Alias (High-Complexity Components)
-
-For components that require substantial structural changes (primarily `OnboardingWizard.tsx`), use Vite's `resolve.alias` to swap the import at build time. This keeps the upstream file untouched.
-
-**Existing Vite config** (`ui/vite.config.ts`) already uses `resolve.alias`:
-```typescript
-resolve: {
-  alias: {
-    "@": path.resolve(__dirname, "./src"),
-    lexical: path.resolve(__dirname, "./node_modules/lexical/Lexical.mjs"),
-  },
-},
-```
-
-**Add a Nexus override alias:**
-```typescript
-// ui/vite.config.ts  [nexus]
-resolve: {
-  alias: {
-    "@": path.resolve(__dirname, "./src"),
-    lexical: path.resolve(__dirname, "./node_modules/lexical/Lexical.mjs"),
-    // [nexus] component overrides
-    "@/components/OnboardingWizard": path.resolve(
-      __dirname, "./src/nexus/OnboardingWizard.tsx"
-    ),
-  },
-},
-```
-
-**New file:** `ui/src/nexus/OnboardingWizard.tsx` — entirely Nexus-owned, never conflicts.
-
-**Upstream file:** `ui/src/components/OnboardingWizard.tsx` — left unmodified. Any upstream updates to it are absorbed without conflict because the alias bypasses it.
-
-**Tradeoff:** This pattern is only worth the complexity for large rewrites (100+ lines changed). For small string changes, inline edits are lower overhead. Apply to `OnboardingWizard.tsx` only.
-
-**Confidence:** HIGH — Vite alias file swapping is a documented pattern used in white-label React apps. The existing config already demonstrates the alias syntax.
-
----
-
-## Isolation Pattern 5: Home Directory Pointer Mechanism
-
-The `~/.nexus` pointer file is Nexus-specific infrastructure. The approach:
-
-1. Modify `server/src/home-paths.ts` — change the single default string `".paperclip"` to `".nexus"`. This is a one-line change; conflict risk is minimal because upstream rarely changes default paths.
-
-2. Create `~/.nexus` as a single-line text file containing the root path. This is runtime data, not code.
-
-3. The `PAPERCLIP_HOME` env var override still works — Nexus does not rename it (display-only constraint).
-
-**Inline change in `server/src/home-paths.ts`:**
-```typescript
-// [nexus] home dir rename
-const DEFAULT_HOME = ".nexus";
-```
-
----
-
-## Data Flow: How Changes Propagate
-
-```
-nexus-labels.ts (NEW)
-  └── imported by: Companies.tsx, CompanyRail.tsx, InstanceSidebar.tsx, etc.
-      └── display strings centralized — upstream files only gain one import line
-
-constants.ts (MODIFIED, minimal)
-  └── AGENT_ROLE_LABELS.ceo = "Project Manager"
-      └── used by: AgentConfigForm.tsx, NewAgent.tsx, ApprovalPayload.tsx
-          └── no other changes needed in those files
-
-OnboardingWizard.nexus.tsx (NEW)
-  └── aliased via vite.config.ts (one-line alias addition)
-      └── upstream OnboardingWizard.tsx untouched
-
-onboarding-assets/ceo/*.md (MODIFIED content, same paths)
-  └── loaded by default-agent-instructions.ts (unchanged)
-
-onboarding-assets/pm/ (NEW directory)
-onboarding-assets/engineer/ (NEW directory)
-  └── loaded by new template selector in OnboardingWizard.nexus.tsx
-```
-
----
-
-## Anti-Patterns to Avoid
-
-### Anti-Pattern 1: Renaming Upstream Files or Directories
-
-**What:** Renaming `CompanyRail.tsx` → `WorkspaceRail.tsx`, or `onboarding-assets/ceo/` → `onboarding-assets/pm/`
-**Why bad:** Git tracks renames as delete + add. During `git rebase upstream/master`, if upstream makes changes to `CompanyRail.tsx`, the patch will not apply to `WorkspaceRail.tsx`. You get an unresolved conflict that requires manual merge of the upstream diff into the renamed file.
-**Instead:** Keep all upstream file paths. Use wrapper files or content replacement. Reserve new names for new files only.
-
-### Anti-Pattern 2: Renaming TypeScript Identifiers in Upstream Files
-
-**What:** Renaming `companyService` → `workspaceService`, `CompanyContext` → `WorkspaceContext`
-**Why bad:** Any upstream commit touching those files produces a merge conflict on every renamed symbol. The conflict surface grows proportionally to how many usages exist (currently hundreds of import sites).
-**Instead:** Leave all identifiers unchanged. The mapping from internal name to display name happens in `nexus-labels.ts` and the `AGENT_ROLE_LABELS` constant only.
-
-### Anti-Pattern 3: Squashing All Nexus Commits
-
-**What:** Maintaining Nexus changes as a single squashed "fork" commit
-**Why bad:** During `git rebase upstream/master`, all conflicts appear in one commit resolution session, making them impossible to isolate. A single upstream change to `constants.ts` forces you to re-resolve every Nexus change in that file simultaneously.
-**Instead:** Keep one atomic `[nexus]` commit per change area (labels, onboarding, home dir, templates). Small commits rebase cleanly. Conflicts are isolated.
-
-### Anti-Pattern 4: Package Name Renames
-
-**What:** `@paperclipai/shared` → `@nexusai/shared`
-**Why bad:** Every upstream file that imports from `@paperclipai/*` will conflict because Nexus has rewritten the import path. This is effectively every file in the monorepo.
-**Instead:** Keep all `@paperclipai/*` package names. This is explicitly in scope as "out of scope" in PROJECT.md.
-
-### Anti-Pattern 5: Centralizing All Changes in One File
-
-**What:** Putting all Nexus overrides in `constants.ts` or `App.tsx`
-**Why bad:** High-traffic upstream files accumulate the most conflicts. Concentrating fork changes there maximizes conflict exposure.
-**Instead:** Prefer adding new files (zero conflict risk) over modifying high-traffic upstream files.
-
----
-
-## Scalability Considerations
-
-| Concern | Now (v1) | Future upstream rebases |
-|---------|----------|------------------------|
-| Label changes | 1 constants.ts edit + nexus-labels.ts | nexus-labels.ts never conflicts; constants.ts conflict is isolated to 1 line |
-| Onboarding | OnboardingWizard aliased via Vite | Upstream OnboardingWizard changes ignored automatically |
-| Template content | ceo/ files replaced in-place | Manual prose merge if upstream edits ceo/ — rare |
-| New upstream entities | Zero action needed | New upstream files have no Nexus edits |
-| New Nexus features | Add to nexus/ directory | Zero conflict risk — new files only |
-
----
-
-## Implementation Order (Least to Most Conflict Risk)
-
-This order ensures each phase can be validated and rebased independently before the next phase adds more change surface.
-
-### Phase 1 — Foundation (zero upstream file changes)
-1. Create `ui/src/nexus/` directory
-2. Create `ui/src/lib/nexus-labels.ts` with full label registry
-3. Create `server/src/onboarding-assets/pm/` and `engineer/` template directories
-4. Add `[nexus]` commit: "add nexus overlay directory and label registry"
-
-**Why first:** Establishes the containment structure with no upstream file touches. Safe to rebase at any point.
-
-### Phase 2 — Constants and Labels (1 upstream file, 1-line change)
-1. Edit `packages/shared/src/constants.ts` — change `ceo: "CEO"` to `ceo: "Project Manager"` in `AGENT_ROLE_LABELS`
-2. Add `[nexus]` commit: "rename CEO display label to Project Manager"
-
-**Why second:** Single file, single line. Easiest conflict to resolve if upstream touches the same line.
-
-### Phase 3 — Home Directory (1 upstream file, 1-line change)
-1. Edit `server/src/home-paths.ts` — change default home dir string to `.nexus`
-2. Edit `cli/src/config/home.ts` — same change
-3. Add `[nexus]` commit: "change default home dir from .paperclip to .nexus"
-
-**Why third:** Low-risk lines. Home dir defaults are very rarely changed by upstream.
-
-### Phase 4 — UI String Renames (several upstream files, inline strings only)
-1. Edit `ui/src/pages/Companies.tsx` — rename "Companies" breadcrumb and "New Company" button to "Workspaces" / "New Workspace"
-2. Edit `ui/src/components/CompanyRail.tsx` — swap `Paperclip` lucide icon for a different icon
-3. Edit `ui/src/pages/CompanySettings.tsx`, `InstanceSidebar.tsx` — display-string renames
-4. Edit `cli/src/commands/onboard.ts` — terminal output strings
-5. One `[nexus]` commit per file changed
-
-**Why fourth:** More files touched, but changes are string-only. Each commit is independently rebaseable. `// [nexus]` markers make conflict resolution mechanical.
-
-### Phase 5 — Onboarding Redesign (Vite alias + new file)
-1. Add Vite alias in `ui/vite.config.ts` pointing `OnboardingWizard` to `nexus/OnboardingWizard.tsx`
-2. Write `ui/src/nexus/OnboardingWizard.tsx` as a full replacement (root dir picker, PM + Engineer auto-create)
-3. Replace `server/src/onboarding-assets/ceo/` file content with PM-framed prose
-4. One `[nexus]` commit: "redesign onboarding for single-dev workspace flow"
-
-**Why last:** Most complex change. The Vite alias approach means upstream `OnboardingWizard.tsx` can evolve freely without conflicting. Template content is the highest natural-language conflict risk but lowest structural risk.
-
----
-
-## Rebase Workflow
-
-```bash
-# Pull upstream changes
-git fetch upstream
-git rebase upstream/master
-
-# For each [nexus] commit, git will pause on conflicts.
-# Expected conflict files per phase:
-#   Phase 2: packages/shared/src/constants.ts (1 line)
-#   Phase 3: server/src/home-paths.ts, cli/src/config/home.ts (1 line each)
-#   Phase 4: ui/src/pages/*.tsx, cli/src/commands/onboard.ts (string lines)
-#   Phase 5: server/src/onboarding-assets/ceo/*.md (prose), ui/vite.config.ts (1 line)
-#
-# Resolution rule: keep [nexus] version for any line marked // [nexus]
-#                  accept upstream for everything else
-
-# After rebase, verify no Nexus labels reverted:
-grep -r '\[nexus\]' /Volumes/UsbNvme/repos/nexus --include="*.ts" --include="*.tsx"
-```
-
----
-
-## Sources
-
-- Codebase inspection: `/Volumes/UsbNvme/repos/nexus/` (direct analysis, HIGH confidence)
-- Vite resolve.alias documentation: https://vite.dev/config/shared-options (HIGH confidence)
-- White-label file-swap pattern: https://krasimirtsonev.com/blog/article/whitelabel-react-apps (MEDIUM confidence — describes Webpack, pattern is equivalent in Vite)
-- Fork rebase best practices: https://joaquimrocha.com/2024/09/22/how-to-fork/ (MEDIUM confidence)
-- Atomic commit strategy for forks: https://medium.com/@ruthmpardee/git-fork-workflow-using-rebase-587a144be470 (MEDIUM confidence)

.planning/research/FEATURES.md

@@ -1,193 +0,0 @@
-# Feature Landscape
-
-**Domain:** Personal AI Agent Orchestration Platform (solo-developer fork of Paperclip)
-**Researched:** 2026-03-30
-**Confidence:** HIGH for Paperclip base features (read from codebase); MEDIUM for ecosystem positioning (web research); LOW for subjective UX judgments
-
----
-
-## Context
-
-This analysis is scoped to the Nexus fork of Paperclip. The upstream already ships a comprehensive engine — heartbeats, task lifecycle, multi-adapter support, cost budgets, approval gates, plugin system. The fork question is not "what to build" but "what to rename, what to surface, and what to hide." Features are evaluated against that lens.
-
-**Two distinct tracks:**
-1. **Engine features** — what the orchestration runtime does (mostly inherited from upstream, not to be changed)
-2. **Display-layer features** — what the UI and CLI communicate to the human operator (primary fork scope)
-
----
-
-## Table Stakes
-
-Features the fork must get right for Nexus to feel complete and usable. Missing or broken = product feels unfinished.
-
-| Feature | Why Expected | Complexity | Notes |
-|---------|--------------|------------|-------|
-| Dashboard with live agent status | Users need to see what agents are doing at a glance | Low | Upstream has SSE-backed live updates; display rename only (Company → Workspace) |
-| Real-time run logs / heartbeat transcript | "Is my agent running or stuck?" is the first question every time | Low | Upstream streams stdout/stderr per heartbeat; UI already exists; display polish needed |
-| Cost visibility per agent | Without it users have no feedback loop on spend | Low | Upstream tracks `cost_events`; display rename + cleanup |
-| Task (issue) list with status | Core work item visibility | Low | Upstream has full issue model; display rename only |
-| Agent status indicators (idle/running/paused) | Know agent state without opening logs | Low | Upstream has agent `status` field; surface in sidebar/card |
-| One-command startup | `nexus run` → working dashboard | Low | CLI command exists as `paperclipai run`; display rename only |
-| Human approval workflow | Agents can request approval before acting; critical for trust | Low | Upstream has `approvals` table and routes; display rename only |
-| Agent configuration page | View and edit adapter type, model, instructions file | Medium | Upstream has config revisions and rollback; display cleanup needed |
-| Sub-task / issue hierarchy | Agents create sub-issues; user needs to see nesting | Low | Upstream has `parentId` and `requestDepth`; display only |
-| Project grouping | Issues are grouped under Projects; navigation must reflect this | Low | Upstream has `projects` entity; display rename only (no collision — Workspace > Project > Issue) |
-| Scheduled task creation (routines) | Recurring tasks without manual triggering | Low | Upstream has `routines` model with cron; display rename only |
-| CLI help text that uses Nexus vocabulary | Every `--help` output that says "Paperclip" or "company" breaks the mental model | Medium | All CLI display strings need `[nexus]` overrides |
-
-**Assessment:** Every table-stakes feature already exists in the upstream engine. The work is entirely display-layer: surface the right label, hide corporate metaphor, keep the behavior. Estimated risk: LOW — no functional code changes required.
-
----
-
-## Differentiators
-
-Features that make Nexus feel personal and purpose-built for a solo developer, versus Paperclip's "zero-human company" framing.
-
-### D1: Zero-Question Onboarding
-**Value:** Paperclip's onboarding asks for company name, mission, CEO name, adapter config, and then creates a task to "hire a founding engineer." None of this maps to a solo developer with a root directory of projects. Nexus asks for ONE thing (root directory), auto-creates PM + Engineer agents with sane templates, and drops the user in the dashboard.
-
-**Why it matters:** Paperclip's own product notes flag "getting from install to first task in under 5 minutes" as a stated goal, not yet achieved consistently. This is the single highest-impact UX change.
-
-**Complexity:** Medium (requires rewriting `OnboardingWizard.tsx` step sequence and `onboard.ts` CLI wizard; no schema changes)
-
-**Dependencies:** Predefined agent templates (D2) must exist before onboarding can auto-create them.
-
----
-
-### D2: Predefined Agent Templates (PM + Engineer)
-**Value:** Instead of asking "what should I name my CEO and what adapter should it use?", Nexus ships two templates that are immediately useful: a Project Manager agent wired to delegate and coordinate, and an Engineer agent wired to execute code tasks.
-
-**Why it matters:** The upstream's default first task ("hire a founding engineer, write a hiring plan") is designed for a multi-agent org-building flow. Solo developers do not want to bootstrap an org — they want to point agents at work. Opinionated defaults remove the blank-canvas paralysis.
-
-**Complexity:** Low (template content in AGENTS.md / HEARTBEAT.md / SOUL.md / TOOLS.md files; no schema changes; one new UI dropdown in "Add Agent" dialog)
-
-**Dependencies:** None — these are static files bundled with the fork.
-
----
-
-### D3: Workspace-First Mental Model
-**Value:** Replacing the Company/CEO metaphor with Workspace/Project Manager throughout every user-facing surface creates a consistent mental model. When every button, heading, and CLI response uses the same vocabulary, the user stops translating and starts working.
-
-**Why it matters:** Every time a user sees "CEO" or "Company" in the Nexus UI, it costs cognitive load. Multiplied across hundreds of daily interactions, this friction accumulates. The rename is not cosmetic — it removes a persistent mismatch between the user's world model and the tool's communication.
-
-**Complexity:** Medium (systematic string audit across `ui/src/`, `cli/src/`, agent template files; the work is large in surface area but each change is trivial)
-
-**Dependencies:** None — display-only. Each component can be renamed independently.
-
----
-
-### D4: Human-Readable Agent Directories Under User Root
-**Value:** Instead of `~/.paperclip/` opaque config, Nexus stores everything under the user-chosen root directory with human-readable names. An agent called "Engineer" lives at `~/RaglanWork/agents/engineer/`. The user can `ls` their agent setup.
-
-**Why it matters:** Solo developers inspect their file system. Opaque hidden directories make tooling feel like a black box. Transparent directory layout builds trust and makes debugging obvious.
-
-**Complexity:** Medium (requires updating config resolution in CLI and server to respect `~/.nexus` pointer file; no DB changes)
-
-**Dependencies:** Zero-question onboarding (D1) — the root directory picker sets the base path.
-
----
-
-### D5: Nexus Branding Throughout
-**Value:** Consistent logo, color, app name, tab title, CLI program name (`nexus` not `paperclipai`), and absence of any upstream branding.
-
-**Why it matters:** Every occurrence of "Paperclip" in a tool you use daily is a reminder that you are using someone else's thing. Branding the fork removes that friction.
-
-**Complexity:** Low (HTML `<title>`, favicon, logo asset swap, CLI binary name in `package.json`, help text strings)
-
-**Dependencies:** None — purely presentational.
-
----
-
-### D6: "Add Agent" Dialog with Template Dropdown
-**Value:** The current upstream flow says "hire" an agent. Nexus replaces this with "Add Agent" with a dropdown of predefined templates (PM, Engineer, custom). Users pick a template and get a pre-configured agent immediately.
-
-**Why it matters:** The hiring metaphor forces users through a corporate onboarding flow. The template dropdown reduces the mental model to "pick what kind of agent you want."
-
-**Complexity:** Low (UI-only change to the dialog component; templates are static config)
-
-**Dependencies:** Predefined agent templates (D2) must be defined.
-
----
-
-## Anti-Features
-
-Things to deliberately NOT change in v1. Each has a reason.
-
-| Anti-Feature | Why Avoid | What to Do Instead |
-|--------------|-----------|-------------------|
-| Rename DB columns (`company_id`, `companies` table) | Breaks upstream rebase permanently; any `git rebase upstream/master` creates hundreds of conflicts with zero benefit | Accept the mismatch; translate at the display layer |
-| Rename API routes (`/api/companies`) | UI already translates; server staying upstream-compatible means zero merge conflicts on route changes | Keep routes; update only the client-side labels |
-| Rename TypeScript identifiers (`companyService`, `boardAuthService`) | Mechanical but enormous merge conflict surface; thousands of import statements | Leave unchanged; the identifier is not user-visible |
-| Rename environment variables (`PAPERCLIP_*`) | Would break every existing deployment config and upstream docs | Keep env vars; update only the user-facing config documentation |
-| Rename plugin API contracts (`company.created` events) | Would break any existing plugins silently | Leave event names unchanged; document the mismatch for plugin authors |
-| Rename `.paperclip.yaml` export format | Would break import compatibility with upstream instances | Keep format; rename only the CLI command description, not the file format |
-| Full Catppuccin Mocha theme | High visual complexity for v1; risk of breaking responsive layout | Treat as stretch goal; focus on vocabulary rename first |
-| Multi-workspace support UI overhaul | The upstream multi-company feature already works; it's just renamed | Rename "Companies" → "Workspaces" in the switcher; don't rebuild the underlying logic |
-| Telegram Channels integration | Separate project scope | Defer entirely |
-| Recipe Registry plugin | Separate project scope | Defer entirely |
-| MCP connector layer | Upstream adapter system already handles this via the adapter registry and process/http adapters | Do not add a new abstraction layer on top |
-| Agent observability / tracing / OTEL | Enterprise-grade monitoring is overkill for a single-developer Mac Mini deployment | The upstream heartbeat logs + SSE updates are sufficient |
-
----
-
-## Feature Dependencies
-
-```
-D2 (Agent Templates)
-  → D1 (Zero-Question Onboarding)     [onboarding auto-creates templates; templates must exist first]
-  → D6 (Add Agent Dialog w/ templates) [dropdown requires templates to be defined]
-
-D1 (Zero-Question Onboarding)
-  → D4 (Human-Readable Directories)   [root directory picker sets the base; directory layout flows from it]
-
-D5 (Branding)                         [no dependencies; can ship independently]
-D3 (Workspace Mental Model)           [no dependencies; can ship incrementally per surface]
-```
-
-**Critical path:** D2 → D1 → D4. Templates first, then onboarding wizard, then directory structure. D3, D5, D6 can ship in any order alongside or after.
-
----
-
-## MVP Recommendation
-
-Prioritize in this order:
-
-1. **D2 — Predefined agent templates** (AGENTS.md, HEARTBEAT.md, SOUL.md, TOOLS.md for PM + Engineer)
-2. **D1 — Zero-question onboarding** (rewrite wizard to use root dir + auto-create from templates)
-3. **D3 — Workspace mental model rename** (systematic string pass across UI + CLI)
-4. **D5 — Nexus branding** (logo, title, CLI binary name)
-5. **D6 — Add Agent dialog** (template dropdown)
-6. **D4 — Human-readable directories** (`.nexus` pointer file + root-relative paths)
-
-**Defer to v2:**
-- Full Catppuccin Mocha theme (stretch, high visual risk)
-- Telegram integration (separate project)
-- Recipe Registry (separate project)
-- Any plugin API renames (breaks plugins)
-
----
-
-## Confidence Assessment
-
-| Area | Confidence | Notes |
-|------|------------|-------|
-| Table stakes features | HIGH | Derived directly from codebase analysis; features exist and are verified |
-| Differentiator prioritization | MEDIUM | Based on Paperclip's own stated onboarding goals (product docs) + ecosystem research |
-| Anti-feature list | HIGH | Based on explicit PROJECT.md constraints and merge-conflict risk analysis |
-| UX claims (cognitive load, blank-canvas friction) | LOW | Reasonable inference from UX research but not validated against actual users |
-| Complexity estimates | MEDIUM | Based on reading the codebase; no actual implementation attempted |
-
----
-
-## Sources
-
-- Paperclip codebase analysis: `/Volumes/UsbNvme/agent/.planning/codebase/ARCHITECTURE.md`
-- Project context: `/Volumes/UsbNvme/agent/.planning/PROJECT.md`
-- [Paperclip GitHub README](https://github.com/paperclipai/paperclip)
-- [Paperclip AI Review (The 4th Path, 2026)](https://www.the4thpath.com/2026/03/paperclip-ai-review-if-agents-are.html)
-- [Paperclip Review 2026 — AI Agent Teams as Companies (VibeCoding)](https://vibecoding.app/blog/paperclip-review)
-- [What Is an AI Agent Orchestration Platform? (Teneo, 2026)](https://www.teneo.ai/blog/what-is-an-ai-agent-orchestration-platform-benefits-features-use-cases-2026)
-- [Designing For Agentic AI: Practical UX Patterns (Smashing Magazine, 2026)](https://www.smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/)
-- [AI Agent Monitoring: Best Practices, Tools, and Metrics (UptimeRobot, 2026)](https://uptimerobot.com/knowledge-hub/monitoring/ai-agent-monitoring-best-practices-tools-and-metrics/)
-- [Learnings From Forking an Open Source Project (Echobind)](https://echobind.com/post/learnings-from-forking-an-open-source-project)
-- [Top 5 AI Agent Observability Platforms (o-mega, 2026)](https://o-mega.ai/articles/top-5-ai-agent-observability-platforms-the-ultimate-2026-guide)

.planning/research/PITFALLS.md

@@ -1,277 +0,0 @@
-# Domain Pitfalls — Nexus Fork of Paperclip
-
-**Domain:** Forked open-source project with display-layer renames, no i18n layer
-**Researched:** 2026-03-30
-**Confidence:** HIGH — based primarily on direct codebase analysis of `/Volumes/UsbNvme/repos/nexus` via CONCERNS.md, supplemented by fork maintenance community research
-
----
-
-## Critical Pitfalls
-
-Mistakes that cause data loss, broken upstream rebase, or irreversible divergence.
-
----
-
-### Pitfall 1: Renaming a Code Identifier That Is Also a Stored DB Value
-
-**What goes wrong:** You rename a TypeScript constant, CLI command, or function to use the new Nexus vocabulary, not realising the same string is also stored as a literal value in database rows. The app breaks for any existing installation because the server checks `approval.type === "hire_agent"` but the DB still has `"hire_agent"` rows. Or worse: you change the constant on one side (server) but not the other (CLI) and the two sides silently disagree.
-
-**Why it happens:** In Paperclip the same string serves double duty: it is both a TypeScript constant/enum and a persisted DB value. The CONCERNS.md audit identifies these dual-purpose strings explicitly:
-- `"ceo"` — stored in `agents.role` column AND used in TypeScript `AGENT_ROLES` array
-- `"hire_agent"` — stored in `approvals.type` column AND checked in route handlers
-- `"approve_ceo_strategy"` — stored in `approvals.type` column AND displayed in `ApprovalPayload.tsx`
-- `"bootstrap_ceo"` — stored in `invites.invite_type` column AND checked in `InviteLanding.tsx`
-- `"company"` — stored as a value in `goals.level` column AND used as a string literal in constants
-- `"board"` — stored in `cli_auth_challenges.requested_access` column AND used in auth middleware
-
-**Consequences:** Silent data incompatibility on existing installations. New rows written with the renamed value, old rows still have the old value. Code that does `WHERE type = $new_value` misses all old rows. A fresh install works; an existing install silently loses data or shows empty lists.
-
-**Prevention:**
-1. Treat every string in the Summary Risk Table (CONCERNS.md) marked "Critical" as immutable. Do not rename them, even in display contexts, without a data migration.
-2. For display renaming only: change the label map (`AGENT_ROLE_LABELS`, `ApprovalPayload` display maps) without touching the underlying constant value. Rename `ceo: "CEO"` to `ceo: "Project Manager"` — the key `ceo` stays, the display label changes.
-3. Before touching any string, grep for it in the schema directory (`packages/db/src/schema/`) and migration files. If it appears there, it is a stored value, not just a display string.
-
-**Detection (warning signs):**
-- Any string that also appears in `packages/db/src/schema/` or `packages/db/src/migrations/` is a stored value
-- Approval, invite, and goal lists that show empty on an existing install but work on a fresh install
-- TypeScript constants in `APPROVAL_TYPES`, `INVITE_TYPES`, `GOAL_LEVELS`, `AGENT_ROLES` — these feed directly into DB queries
-
-**Phase:** Phase 1 (Display Rename). Must be resolved before any rename touches these identifiers.
-
----
-
-### Pitfall 2: Treating "Display-Only Rename" as a Simple Find-Replace
-
-**What goes wrong:** You run a bulk `sed` or IDE find-replace on "company" → "workspace" across the entire codebase to get the strings right fast. The rename touches service files, route files, schema files, and test files indiscriminately. The next `git rebase upstream/master` has conflicts on hundreds of files, most of which were upstream-compatible before.
-
-**Why it happens:** "Display-only" is a *policy* decision, not a property the codebase enforces. Nothing in the TypeScript source distinguishes a user-facing label string from an internal identifier. Both are just string literals. A naive find-replace cannot tell `<h1>Company Settings</h1>` (display — safe to rename) from `companyService()` (code identifier — must not be renamed) from `"company"` in `GOAL_LEVELS` (stored DB value — renaming breaks data).
-
-**Consequences:** Blown upstream sync. Every file that had `company` as a code identifier now has a conflict on rebase. The entire maintenance advantage of display-only renaming is lost. Recovering requires reverting the bulk rename and redoing it file-by-file.
-
-**Prevention:**
-1. Establish a strict three-zone taxonomy before touching any string:
-   - **Zone A — Display strings**: JSX text nodes, `p.log()` CLI output, Markdown prose in onboarding assets, comment text. These are in scope.
-   - **Zone B — Code identifiers**: TypeScript variable names, function names, class names, file names, import paths, package names. These are OUT of scope.
-   - **Zone C — Dual-purpose stored values**: strings that are both code constants and stored in the DB (see Pitfall 1). OUT of scope for value; label-map only for display.
-2. Never run a global find-replace. Work file-by-file with the zone taxonomy applied per file.
-3. When unsure, ask: "Would upstream Paperclip have to change this file to fix a bug?" If yes, minimise changes to it.
-
-**Detection (warning signs):**
-- A PR diff that touches `server/src/services/`, `server/src/routes/`, or `packages/db/` with rename changes is a red flag
-- A diff that shows changes to TypeScript identifier names (not string literals in JSX) is a Zone B violation
-- Rebase producing conflicts in files not intentionally modified by Nexus
-
-**Phase:** Phase 1 (Display Rename). The zone taxonomy must be documented and applied from the first commit.
-
----
-
-### Pitfall 3: Diverging the Onboarding Assets Directory Name From Upstream
-
-**What goes wrong:** You rename the `server/src/onboarding-assets/ceo/` directory to `server/src/onboarding-assets/pm/` (or similar) to match the new PM vocabulary. Upstream changes a file inside `ceo/` in a future commit. `git rebase` cannot reconcile a file renamed on one side with a content edit on the other — it presents as a delete/modify conflict and the upstream change is silently dropped.
-
-**Why it happens:** Git rename detection is heuristic. When you rename a directory AND upstream edits a file within that directory, git frequently misidentifies this as "deleted old file + created new file" rather than "renamed file + edited renamed file." The merge resolves by keeping your renamed version and discarding upstream's content edit.
-
-**Consequences:** You silently miss upstream improvements to agent instructions. If upstream fixes a security or correctness issue in the default agent template, your fork never gets it.
-
-**Prevention:**
-1. Do not rename the `ceo/` directory. Keep the directory path as `onboarding-assets/ceo/` in the filesystem. Only change the file *content* (the Markdown prose that says "You are the CEO").
-2. The directory name `ceo/` is an internal asset path loaded by `default-agent-instructions.ts` — it is Zone B. The prose inside `SOUL.md`, `AGENTS.md`, `HEARTBEAT.md` is Zone A.
-3. If a directory rename is truly necessary, document it explicitly and set up a post-rebase hook that verifies the content was not silently dropped.
-
-**Detection (warning signs):**
-- Rebase conflict shows a file as "deleted" that you expected to be "modified"
-- Upstream changelog mentions onboarding asset changes but your fork's onboarding assets are unchanged after rebase
-
-**Phase:** Phase 1 (Onboarding Redesign). Address before modifying any asset file.
-
----
-
-### Pitfall 4: Changing the `localStorage` Key or `~/.paperclip` Config Path Without a Migration
-
-**What goes wrong:** The UI stores the selected company/workspace ID in `localStorage` under the key `"paperclip.selectedCompanyId"` (identified in `CompanyContext.tsx`). If you rename this key to `"nexus.selectedWorkspaceId"`, every existing browser session loses its selected workspace on next load. Similarly, if `~/.paperclip` config path is changed to `~/.nexus` without migrating existing data, the server starts as if it were a fresh install, losing all existing agents, API keys, and worktrees.
-
-**Why it happens:** These are persisted-state keys — they survive across deploys. Unlike code, they cannot be "renamed" by changing source; existing data already written under the old key must be read and migrated or the old key must continue to be read as a fallback.
-
-**Consequences:** On `~/.paperclip` rename: complete data loss for the running installation. All agents, projects, API keys, and worktrees appear to vanish. On `localStorage` key rename: users are logged out of the UI on next load (minor but disorienting).
-
-**Prevention:**
-1. For `~/.paperclip`: Keep the default path OR implement a read-both-paths fallback (check `~/.nexus` first, fall back to `~/.paperclip`, emit a deprecation log). The `~/.nexus` pointer-file mechanism described in PROJECT.md should write to `~/.nexus` but read from `~/.paperclip` if `~/.nexus` does not exist.
-2. For `localStorage`: Either keep the key name `"paperclip.selectedCompanyId"` (it is internal, users never see it), or write a migration on app boot that reads the old key and writes the new key before deleting the old one.
-3. Treat `PAPERCLIP_*` environment variable names as immutable for the same reason — existing Docker configs and systemd units use them.
-
-**Detection (warning signs):**
-- After deploy, server logs show "no config found, starting fresh" on a machine with existing data
-- UI shows empty workspace list on first load after deploy
-- `docker-compose.untrusted-review.yml` still references `PAPERCLIP_HOME` after an env var rename
-
-**Phase:** Phase 2 (Directory Restructure / `~/.nexus` Pointer). Must have migration or fallback before shipping.
-
----
-
-### Pitfall 5: Upstream Rebase Cadence Slipping Below Weekly
-
-**What goes wrong:** The fork is deployed and working. A busy week becomes two, then a month. Upstream ships 15 commits. Now the rebase involves resolving conflicts in files you modified for display renames AND new logic added upstream to the same files. What was a 10-minute weekly rebase becomes a 4-hour archaeology session. This compounds: the next month is even harder.
-
-**Why it happens:** Fork drift is non-linear. Each upstream commit that touches a file you also modified adds another conflict to resolve. When upstream commits accumulate faster than you rebase, the conflict count grows faster than linearly because upstream changes begin to interact with each other in ways that are opaque without context.
-
-**Consequences:** Either you stop rebasing (fork permanently diverges, missing security patches and new features) or you spend disproportionate time on merge archaeology. Community research confirms: "initial updates took minutes; later attempts required an hour or two."
-
-**Prevention:**
-1. Rebase against `upstream/master` at minimum weekly, ideally on a fixed schedule (e.g., every Sunday).
-2. Keep a `[nexus]` commit prefix convention strictly — every Nexus-specific commit is prefixed. This makes it trivial to identify which commits are yours vs. rebased upstream commits during conflict resolution.
-3. Run a CI check (even a local cron) that attempts `git rebase upstream/master` on a test branch and alerts on failure. Catch conflicts before they accumulate.
-4. If an upstream commit touches a file you have also modified, resolve it immediately rather than deferring.
-
-**Detection (warning signs):**
-- Last rebase was more than 2 weeks ago
-- `git log upstream/master..HEAD` shows more than 20 upstream commits unmerged
-- Rebase produces conflicts in more than 5 files at once
-
-**Phase:** Ongoing. Establish cadence in Phase 1; automate alert in Phase 2.
-
----
-
-## Moderate Pitfalls
-
----
-
-### Pitfall 6: Renaming the CLI Binary Name (`paperclipai` → `nexus`) Without a Shim
-
-**What goes wrong:** The CLI binary is currently invoked as `pnpm paperclipai run`. The UI (`App.tsx`, `startup-banner.ts`) renders the literal string `pnpm paperclipai auth bootstrap-ceo` as instructional copy. If you rename the binary to `nexus` but forget to update every UI string that mentions `paperclipai`, users see a mix of `nexus` and `paperclipai` commands in the UI, causing confusion and failed copy-paste attempts.
-
-**Why it happens:** The binary name appears in at least four distinct locations: `package.json` bin entry, `startup-banner.ts`, `App.tsx`, and `onboard.ts` terminal output. These are not linked by a constant. Changing the binary name in `package.json` alone does not update the rendered copy.
-
-**Prevention:**
-1. Inventory every occurrence of `paperclipai` as a user-facing command string (not package name) before renaming.
-2. Consider keeping the binary named `paperclipai` and adding a `nexus` alias, so existing muscle memory and documented commands continue to work. The alias can be the primary name in Nexus docs while `paperclipai` continues to work.
-3. If renaming, treat it as an atomic change: rename binary, update all instructional strings, update docs, and test the smoke tests in one commit.
-
-**Detection (warning signs):**
-- `startup-banner.ts` still says `paperclipai` after binary rename
-- `ui/src/pages/App.tsx` shows mixed command names
-
-**Phase:** Phase 1 (CLI String Updates).
-
----
-
-### Pitfall 7: Partial Rename — Changing Some Occurrences But Not All
-
-**What goes wrong:** You rename "CEO" → "Project Manager" in the `OnboardingWizard.tsx` default task description and the `AGENT_ROLE_LABELS` constant, but miss the `DEFAULT_TASK_DESCRIPTION` which starts "You are the CEO." You also miss `InviteLanding.tsx` which checks `invite.inviteType === "bootstrap_ceo"` and renders "Bootstrap your Paperclip instance." Users see a mix of "CEO" and "Project Manager" in different parts of the UI.
-
-**Why it happens:** With no i18n layer, there is no single source of truth for any display string. "CEO" appears in at least 12 distinct files. A partial search (only checking one or two obvious files) will miss the rest. There is no compile-time check that a string has been fully replaced.
-
-**Consequences:** Inconsistent vocabulary in the product. Users see "Project Manager" on the dashboard and "CEO" in the invite flow and onboarding wizard. This degrades trust in the product.
-
-**Prevention:**
-1. Before declaring a rename complete, run a case-insensitive `grep -r "CEO" ui/src cli/src server/src` and verify that every remaining occurrence is either: (a) intentionally kept (Zone B/C), or (b) not user-visible (e.g., an internal comment).
-2. Maintain a rename checklist in `.planning/` that tracks each term and its known locations. Check off each location as it is addressed.
-3. After each phase, do a full-corpus string audit for any target terms that should have been renamed.
-
-**Detection (warning signs):**
-- grep of the target term still returns JSX text nodes after the rename commit
-- Onboarding flow or invite page still shows old vocabulary
-
-**Phase:** Phase 1 (Display Rename). Checklist needed before Phase 1 is marked complete.
-
----
-
-### Pitfall 8: The `[nexus]` Commit Prefix Not Applied Consistently From the Start
-
-**What goes wrong:** Early commits are made without the `[nexus]` prefix convention. Later, when rebasing, you cannot easily distinguish "these are our changes, apply them on top of new upstream" from "this is an upstream commit we already rebased." You end up with duplicate commits or missing commits.
-
-**Why it happens:** The prefix convention feels optional at the start when there are only a few commits. Once there are 30+ commits, inconsistent prefixing means manual archaeology to reconstruct which commits are yours.
-
-**Prevention:**
-1. Apply `[nexus]` prefix from the very first commit in the fork.
-2. Add a pre-commit hook that rejects commits whose message does not start with `[nexus]` or `[upstream]` (or an equivalent marker).
-3. Periodically run `git log --oneline HEAD` and verify every Nexus commit has the prefix.
-
-**Detection (warning signs):**
-- Any commit without `[nexus]` prefix in the fork's log
-- Difficulty answering "which commits are mine?" during a rebase
-
-**Phase:** Phase 1. The hook should be in place before the first Nexus commit.
-
----
-
-### Pitfall 9: Onboarding Redesign Coupled to the Corporate Metaphor in Data Layer
-
-**What goes wrong:** The new onboarding flow (root directory picker, auto-create PM + Engineer) is implemented by calling the existing `companiesApi.create()` endpoint. But the wizard's UI variables are all named `companyName`, `companyGoal`, and the new onboarding flow does not pass a "company name" at all (the user picks a directory, not a name). If you rename the variables in the wizard without considering what the API expects, the API call sends an empty or undefined `name` field, and the company is created with no name.
-
-**Why it happens:** The onboarding redesign changes the *UX flow* (fewer steps, different inputs) but the *API shape* has not changed. The mismatch between "user provides a directory path" and "API requires a company name" must be explicitly resolved — probably by deriving the workspace name from the directory basename.
-
-**Prevention:**
-1. Document the API contract (`POST /api/companies` body shape) before redesigning the wizard. Identify every required field.
-2. For fields no longer collected from the user (company name), define a derivation rule (e.g., `basename(rootDir)`) and implement it explicitly rather than relying on defaults.
-3. Test the onboarding flow with a fresh database to verify no required field is silently undefined.
-
-**Detection (warning signs):**
-- Workspace created with an empty name after the new onboarding flow
-- API 422 errors in the network tab after submitting the redesigned onboarding form
-
-**Phase:** Phase 2 (Onboarding Redesign).
-
----
-
-## Minor Pitfalls
-
----
-
-### Pitfall 10: Forgetting to Update Tests That Assert on Display Strings
-
-**What goes wrong:** `server/src/__tests__/invite-onboarding-text.test.ts` likely asserts that invite text contains "CEO." After renaming "CEO" to "Project Manager" in the display layer, the test fails. This is the correct outcome — the test needs to be updated — but if you do not notice it, you either ship a failing test suite or (worse) you revert the display rename to make tests pass.
-
-**Why it happens:** Tests that assert on display strings are fragile to any vocabulary change. There is no way to know from the source that `invite-onboarding-text.test.ts` contains "CEO" assertions without reading it.
-
-**Prevention:**
-1. Before any rename commit, run `grep -r "CEO\|company\|board\|hire\|fire\|paperclip" --include="*.test.ts" cli/src server/src ui/src` to find all test files that will need updating.
-2. Update the relevant tests in the same commit as the display string change — not in a follow-up commit.
-
-**Detection (warning signs):**
-- CI fails on a test whose name contains "invite", "onboarding", or "branding" after a string rename
-
-**Phase:** Phase 1 (Display Rename). Pre-rename test audit is a prerequisite step.
-
----
-
-### Pitfall 11: Exporting a `.nexus.yaml` File While Upstream Exports `.paperclip.yaml`
-
-**What goes wrong:** If the export file format is renamed to `.nexus.yaml`, any workspace exported from a Nexus instance cannot be imported into an upstream Paperclip instance and vice versa. This breaks the stated goal of "import upstream company bundles" and creates a permanent portability split.
-
-**Why it happens:** The export format is an identifiable artifact with a schema header (`schema: paperclip/v1`). Renaming only the file extension while keeping the schema header creates a confusing half-rename. Renaming both breaks import compatibility.
-
-**Prevention:**
-1. Keep emitting `.paperclip.yaml` and reading `.paperclip.yaml`. The filename and schema header are Zone B/C — they are part of the interchange contract with upstream.
-2. If a Nexus-native export format is ever needed, emit `.nexus.yaml` as an *additional* file alongside `.paperclip.yaml`, not as a replacement.
-
-**Detection (warning signs):**
-- Attempting to import a workspace from upstream Paperclip into Nexus returns "unrecognised format" error
-
-**Phase:** Phase 1 (Display Rename). Decide explicitly: keep `.paperclip.yaml` unchanged.
-
----
-
-## Phase-Specific Warnings
-
-| Phase Topic | Likely Pitfall | Mitigation |
-|-------------|---------------|------------|
-| Display rename — CEO/Board/Company strings | Pitfall 1 (dual-purpose stored values) | Rename label maps only; leave constant values (`"ceo"`, `"hire_agent"`) unchanged |
-| Display rename — bulk approach | Pitfall 2 (Zone B contamination) | File-by-file using zone taxonomy; never global find-replace |
-| Onboarding asset content rewrite | Pitfall 3 (directory rename breaks git rebase) | Change file content only; leave `ceo/` directory name unchanged |
-| CLI binary rename `paperclipai` → `nexus` | Pitfall 6 (partial instructional string update) | Atomic commit covering all instructional copy |
-| Onboarding redesign (root dir picker) | Pitfall 9 (API shape mismatch) | Document API contract first; derive workspace name from directory basename |
-| `~/.nexus` pointer file mechanism | Pitfall 4 (data path migration) | Read-both-paths fallback; never rename path without migration |
-| `[nexus]` commit convention | Pitfall 8 (inconsistent prefix) | Pre-commit hook from first commit |
-| Upstream rebase cadence | Pitfall 5 (drift) | Weekly schedule; CI rebase check |
-| Test suite after string renames | Pitfall 10 (test assertions on display strings) | Pre-rename test audit; update tests in same commit |
-| Export file format | Pitfall 11 (`.paperclip.yaml` vs `.nexus.yaml`) | Keep upstream format; no rename |
-
----
-
-## Sources
-
-- Codebase analysis: `/Volumes/UsbNvme/agent/.planning/codebase/CONCERNS.md` — direct audit of Paperclip source (HIGH confidence)
-- [Stop Forking Around — Fork Drift in Open Source](https://preset.io/blog/stop-forking-around-the-hidden-dangers-of-fork-drift-in-open-source-adoption/) — fork drift patterns (MEDIUM confidence)
-- [Lessons Learned from Maintaining a Fork](https://dev.to/bengreenberg/lessons-learned-from-maintaining-a-fork-48i8) — exponential maintenance cost (MEDIUM confidence)
-- [Friendly Fork Management — GitHub Blog](https://github.blog/2022-05-02-friend-zone-strategies-friendly-fork-management/) — sync strategies, conflict accumulation (MEDIUM confidence)
-- [The Dynamic Relationship of Forks with Upstream](https://ropensci.org/blog/2025/02/20/forks-upstream-relationship/) — upstream isolation patterns (MEDIUM confidence)

.planning/research/STACK.md

@@ -1,364 +0,0 @@
-# Technology Stack: Fork Maintenance Approach
-
-**Project:** Nexus (fork of Paperclip)
-**Researched:** 2026-03-30
-**Scope:** Safely maintaining a display-layer fork of a TypeScript monorepo while staying rebassable on upstream
-
----
-
-## Summary Recommendation
-
-Use **git rebase with a [nexus] commit prefix convention** for fork maintenance. Extract all display strings into **a single `packages/branding/` package** that acts as the exclusive mutation surface. Keep every code identifier, route, schema, and package name unchanged. This combination minimises conflict surface to two file types: branding constants and onboarding assets.
-
----
-
-## 1. Fork Maintenance Strategy
-
-### Recommended: Rebase-Over-Upstream with Prefix Convention
-
-**Confidence: HIGH** — Used by git-for-windows, microsoft/git, and VSCodium. Standard practice for long-lived forks.
-
-**How it works:**
-
-Every Nexus-specific commit carries a `[nexus]` prefix in the commit message. On each upstream release:
-
-```bash
-git fetch upstream
-git rebase upstream/master
-```
-
-During rebase, conflicts only appear on commits that touch the same lines as upstream changes. With display-only mutations (string constants, Markdown prose, one config file), the conflict surface is tiny. Non-conflicting commits replay cleanly.
-
-**Commit message convention:**
-```
-[nexus] Rename CEO→Project Manager in OnboardingWizard
-[nexus] Replace AGENT_ROLE_LABELS display value for ceo role
-[nexus] Rewrite onboarding-assets/ceo/ SOUL.md and AGENTS.md
-```
-
-The prefix does two things: it makes `[nexus]` commits immediately identifiable in `git log`, and it allows `git range-diff` to verify that a rebase correctly replayed all downstream patches.
-
-**Verification after every upstream sync:**
-
-```bash
-# Compare the old and new version of the downstream patch series
-git range-diff upstream/master ORIG_HEAD HEAD
-```
-
-`git range-diff` shows which `[nexus]` commits changed during rebase (conflict resolutions), which replayed identically, and which were dropped. This is the standard tool used by the Git project itself for patch-series validation. **Confidence: HIGH** (official Git tooling, not a third-party tool).
-
-**Enable rerere to auto-replay recurring resolutions:**
-
-```bash
-git config rerere.enabled true
-```
-
-`git rerere` records how each conflict was resolved. On the next upstream sync, if the same conflict hunk appears again (common when upstream frequently touches the same area), Git auto-resolves it identically. This eliminates repetitive manual conflict resolution. **Confidence: HIGH** (official Git feature, described in Pro Git book).
-
-**Atomic commits — most important discipline:**
-
-Each `[nexus]` commit must touch exactly one logical unit. Never mix a display-string change with a behaviour change in the same commit. Rationale: if upstream changes the same file for a different reason, a mixed commit creates conflicts in code paths you didn't mean to touch. Atomic commits mean a conflict only appears on the exact line you changed. **Confidence: HIGH** (documented in git-for-windows strategy and GitHub's friendly fork guide).
-
----
-
-### Alternative Considered: git-format-patch / Quilt-style Patch Queue
-
-**What it is:** Maintain Nexus changes as a series of `.patch` files outside the tree, applied on top of a clean upstream checkout. Used by VSCodium for build-time patch application with placeholder substitution.
-
-**Why not for Nexus:** VSCodium's patch approach works because they rebuild from source on every release. Nexus is a live development fork where engineers commit code daily. Applying patches at build time would break the normal `git commit` / `git push` workflow. Rebase-over-upstream is the right model when the fork is being actively developed, not just rebranded at release time.
-
-**Confidence: MEDIUM** — VSCodium's approach is well-documented but architecturally different from a dev fork.
-
----
-
-### Alternative Considered: Merge (not rebase)
-
-Merge upstream with `git merge upstream/master` produces a merge commit that interleaves upstream and Nexus history. GitHub's friendly fork guide recommends merge for multi-contributor forks. For a solo-developer fork with a small, clearly bounded patch set, rebase produces a cleaner history and makes it obvious exactly which commits are Nexus-specific. Use merge only if the team grows beyond one or two contributors.
-
----
-
-## 2. String Extraction Pattern
-
-### Recommended: Centralised Branding Package with Typed Constants
-
-**Confidence: HIGH** — Standard TypeScript monorepo pattern, no third-party risk.
-
-#### Why NOT i18n (react-i18next, LinguiJS, etc.)
-
-i18n libraries are designed for multi-locale text management. They add runtime overhead, require JSON translation files, and introduce a dependency that Paperclip upstream does not have. Importing one into a display-layer fork creates a new package.json entry that will conflict if upstream ever adds i18n itself. The simpler approach is a plain TypeScript constants module.
-
-#### The Pattern: `packages/branding/`
-
-Create a dedicated workspace package at `packages/branding/` that is the single place all display-layer strings live. Nothing else in the monorepo hardcodes Nexus-facing strings.
-
-**Package structure:**
-
-```
-packages/branding/
-  src/
-    index.ts          -- re-exports everything
-    vocabulary.ts     -- entity names (Workspace, Project Manager, Owner)
-    ui-labels.ts      -- button text, page titles, sidebar labels
-    cli-strings.ts    -- CLI output messages, prompts, banner
-    agent-roles.ts    -- display labels for role constants
-  package.json        -- name: "@paperclipai/branding" (keeps @paperclipai namespace)
-  tsconfig.json
-```
-
-**`vocabulary.ts` example:**
-
-```typescript
-export const VOCAB = {
-  // The Company entity displayed as:
-  company: {
-    singular: "Workspace",
-    plural: "Workspaces",
-    possessive: "Workspace's",
-  },
-  // The CEO role displayed as:
-  ceo: {
-    singular: "Project Manager",
-    short: "PM",
-  },
-  // The Board role displayed as:
-  board: {
-    singular: "Owner",
-  },
-  // Product name
-  product: {
-    name: "Nexus",
-    cli: "nexus",
-    tagline: "Your agent workspace",
-  },
-} as const;
-```
-
-**`agent-roles.ts` example — overrides `AGENT_ROLE_LABELS` from shared:**
-
-```typescript
-import { AGENT_ROLE_LABELS } from "@paperclipai/shared";
-
-// Override display labels only. Underlying keys (ceo, engineer, etc.) are unchanged.
-export const DISPLAY_ROLE_LABELS: typeof AGENT_ROLE_LABELS = {
-  ...AGENT_ROLE_LABELS,
-  ceo: "Project Manager",
-};
-```
-
-**Why keep the package name `@paperclipai/branding`:** The `@paperclipai/*` namespace is used by thousands of import statements. Adding a new package under the same namespace costs nothing and avoids the namespace change that would ripple through every file. The branding package is net-new; it does not rename any existing package.
-
-**Usage in UI:**
-
-Components import from `@paperclipai/branding` instead of hardcoding strings. The existing `AGENT_ROLE_LABELS` from `@paperclipai/shared` stays unchanged; components use `DISPLAY_ROLE_LABELS` from branding instead.
-
-```tsx
-// Before (upstream hardcoded):
-<span>Company</span>
-<span>{AGENT_ROLE_LABELS[agent.role]}</span>
-
-// After (Nexus):
-import { VOCAB, DISPLAY_ROLE_LABELS } from "@paperclipai/branding";
-<span>{VOCAB.company.singular}</span>
-<span>{DISPLAY_ROLE_LABELS[agent.role]}</span>
-```
-
-**Usage in CLI (`cli/src/commands/onboard.ts`):**
-
-```typescript
-import { VOCAB } from "@paperclipai/branding";
-
-p.intro(`${VOCAB.product.name} setup`);
-// Replaces: p.intro("Paperclip setup");
-```
-
-**Usage in server banner (`server/src/startup-banner.ts`):**
-
-```typescript
-import { VOCAB } from "@paperclipai/branding";
-
-// Replace ASCII art "PAPERCLIP" with "NEXUS"
-// Replace embedded CLI command text with VOCAB.product.cli references
-```
-
-#### What Stays in `@paperclipai/shared` — Unchanged
-
-The following stay exactly as upstream to preserve upstream rebasability:
-
-- `AGENT_ROLE_LABELS` (with `ceo: "CEO"`) — the authoritative map, untouched
-- `AGENT_ROLES` array containing `"ceo"` — these are stored values, not display strings
-- `APPROVAL_TYPES`, `INVITE_TYPES` — stored DB enum values, untouched
-- `API.companies = "/api/companies"` — route constants, untouched
-
-The branding package only **overrides at the callsite**, never modifying shared constants.
-
----
-
-## 3. UI Branding / Theming Layer
-
-### Recommended: CSS Custom Properties in Tailwind v4 + a Single `branding.css` File
-
-**Confidence: HIGH** — Tailwind v4's CSS-first config model is designed for this. Official Vite + Tailwind v4 docs confirm CSS custom properties as the standard.
-
-Paperclip already uses Tailwind CSS 4.0.7. In Tailwind v4, theme tokens are defined as CSS custom properties in the CSS file, not in a JavaScript config. This makes branding overrides a single CSS file change.
-
-**`ui/src/branding.css` (new [nexus] file):**
-
-```css
-/* Nexus brand overrides — Tailwind v4 custom properties */
-:root {
-  --color-brand-primary: oklch(65% 0.2 270); /* Nexus blue-purple */
-  --color-brand-secondary: oklch(75% 0.15 200);
-}
-```
-
-Import this file once in `ui/src/main.tsx` after the main Tailwind CSS import. Zero upstream conflict risk: it is a net-new file.
-
-**Vite `define` for build-time constants:**
-
-For values injected at build time (version strings, product name in `<title>` tag), use Vite's `define` option in `vite.config.ts`:
-
-```typescript
-// vite.config.ts — [nexus] section
-define: {
-  __NEXUS_PRODUCT_NAME__: JSON.stringify("Nexus"),
-  __NEXUS_VERSION__: JSON.stringify(process.env.npm_package_version),
-},
-```
-
-Declare the type in `ui/src/vite-env.d.ts`:
-
-```typescript
-declare const __NEXUS_PRODUCT_NAME__: string;
-```
-
-Use this only for values that must appear in static HTML before React hydrates (e.g. `<title>` tag, meta tags). Component-level strings should use the branding package, not `define`.
-
-**Why not a full Catppuccin Mocha theme in v1:** Full theme overhaul is listed as out-of-scope in PROJECT.md. CSS custom properties allow it to be added later as a single-file change.
-
----
-
-## 4. Onboarding Assets — Separate Files, Zero Code Conflict
-
-### Recommended: Direct File Replacement, No Pattern Needed
-
-**Confidence: HIGH** — This is already how the codebase works.
-
-The files in `server/src/onboarding-assets/ceo/` (SOUL.md, AGENTS.md, HEARTBEAT.md, TOOLS.md) are plain Markdown loaded at runtime via `fs.readFile`. They contain the hardcoded "You are the CEO" prose that must change for Nexus.
-
-**Strategy:** Replace these files entirely as a `[nexus]` commit. The directory name `ceo/` stays unchanged (directory rename would cause upstream conflicts on every change upstream makes to these files). The file content changes. These files are prose with no TypeScript identifiers — conflict risk is purely editorial (if upstream rewrites the CEO instructions, the rebase will conflict on the content, which is a genuine conflict to resolve manually).
-
-**For new Nexus-specific agent templates** (PM and Engineer predefined templates), add new directories:
-
-```
-server/src/onboarding-assets/
-  ceo/          -- upstream directory, content replaced by [nexus]
-  pm/           -- [nexus] new directory, PM template
-  engineer/     -- [nexus] new directory, Engineer template
-```
-
-New directories are never touched by upstream; they replay through rebase with zero conflicts.
-
----
-
-## 5. What NOT to Do — Anti-Patterns
-
-### Anti-Pattern 1: Rename any `@paperclipai/*` package
-
-**What happens:** Every TypeScript file in the monorepo imports from `@paperclipai/shared`, `@paperclipai/db`, etc. Renaming any of these produces thousands of lines of import-statement diffs across every file. On the next upstream rebase, every one of those files conflicts because upstream and Nexus both modified the imports (upstream: added a new function, Nexus: changed the import path). This turns a clean rebase into a multi-hour conflict session on every upstream release.
-
-**Instead:** Keep all `@paperclipai/*` names. The new branding package is `@paperclipai/branding` — same namespace, no existing files modified.
-
-### Anti-Pattern 2: Rename TypeScript identifiers (`companyService`, `CompanyContext`, etc.)
-
-**What happens:** If `companyService` is renamed to `workspaceService` in Nexus, any upstream commit that touches `companies.ts` will produce a conflict at that identifier. The function is the same; only the name differs. This is a pure noise conflict with zero semantic value.
-
-**Instead:** Leave all identifiers unchanged. `CompanyContext` stays `CompanyContext` internally; only the string it renders in JSX changes.
-
-### Anti-Pattern 3: Scatter display strings across individual component files
-
-**What happens:** If each component file hardcodes its own Nexus strings (`<span>Workspace</span>` scattered across 30 files), every upstream change to a component file produces a conflict on the string line. Finding and resolving these becomes the dominant cost of each sync.
-
-**Instead:** All display strings live in `packages/branding/`. Each component imports one constant. Upstream touches component logic; Nexus touches the branding package. File overlap is minimised.
-
-### Anti-Pattern 4: Change DB column names, stored enum values, or API routes
-
-**What happens:** These are breaking changes with migration requirements. They also conflict with upstream on every schema or route change.
-
-**Instead:** These are already out-of-scope per PROJECT.md. The ORM layer stays `companies`, `company_id`, `"ceo"` role. The branding package translates at display time.
-
-### Anti-Pattern 5: Mix Nexus and upstream changes in one commit
-
-**What happens:** If a `[nexus]` commit also contains an upstream bug fix, the bug fix becomes entangled with the display change. On rebase, if upstream fixes the same bug, there is a conflict in a commit that was supposed to be a display-only patch.
-
-**Instead:** If a bug fix is needed, create a separate commit without the `[nexus]` prefix. Consider submitting it upstream. Keep `[nexus]` commits purely display-layer.
-
-### Anti-Pattern 6: Rename `~/.paperclip` to `~/.nexus` (data directory)
-
-**What happens:** Requires changing `PAPERCLIP_HOME` environment variable references across server, CLI, Docker files, and documentation. Breaks all existing deployments. Creates conflicts on every upstream change touching home-path logic.
-
-**Instead:** Use `~/.nexus` as a pointer file only (containing the root directory path), as described in PROJECT.md. The actual data directory stays `~/.paperclip`. The `~/.nexus` pointer file is a net-new file; upstream never touches it.
-
----
-
-## 6. Tooling Summary
-
-| Tool | Purpose | Confidence |
-|------|---------|------------|
-| `git rebase upstream/master` | Sync with upstream releases | HIGH |
-| `[nexus]` commit prefix | Identify all downstream-only commits | HIGH |
-| `git range-diff` | Verify rebase replayed all patches correctly | HIGH |
-| `git rerere` | Auto-resolve recurring conflict patterns | HIGH |
-| `packages/branding/` package | Single mutation surface for display strings | HIGH |
-| `ui/src/branding.css` | CSS custom property overrides for Tailwind v4 | HIGH |
-| `vite.config.ts define` | Build-time product name injection for static HTML | HIGH |
-
----
-
-## 7. File Mutation Surface (Complete List)
-
-Files that `[nexus]` commits are permitted to touch, and the rationale:
-
-| File / Directory | Change Type | Upstream Conflict Risk |
-|------------------|------------|----------------------|
-| `packages/branding/` (new) | Create entire package | None — net new |
-| `ui/src/branding.css` (new) | Create branding CSS | None — net new |
-| `server/src/onboarding-assets/ceo/*.md` | Replace prose content | Low — prose-level conflict only if upstream rewrites instructions |
-| `server/src/onboarding-assets/pm/` (new) | Create PM template | None — net new |
-| `server/src/onboarding-assets/engineer/` (new) | Create Engineer template | None — net new |
-| `ui/src/components/OnboardingWizard.tsx` | Replace JSX strings with branding imports | Medium — upstream actively modifies onboarding |
-| `ui/src/pages/App.tsx` | Replace CLI command strings | Low — static text, rarely changed |
-| `server/src/startup-banner.ts` | Replace ASCII art and startup text | Low — rarely changed |
-| `cli/src/commands/onboard.ts` | Replace terminal output strings | Medium — onboarding logic changes |
-| `vite.config.ts` | Add `define` block | Low — config changes rarely conflict |
-| `ui/index.html` | Update `<title>` tag | Low — rarely touched |
-
-Files that `[nexus]` commits must NEVER touch:
-
-- `packages/db/src/schema/` — DB schema
-- `packages/db/src/migrations/` — migration SQL
-- `packages/shared/src/constants.ts` — stored enum values
-- `packages/shared/src/api.ts` — route constants
-- `server/src/routes/` — API route handlers
-- Any `package.json` `"name"` field other than the new branding package
-- `pnpm-workspace.yaml` (except to add `packages/branding`)
-- Any TypeScript identifier (function name, variable name, class name)
-
----
-
-## Sources
-
-- [History-preserving fork maintenance with git](https://amboar.github.io/notes/2021/09/16/history-preserving-fork-maintenance-with-git.html)
-- [GitHub: Strategies for friendly fork management](https://github.blog/developer-skills/github/friend-zone-strategies-friendly-fork-management/)
-- [VSCodium Build System — DeepWiki](https://deepwiki.com/VSCodium/vscodium/2-build-system)
-- [Git range-diff documentation](https://git-scm.com/docs/git-range-diff)
-- [Git rerere — Pro Git book](https://git-scm.com/book/en/v2/Git-Tools-Rerere)
-- [Mastering Git Rerere — This Dot Labs](https://www.thisdot.co/blog/mastering-git-rerere-solving-repetitive-merge-conflicts-with-ease)
-- [Vite define option](https://vite.dev/config/shared-options#define)
-- [Tailwind CSS v4 + Vite — CSS custom properties theming](https://medium.com/render-beyond/build-a-flawless-multi-theme-ui-using-new-tailwind-css-v4-react-dca2b3c95510)
-- [A Scalable Text Management Pattern — React Context + TypeScript](https://nicholasgalante1997.medium.com/a-scalable-text-management-pattern-for-web-developers-with-react-context-and-typescript-5b26aacceceb)
-- [TypeScript Record pattern for display labels](https://dev.to/naserrasouli/mastering-record-in-typescript-the-clean-way-to-map-enums-to-labels-and-colors-46bh)
-- [How to Synchronize Your Fork with Upstream Changes](https://nhutduong.com/blog/how-to-synchronize-your-fork-repository-with-upstream-changes/)
-
----
-
-*Stack research: 2026-03-30*

.planning/research/SUMMARY.md

@@ -1,185 +0,0 @@
-# Project Research Summary
-
-**Project:** Nexus (fork of Paperclip)
-**Domain:** Display-layer fork of a TypeScript AI agent orchestration monorepo
-**Researched:** 2026-03-30
-**Confidence:** HIGH
-
-## Executive Summary
-
-Nexus is a personal-use fork of Paperclip, an open-source AI agent orchestration platform. The project scope is strictly display-layer: rename corporate metaphors (Company, CEO, Board) to solo-developer vocabulary (Workspace, Project Manager, Owner), replace the onboarding wizard with a zero-friction root-directory-picker flow, and ship predefined PM and Engineer agent templates. No engine changes, no schema changes, no route changes. Every functional capability is inherited from upstream — the work is entirely in what the product communicates to its operator.
-
-The recommended approach is rebase-over-upstream with a `[nexus]` commit prefix convention, all fork-specific strings isolated in a new `packages/branding/` package and `ui/src/lib/nexus-labels.ts` file, and a Vite alias to redirect the `OnboardingWizard` import to a fully Nexus-owned replacement component. This architecture concentrates the entire mutable surface in new files that upstream will never create, minimising rebase conflict exposure to a small number of well-understood lines in five upstream files.
-
-The principal risk is accidental scope creep into Zone B (code identifiers) or Zone C (dual-purpose stored DB values) during rename work. A single naive find-replace that touches `companyService`, `"ceo"` in `AGENT_ROLES`, or `/api/companies` routes would shatter rebasability and require a recovery that undoes the entire rename. The mitigation is a strict three-zone taxonomy applied file-by-file from the first commit, combined with a pre-commit hook enforcing the `[nexus]` prefix and a weekly rebase cadence.
-
----
-
-## Key Findings
-
-### Recommended Stack
-
-Paperclip's existing stack is retained without alteration. The fork adds one new workspace package (`@paperclipai/branding`) and two new UI files (`nexus-labels.ts`, `branding.css`) — all additions, no modifications to `package.json` names, tsconfig paths, or Tailwind config structure.
-
-The only tooling additions are: `git rerere` enabled in the repo config to auto-replay recurring conflict resolutions, and a `vite.config.ts` `define` block for build-time product name injection into static HTML. Both are zero-dependency changes.
-
-**Core tools:**
-- `git rebase upstream/master` + `[nexus]` prefix convention: fork sync strategy — standard practice used by git-for-windows, VSCodium, microsoft/git
-- `git range-diff` + `git rerere`: rebase verification and auto-resolution — official Git tooling, no third-party risk
-- `packages/branding/` (`@paperclipai/branding`): single string mutation surface — new package in existing namespace, zero import-path disruption
-- `ui/src/lib/nexus-labels.ts`: UI-layer label registry — new file, zero upstream conflict risk
-- `ui/src/branding.css`: Tailwind v4 CSS custom property overrides — new file, zero upstream conflict risk
-- Vite `resolve.alias` for `OnboardingWizard`: build-time component swap — existing vite.config.ts already uses alias syntax
-
-### Expected Features
-
-**Must have (table stakes) — all already exist in upstream, display rename only:**
-- Dashboard with live agent status (SSE-backed, Company → Workspace rename)
-- Real-time run logs and heartbeat transcript
-- Cost visibility per agent (`cost_events` table already tracked)
-- Task/issue list with status and sub-task hierarchy
-- Agent status indicators (idle/running/paused)
-- One-command startup (`nexus run` replacing `paperclipai run`)
-- Human approval workflow (approvals table and routes intact)
-- Agent configuration page with config revision history
-- Scheduled task creation (routines with cron)
-- CLI help text using Nexus vocabulary throughout
-
-**Should have (differentiators):**
-- Zero-question onboarding — root directory picker, auto-create PM + Engineer agents, no "company name" or "CEO" prompts (highest-impact UX change)
-- Predefined agent templates (PM + Engineer) — SOUL.md, AGENTS.md, HEARTBEAT.md, TOOLS.md for each role
-- Workspace-first mental model — systematic string audit across all UI and CLI surfaces
-- Nexus branding — logo, `<title>`, CLI binary name (`nexus`), favicon
-- "Add Agent" dialog with template dropdown replacing the "hire agent" flow
-- Human-readable agent directories under user root (`~/RaglanWork/agents/engineer/`)
-
-**Defer (v2+):**
-- Full Catppuccin Mocha theme (high visual risk for v1, CSS custom properties make it addable later as a single-file change)
-- Telegram Channels integration (separate project scope)
-- Recipe Registry plugin (separate project scope)
-- Plugin API event renames (`company.created` etc.) — would break existing plugins silently
-- MCP connector layer abstraction (upstream adapter system already handles this)
-
-**Critical path for differentiators:** D2 (Agent Templates) → D1 (Zero-Question Onboarding) → D4 (Human-Readable Directories). D3 (Workspace Mental Model), D5 (Branding), and D6 (Add Agent Dialog) can ship in any order alongside or after.
-
-### Architecture Approach
-
-The architecture goal is to confine all fork-specific content to new files that upstream will never create. Two strategies cover every change type: (1) add-only new files for net-new content (zero conflict risk), and (2) minimal inline edits with `// [nexus]` markers on lines that must touch existing upstream files (string changes only, never identifier renames). For the one component requiring substantial structural rewriting (OnboardingWizard), a Vite alias redirects the import to a fully Nexus-owned file, leaving the upstream file untouched and allowing upstream to evolve it freely.
-
-**Major components:**
-1. `packages/branding/` (NEW) — canonical vocabulary constants (`VOCAB`, `DISPLAY_ROLE_LABELS`); the only place Nexus display strings are defined
-2. `ui/src/lib/nexus-labels.ts` (NEW) — UI-layer label registry imported by components instead of hardcoded strings
-3. `ui/src/nexus/OnboardingWizard.tsx` (NEW) — full Nexus onboarding replacement; upstream `OnboardingWizard.tsx` left untouched
-4. `server/src/onboarding-assets/pm/` and `engineer/` (NEW) — predefined agent template directories; zero conflict risk as net-new paths
-5. `ui/src/branding.css` (NEW) — Tailwind v4 CSS custom property overrides for brand colors
-6. `packages/shared/src/constants.ts` (MODIFIED, 1 line) — `ceo: "Project Manager"` in `AGENT_ROLE_LABELS`; the only upstream constants file touched
-7. `server/src/home-paths.ts` (MODIFIED, 1 line) — default home dir `".nexus"`
-8. `ui/vite.config.ts` (MODIFIED, 1 line) — alias entry redirecting `OnboardingWizard` import
-
-### Critical Pitfalls
-
-1. **Renaming a code identifier that is also a stored DB value** — `"ceo"`, `"hire_agent"`, `"bootstrap_ceo"`, `"board"`, `"company"` are stored in DB rows, not just TypeScript constants. Renaming the constant value silently breaks existing installations (old rows no longer match). Mitigation: rename only the label map value (`ceo: "Project Manager"`), never the key (`ceo`). Grep for any target string in `packages/db/src/schema/` before renaming.
-
-2. **Bulk find-replace contaminating Zone B (code identifiers)** — a naive global replace of "company" touches `companyService`, import paths, and DB schema values alongside JSX strings. Result: hundreds of rebase conflicts in files that should never have been modified. Mitigation: three-zone taxonomy enforced file-by-file; no global find-replace ever.
-
-3. **Upstream rebase cadence drift** — fork conflicts accumulate non-linearly. A two-week gap becomes a four-hour archaeology session. Mitigation: weekly rebase on a fixed schedule, `[nexus]` prefix from the first commit, CI rebase check on a test branch.
-
-4. **Renaming `~/.paperclip` config path without a migration** — existing installations lose all agents, projects, and API keys on next startup if the config path is renamed without a read-both-paths fallback. Mitigation: check `~/.nexus` first, fall back to `~/.paperclip`; implement the pointer-file mechanism before shipping the home dir change.
-
-5. **Partial rename — missing occurrences across 12+ files** — "CEO" appears in at least 12 distinct files. Without an i18n layer there is no compile-time verification that a rename is complete. Mitigation: run `grep -ri "CEO\|company\|board\|hire\|paperclip" ui/src cli/src server/src` after each phase and verify every remaining occurrence is intentional (Zone B/C).
-
----
-
-## Implications for Roadmap
-
-Based on research, suggested phase structure:
-
-### Phase 1: Foundation and String Infrastructure
-**Rationale:** Establishes all new files with zero upstream file touches. Creates the containment structure before any existing file is modified. Safe to rebase at any point. Pre-commit hook and zone taxonomy documented here — if these are not in place before Phase 2, all subsequent work is at risk.
-**Delivers:** `packages/branding/`, `ui/src/lib/nexus-labels.ts`, `ui/src/nexus/` directory, `server/src/onboarding-assets/pm/` and `engineer/` skeleton directories, `[nexus]` pre-commit hook, zone taxonomy document in `.planning/`.
-**Addresses:** D2 partial (template directories created), D5 partial (branding package scaffold)
-**Avoids:** Pitfall 8 (no-prefix commits), Pitfall 2 (Zone B contamination from lack of taxonomy)
-
-### Phase 2: Constants, Labels, and Home Directory
-**Rationale:** Touches three upstream files with one-line changes each. These are the lowest-risk upstream file modifications: rarely-changed lines, isolated diffs, immediately verifiable. Completing this phase makes every downstream component able to import correct labels before any component is touched.
-**Delivers:** `AGENT_ROLE_LABELS.ceo = "Project Manager"` live, home dir default changed to `.nexus` with read-both-paths fallback, `DISPLAY_ROLE_LABELS` exported from branding package.
-**Addresses:** D3 (core vocabulary change), D4 partial (home dir pointer)
-**Avoids:** Pitfall 1 (dual-purpose stored values — keys unchanged), Pitfall 4 (config migration — fallback implemented here)
-
-### Phase 3: UI and CLI String Renames
-**Rationale:** Surface-area is larger (multiple upstream files) but each change is string-only with `// [nexus]` markers. Individual commits per file keep each rebase conflict isolated and mechanically resolvable. The branding infrastructure from Phases 1–2 must exist before this phase to avoid scattering string definitions.
-**Delivers:** All "Company/CEO/Board" display strings replaced with "Workspace/Project Manager/Owner" across `Companies.tsx`, `CompanyRail.tsx`, `CompanySettings.tsx`, `InstanceSidebar.tsx`, `cli/onboard.ts`, `startup-banner.ts`. CLI binary renamed to `nexus` atomically with all instructional copy updated.
-**Addresses:** D3 (complete), D5 (complete), D6 partial (dialog strings updated)
-**Avoids:** Pitfall 6 (atomic CLI rename), Pitfall 7 (post-phase grep audit), Pitfall 10 (test assertions updated in same commits)
-
-### Phase 4: Onboarding Redesign
-**Rationale:** Most complex change goes last. Vite alias approach means upstream `OnboardingWizard.tsx` is never touched and can evolve independently. PM and Engineer template content (written in Phase 1) is wired up here. Onboarding API shape mismatch (workspace name derived from directory basename) must be explicitly resolved.
-**Delivers:** `ui/src/nexus/OnboardingWizard.tsx` full replacement (root dir picker, auto-create PM + Engineer agents, one-step flow), Vite alias in `vite.config.ts`, `ceo/` onboarding asset content replaced with PM framing, PM and Engineer template files populated, "Add Agent" dialog updated with template dropdown.
-**Addresses:** D1 (complete), D2 (complete), D4 (complete), D6 (complete)
-**Avoids:** Pitfall 3 (ceo/ directory name kept, only content replaced), Pitfall 9 (API shape documented and workspace name derived before implementation)
-
-### Phase Ordering Rationale
-
-- New files before upstream file modifications — zero conflict risk for the majority of work
-- Constants before components — components can import correct labels from day one
-- String renames before onboarding redesign — the vocabulary must be stable before the most complex component is written against it
-- Onboarding last — its Vite alias approach is the most architectural change; having it isolated keeps every earlier phase simple and independently rebaseable
-- Each phase produces a rebasing-clean state — can sync upstream between any two phases without compound conflicts
-
-### Research Flags
-
-Phases with well-documented patterns (skip `/gsd:research-phase`):
-- **Phase 1:** Standard TypeScript monorepo package creation and git hook setup — no research needed
-- **Phase 2:** Single-line constant and config path changes — no research needed
-- **Phase 3:** Mechanical string replacement with documented taxonomy — no research needed
-
-Phases likely benefiting from deeper research during planning:
-- **Phase 4:** The onboarding API shape mismatch (Pitfall 9) needs the `POST /api/companies` contract documented before writing the new wizard. A brief codebase read of `server/src/routes/companies.ts` and the API client should resolve this. Not complex — 30 minutes of reading, not a full research session.
-
----
-
-## Confidence Assessment
-
-| Area | Confidence | Notes |
-|------|------------|-------|
-| Stack | HIGH | Based on direct codebase inspection of live repo + official Git, Vite, Tailwind v4 documentation |
-| Features | HIGH (table stakes), MEDIUM (differentiators) | Table stakes verified from codebase; differentiator prioritization informed by Paperclip product notes and UX research but not validated against actual users |
-| Architecture | HIGH | Patterns derived from direct codebase inspection; Vite alias pattern verified against official docs and existing vite.config.ts in the repo |
-| Pitfalls | HIGH | Primarily from direct audit of CONCERNS.md and codebase; supplemented by fork maintenance community research |
-
-**Overall confidence:** HIGH
-
-### Gaps to Address
-
-- **OnboardingWizard API contract:** The `POST /api/companies` required fields are not fully documented in research. Before Phase 4 implementation, read `server/src/routes/companies.ts` to determine exactly what fields are required and derive a rule for the workspace name field (likely `basename(rootDir)`).
-- **Test suite audit scope:** The pre-rename test audit (Pitfall 10) requires running the grep against the actual test files. The exact count of test files asserting on "CEO" / "company" display strings is not known — this should be done as the first step of Phase 3 execution, not planning.
-- **`localStorage` key migration:** Whether to keep `"paperclip.selectedCompanyId"` or migrate it is unresolved. Given it is internal and users never see it, keeping it unchanged is the lowest-risk path and should be the default decision unless there is a specific reason to change it.
-- **Catppuccin Mocha theme scope boundary:** The `branding.css` scaffold is included in Phase 1 but full theme is deferred. The exact CSS custom property overrides needed for even minimal brand differentiation (Nexus blue-purple vs Paperclip defaults) should be defined during Phase 3 execution.
-
----
-
-## Sources
-
-### Primary (HIGH confidence)
-- `/Volumes/UsbNvme/agent/.planning/codebase/ARCHITECTURE.md` — direct codebase analysis
-- `/Volumes/UsbNvme/agent/.planning/codebase/CONCERNS.md` — direct audit of dual-purpose stored values
-- `/Volumes/UsbNvme/agent/.planning/PROJECT.md` — project constraints and scope
-- `/Volumes/UsbNvme/repos/nexus/` — live codebase inspection
-- [Git range-diff documentation](https://git-scm.com/docs/git-range-diff)
-- [Git rerere — Pro Git book](https://git-scm.com/book/en/v2/Git-Tools-Rerere)
-- [Vite resolve.alias + define documentation](https://vite.dev/config/shared-options)
-
-### Secondary (MEDIUM confidence)
-- [GitHub: Strategies for friendly fork management](https://github.blog/developer-skills/github/friend-zone-strategies-friendly-fork-management/)
-- [History-preserving fork maintenance with git](https://amboar.github.io/notes/2021/09/16/history-preserving-fork-maintenance-with-git.html)
-- [VSCodium Build System — DeepWiki](https://deepwiki.com/VSCodium/vscodium/2-build-system)
-- [Stop Forking Around — Fork Drift in Open Source](https://preset.io/blog/stop-forking-around-the-hidden-dangers-of-fork-drift-in-open-source-adoption/)
-- [Designing For Agentic AI: Practical UX Patterns (Smashing Magazine, 2026)](https://www.smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/)
-- [Tailwind CSS v4 + Vite — CSS custom properties theming](https://medium.com/render-beyond/build-a-flawless-multi-theme-ui-using-new-tailwind-css-v4-react-dca2b3c95510)
-
-### Tertiary (LOW confidence)
-- UX claims regarding cognitive load from vocabulary mismatch — reasonable inference, not validated against actual users
-
----
-*Research completed: 2026-03-30*
-*Ready for roadmap: yes*

Dockerfile

@@ -1,17 +1,9 @@
 FROM node:lts-trixie-slim AS base
-ARG USER_UID=1000
-ARG USER_GID=1000
 RUN apt-get update \
-  && apt-get install -y --no-install-recommends ca-certificates curl git gosu \
+  && apt-get install -y --no-install-recommends ca-certificates curl git \
   && rm -rf /var/lib/apt/lists/*
-
 RUN corepack enable
 
-# Modify the existing node user/group to have the specified UID/GID to match host user
-RUN usermod -u $USER_UID --non-unique node \
-  && groupmod -g $USER_GID --non-unique node \
-  && usermod -g $USER_GID -d /paperclip node
-
 FROM base AS deps
 WORKDIR /app
 COPY package.json pnpm-workspace.yaml pnpm-lock.yaml .npmrc ./
@@ -43,17 +35,12 @@ RUN pnpm --filter @paperclipai/server build
 RUN test -f server/dist/index.js || (echo "ERROR: server build output missing" && exit 1)
 
 FROM base AS production
-ARG USER_UID=1000
-ARG USER_GID=1000
 WORKDIR /app
 COPY --chown=node:node --from=build /app /app
 RUN npm install --global --omit=dev @anthropic-ai/claude-code@latest @openai/codex@latest opencode-ai \
   && mkdir -p /paperclip \
   && chown node:node /paperclip
 
-COPY docker-entrypoint.sh /usr/local/bin/
-RUN chmod +x /usr/local/bin/docker-entrypoint.sh
-
 ENV NODE_ENV=production \
   HOME=/paperclip \
   HOST=0.0.0.0 \
@@ -61,8 +48,6 @@ ENV NODE_ENV=production \
   SERVE_UI=true \
   PAPERCLIP_HOME=/paperclip \
   PAPERCLIP_INSTANCE_ID=default \
-  USER_UID=${USER_UID} \
-  USER_GID=${USER_GID} \
   PAPERCLIP_CONFIG=/paperclip/instances/default/config.json \
   PAPERCLIP_DEPLOYMENT_MODE=authenticated \
   PAPERCLIP_DEPLOYMENT_EXPOSURE=private
@@ -70,5 +55,5 @@ ENV NODE_ENV=production \
 VOLUME ["/paperclip"]
 EXPOSE 3100
 
-ENTRYPOINT ["docker-entrypoint.sh"]
+USER node
 CMD ["node", "--import", "./server/node_modules/tsx/dist/loader.mjs", "server/dist/index.js"]

README.md

@@ -177,8 +177,6 @@ Open source. Self-hosted. No Paperclip account required.
 npx paperclipai onboard --yes
 ```
 
-If you already have Paperclip configured, rerunning `onboard` keeps the existing config in place. Use `paperclipai configure` to edit settings.
-
 Or manually:
 
 ```bash

cli/README.md

@@ -1,292 +0,0 @@
-<p align="center">
-  <img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/header.png" alt="Paperclip — runs your business" width="720" />
-</p>
-
-<p align="center">
-  <a href="#quickstart"><strong>Quickstart</strong></a> &middot;
-  <a href="https://paperclip.ing/docs"><strong>Docs</strong></a> &middot;
-  <a href="https://github.com/paperclipai/paperclip"><strong>GitHub</strong></a> &middot;
-  <a href="https://discord.gg/m4HZY7xNG3"><strong>Discord</strong></a>
-</p>
-
-<p align="center">
-  <a href="https://github.com/paperclipai/paperclip/blob/master/LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue" alt="MIT License" /></a>
-  <a href="https://github.com/paperclipai/paperclip/stargazers"><img src="https://img.shields.io/github/stars/paperclipai/paperclip?style=flat" alt="Stars" /></a>
-  <a href="https://discord.gg/m4HZY7xNG3"><img src="https://img.shields.io/badge/discord-join%20chat-5865F2?logo=discord&logoColor=white" alt="Discord" /></a>
-</p>
-
-<br/>
-
-<div align="center">
-  <video src="https://github.com/user-attachments/assets/773bdfb2-6d1e-4e30-8c5f-3487d5b70c8f" width="600" controls></video>
-</div>
-
-<br/>
-
-## What is Paperclip?
-
-# Open-source orchestration for zero-human companies
-
-**If OpenClaw is an _employee_, Paperclip is the _company_**
-
-Paperclip is a Node.js server and React UI that orchestrates a team of AI agents to run a business. Bring your own agents, assign goals, and track your agents' work and costs from one dashboard.
-
-It looks like a task manager — but under the hood it has org charts, budgets, governance, goal alignment, and agent coordination.
-
-**Manage business goals, not pull requests.**
-
-|        | Step            | Example                                                            |
-| ------ | --------------- | ------------------------------------------------------------------ |
-| **01** | Define the goal | _"Build the #1 AI note-taking app to $1M MRR."_                    |
-| **02** | Hire the team   | CEO, CTO, engineers, designers, marketers — any bot, any provider. |
-| **03** | Approve and run | Review strategy. Set budgets. Hit go. Monitor from the dashboard.  |
-
-<br/>
-
-> **COMING SOON: Clipmart** — Download and run entire companies with one click. Browse pre-built company templates — full org structures, agent configs, and skills — and import them into your Paperclip instance in seconds.
-
-<br/>
-
-<div align="center">
-<table>
-  <tr>
-    <td align="center"><strong>Works<br/>with</strong></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/openclaw.svg" width="32" alt="OpenClaw" /><br/><sub>OpenClaw</sub></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/claude.svg" width="32" alt="Claude" /><br/><sub>Claude Code</sub></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/codex.svg" width="32" alt="Codex" /><br/><sub>Codex</sub></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/cursor.svg" width="32" alt="Cursor" /><br/><sub>Cursor</sub></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/bash.svg" width="32" alt="Bash" /><br/><sub>Bash</sub></td>
-    <td align="center"><img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/logos/http.svg" width="32" alt="HTTP" /><br/><sub>HTTP</sub></td>
-  </tr>
-</table>
-
-<em>If it can receive a heartbeat, it's hired.</em>
-
-</div>
-
-<br/>
-
-## Paperclip is right for you if
-
-- ✅ You want to build **autonomous AI companies**
-- ✅ You **coordinate many different agents** (OpenClaw, Codex, Claude, Cursor) toward a common goal
-- ✅ You have **20 simultaneous Claude Code terminals** open and lose track of what everyone is doing
-- ✅ You want agents running **autonomously 24/7**, but still want to audit work and chime in when needed
-- ✅ You want to **monitor costs** and enforce budgets
-- ✅ You want a process for managing agents that **feels like using a task manager**
-- ✅ You want to manage your autonomous businesses **from your phone**
-
-<br/>
-
-## Features
-
-<table>
-<tr>
-<td align="center" width="33%">
-<h3>🔌 Bring Your Own Agent</h3>
-Any agent, any runtime, one org chart. If it can receive a heartbeat, it's hired.
-</td>
-<td align="center" width="33%">
-<h3>🎯 Goal Alignment</h3>
-Every task traces back to the company mission. Agents know <em>what</em> to do and <em>why</em>.
-</td>
-<td align="center" width="33%">
-<h3>💓 Heartbeats</h3>
-Agents wake on a schedule, check work, and act. Delegation flows up and down the org chart.
-</td>
-</tr>
-<tr>
-<td align="center">
-<h3>💰 Cost Control</h3>
-Monthly budgets per agent. When they hit the limit, they stop. No runaway costs.
-</td>
-<td align="center">
-<h3>🏢 Multi-Company</h3>
-One deployment, many companies. Complete data isolation. One control plane for your portfolio.
-</td>
-<td align="center">
-<h3>🎫 Ticket System</h3>
-Every conversation traced. Every decision explained. Full tool-call tracing and immutable audit log.
-</td>
-</tr>
-<tr>
-<td align="center">
-<h3>🛡️ Governance</h3>
-You're the board. Approve hires, override strategy, pause or terminate any agent — at any time.
-</td>
-<td align="center">
-<h3>📊 Org Chart</h3>
-Hierarchies, roles, reporting lines. Your agents have a boss, a title, and a job description.
-</td>
-<td align="center">
-<h3>📱 Mobile Ready</h3>
-Monitor and manage your autonomous businesses from anywhere.
-</td>
-</tr>
-</table>
-
-<br/>
-
-## Problems Paperclip solves
-
-| Without Paperclip                                                                                                                     | With Paperclip                                                                                                                         |
-| ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| ❌ You have 20 Claude Code tabs open and can't track which one does what. On reboot you lose everything.                              | ✅ Tasks are ticket-based, conversations are threaded, sessions persist across reboots.                                                |
-| ❌ You manually gather context from several places to remind your bot what you're actually doing.                                     | ✅ Context flows from the task up through the project and company goals — your agent always knows what to do and why.                  |
-| ❌ Folders of agent configs are disorganized and you're re-inventing task management, communication, and coordination between agents. | ✅ Paperclip gives you org charts, ticketing, delegation, and governance out of the box — so you run a company, not a pile of scripts. |
-| ❌ Runaway loops waste hundreds of dollars of tokens and max your quota before you even know what happened.                           | ✅ Cost tracking surfaces token budgets and throttles agents when they're out. Management prioritizes with budgets.                    |
-| ❌ You have recurring jobs (customer support, social, reports) and have to remember to manually kick them off.                        | ✅ Heartbeats handle regular work on a schedule. Management supervises.                                                                |
-| ❌ You have an idea, you have to find your repo, fire up Claude Code, keep a tab open, and babysit it.                                | ✅ Add a task in Paperclip. Your coding agent works on it until it's done. Management reviews their work.                              |
-
-<br/>
-
-## Why Paperclip is special
-
-Paperclip handles the hard orchestration details correctly.
-
-|                                   |                                                                                                               |
-| --------------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| **Atomic execution.**             | Task checkout and budget enforcement are atomic, so no double-work and no runaway spend.                      |
-| **Persistent agent state.**       | Agents resume the same task context across heartbeats instead of restarting from scratch.                     |
-| **Runtime skill injection.**      | Agents can learn Paperclip workflows and project context at runtime, without retraining.                      |
-| **Governance with rollback.**     | Approval gates are enforced, config changes are revisioned, and bad changes can be rolled back safely.        |
-| **Goal-aware execution.**         | Tasks carry full goal ancestry so agents consistently see the "why," not just a title.                        |
-| **Portable company templates.**   | Export/import orgs, agents, and skills with secret scrubbing and collision handling.                          |
-| **True multi-company isolation.** | Every entity is company-scoped, so one deployment can run many companies with separate data and audit trails. |
-
-<br/>
-
-## What Paperclip is not
-
-|                              |                                                                                                                      |
-| ---------------------------- | -------------------------------------------------------------------------------------------------------------------- |
-| **Not a chatbot.**           | Agents have jobs, not chat windows.                                                                                  |
-| **Not an agent framework.**  | We don't tell you how to build agents. We tell you how to run a company made of them.                                |
-| **Not a workflow builder.**  | No drag-and-drop pipelines. Paperclip models companies — with org charts, goals, budgets, and governance.            |
-| **Not a prompt manager.**    | Agents bring their own prompts, models, and runtimes. Paperclip manages the organization they work in.               |
-| **Not a single-agent tool.** | This is for teams. If you have one agent, you probably don't need Paperclip. If you have twenty — you definitely do. |
-| **Not a code review tool.**  | Paperclip orchestrates work, not pull requests. Bring your own review process.                                       |
-
-<br/>
-
-## Quickstart
-
-Open source. Self-hosted. No Paperclip account required.
-
-```bash
-npx paperclipai onboard --yes
-```
-
-If you already have Paperclip configured, rerunning `onboard` keeps the existing config in place. Use `paperclipai configure` to edit settings.
-
-Or manually:
-
-```bash
-git clone https://github.com/paperclipai/paperclip.git
-cd paperclip
-pnpm install
-pnpm dev
-```
-
-This starts the API server at `http://localhost:3100`. An embedded PostgreSQL database is created automatically — no setup required.
-
-> **Requirements:** Node.js 20+, pnpm 9.15+
-
-<br/>
-
-## FAQ
-
-**What does a typical setup look like?**
-Locally, a single Node.js process manages an embedded Postgres and local file storage. For production, point it at your own Postgres and deploy however you like. Configure projects, agents, and goals — the agents take care of the rest.
-
-If you're a solo-entreprenuer you can use Tailscale to access Paperclip on the go. Then later you can deploy to e.g. Vercel when you need it.
-
-**Can I run multiple companies?**
-Yes. A single deployment can run an unlimited number of companies with complete data isolation.
-
-**How is Paperclip different from agents like OpenClaw or Claude Code?**
-Paperclip _uses_ those agents. It orchestrates them into a company — with org charts, budgets, goals, governance, and accountability.
-
-**Why should I use Paperclip instead of just pointing my OpenClaw to Asana or Trello?**
-Agent orchestration has subtleties in how you coordinate who has work checked out, how to maintain sessions, monitoring costs, establishing governance - Paperclip does this for you.
-
-(Bring-your-own-ticket-system is on the Roadmap)
-
-**Do agents run continuously?**
-By default, agents run on scheduled heartbeats and event-based triggers (task assignment, @-mentions). You can also hook in continuous agents like OpenClaw. You bring your agent and Paperclip coordinates.
-
-<br/>
-
-## Development
-
-```bash
-pnpm dev              # Full dev (API + UI, watch mode)
-pnpm dev:once         # Full dev without file watching
-pnpm dev:server       # Server only
-pnpm build            # Build all
-pnpm typecheck        # Type checking
-pnpm test:run         # Run tests
-pnpm db:generate      # Generate DB migration
-pnpm db:migrate       # Apply migrations
-```
-
-See [doc/DEVELOPING.md](https://github.com/paperclipai/paperclip/blob/master/doc/DEVELOPING.md) for the full development guide.
-
-<br/>
-
-## Roadmap
-
-- ✅ Plugin system (e.g. add a knowledge base, custom tracing, queues, etc)
-- ✅ Get OpenClaw / claw-style agent employees
-- ✅ companies.sh - import and export entire organizations
-- ✅ Easy AGENTS.md configurations
-- ✅ Skills Manager
-- ✅ Scheduled Routines
-- ✅ Better Budgeting
-- ⚪ Artifacts & Deployments
-- ⚪ CEO Chat
-- ⚪ MAXIMIZER MODE
-- ⚪ Multiple Human Users
-- ⚪ Cloud / Sandbox agents (e.g. Cursor / e2b agents)
-- ⚪ Cloud deployments
-- ⚪ Desktop App
-
-<br/>
-
-## Community & Plugins
-
-Find Plugins and more at [awesome-paperclip](https://github.com/gsxdsm/awesome-paperclip)
-
-## Contributing
-
-We welcome contributions. See the [contributing guide](https://github.com/paperclipai/paperclip/blob/master/CONTRIBUTING.md) for details.
-
-<br/>
-
-## Community
-
-- [Discord](https://discord.gg/m4HZY7xNG3) — Join the community
-- [GitHub Issues](https://github.com/paperclipai/paperclip/issues) — bugs and feature requests
-- [GitHub Discussions](https://github.com/paperclipai/paperclip/discussions) — ideas and RFC
-
-<br/>
-
-## License
-
-MIT &copy; 2026 Paperclip
-
-## Star History
-
-[![Star History Chart](https://api.star-history.com/image?repos=paperclipai/paperclip&type=date&legend=top-left)](https://www.star-history.com/?repos=paperclipai%2Fpaperclip&type=date&legend=top-left)
-
-<br/>
-
----
-
-<p align="center">
-  <img src="https://raw.githubusercontent.com/paperclipai/paperclip/master/doc/assets/footer.jpg" alt="" width="720" />
-</p>
-
-<p align="center">
-  <sub>Open source under MIT. Built for people who want to run companies, not babysit agents.</sub>
-</p>

cli/src/__tests__/onboard.test.ts

@@ -1,105 +0,0 @@
-import fs from "node:fs";
-import os from "node:os";
-import path from "node:path";
-import { afterEach, beforeEach, describe, expect, it } from "vitest";
-import { onboard } from "../commands/onboard.js";
-import type { PaperclipConfig } from "../config/schema.js";
-
-const ORIGINAL_ENV = { ...process.env };
-
-function createExistingConfigFixture() {
-  const root = fs.mkdtempSync(path.join(os.tmpdir(), "paperclip-onboard-"));
-  const runtimeRoot = path.join(root, "runtime");
-  const configPath = path.join(root, ".paperclip", "config.json");
-  const config: PaperclipConfig = {
-    $meta: {
-      version: 1,
-      updatedAt: "2026-03-29T00:00:00.000Z",
-      source: "configure",
-    },
-    database: {
-      mode: "embedded-postgres",
-      embeddedPostgresDataDir: path.join(runtimeRoot, "db"),
-      embeddedPostgresPort: 54329,
-      backup: {
-        enabled: true,
-        intervalMinutes: 60,
-        retentionDays: 30,
-        dir: path.join(runtimeRoot, "backups"),
-      },
-    },
-    logging: {
-      mode: "file",
-      logDir: path.join(runtimeRoot, "logs"),
-    },
-    server: {
-      deploymentMode: "local_trusted",
-      exposure: "private",
-      host: "127.0.0.1",
-      port: 3100,
-      allowedHostnames: [],
-      serveUi: true,
-    },
-    auth: {
-      baseUrlMode: "auto",
-      disableSignUp: false,
-    },
-    storage: {
-      provider: "local_disk",
-      localDisk: {
-        baseDir: path.join(runtimeRoot, "storage"),
-      },
-      s3: {
-        bucket: "paperclip",
-        region: "us-east-1",
-        prefix: "",
-        forcePathStyle: false,
-      },
-    },
-    secrets: {
-      provider: "local_encrypted",
-      strictMode: false,
-      localEncrypted: {
-        keyFilePath: path.join(runtimeRoot, "secrets", "master.key"),
-      },
-    },
-  };
-
-  fs.mkdirSync(path.dirname(configPath), { recursive: true });
-  fs.writeFileSync(configPath, `${JSON.stringify(config, null, 2)}\n`, { mode: 0o600 });
-
-  return { configPath, configText: fs.readFileSync(configPath, "utf8") };
-}
-
-describe("onboard", () => {
-  beforeEach(() => {
-    process.env = { ...ORIGINAL_ENV };
-    delete process.env.PAPERCLIP_AGENT_JWT_SECRET;
-    delete process.env.PAPERCLIP_SECRETS_MASTER_KEY;
-    delete process.env.PAPERCLIP_SECRETS_MASTER_KEY_FILE;
-  });
-
-  afterEach(() => {
-    process.env = { ...ORIGINAL_ENV };
-  });
-
-  it("preserves an existing config when rerun without flags", async () => {
-    const fixture = createExistingConfigFixture();
-
-    await onboard({ config: fixture.configPath });
-
-    expect(fs.readFileSync(fixture.configPath, "utf8")).toBe(fixture.configText);
-    expect(fs.existsSync(`${fixture.configPath}.backup`)).toBe(false);
-    expect(fs.existsSync(path.join(path.dirname(fixture.configPath), ".env"))).toBe(true);
-  });
-
-  it("preserves an existing config when rerun with --yes", async () => {
-    const fixture = createExistingConfigFixture();
-
-    await onboard({ config: fixture.configPath, yes: true, invokedByRun: true });
-
-    expect(fs.readFileSync(fixture.configPath, "utf8")).toBe(fixture.configText);
-    expect(fs.existsSync(`${fixture.configPath}.backup`)).toBe(false);
-    expect(fs.existsSync(path.join(path.dirname(fixture.configPath), ".env"))).toBe(true);
-  });
-});

cli/src/__tests__/worktree.test.ts

@@ -415,7 +415,7 @@ describe("worktree helpers", () => {
       });
 
       const config = JSON.parse(fs.readFileSync(path.join(repoRoot, ".paperclip", "config.json"), "utf8"));
-      expect(config.server.port).toBeGreaterThan(3101);
+      expect(config.server.port).toBe(3102);
       expect(config.database.embeddedPostgresPort).not.toBe(54330);
       expect(config.database.embeddedPostgresPort).not.toBe(config.server.port);
       expect(config.database.embeddedPostgresPort).toBeGreaterThan(54330);

cli/src/checks/agent-jwt-secret-check.ts

@@ -4,7 +4,6 @@ import {
   readAgentJwtSecretFromEnvFile,
   resolveAgentJwtEnvFile,
 } from "../config/env.js";
-import { VOCAB } from "@paperclipai/branding";
 import type { CheckResult } from "./index.js";
 
 export function agentJwtSecretCheck(configPath?: string): CheckResult {
@@ -24,7 +23,7 @@ export function agentJwtSecretCheck(configPath?: string): CheckResult {
       name: "Agent JWT secret",
       status: "warn",
       message: `PAPERCLIP_AGENT_JWT_SECRET is present in ${envPath} but not loaded into environment`,
-      repairHint: `Set the value from ${envPath} in your shell before starting the ${VOCAB.appName} server`,
+      repairHint: `Set the value from ${envPath} in your shell before starting the Paperclip server`,
     };
   }
 

cli/src/checks/deployment-auth-check.ts

@@ -1,5 +1,4 @@
 import type { PaperclipConfig } from "../config/schema.js";
-import { VOCAB } from "@paperclipai/branding";
 import type { CheckResult } from "./index.js";
 
 function isLoopbackHost(host: string) {
@@ -38,7 +37,7 @@ export function deploymentAuthCheck(config: PaperclipConfig): CheckResult {
       status: "fail",
       message: "authenticated mode requires BETTER_AUTH_SECRET (or PAPERCLIP_AGENT_JWT_SECRET)",
       canRepair: false,
-      repairHint: `Set BETTER_AUTH_SECRET before starting ${VOCAB.appName}`,
+      repairHint: "Set BETTER_AUTH_SECRET before starting Paperclip",
     };
   }
 

cli/src/commands/allowed-hostname.ts

@@ -1,5 +1,4 @@
 import * as p from "@clack/prompts";
-import { VOCAB } from "@paperclipai/branding";
 import pc from "picocolors";
 import { normalizeHostnameInput } from "../config/hostnames.js";
 import { readConfig, resolveConfigPath, writeConfig } from "../config/store.js";
@@ -28,7 +27,7 @@ export async function addAllowedHostname(host: string, opts: { config?: string }
   } else {
     p.log.success(`Added allowed hostname: ${pc.cyan(normalized)}`);
     p.log.message(
-      pc.dim(`Restart the ${VOCAB.appName} server for this change to take effect.`),
+      pc.dim("Restart the Paperclip server for this change to take effect."),
     );
   }
 

cli/src/commands/client/activity.ts

@@ -1,5 +1,4 @@
 import { Command } from "commander";
-import { VOCAB } from "@paperclipai/branding";
 import type { ActivityEvent } from "@paperclipai/shared";
 import {
   addCommonClientOptions,
@@ -23,8 +22,8 @@ export function registerActivityCommands(program: Command): void {
   addCommonClientOptions(
     activity
       .command("list")
-      .description(`List ${VOCAB.company.toLowerCase()} activity log entries`)
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .description("List company activity log entries")
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .option("--agent-id <id>", "Filter by agent ID")
       .option("--entity-type <type>", "Filter by entity type")
       .option("--entity-id <id>", "Filter by entity ID")

cli/src/commands/client/agent.ts

@@ -1,5 +1,4 @@
 import { Command } from "commander";
-import { VOCAB } from "@paperclipai/branding";
 import type { Agent } from "@paperclipai/shared";
 import {
   removeMaintainerOnlySkillSymlinks,
@@ -163,8 +162,8 @@ export function registerAgentCommands(program: Command): void {
   addCommonClientOptions(
     agent
       .command("list")
-      .description(`List agents for a ${VOCAB.company.toLowerCase()}`)
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .description("List agents for a company")
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .action(async (opts: AgentListOptions) => {
         try {
           const ctx = resolveCommandContext(opts, { requireCompany: true });
@@ -223,7 +222,7 @@ export function registerAgentCommands(program: Command): void {
         "Create an agent API key, install local Paperclip skills for Codex/Claude, and print shell exports",
       )
       .argument("<agentRef>", "Agent ID or shortname/url-key")
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .option("--key-name <name>", "API key label", "local-cli")
       .option(
         "--no-install-skills",

cli/src/commands/client/approval.ts

@@ -1,5 +1,4 @@
 import { Command } from "commander";
-import { VOCAB } from "@paperclipai/branding";
 import {
   createApprovalSchema,
   requestApprovalRevisionSchema,
@@ -49,8 +48,8 @@ export function registerApprovalCommands(program: Command): void {
   addCommonClientOptions(
     approval
       .command("list")
-      .description(`List approvals for a ${VOCAB.company.toLowerCase()}`)
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .description("List approvals for a company")
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .option("--status <status>", "Status filter")
       .action(async (opts: ApprovalListOptions) => {
         try {
@@ -111,7 +110,7 @@ export function registerApprovalCommands(program: Command): void {
     approval
       .command("create")
       .description("Create an approval request")
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .requiredOption("--type <type>", "Approval type (hire_agent|approve_ceo_strategy)")
       .requiredOption("--payload <json>", "Approval payload as JSON object")
       .option("--requested-by-agent-id <id>", "Requesting agent ID")

cli/src/commands/client/company.ts

@@ -83,7 +83,7 @@ const IMPORT_INCLUDE_OPTIONS: Array<{
   { value: "projects", label: "Projects", hint: "projects and workspace metadata" },
   { value: "issues", label: "Tasks", hint: "tasks and recurring routines" },
   { value: "agents", label: "Agents", hint: "agent records and org structure" },
-  { value: "skills", label: "Skills", hint: `${VOCAB.company.toLowerCase()} skill packages and references` }, // [nexus]
+  { value: "skills", label: "Skills", hint: "company skill packages and references" },
 ];
 
 const IMPORT_PREVIEW_SAMPLE_LIMIT = 6;
@@ -1046,7 +1046,7 @@ export function registerCompanyCommands(program: Command): void {
   addCommonClientOptions(
     company
       .command("list")
-      .description(`List ${VOCAB.companies.toLowerCase()}`) // [nexus]
+      .description("List companies")
       .action(async (opts: CompanyCommandOptions) => {
         try {
           const ctx = resolveCommandContext(opts);
@@ -1081,8 +1081,8 @@ export function registerCompanyCommands(program: Command): void {
   addCommonClientOptions(
     company
       .command("get")
-      .description(`Get one ${VOCAB.company.toLowerCase()}`) // [nexus]
-      .argument("<companyId>", `${VOCAB.company} ID`) // [nexus]
+      .description("Get one company")
+      .argument("<companyId>", "Company ID")
       .action(async (companyId: string, opts: CompanyCommandOptions) => {
         try {
           const ctx = resolveCommandContext(opts);
@@ -1097,8 +1097,8 @@ export function registerCompanyCommands(program: Command): void {
   addCommonClientOptions(
     company
       .command("export")
-      .description(`Export a ${VOCAB.company.toLowerCase()} into a portable markdown package`) // [nexus]
-      .argument("<companyId>", `${VOCAB.company} ID`) // [nexus]
+      .description("Export a company into a portable markdown package")
+      .argument("<companyId>", "Company ID")
       .requiredOption("--out <path>", "Output directory")
       .option("--include <values>", "Comma-separated include set: company,agents,projects,issues,tasks,skills", "company,agents")
       .option("--skills <values>", "Comma-separated skill slugs/keys to export")
@@ -1373,8 +1373,8 @@ export function registerCompanyCommands(program: Command): void {
   addCommonClientOptions(
     company
       .command("delete")
-      .description(`Delete a ${VOCAB.company.toLowerCase()} by ID or shortname/prefix (destructive)`) // [nexus]
-      .argument("<selector>", `${VOCAB.company} ID or issue prefix (for example PAP)`) // [nexus]
+      .description("Delete a company by ID or shortname/prefix (destructive)")
+      .argument("<selector>", "Company ID or issue prefix (for example PAP)")
       .option(
         "--by <mode>",
         "Selector mode: auto | id | prefix",
@@ -1383,7 +1383,7 @@ export function registerCompanyCommands(program: Command): void {
       .option("--yes", "Required safety flag to confirm destructive action", false)
       .option(
         "--confirm <value>",
-        `Required safety value: target ${VOCAB.company.toLowerCase()} ID or shortname/prefix`, // [nexus]
+        "Required safety value: target company ID or shortname/prefix",
       )
       .action(async (selector: string, opts: CompanyDeleteOptions) => {
         try {
@@ -1425,7 +1425,7 @@ export function registerCompanyCommands(program: Command): void {
             } catch (error) {
               if (error instanceof ApiRequestError && error.status === 403 && error.message.includes("Board access required")) {
                 throw new Error(
-                  `${VOCAB.board} access is required to resolve ${VOCAB.companies.toLowerCase()} across the instance. Use a ${VOCAB.company.toLowerCase()} ID/prefix for your current ${VOCAB.company.toLowerCase()}, or run with ${VOCAB.board.toLowerCase()} authentication.`, // [nexus]
+                  "Board access is required to resolve companies across the instance. Use a company ID/prefix for your current company, or run with board authentication.",
                 );
               }
               throw error;

cli/src/commands/client/dashboard.ts

@@ -1,5 +1,4 @@
 import { Command } from "commander";
-import { VOCAB } from "@paperclipai/branding";
 import type { DashboardSummary } from "@paperclipai/shared";
 import {
   addCommonClientOptions,
@@ -19,8 +18,8 @@ export function registerDashboardCommands(program: Command): void {
   addCommonClientOptions(
     dashboard
       .command("get")
-      .description(`Get dashboard summary for a ${VOCAB.company.toLowerCase()}`)
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .description("Get dashboard summary for a company")
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .action(async (opts: DashboardGetOptions) => {
         try {
           const ctx = resolveCommandContext(opts, { requireCompany: true });

cli/src/commands/client/issue.ts

@@ -1,5 +1,4 @@
 import { Command } from "commander";
-import { VOCAB } from "@paperclipai/branding";
 import {
   addIssueCommentSchema,
   checkoutIssueSchema,
@@ -68,8 +67,8 @@ export function registerIssueCommands(program: Command): void {
   addCommonClientOptions(
     issue
       .command("list")
-      .description(`List issues for a ${VOCAB.company.toLowerCase()}`)
-      .option("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .description("List issues for a company")
+      .option("-C, --company-id <id>", "Company ID")
       .option("--status <csv>", "Comma-separated statuses")
       .option("--assignee-agent-id <id>", "Filter by assignee agent ID")
       .option("--project-id <id>", "Filter by project ID")
@@ -137,7 +136,7 @@ export function registerIssueCommands(program: Command): void {
     issue
       .command("create")
       .description("Create an issue")
-      .requiredOption("-C, --company-id <id>", `${VOCAB.company} ID`)
+      .requiredOption("-C, --company-id <id>", "Company ID")
       .requiredOption("--title <title>", "Issue title")
       .option("--description <text>", "Issue description")
       .option("--status <status>", "Issue status")

cli/src/commands/onboard.ts

@@ -328,12 +328,11 @@ export async function onboard(opts: OnboardOptions): Promise<void> {
     ),
   );
 
-  let existingConfig: PaperclipConfig | null = null;
   if (configExists(opts.config)) {
-    p.log.message(pc.dim(`${configPath} exists`));
+    p.log.message(pc.dim(`${configPath} exists, updating config`));
 
     try {
-      existingConfig = readConfig(opts.config);
+      readConfig(opts.config);
     } catch (err) {
       p.log.message(
         pc.yellow(
@@ -343,76 +342,6 @@ export async function onboard(opts: OnboardOptions): Promise<void> {
     }
   }
 
-  if (existingConfig) {
-    p.log.message(
-      pc.dim("Existing Paperclip install detected; keeping the current configuration unchanged."),
-    );
-    p.log.message(pc.dim(`Use ${pc.cyan("paperclipai configure")} if you want to change settings.`));
-
-    const jwtSecret = ensureAgentJwtSecret(configPath);
-    const envFilePath = resolveAgentJwtEnvFile(configPath);
-    if (jwtSecret.created) {
-      p.log.success(`Created ${pc.cyan("PAPERCLIP_AGENT_JWT_SECRET")} in ${pc.dim(envFilePath)}`);
-    } else if (process.env.PAPERCLIP_AGENT_JWT_SECRET?.trim()) {
-      p.log.info(`Using existing ${pc.cyan("PAPERCLIP_AGENT_JWT_SECRET")} from environment`);
-    } else {
-      p.log.info(`Using existing ${pc.cyan("PAPERCLIP_AGENT_JWT_SECRET")} in ${pc.dim(envFilePath)}`);
-    }
-
-    const keyResult = ensureLocalSecretsKeyFile(existingConfig, configPath);
-    if (keyResult.status === "created") {
-      p.log.success(`Created local secrets key file at ${pc.dim(keyResult.path)}`);
-    } else if (keyResult.status === "existing") {
-      p.log.message(pc.dim(`Using existing local secrets key file at ${keyResult.path}`));
-    }
-
-    p.note(
-      [
-        "Existing config preserved",
-        `Database: ${existingConfig.database.mode}`,
-        existingConfig.llm ? `LLM: ${existingConfig.llm.provider}` : "LLM: not configured",
-        `Logging: ${existingConfig.logging.mode} -> ${existingConfig.logging.logDir}`,
-        `Server: ${existingConfig.server.deploymentMode}/${existingConfig.server.exposure} @ ${existingConfig.server.host}:${existingConfig.server.port}`,
-        `Allowed hosts: ${existingConfig.server.allowedHostnames.length > 0 ? existingConfig.server.allowedHostnames.join(", ") : "(loopback only)"}`,
-        `Auth URL mode: ${existingConfig.auth.baseUrlMode}${existingConfig.auth.publicBaseUrl ? ` (${existingConfig.auth.publicBaseUrl})` : ""}`,
-        `Storage: ${existingConfig.storage.provider}`,
-        `Secrets: ${existingConfig.secrets.provider} (strict mode ${existingConfig.secrets.strictMode ? "on" : "off"})`,
-        "Agent auth: PAPERCLIP_AGENT_JWT_SECRET configured",
-      ].join("\n"),
-      "Configuration ready",
-    );
-
-    p.note(
-      [
-        `Run: ${pc.cyan("paperclipai run")}`,
-        `Reconfigure later: ${pc.cyan("paperclipai configure")}`,
-        `Diagnose setup: ${pc.cyan("paperclipai doctor")}`,
-      ].join("\n"),
-      "Next commands",
-    );
-
-    let shouldRunNow = opts.run === true || opts.yes === true;
-    if (!shouldRunNow && !opts.invokedByRun && process.stdin.isTTY && process.stdout.isTTY) {
-      const answer = await p.confirm({
-        message: "Start Paperclip now?",
-        initialValue: true,
-      });
-      if (!p.isCancel(answer)) {
-        shouldRunNow = answer;
-      }
-    }
-
-    if (shouldRunNow && !opts.invokedByRun) {
-      process.env.PAPERCLIP_OPEN_ON_LISTEN = "true";
-      const { runCommand } = await import("./run.js");
-      await runCommand({ config: configPath, repair: true, yes: true });
-      return;
-    }
-
-    p.outro("Existing Paperclip setup is ready.");
-    return;
-  }
-
   let setupMode: SetupMode = "quickstart";
   if (opts.yes) {
     p.log.message(pc.dim("`--yes` enabled: using Quickstart defaults."));

cli/src/commands/run.ts

@@ -1,5 +1,4 @@
 import fs from "node:fs";
-import { VOCAB } from "@paperclipai/branding";
 import path from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 import * as p from "@clack/prompts";
@@ -79,7 +78,7 @@ export async function runCommand(opts: RunOptions): Promise<void> {
     process.exit(1);
   }
 
-  p.log.step(`Starting ${VOCAB.appName} server...`);
+  p.log.step("Starting Paperclip server...");
   const startedServer = await importServerEntry();
 
   if (shouldGenerateBootstrapInviteAfterStart(config)) {
@@ -166,13 +165,13 @@ async function importServerEntry(): Promise<StartedServer> {
     const missingServerEntrypoint = !missingSpecifier || missingSpecifier === "@paperclipai/server";
     if (isModuleNotFoundError(err) && missingServerEntrypoint) {
       throw new Error(
-        `Could not locate a ${VOCAB.appName} server entrypoint.\n` +
+        `Could not locate a Paperclip server entrypoint.\n` +
           `Tried: ${devEntry}, @paperclipai/server\n` +
           `${formatError(err)}`,
       );
     }
     throw new Error(
-      `${VOCAB.appName} server failed to start.\n` +
+      `Paperclip server failed to start.\n` +
         `${formatError(err)}`,
     );
   }

cli/src/commands/worktree.ts

@@ -77,7 +77,6 @@ import {
   type PlannedIssueDocumentMerge,
   type PlannedIssueInsert,
 } from "./worktree-merge-history-lib.js";
-import { VOCAB } from "@paperclipai/branding";
 
 type WorktreeInitOptions = {
   name?: string;
@@ -1539,7 +1538,7 @@ async function resolveMergeCompany(input: {
   }
 
   if (shared.length === 0) {
-    throw new Error(`Source and target databases do not share a ${VOCAB.company.toLowerCase()} id. Pass --company explicitly once both sides match.`);
+    throw new Error("Source and target databases do not share a company id. Pass --company explicitly once both sides match.");
   }
 
   const options = shared
@@ -2645,7 +2644,7 @@ export function registerWorktreeCommands(program: Command): void {
     .argument("[source]", "Optional source worktree path, directory name, or branch name (back-compat alias for --from)")
     .option("--from <worktree>", "Source worktree path, directory name, branch name, or current")
     .option("--to <worktree>", "Target worktree path, directory name, branch name, or current (defaults to current)")
-    .option("--company <id-or-prefix>", `Shared ${VOCAB.company.toLowerCase()} id or issue prefix inside the chosen source/target instances`)
+    .option("--company <id-or-prefix>", "Shared company id or issue prefix inside the chosen source/target instances")
     .option("--scope <items>", "Comma-separated scopes to import (issues, comments)", "issues,comments")
     .option("--apply", "Apply the import after previewing the plan", false)
     .option("--dry", "Preview only and do not import anything", false)

doc/DEVELOPING.md

@@ -39,17 +39,6 @@ This starts:
 
 `pnpm dev` runs the server in watch mode and restarts on changes from workspace packages (including adapter packages). Use `pnpm dev:once` to run without file watching.
 
-`pnpm dev:once` auto-applies pending local migrations by default before starting the dev server.
-
-`pnpm dev` and `pnpm dev:once` are now idempotent for the current repo and instance: if the matching Paperclip dev runner is already alive, Paperclip reports the existing process instead of starting a duplicate.
-
-Inspect or stop the current repo's managed dev runner:
-
-```sh
-pnpm dev:list
-pnpm dev:stop
-```
-
 `pnpm dev:once` now tracks backend-relevant file changes and pending migrations. When the current boot is stale, the board UI shows a `Restart required` banner. You can also enable guarded auto-restart in `Instance Settings > Experimental`, which waits for queued/running local agent runs to finish before restarting the dev server.
 
 Tailscale/private-auth dev mode:
@@ -145,8 +134,6 @@ For `codex_local`, Paperclip also manages a per-company Codex home under the ins
 
 - `~/.paperclip/instances/default/companies/<company-id>/codex-home`
 
-If the `codex` CLI is not installed or not on `PATH`, `codex_local` agent runs fail at execution time with a clear adapter error. Quota polling uses a short-lived `codex app-server` subprocess: when `codex` cannot be spawned, that provider reports `ok: false` in aggregated quota results and the API server keeps running (it must not exit on a missing binary).
-
 ## Worktree-local Instances
 
 When developing from multiple git worktrees, do not point two Paperclip servers at the same embedded PostgreSQL data directory.

doc/PUBLISHING.md

@@ -76,45 +76,6 @@ The `ui` package uses [`scripts/generate-ui-package-json.mjs`](../scripts/genera
 
 After packing or publishing, `postpack` restores the development manifest automatically.
 
-### Manual first publish for `@paperclipai/ui`
-
-If you need to publish only the UI package once by hand, use the real package name:
-
-- `@paperclipai/ui`
-
-Recommended flow from the repo root:
-
-```bash
-# optional sanity check: this 404s until the first publish exists
-npm view @paperclipai/ui version
-
-# make sure the dist payload is fresh
-pnpm --filter @paperclipai/ui build
-
-# confirm your local npm auth before the real publish
-npm whoami
-
-# safe preview of the exact publish payload
-cd ui
-pnpm publish --dry-run --no-git-checks --access public
-
-# real publish
-pnpm publish --no-git-checks --access public
-```
-
-Notes:
-
-- Publish from `ui/`, not the repo root.
-- `prepack` automatically rewrites `ui/package.json` to the lean publish manifest, and `postpack` restores the dev manifest after the command finishes.
-- If `npm view @paperclipai/ui version` already returns the same version that is in [`ui/package.json`](../ui/package.json), do not republish. Bump the version or use the normal repo-wide release flow in [`scripts/release.sh`](../scripts/release.sh).
-
-If the first real publish returns npm `E404`, check npm-side prerequisites before retrying:
-
-- `npm whoami` must succeed first. An expired or missing npm login will block the publish.
-- For an organization-scoped package like `@paperclipai/ui`, the `paperclipai` npm organization must exist and the publisher must be a member with permission to publish to that scope.
-- The initial publish must include `--access public` for a public scoped package.
-- npm also requires either account 2FA for publishing or a granular token that is allowed to bypass 2FA.
-
 ## Version formats
 
 Paperclip uses calendar versions:

docker-entrypoint.sh

@@ -1,29 +0,0 @@
-#!/bin/sh
-set -e
-
-# Capture runtime UID/GID from environment variables, defaulting to 1000
-PUID=${USER_UID:-1000}
-PGID=${USER_GID:-1000}
-
-# Adjust the node user's UID/GID if they differ from the runtime request
-# and fix volume ownership only when a remap is needed
-changed=0
-
-if [ "$(id -u node)" -ne "$PUID" ]; then
-    echo "Updating node UID to $PUID"
-    usermod -o -u "$PUID" node
-    changed=1
-fi
-
-if [ "$(id -g node)" -ne "$PGID" ]; then
-    echo "Updating node GID to $PGID"
-    groupmod -o -g "$PGID" node
-    usermod -g "$PGID" node
-    changed=1
-fi
-
-if [ "$changed" = "1" ]; then
-    chown -R node:node /paperclip
-fi
-
-exec gosu node "$@"

docs/adapters/overview.md

@@ -20,12 +20,9 @@ When a heartbeat fires, Paperclip:
 |---------|----------|-------------|
 | [Claude Local](/adapters/claude-local) | `claude_local` | Runs Claude Code CLI locally |
 | [Codex Local](/adapters/codex-local) | `codex_local` | Runs OpenAI Codex CLI locally |
-| [Gemini Local](/adapters/gemini-local) | `gemini_local` | Runs Gemini CLI locally (experimental — adapter package exists, not yet in stable type enum) |
+| [Gemini Local](/adapters/gemini-local) | `gemini_local` | Runs Gemini CLI locally |
 | OpenCode Local | `opencode_local` | Runs OpenCode CLI locally (multi-provider `provider/model`) |
-| Hermes Local | `hermes_local` | Runs Hermes CLI locally |
-| Cursor | `cursor` | Runs Cursor in background mode |
-| Pi Local | `pi_local` | Runs an embedded Pi agent locally |
-| OpenClaw Gateway | `openclaw_gateway` | Connects to an OpenClaw gateway endpoint |
+| OpenClaw | `openclaw` | Sends wake payloads to an OpenClaw webhook |
 | [Process](/adapters/process) | `process` | Executes arbitrary shell commands |
 | [HTTP](/adapters/http) | `http` | Sends webhooks to external agents |
 
@@ -58,7 +55,7 @@ Three registries consume these modules:
 
 ## Choosing an Adapter
 
-- **Need a coding agent?** Use `claude_local`, `codex_local`, `opencode_local`, or `hermes_local`
+- **Need a coding agent?** Use `claude_local`, `codex_local`, `gemini_local`, or `opencode_local`
 - **Need to run a script or command?** Use `process`
 - **Need to call an external service?** Use `http`
 - **Need something custom?** [Create your own adapter](/adapters/creating-an-adapter)

docs/cli/setup-commands.md

@@ -33,8 +33,6 @@ Interactive first-time setup:
 pnpm paperclipai onboard
 ```
 
-If Paperclip is already configured, rerunning `onboard` keeps the existing config in place. Use `paperclipai configure` to change settings on an existing install.
-
 First prompt:
 
 1. `Quickstart` (recommended): local defaults (embedded database, no LLM provider, local disk storage, default secrets)
@@ -52,8 +50,6 @@ Non-interactive defaults + immediate start (opens browser on server listen):
 pnpm paperclipai onboard --yes
 ```
 
-On an existing install, `--yes` now preserves the current config and just starts Paperclip with that setup.
-
 ## `paperclipai doctor`
 
 Health checks with optional auto-repair:

docs/docs.json

@@ -46,8 +46,6 @@
               "guides/board-operator/managing-agents",
               "guides/board-operator/org-structure",
               "guides/board-operator/managing-tasks",
-              "guides/board-operator/execution-workspaces-and-runtime-services",
-              "guides/board-operator/delegation",
               "guides/board-operator/approvals",
               "guides/board-operator/costs-and-budgets",
               "guides/board-operator/activity-log",

docs/guides/board-operator/delegation.md

@@ -1,122 +0,0 @@
----
-title: How Delegation Works
-summary: How the CEO breaks down goals into tasks and assigns them to agents
----
-
-Delegation is one of Paperclip's most powerful features. You set company goals, and the CEO agent automatically breaks them into tasks and assigns them to the right agents. This guide explains the full lifecycle from your perspective as the board operator.
-
-## The Delegation Lifecycle
-
-When you create a company goal, the CEO doesn't just acknowledge it — it builds a plan and mobilizes the team:
-
-```
-You set a company goal
-  → CEO wakes up on heartbeat
-  → CEO proposes a strategy (creates an approval for you)
-  → You approve the strategy
-  → CEO breaks goals into tasks and assigns them to reports
-  → Reports wake up (heartbeat triggered by assignment)
-  → Reports execute work and update task status
-  → CEO monitors progress, unblocks, and escalates
-  → You see results in the dashboard and activity log
-```
-
-Each step is traceable. Every task links back to the goal through a parent hierarchy, so you can always see why work is happening.
-
-## What You Need to Do
-
-Your role is strategic oversight, not task management. Here's what the delegation model expects from you:
-
-1. **Set clear company goals.** The CEO works from these. Specific, measurable goals produce better delegation. "Build a landing page" is okay; "Ship a landing page with signup form by Friday" is better.
-
-2. **Approve the CEO's strategy.** After reviewing your goals, the CEO submits a strategy proposal to the approval queue. Review it, then approve, reject, or request revisions.
-
-3. **Approve hire requests.** When the CEO needs more capacity (e.g., a frontend engineer to build the landing page), it submits a hire request. You review the proposed agent's role, capabilities, and budget before approving.
-
-4. **Monitor progress.** Use the dashboard and activity log to track how work is flowing. Check task status, agent activity, and completion rates.
-
-5. **Intervene only when things stall.** If progress stops, check these in order:
-   - Is an approval pending in your queue?
-   - Is an agent paused or in an error state?
-   - Is the CEO's budget exhausted (above 80%, it focuses on critical tasks only)?
-
-## What the CEO Does Automatically
-
-You do **not** need to tell the CEO to engage specific agents. After you approve its strategy, the CEO:
-
-- **Breaks goals into concrete tasks** with clear descriptions, priorities, and acceptance criteria
-- **Assigns tasks to the right agent** based on role and capabilities (e.g., engineering tasks go to the CTO or engineers, marketing tasks go to the CMO)
-- **Creates subtasks** when work needs to be decomposed further
-- **Hires new agents** when the team lacks capacity for a goal (subject to your approval)
-- **Monitors progress** on each heartbeat, checking task status and unblocking reports
-- **Escalates to you** when it encounters something it can't resolve — budget issues, blocked approvals, or strategic ambiguity
-
-## Common Delegation Patterns
-
-### Flat Hierarchy (Small Teams)
-
-For small companies with 3-5 agents, the CEO delegates directly to each report:
-
-```
-CEO
- ├── CTO         (engineering tasks)
- ├── CMO         (marketing tasks)
- └── Designer    (design tasks)
-```
-
-The CEO assigns tasks directly. Each agent works independently and reports status back.
-
-### Three-Level Hierarchy (Larger Teams)
-
-For larger organizations, managers delegate further down the chain:
-
-```
-CEO
- ├── CTO
- │    ├── Backend Engineer
- │    └── Frontend Engineer
- └── CMO
-      └── Content Writer
-```
-
-The CEO assigns high-level tasks to the CTO and CMO. They break those into subtasks and assign them to their own reports. You only interact with the CEO — the rest happens automatically.
-
-### Hire-on-Demand
-
-The CEO can start as the only agent and hire as work requires:
-
-1. You set a goal that needs engineering work
-2. The CEO proposes a strategy that includes hiring a CTO
-3. You approve the hire
-4. The CEO assigns engineering tasks to the new CTO
-5. As scope grows, the CTO may request to hire engineers
-
-This pattern lets you start small and scale the team based on actual work, not upfront planning.
-
-## Troubleshooting
-
-### "Why isn't the CEO delegating?"
-
-If you've set a goal but nothing is happening, check these common causes:
-
-| Check | What to look for |
-|-------|-----------------|
-| **Approval queue** | The CEO may have submitted a strategy or hire request that's waiting for your approval. This is the most common reason. |
-| **Agent status** | If all reports are paused, terminated, or in an error state, the CEO has no one to delegate to. Check the Agents page. |
-| **Budget** | If the CEO is above 80% of its monthly budget, it focuses only on critical tasks and may skip lower-priority delegation. |
-| **Goals** | If no company goals are set, the CEO has nothing to work from. Create a goal first. |
-| **Heartbeat** | Is the CEO's heartbeat enabled and running? Check the agent detail page for recent heartbeat history. |
-| **Agent instructions** | The CEO's delegation behavior is driven by its `AGENTS.md` instructions file. Open the CEO agent's detail page and verify that its instructions path is set and that the file includes delegation directives (subtask creation, hiring, assignment). If AGENTS.md is missing or doesn't mention delegation, the CEO won't know to break down goals and assign work. |
-
-### "Do I have to tell the CEO to engage engineering and marketing?"
-
-**No.** The CEO will delegate automatically after you approve its strategy. It knows the org chart and assigns tasks based on each agent's role and capabilities. You set the goal and approve the plan — the CEO handles task breakdown and assignment.
-
-### "A task seems stuck"
-
-If a specific task isn't progressing:
-
-1. Check the task's comment thread — the assigned agent may have posted a blocker
-2. Check if the task is in `blocked` status — read the blocker comment to understand why
-3. Check the assigned agent's status — it may be paused or over budget
-4. If the agent is stuck, you can reassign the task or add a comment with guidance

docs/guides/board-operator/execution-workspaces-and-runtime-services.md

@@ -1,68 +0,0 @@
----
-title: Execution Workspaces And Runtime Services
-summary: How project runtime configuration, execution workspaces, and issue runs fit together
----
-
-This guide documents the intended runtime model for projects, execution workspaces, and issue runs in Paperclip.
-
-## Project runtime configuration
-
-You can define how to run a project on the project workspace itself.
-
-- Project workspace runtime config describes how to run services for that project checkout.
-- This is the default runtime configuration that child execution workspaces may inherit.
-- Defining the config does not start anything by itself.
-
-## Manual runtime control
-
-Runtime services are manually controlled from the UI.
-
-- Project workspace runtime services are started and stopped from the project workspace UI.
-- Execution workspace runtime services are started and stopped from the execution workspace UI.
-- Paperclip does not automatically start or stop these runtime services as part of issue execution.
-- Paperclip also does not automatically restart workspace runtime services on server boot.
-
-## Execution workspace inheritance
-
-Execution workspaces isolate code and runtime state from the project primary workspace.
-
-- An isolated execution workspace has its own checkout path, branch, and local runtime instance.
-- The runtime configuration may inherit from the linked project workspace by default.
-- The execution workspace may override that runtime configuration with its own workspace-specific settings.
-- The inherited configuration answers "how to run the service", but the running process is still specific to that execution workspace.
-
-## Issues and execution workspaces
-
-Issues are attached to execution workspace behavior, not to automatic runtime management.
-
-- An issue may create a new execution workspace when you choose an isolated workspace mode.
-- An issue may reuse an existing execution workspace when you choose reuse.
-- Multiple issues may intentionally share one execution workspace so they can work against the same branch and running runtime services.
-- Assigning or running an issue does not automatically start or stop runtime services for that workspace.
-
-## Execution workspace lifecycle
-
-Execution workspaces are durable until a human closes them.
-
-- The UI can archive an execution workspace.
-- Closing an execution workspace stops its runtime services and cleans up its workspace artifacts when allowed.
-- Shared workspaces that point at the project primary checkout are treated more conservatively during cleanup than disposable isolated workspaces.
-
-## Resolved workspace logic during heartbeat runs
-
-Heartbeat still resolves a workspace for the run, but that is about code location and session continuity, not runtime-service control.
-
-1. Heartbeat resolves a base workspace for the run.
-2. Paperclip realizes the effective execution workspace, including creating or reusing a worktree when needed.
-3. Paperclip persists execution-workspace metadata such as paths, refs, and provisioning settings.
-4. Heartbeat passes the resolved code workspace to the agent run.
-5. Workspace runtime services remain manual UI-managed controls rather than automatic heartbeat-managed services.
-
-## Current implementation guarantees
-
-With the current implementation:
-
-- Project workspace runtime config is the fallback for execution workspace UI controls.
-- Execution workspace runtime overrides are stored on the execution workspace.
-- Heartbeat runs do not auto-start workspace runtime services.
-- Server startup does not auto-restart workspace runtime services.

docs/guides/board-operator/managing-agents.md

@@ -29,7 +29,7 @@ Create agents from the Agents page. Each agent requires:
 
 Common adapter choices:
 - `claude_local` / `codex_local` / `opencode_local` for local coding agents
-- `openclaw_gateway` / `http` for webhook-based external agents
+- `openclaw` / `http` for webhook-based external agents
 - `process` for generic local command execution
 
 For `opencode_local`, configure an explicit `adapterConfig.model` (`provider/model`).

docs/start/core-concepts.md

@@ -1,9 +1,9 @@
 ---
 title: Core Concepts
-summary: Companies, agents, issues, delegation, heartbeats, and governance
+summary: Companies, agents, issues, heartbeats, and governance
 ---
 
-Paperclip organizes autonomous AI work around six key concepts.
+Paperclip organizes autonomous AI work around five key concepts.
 
 ## Company
 
@@ -50,17 +50,6 @@ Terminal states: `done`, `cancelled`.
 
 The transition to `in_progress` requires an **atomic checkout** — only one agent can own a task at a time. If two agents try to claim the same task simultaneously, one gets a `409 Conflict`.
 
-## Delegation
-
-The CEO is the primary delegator. When you set company goals, the CEO:
-
-1. Creates a strategy and submits it for your approval
-2. Breaks approved goals into tasks
-3. Assigns tasks to agents based on their role and capabilities
-4. Hires new agents when needed (subject to your approval)
-
-You don't need to manually assign every task — set the goals and let the CEO organize the work. You approve key decisions (strategy, hiring) and monitor progress. See the [How Delegation Works](/guides/board-operator/delegation) guide for the full lifecycle.
-
 ## Heartbeats
 
 Agents don't run continuously. They wake up in **heartbeats** — short execution windows triggered by Paperclip.

docs/start/quickstart.md

@@ -13,8 +13,6 @@ npx paperclipai onboard --yes
 
 This walks you through setup, configures your environment, and gets Paperclip running.
 
-If you already have a Paperclip install, rerunning `onboard` keeps your current config and data paths intact. Use `paperclipai configure` if you want to edit settings.
-
 To start Paperclip again later:
 
 ```sh

package.json

@@ -3,11 +3,9 @@
   "private": true,
   "type": "module",
   "scripts": {
-    "dev": "pnpm --filter @paperclipai/server exec tsx ../scripts/dev-runner.ts watch",
-    "dev:watch": "pnpm --filter @paperclipai/server exec tsx ../scripts/dev-runner.ts watch",
-    "dev:once": "pnpm --filter @paperclipai/server exec tsx ../scripts/dev-runner.ts dev",
-    "dev:list": "pnpm --filter @paperclipai/server exec tsx ../scripts/dev-service.ts list",
-    "dev:stop": "pnpm --filter @paperclipai/server exec tsx ../scripts/dev-service.ts stop",
+    "dev": "node scripts/dev-runner.mjs watch",
+    "dev:watch": "node scripts/dev-runner.mjs watch",
+    "dev:once": "node scripts/dev-runner.mjs dev",
     "dev:server": "pnpm --filter @paperclipai/server dev",
     "dev:ui": "pnpm --filter @paperclipai/ui dev",
     "build": "pnpm -r build",
@@ -34,8 +32,7 @@
     "test:e2e:headed": "npx playwright test --config tests/e2e/playwright.config.ts --headed",
     "evals:smoke": "cd evals/promptfoo && npx promptfoo@0.103.3 eval",
     "test:release-smoke": "npx playwright test --config tests/release-smoke/playwright.config.ts",
-    "test:release-smoke:headed": "npx playwright test --config tests/release-smoke/playwright.config.ts --headed",
-    "metrics:paperclip-commits": "tsx scripts/paperclip-commit-metrics.ts"
+    "test:release-smoke:headed": "npx playwright test --config tests/release-smoke/playwright.config.ts --headed"
   },
   "devDependencies": {
     "@playwright/test": "^1.58.2",

packages/adapter-utils/src/adapter-skill-config.ts

@@ -1,120 +0,0 @@
-import type { AdapterSkillConfig } from "./types.js";
-
-/**
- * Static configuration for all known adapter types.
- * This is the single source of truth for skill directory paths, formats, and
- * install capability across the Nexus adapter ecosystem.
- */
-const ADAPTER_SKILL_CONFIGS: readonly AdapterSkillConfig[] = [
-  {
-    adapterType: "claude_local",
-    skillDir: "~/.claude/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "hermes_local",
-    skillDir: "~/.hermes/skills/",
-    nativeSkillDir: "~/.hermes/skills/",
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "openclaw_gateway",
-    skillDir: "~/.openclaw/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "codex_local",
-    skillDir: "~/.agents/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "cursor",
-    skillDir: "~/.cursor/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "opencode_local",
-    skillDir: "~/.config/opencode/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "pi_local",
-    skillDir: "~/.pi/agent/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "gemini_local",
-    skillDir: "~/.gemini/skills/",
-    nativeSkillDir: null,
-    format: "skill-md",
-    supportsInstall: true,
-    unsupportedReason: null,
-  },
-  {
-    adapterType: "process",
-    skillDir: null,
-    nativeSkillDir: null,
-    format: "none",
-    supportsInstall: false,
-    unsupportedReason: "Skills not supported for this adapter type",
-  },
-  {
-    adapterType: "http",
-    skillDir: null,
-    nativeSkillDir: null,
-    format: "none",
-    supportsInstall: false,
-    unsupportedReason: "Skills not supported for this adapter type",
-  },
-];
-
-/** Lookup index built from the static config array for O(1) resolution. */
-const CONFIG_BY_TYPE = new Map<string, AdapterSkillConfig>(
-  ADAPTER_SKILL_CONFIGS.map((cfg) => [cfg.adapterType, cfg]),
-);
-
-/** Fallback returned for unknown adapter types — never throws. */
-const FALLBACK_CONFIG: AdapterSkillConfig = {
-  adapterType: "unknown",
-  skillDir: null,
-  nativeSkillDir: null,
-  format: "none",
-  supportsInstall: false,
-  unsupportedReason: "Unknown adapter type — skills not supported",
-};
-
-/**
- * Returns the AdapterSkillConfig for the given adapter type.
- * Unknown types receive a safe fallback config with supportsInstall: false.
- * Never throws.
- */
-export function resolveAdapterSkillConfig(adapterType: string): AdapterSkillConfig {
-  return CONFIG_BY_TYPE.get(adapterType) ?? { ...FALLBACK_CONFIG, adapterType };
-}
-
-/**
- * Returns all registered adapter skill configs (one per known adapter type).
- */
-export function listAdapterSkillConfigs(): readonly AdapterSkillConfig[] {
-  return ADAPTER_SKILL_CONFIGS;
-}

packages/adapter-utils/src/index.ts

@@ -1,5 +1,3 @@
-export type { AdapterSkillFormat, AdapterSkillConfig } from "./types.js";
-export { resolveAdapterSkillConfig, listAdapterSkillConfigs } from "./adapter-skill-config.js";
 export type {
   AdapterAgent,
   AdapterRuntime,

packages/adapter-utils/src/server-utils.ts

@@ -201,33 +201,6 @@ export function redactEnvForLogs(env: Record<string, string>): Record<string, st
   return redacted;
 }
 
-export function buildInvocationEnvForLogs(
-  env: Record<string, string>,
-  options: {
-    runtimeEnv?: NodeJS.ProcessEnv | Record<string, string>;
-    includeRuntimeKeys?: string[];
-    resolvedCommand?: string | null;
-    resolvedCommandEnvKey?: string;
-  } = {},
-): Record<string, string> {
-  const merged: Record<string, string> = { ...env };
-  const runtimeEnv = options.runtimeEnv ?? {};
-
-  for (const key of options.includeRuntimeKeys ?? []) {
-    if (key in merged) continue;
-    const value = runtimeEnv[key];
-    if (typeof value !== "string" || value.length === 0) continue;
-    merged[key] = value;
-  }
-
-  const resolvedCommand = options.resolvedCommand?.trim();
-  if (resolvedCommand) {
-    merged[options.resolvedCommandEnvKey ?? "PAPERCLIP_RESOLVED_COMMAND"] = resolvedCommand;
-  }
-
-  return redactEnvForLogs(merged);
-}
-
 export function buildPaperclipEnv(agent: { id: string; companyId: string }): Record<string, string> {
   const resolveHostForUrl = (rawHost: string): string => {
     const host = rawHost.trim();
@@ -296,10 +269,6 @@ async function resolveCommandPath(command: string, cwd: string, env: NodeJS.Proc
   return null;
 }
 
-export async function resolveCommandForLogs(command: string, cwd: string, env: NodeJS.ProcessEnv): Promise<string> {
-  return (await resolveCommandPath(command, cwd, env)) ?? command;
-}
-
 function quoteForCmd(arg: string) {
   if (!arg.length) return '""';
   const escaped = arg.replace(/"/g, '""');

packages/adapter-utils/src/types.ts

@@ -287,12 +287,6 @@ export interface ServerAdapterModule {
    * without knowing provider-specific credential paths or API shapes.
    */
   getQuotaWindows?: () => Promise<ProviderQuotaResult>;
-  /**
-   * Optional: detect the currently configured model from local config files.
-   * Returns the detected model/provider and the config source, or null if
-   * the adapter does not support detection or no config is found.
-   */
-  detectModel?: () => Promise<{ model: string; provider: string; source: string } | null>;
 }
 
 // ---------------------------------------------------------------------------
@@ -354,36 +348,3 @@ export interface CreateConfigValues {
   heartbeatEnabled: boolean;
   intervalSec: number;
 }
-
-// ---------------------------------------------------------------------------
-// Adapter skill config types — maps adapter type to skill directory and capabilities
-// ---------------------------------------------------------------------------
-
-/** Format of skill files recognized by the adapter. */
-export type AdapterSkillFormat = "skill-md" | "none";
-
-/**
- * Static configuration describing where an adapter stores skills and whether
- * the Nexus skill install/uninstall flow is supported for it.
- */
-export interface AdapterSkillConfig {
-  /** The adapter type string (e.g. "claude_local", "hermes_local"). */
-  adapterType: string;
-  /**
-   * Path to the directory where skills are installed for this adapter.
-   * Uses `~` as home-directory prefix. Null when skills are not supported.
-   */
-  skillDir: string | null;
-  /**
-   * Path to the adapter's native skill directory when it differs from skillDir,
-   * e.g. when the adapter has its own concept of a skills folder.
-   * Null for most adapters.
-   */
-  nativeSkillDir?: string | null;
-  /** Format of skill documents used by this adapter. */
-  format: AdapterSkillFormat;
-  /** Whether the Nexus install/uninstall flow is supported for this adapter. */
-  supportsInstall: boolean;
-  /** Human-readable reason why skills are not supported (when supportsInstall is false). */
-  unsupportedReason: string | null;
-}

packages/adapters/claude-local/src/cli/format-event.ts

@@ -17,27 +17,6 @@ function asErrorText(value: unknown): string {
   }
 }
 
-function printToolResult(block: Record<string, unknown>): void {
-  const isError = block.is_error === true;
-  let text = "";
-  if (typeof block.content === "string") {
-    text = block.content;
-  } else if (Array.isArray(block.content)) {
-    const parts: string[] = [];
-    for (const part of block.content) {
-      if (typeof part !== "object" || part === null || Array.isArray(part)) continue;
-      const record = part as Record<string, unknown>;
-      if (typeof record.text === "string") parts.push(record.text);
-    }
-    text = parts.join("\n");
-  }
-
-  console.log((isError ? pc.red : pc.cyan)(`tool_result${isError ? " (error)" : ""}`));
-  if (text) {
-    console.log((isError ? pc.red : pc.gray)(text));
-  }
-}
-
 export function printClaudeStreamEvent(raw: string, debug: boolean): void {
   const line = raw.trim();
   if (!line) return;
@@ -72,9 +51,6 @@ export function printClaudeStreamEvent(raw: string, debug: boolean): void {
       if (blockType === "text") {
         const text = typeof block.text === "string" ? block.text : "";
         if (text) console.log(pc.green(`assistant: ${text}`));
-      } else if (blockType === "thinking") {
-        const text = typeof block.thinking === "string" ? block.thinking : "";
-        if (text) console.log(pc.gray(`thinking: ${text}`));
       } else if (blockType === "tool_use") {
         const name = typeof block.name === "string" ? block.name : "unknown";
         console.log(pc.yellow(`tool_call: ${name}`));
@@ -86,22 +62,6 @@ export function printClaudeStreamEvent(raw: string, debug: boolean): void {
     return;
   }
 
-  if (type === "user") {
-    const message =
-      typeof parsed.message === "object" && parsed.message !== null && !Array.isArray(parsed.message)
-        ? (parsed.message as Record<string, unknown>)
-        : {};
-    const content = Array.isArray(message.content) ? message.content : [];
-    for (const blockRaw of content) {
-      if (typeof blockRaw !== "object" || blockRaw === null || Array.isArray(blockRaw)) continue;
-      const block = blockRaw as Record<string, unknown>;
-      if (typeof block.type === "string" && block.type === "tool_result") {
-        printToolResult(block);
-      }
-    }
-    return;
-  }
-
   if (type === "result") {
     const usage =
       typeof parsed.usage === "object" && parsed.usage !== null && !Array.isArray(parsed.usage)

packages/adapters/claude-local/src/index.ts

@@ -26,7 +26,7 @@ Core fields:
 - extraArgs (string[], optional): additional CLI args
 - env (object, optional): KEY=VALUE environment variables
 - workspaceStrategy (object, optional): execution workspace strategy; currently supports { type: "git_worktree", baseRef?, branchTemplate?, worktreeParentDir? }
-- workspaceRuntime (object, optional): reserved for workspace runtime metadata; workspace runtime services are manually controlled from the workspace UI and are not auto-started by heartbeats
+- workspaceRuntime (object, optional): workspace runtime service intents; local host-managed services are realized before Claude starts and exposed back via context/env
 
 Operational fields:
 - timeoutSec (number, optional): run timeout in seconds

packages/adapters/claude-local/src/server/execute.ts

@@ -14,11 +14,10 @@ import {
   buildPaperclipEnv,
   readPaperclipRuntimeSkillEntries,
   joinPromptSections,
-  buildInvocationEnvForLogs,
+  redactEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePathInEnv,
-  resolveCommandForLogs,
   renderTemplate,
   runChildProcess,
 } from "@paperclipai/adapter-utils/server-utils";
@@ -69,13 +68,11 @@ interface ClaudeExecutionInput {
 
 interface ClaudeRuntimeConfig {
   command: string;
-  resolvedCommand: string;
   cwd: string;
   workspaceId: string | null;
   workspaceRepoUrl: string | null;
   workspaceRepoRef: string | null;
   env: Record<string, string>;
-  loggedEnv: Record<string, string>;
   timeoutSec: number;
   graceSec: number;
   extraArgs: string[];
@@ -239,12 +236,6 @@ async function buildClaudeRuntimeConfig(input: ClaudeExecutionInput): Promise<Cl
 
   const runtimeEnv = ensurePathInEnv({ ...process.env, ...env });
   await ensureCommandResolvable(command, cwd, runtimeEnv);
-  const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-  const loggedEnv = buildInvocationEnvForLogs(env, {
-    runtimeEnv,
-    includeRuntimeKeys: ["HOME", "CLAUDE_CONFIG_DIR"],
-    resolvedCommand,
-  });
 
   const timeoutSec = asNumber(config.timeoutSec, 0);
   const graceSec = asNumber(config.graceSec, 20);
@@ -256,13 +247,11 @@ async function buildClaudeRuntimeConfig(input: ClaudeExecutionInput): Promise<Cl
 
   return {
     command,
-    resolvedCommand,
     cwd,
     workspaceId,
     workspaceRepoUrl,
     workspaceRepoRef,
     env,
-    loggedEnv,
     timeoutSec,
     graceSec,
     extraArgs,
@@ -335,13 +324,11 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
   });
   const {
     command,
-    resolvedCommand,
     cwd,
     workspaceId,
     workspaceRepoUrl,
     workspaceRepoRef,
     env,
-    loggedEnv,
     timeoutSec,
     graceSec,
     extraArgs,
@@ -453,11 +440,11 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     if (onMeta) {
       await onMeta({
         adapterType: "claude_local",
-        command: resolvedCommand,
+        command,
         cwd,
         commandArgs: args,
         commandNotes,
-        env: loggedEnv,
+        env: redactEnvForLogs(env),
         prompt,
         promptMetrics,
         context,

packages/adapters/codex-local/src/index.ts

@@ -24,7 +24,7 @@ Core fields:
 - cwd (string, optional): default absolute working directory fallback for the agent process (created if missing when possible)
 - instructionsFilePath (string, optional): absolute path to a markdown instructions file prepended to stdin prompt at runtime
 - model (string, optional): Codex model id
-- modelReasoningEffort (string, optional): reasoning effort override (minimal|low|medium|high|xhigh) passed via -c model_reasoning_effort=...
+- modelReasoningEffort (string, optional): reasoning effort override (minimal|low|medium|high) passed via -c model_reasoning_effort=...
 - promptTemplate (string, optional): run prompt template
 - search (boolean, optional): run codex with --search
 - dangerouslyBypassApprovalsAndSandbox (boolean, optional): run with bypass flag
@@ -32,7 +32,7 @@ Core fields:
 - extraArgs (string[], optional): additional CLI args
 - env (object, optional): KEY=VALUE environment variables
 - workspaceStrategy (object, optional): execution workspace strategy; currently supports { type: "git_worktree", baseRef?, branchTemplate?, worktreeParentDir? }
-- workspaceRuntime (object, optional): reserved for workspace runtime metadata; workspace runtime services are manually controlled from the workspace UI and are not auto-started by heartbeats
+- workspaceRuntime (object, optional): workspace runtime service intents; local host-managed services are realized before Codex starts and exposed back via context/env
 
 Operational fields:
 - timeoutSec (number, optional): run timeout in seconds

packages/adapters/codex-local/src/server/execute.ts

@@ -9,13 +9,12 @@ import {
   asStringArray,
   parseObject,
   buildPaperclipEnv,
-  buildInvocationEnvForLogs,
+  redactEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePaperclipSkillSymlink,
   ensurePathInEnv,
   readPaperclipRuntimeSkillEntries,
-  resolveCommandForLogs,
   resolvePaperclipDesiredSkillNames,
   renderTemplate,
   joinPromptSections,
@@ -384,12 +383,6 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
   const billingType = resolveCodexBillingType(effectiveEnv);
   const runtimeEnv = ensurePathInEnv(effectiveEnv);
   await ensureCommandResolvable(command, cwd, runtimeEnv);
-  const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-  const loggedEnv = buildInvocationEnvForLogs(env, {
-    runtimeEnv,
-    includeRuntimeKeys: ["HOME"],
-    resolvedCommand,
-  });
 
   const timeoutSec = asNumber(config.timeoutSec, 0);
   const graceSec = asNumber(config.graceSec, 20);
@@ -497,14 +490,14 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     if (onMeta) {
       await onMeta({
         adapterType: "codex_local",
-        command: resolvedCommand,
+        command,
         cwd,
         commandNotes,
         commandArgs: args.map((value, idx) => {
           if (idx === args.length - 1 && value !== "-") return `<prompt ${prompt.length} chars>`;
           return value;
         }),
-        env: loggedEnv,
+        env: redactEnvForLogs(env),
         prompt,
         promptMetrics,
         context,

packages/adapters/codex-local/src/server/quota-spawn-error.test.ts

@@ -1,85 +0,0 @@
-import { EventEmitter } from "node:events";
-import fs from "node:fs";
-import os from "node:os";
-import path from "node:path";
-import type { ChildProcess } from "node:child_process";
-import { describe, expect, it, vi, beforeEach, afterEach } from "vitest";
-
-const { mockSpawn } = vi.hoisted(() => ({
-  mockSpawn: vi.fn(),
-}));
-
-vi.mock("node:child_process", async (importOriginal) => {
-  const cp = await importOriginal<typeof import("node:child_process")>();
-  return {
-    ...cp,
-    spawn: (...args: Parameters<typeof cp.spawn>) => mockSpawn(...args) as ReturnType<typeof cp.spawn>,
-  };
-});
-
-import { getQuotaWindows } from "./quota.js";
-
-function createChildThatErrorsOnMicrotask(err: Error): ChildProcess {
-  const child = new EventEmitter() as ChildProcess;
-  const stream = Object.assign(new EventEmitter(), {
-    setEncoding: () => {},
-  });
-  Object.assign(child, {
-    stdout: stream,
-    stderr: Object.assign(new EventEmitter(), { setEncoding: () => {} }),
-    stdin: { write: vi.fn(), end: vi.fn() },
-    kill: vi.fn(),
-  });
-  queueMicrotask(() => {
-    child.emit("error", err);
-  });
-  return child;
-}
-
-describe("CodexRpcClient spawn failures", () => {
-  let previousCodexHome: string | undefined;
-  let isolatedCodexHome: string | undefined;
-
-  beforeEach(() => {
-    mockSpawn.mockReset();
-    // After the RPC path fails, getQuotaWindows() calls readCodexToken() which
-    // reads $CODEX_HOME/auth.json (default ~/.codex). Point CODEX_HOME at an
-    // empty temp directory so we never hit real host auth or the WHAM network.
-    previousCodexHome = process.env.CODEX_HOME;
-    isolatedCodexHome = fs.mkdtempSync(path.join(os.tmpdir(), "paperclip-codex-spawn-test-"));
-    process.env.CODEX_HOME = isolatedCodexHome;
-  });
-
-  afterEach(() => {
-    if (isolatedCodexHome) {
-      try {
-        fs.rmSync(isolatedCodexHome, { recursive: true, force: true });
-      } catch {
-        /* ignore */
-      }
-      isolatedCodexHome = undefined;
-    }
-    if (previousCodexHome === undefined) {
-      delete process.env.CODEX_HOME;
-    } else {
-      process.env.CODEX_HOME = previousCodexHome;
-    }
-  });
-
-  it("does not crash the process when codex is missing; getQuotaWindows returns ok: false", async () => {
-    const enoent = Object.assign(new Error("spawn codex ENOENT"), {
-      code: "ENOENT",
-      errno: -2,
-      syscall: "spawn codex",
-      path: "codex",
-    });
-    mockSpawn.mockImplementation(() => createChildThatErrorsOnMicrotask(enoent));
-
-    const result = await getQuotaWindows();
-
-    expect(result.ok).toBe(false);
-    expect(result.windows).toEqual([]);
-    expect(result.error).toContain("Codex app-server");
-    expect(result.error).toContain("spawn codex ENOENT");
-  });
-});

packages/adapters/codex-local/src/server/quota.ts

@@ -432,13 +432,6 @@ class CodexRpcClient {
       }
       this.pending.clear();
     });
-    this.proc.on("error", (err: Error) => {
-      for (const request of this.pending.values()) {
-        clearTimeout(request.timer);
-        request.reject(err);
-      }
-      this.pending.clear();
-    });
   }
 
   private onStdout(chunk: string) {

packages/adapters/codex-local/vitest.config.ts

@@ -1,7 +0,0 @@
-import { defineConfig } from "vitest/config";
-
-export default defineConfig({
-  test: {
-    environment: "node",
-  },
-});

packages/adapters/cursor-local/src/server/execute.ts

@@ -9,13 +9,12 @@ import {
   asStringArray,
   parseObject,
   buildPaperclipEnv,
-  buildInvocationEnvForLogs,
+  redactEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePaperclipSkillSymlink,
   ensurePathInEnv,
   readPaperclipRuntimeSkillEntries,
-  resolveCommandForLogs,
   resolvePaperclipDesiredSkillNames,
   removeMaintainerOnlySkillSymlinks,
   renderTemplate,
@@ -272,12 +271,6 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
   const billingType = resolveCursorBillingType(effectiveEnv);
   const runtimeEnv = ensurePathInEnv(effectiveEnv);
   await ensureCommandResolvable(command, cwd, runtimeEnv);
-  const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-  const loggedEnv = buildInvocationEnvForLogs(env, {
-    runtimeEnv,
-    includeRuntimeKeys: ["HOME"],
-    resolvedCommand,
-  });
 
   const timeoutSec = asNumber(config.timeoutSec, 0);
   const graceSec = asNumber(config.graceSec, 20);
@@ -390,11 +383,11 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     if (onMeta) {
       await onMeta({
         adapterType: "cursor",
-        command: resolvedCommand,
+        command,
         cwd,
         commandNotes,
         commandArgs: args,
-        env: loggedEnv,
+        env: redactEnvForLogs(env),
         prompt,
         promptMetrics,
         context,

packages/adapters/gemini-local/src/server/execute.ts

@@ -10,17 +10,16 @@ import {
   asString,
   asStringArray,
   buildPaperclipEnv,
-  buildInvocationEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePaperclipSkillSymlink,
   joinPromptSections,
   ensurePathInEnv,
   readPaperclipRuntimeSkillEntries,
-  resolveCommandForLogs,
   resolvePaperclipDesiredSkillNames,
   removeMaintainerOnlySkillSymlinks,
   parseObject,
+  redactEnvForLogs,
   renderTemplate,
   runChildProcess,
 } from "@paperclipai/adapter-utils/server-utils";
@@ -221,12 +220,6 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
   const billingType = resolveGeminiBillingType(effectiveEnv);
   const runtimeEnv = ensurePathInEnv(effectiveEnv);
   await ensureCommandResolvable(command, cwd, runtimeEnv);
-  const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-  const loggedEnv = buildInvocationEnvForLogs(env, {
-    runtimeEnv,
-    includeRuntimeKeys: ["HOME"],
-    resolvedCommand,
-  });
 
   const timeoutSec = asNumber(config.timeoutSec, 0);
   const graceSec = asNumber(config.graceSec, 20);
@@ -340,13 +333,13 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     if (onMeta) {
       await onMeta({
         adapterType: "gemini_local",
-        command: resolvedCommand,
+        command,
         cwd,
         commandNotes,
         commandArgs: args.map((value, index) => (
           index === args.length - 1 ? `<prompt ${prompt.length} chars>` : value
         )),
-        env: loggedEnv,
+        env: redactEnvForLogs(env),
         prompt,
         promptMetrics,
         context,

packages/adapters/openclaw-gateway/src/index.ts

@@ -31,7 +31,7 @@ Gateway connect identity fields:
 
 Request behavior fields:
 - payloadTemplate (object, optional): additional fields merged into gateway agent params
-- workspaceRuntime (object, optional): reserved workspace runtime metadata; workspace runtime services are manually controlled from the workspace UI and are not auto-started by heartbeats
+- workspaceRuntime (object, optional): desired runtime service intents; Paperclip forwards these in a standardized paperclip.workspaceRuntime block for remote execution environments
 - timeoutSec (number, optional): adapter timeout in seconds (default 120)
 - waitTimeoutMs (number, optional): agent.wait timeout override (default timeoutSec * 1000)
 - autoPairOnFirstConnect (boolean, optional): on first "pairing required", attempt device.pair.list/device.pair.approve via shared auth, then retry once (default true)
@@ -45,7 +45,7 @@ Standard outbound payload additions:
 - paperclip (object): standardized Paperclip context added to every gateway agent request
 - paperclip.workspace (object, optional): resolved execution workspace for this run
 - paperclip.workspaces (array, optional): additional workspace hints Paperclip exposed to the run
-- paperclip.workspaceRuntime (object, optional): reserved workspace runtime metadata when explicitly supplied outside normal heartbeat execution
+- paperclip.workspaceRuntime (object, optional): normalized runtime service intent config for the workspace
 
 Standard result metadata supported:
 - meta.runtimeServices (array, optional): normalized adapter-managed runtime service reports

packages/adapters/opencode-local/src/index.ts

@@ -1,15 +1,7 @@
 export const type = "opencode_local";
 export const label = "OpenCode (local)";
 
-export const DEFAULT_OPENCODE_LOCAL_MODEL = "openai/gpt-5.2-codex";
-
-export const models: Array<{ id: string; label: string }> = [
-  { id: DEFAULT_OPENCODE_LOCAL_MODEL, label: DEFAULT_OPENCODE_LOCAL_MODEL },
-  { id: "openai/gpt-5.4", label: "openai/gpt-5.4" },
-  { id: "openai/gpt-5.2", label: "openai/gpt-5.2" },
-  { id: "openai/gpt-5.1-codex-max", label: "openai/gpt-5.1-codex-max" },
-  { id: "openai/gpt-5.1-codex-mini", label: "openai/gpt-5.1-codex-mini" },
-];
+export const models: Array<{ id: string; label: string }> = [];
 
 export const agentConfigurationDoc = `# opencode_local agent configuration
 
@@ -29,7 +21,7 @@ Core fields:
 - cwd (string, optional): default absolute working directory fallback for the agent process (created if missing when possible)
 - instructionsFilePath (string, optional): absolute path to a markdown instructions file prepended to the run prompt
 - model (string, required): OpenCode model id in provider/model format (for example anthropic/claude-sonnet-4-5)
-- variant (string, optional): provider-specific reasoning/profile variant passed as --variant (for example minimal|low|medium|high|xhigh|max)
+- variant (string, optional): provider-specific model variant (for example minimal|low|medium|high|max)
 - dangerouslySkipPermissions (boolean, optional): inject a runtime OpenCode config that allows \`external_directory\` access without interactive prompts; defaults to true for unattended Paperclip runs
 - promptTemplate (string, optional): run prompt template
 - command (string, optional): defaults to "opencode"

packages/adapters/opencode-local/src/server/execute.ts

@@ -10,12 +10,11 @@ import {
   parseObject,
   buildPaperclipEnv,
   joinPromptSections,
-  buildInvocationEnvForLogs,
+  redactEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePaperclipSkillSymlink,
   ensurePathInEnv,
-  resolveCommandForLogs,
   renderTemplate,
   runChildProcess,
   readPaperclipRuntimeSkillEntries,
@@ -187,12 +186,6 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
       ),
     );
     await ensureCommandResolvable(command, cwd, runtimeEnv);
-    const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-    const loggedEnv = buildInvocationEnvForLogs(preparedRuntimeConfig.env, {
-      runtimeEnv,
-      includeRuntimeKeys: ["HOME"],
-      resolvedCommand,
-    });
 
     await ensureOpenCodeModelConfiguredAndAvailable({
       model,
@@ -305,11 +298,11 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
       if (onMeta) {
         await onMeta({
           adapterType: "opencode_local",
-          command: resolvedCommand,
+          command,
           cwd,
           commandNotes,
           commandArgs: [...args, `<stdin prompt ${prompt.length} chars>`],
-          env: loggedEnv,
+          env: redactEnvForLogs(preparedRuntimeConfig.env),
           prompt,
           promptMetrics,
           context,

packages/adapters/pi-local/src/server/execute.ts

@@ -10,13 +10,12 @@ import {
   parseObject,
   buildPaperclipEnv,
   joinPromptSections,
-  buildInvocationEnvForLogs,
+  redactEnvForLogs,
   ensureAbsoluteDirectory,
   ensureCommandResolvable,
   ensurePaperclipSkillSymlink,
   ensurePathInEnv,
   readPaperclipRuntimeSkillEntries,
-  resolveCommandForLogs,
   resolvePaperclipDesiredSkillNames,
   removeMaintainerOnlySkillSymlinks,
   renderTemplate,
@@ -205,12 +204,6 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     ),
   );
   await ensureCommandResolvable(command, cwd, runtimeEnv);
-  const resolvedCommand = await resolveCommandForLogs(command, cwd, runtimeEnv);
-  const loggedEnv = buildInvocationEnvForLogs(env, {
-    runtimeEnv,
-    includeRuntimeKeys: ["HOME"],
-    resolvedCommand,
-  });
 
   // Validate model is available before execution
   await ensurePiModelConfiguredAndAvailable({
@@ -363,11 +356,11 @@ export async function execute(ctx: AdapterExecutionContext): Promise<AdapterExec
     if (onMeta) {
       await onMeta({
         adapterType: "pi_local",
-        command: resolvedCommand,
+        command,
         cwd,
         commandNotes,
         commandArgs: args,
-        env: loggedEnv,
+        env: redactEnvForLogs(env),
         prompt: userPrompt,
         promptMetrics,
         context,

packages/db/src/client.test.ts

@@ -169,76 +169,4 @@ describeEmbeddedPostgres("applyPendingMigrations", () => {
     },
     20_000,
   );
-
-  it(
-    "replays migration 0046 safely when document revision columns already exist",
-    async () => {
-      const connectionString = await createTempDatabase();
-
-      await applyPendingMigrations(connectionString);
-
-      const sql = postgres(connectionString, { max: 1, onnotice: () => {} });
-      try {
-        const smoothSentinelsHash = await migrationHash("0046_smooth_sentinels.sql");
-
-        await sql.unsafe(
-          `DELETE FROM "drizzle"."__drizzle_migrations" WHERE hash = '${smoothSentinelsHash}'`,
-        );
-
-        const columns = await sql.unsafe<{ column_name: string; is_nullable: string; column_default: string | null }[]>(
-          `
-            SELECT column_name, is_nullable, column_default
-            FROM information_schema.columns
-            WHERE table_schema = 'public'
-              AND table_name = 'document_revisions'
-              AND column_name IN ('title', 'format')
-            ORDER BY column_name
-          `,
-        );
-        expect(columns).toHaveLength(2);
-      } finally {
-        await sql.end();
-      }
-
-      const pendingState = await inspectMigrations(connectionString);
-      expect(pendingState).toMatchObject({
-        status: "needsMigrations",
-        pendingMigrations: ["0046_smooth_sentinels.sql"],
-        reason: "pending-migrations",
-      });
-
-      await applyPendingMigrations(connectionString);
-
-      const finalState = await inspectMigrations(connectionString);
-      expect(finalState.status).toBe("upToDate");
-
-      const verifySql = postgres(connectionString, { max: 1, onnotice: () => {} });
-      try {
-        const columns = await verifySql.unsafe<{ column_name: string; is_nullable: string; column_default: string | null }[]>(
-          `
-            SELECT column_name, is_nullable, column_default
-            FROM information_schema.columns
-            WHERE table_schema = 'public'
-              AND table_name = 'document_revisions'
-              AND column_name IN ('title', 'format')
-            ORDER BY column_name
-          `,
-        );
-        expect(columns).toEqual([
-          expect.objectContaining({
-            column_name: "format",
-            is_nullable: "NO",
-          }),
-          expect.objectContaining({
-            column_name: "title",
-            is_nullable: "YES",
-          }),
-        ]);
-        expect(columns[0]?.column_default).toContain("'markdown'");
-      } finally {
-        await verifySql.end();
-      }
-    },
-    20_000,
-  );
 });

packages/db/src/migrations/0046_smooth_sentinels.sql

@@ -1,11 +0,0 @@
-ALTER TABLE "document_revisions" ADD COLUMN IF NOT EXISTS "title" text;--> statement-breakpoint
-ALTER TABLE "document_revisions" ADD COLUMN IF NOT EXISTS "format" text;--> statement-breakpoint
-ALTER TABLE "document_revisions" ALTER COLUMN "format" SET DEFAULT 'markdown';
---> statement-breakpoint
-UPDATE "document_revisions" AS "dr"
-SET
-  "title" = COALESCE("dr"."title", "d"."title"),
-  "format" = COALESCE("dr"."format", "d"."format", 'markdown')
-FROM "documents" AS "d"
-WHERE "d"."id" = "dr"."document_id";--> statement-breakpoint
-ALTER TABLE "document_revisions" ALTER COLUMN "format" SET NOT NULL;

packages/db/src/migrations/0047_fixed_johnny_storm.sql

@@ -1,27 +0,0 @@
-CREATE TABLE "chat_conversations" (
-	"id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
-	"company_id" uuid NOT NULL,
-	"title" text,
-	"agent_id" uuid,
-	"pinned_at" timestamp with time zone,
-	"archived_at" timestamp with time zone,
-	"deleted_at" timestamp with time zone,
-	"created_at" timestamp with time zone DEFAULT now() NOT NULL,
-	"updated_at" timestamp with time zone DEFAULT now() NOT NULL
-);
---> statement-breakpoint
-CREATE TABLE "chat_messages" (
-	"id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
-	"conversation_id" uuid NOT NULL,
-	"role" text NOT NULL,
-	"content" text NOT NULL,
-	"agent_id" uuid,
-	"created_at" timestamp with time zone DEFAULT now() NOT NULL
-);
---> statement-breakpoint
-ALTER TABLE "chat_conversations" ADD CONSTRAINT "chat_conversations_company_id_companies_id_fk" FOREIGN KEY ("company_id") REFERENCES "public"."companies"("id") ON DELETE no action ON UPDATE no action;--> statement-breakpoint
-ALTER TABLE "chat_conversations" ADD CONSTRAINT "chat_conversations_agent_id_agents_id_fk" FOREIGN KEY ("agent_id") REFERENCES "public"."agents"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
-ALTER TABLE "chat_messages" ADD CONSTRAINT "chat_messages_conversation_id_chat_conversations_id_fk" FOREIGN KEY ("conversation_id") REFERENCES "public"."chat_conversations"("id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
-CREATE INDEX "chat_conversations_company_updated_idx" ON "chat_conversations" USING btree ("company_id","updated_at");--> statement-breakpoint
-CREATE INDEX "chat_conversations_company_deleted_idx" ON "chat_conversations" USING btree ("company_id","deleted_at");--> statement-breakpoint
-CREATE INDEX "chat_messages_conversation_created_idx" ON "chat_messages" USING btree ("conversation_id","created_at");