Task-by-task implementation plan for Phase 8 of the Nexus layout
overhaul (docs/specs/2026-04-11-nexus-layout-overhaul.md §13).
Seven tasks:
1. IconRail component + test
2. ModeBreadcrumb component + test
3. CmdKButton shim component + test
4. GlobalMicButton scaffold + test
5. TopStrip composite + test
6. Layout.tsx rewrite (mount new frame, kill old chrome)
7. Manual smoke test
TDD throughout (write failing test, run, implement, run, commit).
One commit per task. Execution via subagent-driven-development with
fresh subagent per task and two-stage review.
The plan includes complete code for every task (no placeholders),
exact file paths, exact test patterns matching the existing vitest
manual-createRoot pattern from ChatInput.test.tsx, and wire-up
details for preserving Layout.tsx's non-chrome responsibilities
(company-prefix URL sync, first-run onboarding, body overflow,
instance settings memory, dialog overlays).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds docs/specs/2026-04-11-nexus-layout-overhaul.md defining the
complete layout and information architecture redesign:
- 4-destination primary nav (Assistant, Studio, Projects, Settings)
- 56px left icon rail + 48px top strip as global frame
- Assistant as default landing (full-bleed chat, no side panels)
- Studio as 8-card workshop grid (Convert folded in as 8th workshop)
- Projects with per-project Builder tabs replacing global routes
(Issues, Agents, Gates, Costs, Activity, Org become per-project;
Routines moves to Settings; Goals folds into Overview; Inbox
killed-replaced by assistant dot + cmdK)
- Promote-to-project transition (chat compresses to 30%, brainstormer
rises into 70%, inset shadow ripple, 700ms)
- Voice and Cmd-K as global affordances; ChatPanel/PropertiesPanel
killed as global rails
- Implementation phases 8-16 with parallel subagent dispatch pattern
Also promotes the previously untracked MIGRATION-PLAN.md into the
repo, and extends it with section 8b (structural overhaul summary
table linking to the spec) and section 11 (binding subagent dispatch
pattern for phases 8-16).
Approved 2026-04-11 in brainstorming session; all 25 decisions from
the discussion are captured in spec section 11.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add wget, ripgrep, python3, and GitHub CLI (gh) to base image
- Add OPENCODE_ALLOW_ALL_MODELS=true to production ENV
- Move compose files, onboard-smoke Dockerfile to docker/
- Move entrypoint script to scripts/docker-entrypoint.sh
- Add Podman Quadlet unit files (pod, app, db containers)
- Add docker/README.md with build, compose, and quadlet docs
- Add scripts/docker-build-test.sh for local build validation
- Update all doc references for new file locations
- Keep main Dockerfile at project root (no .dockerignore changes needed)
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Fix openclaw → openclaw_gateway type key in adapters overview and managing-agents guide
- Add missing adapters to overview table: hermes_local, cursor, pi_local
- Mark gemini_local as experimental (adapter package exists but not in stable type enum)
- Update "Choosing an Adapter" recommendations to match stable adapter set
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* docs: add board-operator delegation guide
Create docs/guides/board-operator/delegation.md explaining the full
CEO-led delegation lifecycle from the board operator's perspective.
Covers what the board needs to do, what the CEO automates, common
delegation patterns (flat, 3-level, hire-on-demand), and a
troubleshooting section that directly answers the #1 new-user
confusion point: "Do I have to tell the CEO to delegate?"
Also adds a Delegation section to core-concepts.md and wires the
new guide into docs.json navigation after Managing Tasks.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* docs: add AGENTS.md troubleshooting note to delegation guide
Add a row to the troubleshooting table telling board operators to
verify the CEO's AGENTS.md instructions file contains delegation
directives. Without these instructions, the CEO won't delegate.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* docs: fix stale concept count and frontmatter summary
Update "five key concepts" to "six" and add "delegation" to the
frontmatter summary field, addressing Greptile review comments.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
---------
Co-authored-by: Paperclip <noreply@paperclip.ing>
- SPEC: reflect that Paperclip now manages task-linked documents and
attachments (issue documents, file attachments) instead of claiming
it does not manage work artifacts
- agents-runtime: remove bootstrapPromptTemplate from recommended config,
add deprecation notice, update minimal setup checklist
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Documents the `paperclipai company export` and `paperclipai company import`
CLI commands, covering package format, all options, target modes, collision
strategies, GitHub sources, interactive selection, and API endpoints.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
**#1 — Missing `description` field in fields table**
The create body example included `description` and the schema confirms
`description: z.string().optional().nullable()`, but the reference table
omitted it. Added as an optional field.
**#2 — Concurrency policy descriptions were inaccurate**
Original docs described both `coalesce_if_active` and `skip_if_active` as
variants of "skip", which was wrong. Source-verified against
`server/src/services/routines.ts` (dispatchRoutineRun, line 568):
const status = concurrencyPolicy === "skip_if_active" ? "skipped" : "coalesced";
Both policies write identical DB state (same linkedIssueId and
coalescedIntoRunId); the only difference is the run status value.
Descriptions now reflect this: both finalise the incoming run immediately
and link it to the active run — no new issue is created in either case.
Note: the reviewer's suggestion that `coalesce_if_active` "extends or
notifies" the active run was also not supported by the code; corrected
accordingly.
**#3 — `triggerId` undocumented in Manual Run**
`runRoutineSchema` accepts `triggerId` and the service genuinely uses it
(routines.ts:1029–1034): fetches the trigger, enforces that it belongs to
the routine (403) and is enabled (409), then passes it to dispatchRoutineRun
which records the run against the trigger and updates its `lastFiredAt`.
Added `triggerId` to the example body and documented all three behaviours.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Routines are recurring tasks that fire on a schedule, webhook, or API
call and create a heartbeat run for the assigned agent. Document the
full CRUD surface including:
- List / get routines
- Create with concurrency and catch-up policy options
- Add schedule, webhook, and api triggers
- Update / delete triggers, rotate webhook secrets
- Manual run and public trigger fire
- List run history
- Agent access rules (agents can only manage own routines)
- Routine lifecycle (active → paused → archived)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Fix goals-and-projects.md: `completed` is not a valid status — correct to
`achieved` and document all valid values (planned/active/achieved/cancelled)
- Fix issues.md: document that `expectedStatuses: ["in_progress"]` can be used
to re-claim a stale lock after a crashed run; clarify that `runId` in the
request body is not accepted (run ID comes from X-Paperclip-Run-Id header only)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Introduced ReportsToPicker component in AgentConfigForm and NewAgent pages to allow selection of an agent's manager.
- Updated organizational structure documentation to reflect the ability to change an agent's manager post-creation.
- Enhanced error handling in ConfigurationTab to provide user feedback on save failures.
Resolve conflicts by keeping the issue-documents work alongside upstream heartbeat-context, worktree branding, and adapter runtime updates.
Co-Authored-By: Paperclip <noreply@paperclip.ing>