d6c917d726
## Summary Gives external integrations (command palettes, plugin launchers, alternate dashboard shells) a supported way to **discover the host UI** — instead of hardcoding the dashboard's view ids, labels and settings search terms and hand-syncing them on every release. This is the read-only metadata slice of the "constrained by a stable host context and API client" idea in `docs/proposals/2026-07-01-dashboard-theme-plugin-system.md`, and the follow-on to #2415 (theme tokens + overlay layering). Two additions, both inert unless called: | Endpoint | Returns | |---|---| | `GET /api/views` | Every registered built-in view id, in dashboard order — `id`, English `label`, plus optional i18n `labelKey`, legacy `aliases` and `internal` flag. | | `GET /api/settings/sections` | Selectable Settings sections — `id`, `label`, `labelKey`, `scope`, `group`, `keywords`, `searchableKeys`, `advanced`. | Both are read-only, return static project-independent metadata, take no project id, and are mounted inside `createApiRoutes` so they sit behind exactly the same `/api` authentication as every other dashboard route — no more, no less. ## What actually changed — one source of truth The endpoints are the small part. The core of the diff is **collapsing duplicated UI metadata into two shared registries that now drive both the dashboard UI and the API**: - `packages/dashboard/src/shared/dashboard-views.ts` — canonical view ids + English labels + i18n keys + legacy aliases. - `packages/dashboard/src/shared/settings-sections.ts` — canonical settings sections + scope/group/search metadata, with `group` and `advanced` derived from the list's own structure. `LeftSidebarNav`, `SettingsModal` and `useViewState` were rewritten to consume those registries instead of carrying their own copies (net **−230 lines** in `SettingsModal` alone). Edit the registry and the rendered UI and the API move together. ## Drift protection Being precise about what each test can and cannot catch, because "no-drift" claims are easy to overstate: - `left-sidebar-nav-registry-parity.test.tsx` — the one test that catches drift the registry does not already determine. It **renders** the sidebar with a recording `t()` spy and pins each entry's translation key and English fallback to the registry (the sidebar still hardcodes its keys). It also asserts the rendered destination count equals the enrolled id list, so a newly added sidebar view fails until it is enrolled. - `ui-metadata-sync.test.ts` — pins the Settings navigation list, advanced-visibility set, persisted view list, reset-key registry and both endpoint payloads to the registries. Since those consumers are now *derived* from the registries, these assertions mainly guard against a future consumer **re-hardcoding** its own copy. Two of them do stand on their own: each section's served `group` is pinned to the group header it actually renders under, and no published `labelKey` may resolve to a non-leaf i18n node. - `register-ui-metadata-routes.test.ts` — drives the real Express router and asserts each endpoint serves the registry payload verbatim, with no filtering or reshaping. - Exactly two **existing** tests are updated, both for the same reason: they asserted that `SettingsModal.tsx`'s *source text* contains a section literal that now lives in the registry. `VoiceInputSection.modal-visibility.test.tsx` now asserts Voice Input's Basic-mode contract against `SETTINGS_SECTION_METADATA`, and `mcp-documentation.test.ts` reads the registry for the two MCP section ids. No other existing test in the package changes. ## Design notes / decisions for review - **`GET /api/views` returns the full registry, not the live menu.** It includes flag-gated / experimental ids and `internal` (non-navigable) destinations; reachability depends on flags and plugins this endpoint does not evaluate. Documented as "known view ids", not "visible nav entries". - **`labelKey` is optional and best-effort; `label` is the guarantee.** A `labelKey` is published only where the dashboard itself renders that view's title through it. `graph` (labelled from a plugin manifest) and the internal `task-detail` carry none rather than advertise a key that resolves to nothing — and `task-detail` in particular must not point at `taskDetail.title`, which is an occupied i18n *namespace* whose lookup returns an object rather than falling through to a default. A guard test now enforces that. Separately, a few published keys (`nav.ideation`, `nav.importTasks`, `nav.automations`, `pr.view.title`) are the dashboard's real keys but aren't in the shipped catalogs yet because the host supplies their English inline; the docs say plainly that consumers must fall back to `label`. - **`keywords` / `searchableKeys` are explicitly non-contractual.** `searchableKeys` exposes the raw i18n translation-key strings backing a section's searchable copy; values, ordering and presence may change between releases. Documented as best-effort search hints, never stable identifiers. - **Migration is deliberately partial.** The desktop sidebar, Settings navigation and persisted view list now come from the registries; `Header.tsx` and the mobile More sheet still hardcode a few of the same labels. They can still drift from what `GET /api/views` reports; converting them is left to a follow-up so this diff stays reviewable. - **No project scoping, deliberately.** The proposal doc rightly pushes plugin traffic through a project-scoped client — these two endpoints are the exception that proves the rule: they return static registry metadata that is identical for every project, so threading a `projectId` would imply a scoping guarantee that does not exist here. They never touch `getScopedStore` / `TaskStore`. - **Two endpoints rather than one `/api/ui-metadata` envelope.** Views and Settings sections are independent registries with different consumers, and `/settings/sections` sits naturally beside the existing `/settings/*` routes. A consumer that only needs navigation doesn't pay for settings metadata. - **The registry extraction ships with the endpoints rather than as a separate PR.** The registries *are* the mechanism that keeps the API honest — split apart, the first half is a refactor with no observable effect and the second can't land without it. - **Placement:** `packages/dashboard/src/shared/` is a new directory, and these are the first *production* `app/ → src/` imports in the package (today the only one is in `ProviderIcon.test.tsx`). They sit under `src/` because `src/`'s tsconfig cannot import `app/`, so a module both sides consume has nowhere else to go; both registries are dependency-free data leaves, and `vite build` plus `check-no-node-only-core-imports-in-dashboard` confirm the client bundle is unaffected. The considered alternative was `packages/core/src` behind the `dashboard-browser-safe-core-modules.json` allowlist, where `mobile-nav-primary-items.ts` keeps a destination→labelKey table — these stayed out of `core` because they are dashboard-owned UI ids, and because the two tables describe different surfaces (core mirrors the mobile nav's `nav.skills`/`nav.settings`; this registry mirrors the desktop sidebar's `header.skillsView`/`header.settings`). - Ships a `@runfusion/fusion` **minor** changeset (`category: feature`). Happy to adjust any of the above — shape, placement, or dropping `searchableKeys` — if you'd rather it landed differently. ## Verification - Rebased onto `main@26dcccb7c`. Two conflicts, both resolved by absorbing upstream's work rather than reverting it: - `SettingsModal.tsx` — upstream's `voice-input` section (and the `FNXC:VoiceInput` decision comment explaining it stays out of the advanced-only set) moved into the registry. The registry's section list is byte-identical to `main`'s `SETTINGS_SECTIONS` (45/45 entries, all fields), and the registry-derived `ADVANCED_SETTINGS_SECTION_IDS` is identical to `main`'s hardcoded set (19/19, same order) — both verified mechanically, not by eye. Upstream's `RUNTIME_*` hide-uninstalled-runtimes sets are untouched. - `routes/README.md` — the `mount-sequence` list regenerated from `CREATE_API_ROUTES_REGISTRAR_MOUNT_SEQUENCE`, so `registerVoiceRoutes` and `registerUiMetadataRoutes` are both in place and the contract test passes. - `DASHBOARD_VIEWS` covers exactly `main`'s `BuiltInTaskView` union, aliases included, and `BUILT_IN_TASK_VIEWS` reproduces `main`'s 27-entry array in order (`devserver` still preceding `dev-server` for the migration path). - Every one of the 20 sidebar labels the refactor rewrote was checked to be byte-identical to `main`'s hardcoded fallback, and every `FNXC:` decision comment displaced by the move was accounted for — all 75 in `SettingsModal.tsx` and all 11 in `useViewState.ts` survive, relocated onto the registry entries they document. - The full `dashboard-app` + `dashboard-api` suites were run at this commit (**20,706 passing**) and again on unmodified `main@26dcccb7c`, and the failing-file sets compared: **every file that fails here also fails on `main`** — nothing regresses. The overlap is environment-driven (Postgres-backed `*.pg.test.ts`, tests needing built `dist` artifacts, and `SettingsModalNodeRouting.test.tsx`'s `No "fetchSystemInfo" export is defined on the "../../api" mock`), none of it touched by this change. - `tsc --noEmit` clean for both dashboard projects, `eslint` clean on every changed file, and `vite build` of the client bundle succeeds (the two pre-existing `@fusion-plugin-examples/claude-runtime` / `playwright-core` module-resolution errors reproduce on unmodified `main`). - Repo gate scripts pass: `check-changeset-format`, `check-routes-modular`, `check-no-node-only-core-imports-in-dashboard`, `check-no-cwd-relative-dashboard-test-reads`, `check-mock-completeness`. - The three new assertions were mutation-tested rather than assumed load-bearing: breaking the registry's `group` derivation, dropping an enrolled sidebar id, and re-pointing `task-detail` at the `taskDetail.title` namespace each make their test fail. - Local CodeRabbit review over two passes: 3 minor findings, all addressed (parity projection missing `group`; route tests asserting partial instead of exact payloads; the `labelKey` guard not covering the settings registry). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added authenticated, read-only APIs for discovering dashboard views and selectable Settings sections. * Added dashboard view metadata, including labels, aliases, internal status, and translation keys. * Added Settings metadata with grouping, scope, advanced status, and search-related information. * Updated navigation and Settings UI labels to use shared metadata. * **Documentation** * Documented the new metadata endpoints and integration guidance. * **Bug Fixes** * Added safeguards and automated checks to keep UI navigation and API metadata synchronized. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude <noreply@anthropic.com>
Fusion Documentation
Fusion is an AI-orchestrated task board that turns ideas into reviewed, merged code using a structured workflow: planning → todo → in-progress → in-review → done.
Quick Start
Start the local dashboard with pnpm dev dashboard, then create your first task from the board or CLI.
For a full walkthrough (installation, onboarding, first task, and daily workflow basics):
Documentation Index
Getting Started
| Guide | Description |
|---|---|
| Getting Started | Installation, first-run, first task, and daily workflow basics |
| Dashboard Guide | Board/list views, left/right sidebar navigation, Artifacts, Import Tasks, chat, workflow selection/editor, terminal, git manager, files, planning, and UI tools |
| CLI Reference | Complete fn command reference with subcommands, flags, and examples |
| Remote Access | Operator runbook for Tailscale/Cloudflare setup, tokenized login links, security caveats, and troubleshooting |
| Native Shell Connection Guide | Canonical mobile/desktop shell onboarding, profile management, QR/manual setup, and remote handoff behavior |
Task & Project Management
| Guide | Description |
|---|---|
| Task Management | Task creation modes, lifecycle, prompt specs, comments, archiving, and GitHub integration |
| Todo View | Canonical guide for the experimental Todo View, including enablement, usage, API routes, and storage |
| Missions | Mission hierarchy, planning flow, activation, progress tracking, and autopilot behavior |
| Goals Refinement Gate | Evidence gate for activating the conditional post-v1 goals refinement slice only after real usage pain is documented |
| Goals Refinement Evidence Pack | Structured observation template and two-observation threshold for conditional Slice 4 activation requests |
| Research | Research runs, provider setup, dashboard/CLI usage, findings, exports, and task integration |
| Research View UX Spec | Canonical layout and capability-state messaging spec for the Research dashboard view (FN-4138, informs FN-4134/FN-4135) |
| Workflow Steps | Workflow overview, built-in workflow catalog, per-task selection, runtime semantics, reusable quality gates, templates, phases, and execution results |
| Workflow Editor | Visual workflow editor guide for opening, viewing, authoring, validating, importing/exporting, custom fields/columns/settings, and tuning workflows |
| Custom Workflow Reliability Acceptance Map | End-to-end reliability acceptance criteria for custom workflow authoring, selection, execution, recovery, restart durability, and deferred journeys |
| Custom Non-Coding Workflows MVP Spec | MVP framing for user-authored non-coding workflows, lifecycle mapping, metrics, and risk checklist |
| Task Evaluations | Eval scoring contract, evidence persistence, score categories, and evaluation pipeline |
| Multi-Project | Central registry architecture, project management, isolation modes, and migration paths |
Configuration & Agents
| Settings Reference | Global/project settings, workflow setting values, model/fallback lane hierarchy, defaults, and API endpoints |
| MCP | Model Context Protocol server configuration, secret references, validation, CLI, dashboard, and import/export workflows |
| Agents | Agent management, presets, prompts, heartbeat behavior, spawning, and mailbox workflows |
| Planner Oversight (see Settings Reference, Dashboard Guide, Architecture) | Workflow-native oversight levels (off/observe/steer/autonomous), per-task overrides, notification verbosity, the human-confirmation gate on merge/PR and destructive actions, and the Task Detail overseer controls/Intervention Timeline |
Architecture & Development
| Guide | Description |
|---|---|
| Architecture | System architecture, package layout, storage model, and engine execution flow |
Secrets Store (SecretsStore) |
Core encrypted secret subsystem overview: scopes, AES-256-GCM at-rest model, policy semantics, and public store API surface |
| Dashboard Real-Time | Canonical event-stream architecture contract (shared /api/events bus + dedicated stream boundaries), with project/node scoping, reconnect/cleanup behavior, and realtime pitfalls |
| Storage | PostgreSQL runtime storage, archive, migration compatibility, and file-backed payloads |
| DAG Architecture Deliverables | Milestone A DAG architecture documents plus Milestone B prototype scaffold docs (schema migration plan, DagCoordinator design, implementation checklist) |
| Dev Server Module Audit | Analysis of parallel dashboard dev-server module families, production wiring, and consolidation guidance |
| Shared Cluster Protocol | Shared PostgreSQL multi-node contract: claims/leases, membership, auth, and retired multi-leader mesh replication |
| Signals Connectors | HMAC-signed external signal connectors for setup, payload mapping, and security notes across Sentry, Datadog, PagerDuty, and generic webhooks |
| Multi-Project Sequencing and Dependency Analysis | Sequencing guidance for FN-3448/FN-3449/FN-3503/FN-3182, including identity boundaries and recommended board dependency edges |
| Contributing | Local development setup, testing, release flow, and contributor conventions |
| Docker | Container builds, deployment, and persistence configuration |
| Code Signing | macOS and Windows code signing configuration for release binaries |
| Diagnostics | Engine diagnostic logging subsystems, structured log keys, and key diagnostic points catalog |
| Sandbox Backends | Pluggable sandbox backends for executor command isolation (bubblewrap, spawn-based) |
| Secrets | Encrypted secrets storage, per-secret access policies, scopes, and agent tool wiring |
| Testing | Full testing lanes, worker fanout guidance, test taxonomy, and file organization |
| Real iOS Safari Acceptance Surface | Provisioning runbook and harness usage for terminal verification gates on physical or cloud real-iOS Safari |
| Solutions Catalog | Documented solutions to past problems (bugs, architecture patterns, best practices) organized by category |
| Localization Contributing Guide | Conventions for contributing translations, locale file structure, and i18n tooling |
| Mobile | Capacitor/PWA mobile development setup and workflow |
Plugins
| Guide | Description |
|---|---|
| Plugin Management | End-user guide for discovering, installing, enabling, configuring, updating, uninstalling, and troubleshooting Fusion plugins |
| Plugin Authoring | Developer guide for building Fusion plugins (manifest, SDK hooks, routes, UI/runtime contributions) |
| Even Realities Glasses Plugin | Task-focused Even Realities glasses bridge with quick capture, polling notifications, and agent actions |
| Reports Plugin | Reports plugin rendering, export, standalone HTML generation, and section configuration |
| Even Realities Plugin API | Even Realities plugin API endpoint reference and test coverage matrix |
| Memory Plugin Contract | Pluggable memory backend architecture, interface contract, and migration strategy |
| Compound Engineering Plugin | CE workflow dashboard surface: artifact hub, interactive sessions, work→board bridge, and bidirectional sync |
| External Plugin Authoring | Step-by-step guide for authoring plugins using an installed fn CLI (no monorepo access needed) |
| External Plugin Proof-Point Runbook | Repeatable release-validation runbook for proving an external plugin runs against a published Fusion CLI build |
Audit Reports
| Report | Description |
|---|---|
| Test Feedback-Loop Baseline | Weekly FN-6612 signal-per-second baseline for gate/test wall-time, slowest files, and quarantine trends |
| Test Value Audit | Heuristic test-value audit generated by scripts/test-value-audit.mjs to support human deletion and review decisions |
| Test Velocity Baseline | Weekly feedback-loop velocity baseline for merge-gate, boot-smoke, changed-test, and quarantine metrics |
| UX Audit Report | Comprehensive UX audit with prioritized recommendations for dashboard improvements |
| Codebase Improvement Audit | Evidence-based technical debt and reliability gap audit with prioritized recommendations |
| Gap Analysis | System completeness analysis comparing Fusion to Paperclip feature set |
| Permanent Agent Heartbeat Playbooks | Worked manager/IC/message/blocked/no-task heartbeat scenarios and anti-patterns |
| Agent Sandbox Research | Research on agent isolation, capability enforcement, and sandboxing approaches |
| Even Realities Integration Research (FN-3737) | Research summary and recommended integration topology for Even Realities glasses + Fusion |
| pi-autoresearch Analysis for Fusion Port | Upstream architecture/license analysis and Fusion integration mapping for autoresearch capabilities |
| pi-autoresearch Audit vs Fusion Research | Audit comparing Fusion's research subsystem against upstream pi-autoresearch capabilities and parity gaps (FN-4136) |
| Research Hardening Preflight Baseline | Verified research subsystem baseline, lifecycle contracts, and hardening pressure points |
| Test Audit Report | Test coverage and effectiveness audit with recommendations |
| Skipped Test Inventory | Current intentional test-skip inventory and reconciliation status for older skip follow-ups |
| Dev Server Module Boundary Audit | Boundary/ownership audit for parallel dev-server-* vs devserver-* dashboard modules and FN-2212 prioritization guidance |
| spawn_agent Approval Evaluation (FN-3973) | Decision to keep fn_spawn_agent under generic action-gate governance rather than durable agent provisioning policy |
| Task Lineage Reconciliation Notes | Historical task-ID reuse patterns, confidence semantics for commit attribution, and reconciliation methodology (FN-3953, FN-3998) |
| Dashboard Load Performance (historical) | Pre-cutover SQLite index analysis retained for performance archaeology |
| CLI Printing Press Plugin Design | Architecture design for the CLI printing press bundled plugin (FN-3762) |
| CLI Printing Press Research | Upstream cli-printing-press analysis and Fusion integration mapping (FN-3761) |
| Research vs Experiment Session Naming Decision | Naming decision record: hybrid approach retaining research_* for cited-search/synthesis and adding experiment_session_* for upstream parity (FN-4223) |
| Experiment Executor Design | Experiment executor architecture: lifecycle, run state machine, and worktree isolation model |
| Experiment Finalize Flow | Experiment finalize contract: branch grouping, dry-run planning, and session completion semantics |
| Experiment Session Model | Experiment session data model: state transitions, iteration tracking, and persisted run state |
| Experiment Session MVP Spec | MVP specification for the experiment session feature: scope, invariants, and delivery milestones |
| Sandbox Options Research (FN-4635) | Pluggable sandbox options research: threat model, backend evaluation, and spawn-based isolation design |
| Triage Duplicate Detection Postmortem | Postmortem on duplicate task detection gaps and scheduler dedup hardening |
| Multi-Node Runtime Readiness (FN-4814) | Runtime readiness assessment for multi-node distributed coordination |
| Distributed Multi-Node Coordination Gap (FN-4819) | Gap analysis for distributed multi-node agent coordination and cross-node task assignment |
| Cross-Node Assignment Wake Contract (FN-4824) | Contract specification for cross-node task assignment wake signaling |
| Multi-Node Coordination Validation Findings (FN-4820) | Validation findings from multi-node coordination testing and edge-case analysis |
| Secrets Sync Auth Parity Review (FN-4886) | Review of node secrets sync API authentication parity and security boundaries |
| Test Speed Audit (FN-5048) | Measured baseline test performance, offender list, and optimization priorities |
| Soft-Delete Verification Matrix | Authoritative checklist for the FN-5105 → FN-5143 soft-delete stream: scenario × layer coverage |
| Self-Healing Backward Move Audit | Audit of self-healing backward-move safety checks and edge-case validation |
| Workflow Policy Ownership Map | U1 characterization map classifying production merge, retry, scheduling, and recovery policy branches before workflow-policy migration cutover |
| Test-Speed Baseline (2026-06-03) | Measured per-file test timing baseline and optimization targets (successor to FN-5048 audit) |
| ACP Runtime Contract | Agent Client Protocol plugin launch/readiness contract and failure taxonomy |
| ACP MCP Passthrough & Permission Forwarding Upstream Sponsorship (FN-6475) | Ready-to-file upstream sponsorship for claude-code-cli-acp ACP session/new.mcpServers passthrough and permission-gate traversal; Route A remains NOT GO until proven |
| Mission Completion Gate Contract | Decision record for mission completion gate invariants and acceptance flow |
| Lost-Work Tasks Incident (2026-05-23) | Incident catalog of 9 lost-work tasks from no-op finalize and reuse-handoff bugs | | GitLab Parity Inventory (FN-7421) | Implementation map for first-class GitLab support: import, linked issue tracking, comments, auth/settings UI, CLI/extension, and Command Center surfaces to mirror or explicitly exclude | | PostgreSQL Runtime Cutover Review (2026-07-14) | Current end-to-end authority inventory, intentional legacy SQLite readers, deployment contract, and verification record | | SQLite → PostgreSQL Migration Review (2026-06-26, historical) | Historical multi-agent review of the incomplete migration branch and its original findings | | Dashboard Theme & UI Plugin System Proposal (2026-07-01) | Feasibility-spike proposal for a controlled dashboard theme/UI shell extension point sharing one backend source of truth | | Full-loop Agent Tool-Surface Audit and Delivery Plan | Source-grounded audit of engine-agent and dashboard chat tool factories, gap analysis for mission hierarchy integration, and delivery plan (FN-8280) | | Dashboard Modal Inventory | Canonical classification of all 45 dashboard modal surfaces (classes A–D) with file:line evidence, FloatingWindow migration targets, and the shared migration contract (FN-8605 → FN-8617) |
External Resources
- GitHub repository: https://github.com/Runfusion/Fusion
- npm package: https://www.npmjs.com/package/@runfusion/fusion
- pi agent framework: https://github.com/earendil-works/pi
Suggested Reading Paths
- New user: Getting Started → Dashboard Guide → Task Management
- Workflow author: Dashboard Guide → Workflow Editor → Workflow Steps → Settings Reference
- Power user / automation owner: Settings Reference → Workflow Steps → Agents → Planner Oversight (Settings Reference § Workflow Settings)
- Maintainer / contributor: Architecture → Multi-Project → Contributing