Mission Control — workspaces, people and publishing (part 3)

What it is

This is part 3 of the Mission Control page. It covers who can see and change a board, and the structures that sit above one.

Where to find it

Inside Mission Control: workspace and member controls live in the workspace's own settings, the sharing actions on a board's menu, and goals and portfolios in the left navigation.

How it behaves

Workspaces functionality (post-Phase-4 fast-follow)

A pixel-near rebuild of monday's Workspaces across three surfaces. (1) Left-nav header — the plain <select> became a monday workspace block: a colored icon tile (initial + home glyph; tint from a new workspaces.color or a deterministic id-hash fallback), a name + switcher popover, and a ⋯ actions menu (WorkspaceMenu) — Manage workspace, Edit workspace (icon-color + name + description modal), Sort workspace (a per-workspace localStorage display order), Add new workspace, Browse all workspaces, View archive/trash, and a confirm-gated Delete (disabled for the Main/last workspace). (2) Manage-workspace page (/workspace/:id, rebuilt WorkspacePage) — a banner (large icon, name, inline-editable description, Feedback (inert) / Members → /users / ⋯) over Recents · Content · Permissions tabs: Content is a boards+dashboards asset table (creator avatar, creation date, Last modified, folder, search, selection-delete, a real Cleanup mode that flags assets unmodified 30+ days; the AI-summary column is intentionally dropped); Recents reuses the Home recent-visit locators + favorite stars; Permissions sets the workspace access level (Open/Closed via workspaces.kind), manages workspace owners (people only — add/remove, last owner is guarded), and — for a closed workspace — the specific members & teams with access (an open workspace just reads "everyone in your account"), all via a searchable PrincipalPicker over the account directory + teams. (3) User-management page (/users, UserManagementPage) — the account directory as a full table with an editable role dropdown (PATCH /members/:id), a Products multi-select (real, seeded with work_management), status, Teams chips, joined/invited dates, an Invite dialog (reuses the member invite), and a Manage teams modal over a real Teams subsystem.

Backend (amc-back): migration 0012 adds workspaces.color + description (flow through /nav/tree); 0013 adds boards.updatedAt + dashboards.updatedAt ("Last modified" — auto-bumped via Drizzle $onUpdateFn on row edits and via touchBoard() at the publish() realtime chokepoint on content edits); 0014 adds the teams + team_members tables + a teamsRoutes module (account-scoped CRUD + membership); 0015 adds users.products (jsonb) + extends PATCH /members/:id (role/products) and the member payload (products, joinedAt, invitedAt). PATCH /workspaces/:id gained color/description/kind. Migration 0016 adds the workspace_principals table (polymorphic user|team rows, owner|member role) backing the Permissions tab — seeded so every workspace keeps a real owner (the creator on POST /workspaces + register; the account's earliest user in the migration backfill) — with GET/POST/DELETE /workspaces/:id/principals (owners-are-users, never-zero-owners 409, and account-isolation guards). Boards gained GET /boards/archived + /boards/trash listings and a POST /boards/:id/restore (clears archived + soft-delete; ownership via the board→workspace→account join). Pure Content-tab + Permissions helpers (asset shaping + staleness; owner-removal + picker-candidate filtering) are unit-tested (tests/unit/plugins/mission-control/manage-workspace.test.ts, workspace-permissions.test.ts); every route has bun coverage (the backend package’s workspace-permissions bun test, not tracked in this repo). Design specs docs/superpowers/specs/mission-control-workspaces-design.md, mission-control-workspace-permissions-design.md.

Account & passwords (parity fast-follow)

The login screen gained a "Forgot password?" link: enter your email and you get a neutral confirmation ("if that email exists, we've sent a reset link") that never reveals whether the address is registered. Because the plugin runs on an in-memory router — email links can't deep-link into it, the same constraint that puts the invitation-accept pages on the backend — the reset itself happens on a backend-served HTML page the emailed link points to. The reset token is single-use, expires in one hour, and a fresh request supersedes any earlier link; completing a reset signs out all existing sessions.

Signed in, the top-right account menu (the avatar) adds "Change password" — a modal that requires your current password and a new one of at least 8 characters. Changing it signs out all your OTHER devices while the current one stays signed in.

Logout is now server-side — signing out revokes the session on the backend too (not just a local token wipe), so it takes effect even after a long idle. (There is still no email verification on signup — accounts are usable immediately.)

Board sharing & private-board enforcement (parity fast-follow)

The board header gained a Share button → a modal with a copyable join link and the board's member list. The join link points at a backend-served join page (same pattern as reset/invite — the in-memory router can't be deep-linked); another user on the same account signs in there and is added to the board as an editor. Private boards are now enforced end-to-end: only a board's members — owner / editor / viewer principals, held directly or via a team — can see a board in listings or open it. Only the board owner can mint, rotate, or revoke the share link or add/remove members.

Local board sharing (push-then-share): Boards created via the local SQLite fallback (when the backend is unreachable) carry sync_status = 'local_pending'. When a user clicks Share on such a board, the share modal automatically pushes it to the backend first via the PM_ENSURE_BOARD_SYNCED IPC channel before showing the share UI. If the backend assigns a different board ID, a swapBoardId atomically updates all FK tables and the modal uses the resolved ID for all subsequent share operations. The same pre-sync guard runs on the CLI share routes (GET/POST/DELETE /pm/boards/:id/share). If the push fails, a clear error is shown and sharing is disabled until connectivity is restored.

Workspace invite link (parity fast-follow)

The workspace ⋯ menu gained "Copy invite link." It reuses the workspace's existing invite link and only mints a new one when none exists yet, so the link stays stable across copies. Only workspace owners can manage the link.

Role-Based Entry Points (G14, in-development)

Extends the setup wizard (G12) with three onboarding lanes and a 12-combination default surface matrix that auto-picks a preset from two questions. Gated behind the pm-role-entry-points unreleased feature. When the gate is off, the existing wizard auto-open behavior is preserved.

Three lanes (plain language, no jargon):

• Quick start (Lane 1) — two questions only (AI comfort + org role), then getDefaultSurface(comfort, role) auto-applies the preset from the matrix. Under 60 seconds.
• Guided setup (Lane 2) — the existing 5-step PmSetupWizard. Unchanged.
• Build with AI (Lane 3) — a 10-15 minute AI conversation that infers comfort, role, and preset via structured output ({"pmSetup":{...}} in a fenced JSON block).

12-combination matrix (default-surface-matrix.ts): maps every (comfort x role) pair — 3 comfort levels (low, medium, high) × 4 org roles (tasks, team, department, engineering) — to a PmDefaultSurface with preset, defaultView, aiBehavior (7 per-cell levels: off / minimal / basic / balanced / full / proactive / max), and autoFeatures. Null inputs default to medium/tasks.

G11 signal wiring: buildG11Context() in pm-session-context-provider.ts injects comfort, role, and aiBehavior into ALL PM-project sessions (before the pmItemId guard), so every PM session knows the user's profile.

Admin-assigned onboarding (same-machine): a manager can pre-fill Lane 2 answers for another user via CLI (POST /pm/onboarding/assign). The target user's PM opens with those answers applied. Silently ignored if the user already completed setup. Stored in pm_admin_onboarding SQLite table.

Peer inference: not implemented today — there is no inferPeerFeatures(db) in the tree. The intended shape was to query the local SQLite mirror (columns, views, automations, boards) and return suggested features based on team usage patterns, additive only, with an empty mirror returning empty suggestions.

Retake flow: "Redo Setup" in MissionControlSettings reopens the lane selector (not the wizard directly) when the role-entry-points gate is on.

• Contract: pm-setup-wizard-contract.md (the G14 lane rules: lane-selector-exclusivity, three-onboarding-lanes, twelve-combination-default-surface, deep-interview-structured-output, admin-assigned-onboarding-guarded, retake-respects-lane-gate)
• Key files: src/shared/pm-composability/default-surface-matrix.ts (matrix), src/shared/pm-composability/deep-interview-prompt.ts (AI prompt + parser), src/renderer/src/features/mission-control/setup/OnboardingLaneSelector.tsx (lane picker), src/renderer/src/features/mission-control/setup/QuickPickWizard.tsx (Lane 1), src/main/services/pm/onboarding/pm-deep-interview.ts (Lane 3), src/main/services/pm/onboarding/pm-admin-onboarding.ts (admin assignment), src/shared/pm-composability/peer-inference-types.ts (peer inference types — no longer present in the current tree; inferPeerFeatures(db) above is likewise not implemented today)

Comment Visibility (in-development — pm-comment-visibility flag)

Item comments carry a visibility field (internal or external) controlling who can see them. Internal comments are visible only to board owners and members; external comments are visible to all roles including viewers and guests. Defaults to internal (team-only).

Role-based filtering: getCommentsForItemFiltered(db, itemId, role) checks canViewInternalComments(role) — owners and members see all comments; viewers, guests, and unauthenticated users see only external comments. The visibility filter is applied at the query level.

UI: the renderer component (PmItemComments.tsx) that housed the visibility toggle and comment compose area has been removed as dead code; the backend IPC channels and role-based filtering remain live and are exercised by the CLI routes and E2E specs. Board owners/members can change visibility on existing comments via pm:item-comments:set-visibility.

Sync safety: upsertComment uses ON CONFLICT … DO UPDATE that preserves the existing visibility value when syncing from an external source (the external source does not carry visibility), preventing sync from overwriting local visibility choices.

IPC: 3 channels (pm:item-comments:list, pm:item-comments:add, pm:item-comments:set-visibility), Zod-validated, feature-gated on missionControlEnabled + pmCommentVisibilityEnabled. All three BLOCKED in web-access-ws-channels.ts (desktop-only until the feature ships). CLI-parity: add and set-visibility are feature-scoped-surface exemptions; list is auto-excluded (query verb).

Key files: src/main/services/pm/pm-comment-queries.ts (queries + role check), src/main/ipc/pm-comment-handlers.ts (IPC handlers), src/shared/ipc-schemas/pm-comments.ts (Zod schemas), src/shared/ipc-response-map/pm-comments.ts (response types), tests/unit/services/pm/pm-comment-queries.test.ts (31 tests).

Summarizing a comment thread (shipped, metered — pm-comment-summary)

Summarizing a comment thread is a paid AI call — a small Haiku model over the thread's text, on demand, from the comment pane or from the CLI (POST /pm/items/:id/comments/summarize). It is metered, and the meter is a hard $0.50/day ceiling charged against the pm-comment-summary cost label over a local-midnight day; there is no setting for it, so it does not appear in the settings reference or in Cost Control. If you summarize a lot in one day, the summaries simply stop being generated until the next day — nothing else in the comments feature is affected. Distinct from the Comment Visibility gate in the section just above: that one is in-development and this one ships.

Item History + Undo/Rollback (G8, unreleased — pm-item-history flag)

Every PM field change is tracked in pm_item_history (item_id, column_id, old_value, new_value, actor_type, actor_id, session_id, session_turn, bulk_action_id, cross_board_correlation_id, caused_by_id, timestamp). Actor types: human, agent, automation, import, api. Recording is fail-safe (try/catch, never breaks the parent mutation). Sync-path (import) records only actual changes via diff check.

Undo (executeUndo in src/main/services/pm/pm-undo-service.ts): reverts the last change for a field (column value, name, create, delete). Synced boards route mutations through the Mission Control REST API then update the local mirror via authorized writers; local boards use authorized writers directly. Deletion undo restores from a JSON snapshot. Every undo creates a new forward history entry with caused_by_id linking to the undone entry. Both executeUndo and executeRollback are async (return Promises).

Rollback (planRollback / executeRollback in src/main/services/pm/pm-rollback-service.ts): planRollback(db, itemId, targetHistoryId) builds a plan showing which fields to revert plus conflict flags (a field changed more than once after the target point has hasConflict: true). executeRollback applies the plan with stale-plan detection (rejects if the item was modified after plan.generatedAt). Conflict resolution: revert_to_target (apply the revert) or keep_current (skip conflicting fields only).

Forward-only invariant: undo and rollback create new history entries, never erase old ones. Retention: 180-day cleanup, HISTORY_RETENTION_DAYS in src/main/services/pm/history/pm-history-service.ts.

Frontend: PmHistoryTab in the item card (gated by isPmHistoryEnabled()), showing a timeline of changes with color-coded actor badges, old-to-new value chips, relative timestamps, and per-entry Undo buttons. Bridge API via window.__AMC_PM_HISTORY__ installed by MissionControlPanel.tsx.

IPC: 6 channels (pm:item-history:list, pm:board-history:list, pm:session-pm-changes, pm:item-history:undo, pm:item-history:rollback-plan, pm:item-history:rollback-execute), Zod-validated. CLI: 6 matching routes. Mutation channels blocked in BLOCKED_CHANNELS; read channels baselined.

Key files: src/main/services/pm/history/pm-history-queries.ts (SQL), src/main/services/pm/history/pm-history-service.ts (fail-safe wrappers), src/main/services/pm/pm-undo-service.ts, src/main/services/pm/pm-rollback-service.ts, src/main/ipc/pm-history-handlers.ts, src/main/services/cli/pm/pm-cli-history-ctx.ts (CLI auth → PmHistoryContext mapper), src/plugins/mission-control/web/features/board/PmHistoryTab.tsx, src/shared/ipc-schemas/pm-history.ts, tests/integration/pm-history.test.ts (19 tests).

Cross-entity linking

PM board items can be linked to 14 entity types: KMS vault notes, mind maps, flowcharts, whiteboards, sessions, writer documents, URLs, email threads, meetings, GitHub PRs, GitHub commits, GitHub branches, and GitHub issues. Links are bidirectional:

• Item card Links tab (LinksTab.tsx in plugins/mission-control/web/features/board/) groups linked entities by type with icons, showing a hover-reveal unlink action. GitHub commit links display the short SHA and a commit message excerpt. The tab communicates via bridge methods on window.__AMC_MISSION_CONTROL_SESSION__ (listItemLinks, createItemLink, deleteItemLink, navigateToEntity, createGitHubBranch), installed by MissionControlPanel.tsx.
• "Link to Board Item" action in each visual tool's toolbar or context menu opens PmItemPicker (a DialogShell with debounced search over all boards+items).
• Backlink chips (PmBacklinkChips.tsx) appear in KMS, mind map, flowchart, and whiteboard headers, auto-refreshing on PM_ITEM_LINKS_CHANGED push events.
• GitHub branch creation — a "Create GitHub Branch" button on the Links tab creates a branch named after the item (slugified via slugifyForBranch, e.g. feat/my-item-name) on the first GitHub-connected project, then auto-links it back. Feature-gated behind github-mc-branch-creation unreleased feature. IPC: GITHUB_MC_CREATE_BRANCH in src/shared/ipc-channels/github-mc.ts, handler in src/main/ipc/github-mc-handlers.ts, service in src/main/services/github-mc/github-mc-branch-service.ts.
• Clicking a GitHub commit link opens the commit on GitHub in the browser (URL constructed from the entityId format owner/repo:sha).

GitHub commit scanner (in-development, github-commit-linking unreleased feature): a 5-minute polling service (github-commit-scanner.ts) that automatically detects MC-N references in recent git commit messages and creates github_commit links on the matching board items. The scanner discovers repos from Omniscio project folder paths, fetches the last 100 commits per repo via the gh CLI, parses item references with a configurable prefix (default MC), and resolves them against pm_items.item_number. Commit metadata (SHA, message first line, author, date, URL) is stored in a companion table (github_commit_links) with a FK to pm_item_links. Deduplication is via unique constraints on both the link and companion tables.

Data model: pm_item_links table (entity_type + entity_id + item_id, partial unique index) with an optional companion table per entity type (github_pr_links for PR metadata, github_commit_links for rich commit metadata). Five link IPC channels (PM_ITEM_LINKS_LIST/CREATE/DELETE/FOR_ENTITY/SEARCH_ITEMS), all desktop-only (WS-blocked). The LIST handler enriches github_pr links with prMetadata and github_commit links with commitMetadata from their companion tables. GitHub branch creation uses a separate channel (GITHUB_MC_CREATE_BRANCH).

GitHub PR review requests (unreleased, github-mc-review-notifications): when a github_pr link exists on an item, a background poller (createInboxPoller, 10-min interval) fetches review state via gh api and caches it in pm_github_review_requests. The LinksTab shows a ReviewRequestSection with per-reviewer state badges (approved/changes requested/pending/dismissed/commented). State changes raise inbox alerts via raiseAgentAlert. Kill switch: AMC_DISABLE_GITHUB_REVIEW_POLL=1. Key files: src/main/services/pm/github-review-request-service.ts (poller), src/main/services/pm/github-review-utils.ts (pure logic), src/main/services/pm/pm-queries-github-reviews.ts (DB queries), src/plugins/mission-control/web/features/board/ReviewRequestSection.tsx (UI).

• Contract: pm-cross-entity-link-contract.md
• Key files: src/main/ipc/pm-item-links-handlers.ts (IPC), src/main/ipc/github-mc-handlers.ts (GitHub branch IPC), src/main/services/github-mc/github-mc-branch-service.ts (branch creation service), src/plugins/mission-control/web/features/board/LinksTab.tsx (item card tab), src/renderer/src/features/pm/PmItemPicker.tsx (search dialog), src/renderer/src/features/pm/PmBacklinkChips.tsx (backlink chips), src/renderer/src/features/pm/useLinkToItem.ts (link hook), src/main/services/pm/github-commit-scanner.ts (polling scanner), src/shared/mc-item-reference-parser.ts (reference parser), src/main/services/pm/pm-queries-github-commit-links.ts (companion table queries), src/renderer/src/features/mission-control/bridges/content-bridge.ts (commit navigation)

Goals

Hierarchical goal tracking scoped to a workspace. A goal has a title, description, status (on_track/at_risk/off_track/achieved), optional target date, progress percentage (0-100), progress mode (auto/manual), and optional parent goal for nesting. Goals can link to boards via a junction table, and every mutation records an activity log entry.

UI: /goals list page (status-filter pills: All/On Track/At Risk/Off Track/Achieved; empty state), /goal/:goalId detail page (status pill, progress bar, linked boards section with a manage-boards modal, child goals, paginated activity feed), a shared CreateGoalModal (create + edit). The home page surfaces active (non-achieved) goals in a GoalsSummaryWidget (collapsible, shows up to 5 with inline progress bars; "See all" link when more exist). Left-nav adds a "Goals" section between Dashboards and Trash.

Data: pm_goals, pm_goal_boards, pm_goal_activity tables (local-authority SQLite, session bridge pattern). Status pill uses status-* design tokens. Cycle detection on parent_goal_id updates (recursive CTE walks ancestors).

IPC: 15 channels (pm:goal:list through pm:goal-children:list, plus goal-comments channels for list/add/delete, pm:goal-comments:changed, and pm:goals:changed), Zod-validated. Response map fragments in src/shared/ipc-response-map/pm-goals.ts.

Key files: src/main/db/queries-pm-goals.ts, src/main/ipc/pm-goals-handlers.ts, src/plugins/mission-control/web/features/goals/ (6 components), src/plugins/mission-control/web/lib/session-bridge-goals.ts, src/shared/ipc-schemas/pm-goals.ts.

Portfolios

A named collection of boards scoped to a workspace. A portfolio has a title, description, and links to boards via a junction table. Simpler than goals (no hierarchy, status, or activity log).

UI: /portfolios list page (with SVG empty state), /portfolio/:portfolioId detail page (linked board rows with unlink action, inline board-linking picker). Left-nav adds a "Portfolios" section after Goals.

Data: pm_portfolios, pm_portfolio_boards tables (local-authority SQLite, session bridge pattern). Board item-level data (status counts, health) comes from authedFetch (not session bridge) and is deferred to a follow-up.

IPC: 9 channels (pm:portfolio:list through pm:portfolios:changed), Zod-validated. Response map fragments in src/shared/ipc-response-map/pm-portfolios.ts.

Key files: src/main/db/queries-pm-portfolios.ts, src/main/ipc/pm-portfolios-handlers.ts, src/plugins/mission-control/web/features/portfolios/ (5 components), src/plugins/mission-control/web/lib/session-bridge-portfolios.ts, src/shared/ipc-schemas/pm-portfolios.ts.

Publish to Web (Phase 9b)

Boards and dashboards can be published as read-only web snapshots through the Omniscio Shares pipeline. The MC plugin renders a self-contained HTML document server-side (inline CSS, no external resources, light/dark theme via data-theme attribute) and pushes it through publishArtifact() to GCS, producing a public URL at shares.omniscio.com/s/<token>.

What can be published: any of the board view types (table, kanban, calendar, chart, timeline, roadmap, form, workload, map) plus dashboards (widget grid with numbers/chart/battery/table widgets; sprint-history widgets render placeholders). Form views show an explanatory empty state. Re-publishing the same unchanged content returns the same URL (content-hash dedup). Revoking follows the RT-F016 durable-intent pattern.

UI: BoardPublishButton in the board toolbar, DashboardPublishButton in the dashboard header. Both open a modal with publish/update-snapshot/revoke-link controls. Password and expiry are set post-publish via the Shares panel (matches the Decks pattern).

IPC: 3 channels (MC_BOARD_PUBLISH, MC_DASHBOARD_PUBLISH, MC_BOARD_UNPUBLISH), Zod-validated. All three BLOCKED in web-access-ws-channels.ts (desktop-only).

ShareArtifactKind: 'mc-board' added to the union, with sourceType: 'mc-board-publish', included in FULL_BLEED_KINDS.

Key files: src/main/services/mission-control/mc-board-render.ts (entry point + document shell), mc-board-render-views.ts (re-export barrel) + render/mc-view-*.ts (7 per-view renderers) + render/mc-render-helpers.ts (shared helpers + renderCellValue), mc-board-render-styles.ts (CSS), mc-dashboard-render.ts (dashboard orchestrator) + render/mc-dashboard-data.ts (bucketing) + render/mc-dashboard-styles.ts (CSS) + render/mc-chart-renderers.ts (chart SVG), src/main/ipc/mission-control-publish-handlers.ts (IPC handlers), src/plugins/mission-control/web/features/board/BoardPublishButton.tsx, src/plugins/mission-control/web/features/dashboard/DashboardPublishButton.tsx, src/plugins/mission-control/web/lib/publish-api.ts (IPC bridge).

Tests: tests/unit/mc-board-render.test.ts (48 tests), tests/unit/mc-dashboard-render.test.ts (18 tests), tests/unit/mc-board-share-type.test.ts (7 tests).

Setup Wizard (G12, in-development)

A 5-step onboarding wizard that recommends a PM preset (Tasks / Projects / Operations / Engineering-Linear / Engineering-Jira) based on the user's answers. Gated behind the pm-setup-wizard unreleased feature (Settings → Lab toggle or AMC_SHOW_PM_SETUP_WIZARD=1).

How to use it: enable Mission Control, then enable the PM setup wizard feature flag. The wizard auto-opens when pmSetupComplete is false. Five steps: AI comfort level (low/medium/high), organizational role (tasks/team/department/engineering), feature checklist (10 items), optional free text, and the preset picker. Each step saves to AppSettings on Continue. Skipping applies sensible defaults (medium / tasks / Tasks preset).

Preset recommendation (DL65): role = engineering → Engineering-Linear by default (Engineering-Jira if sourceToolId is 'jira'); any checklist item 1-9 checked → Operations; item 10 (AI integration) is a confidence signal only, never triggers Operations; role = team|department + zero checked → Projects; otherwise → Tasks. The recommendation highlights one card but the user can override.

Presets (pure data records — PDR8):

Three core "lane" presets shown in the wizard picker:

• Tasks — personal (like Todoist): 4 columns, Table view, column picker
• Projects — team (like Trello): 7 columns, Table view, Forms + team infra
• Operations — department (like Monday.com): 10 columns, all 8 views, Dashboards + Automations + Formulas

Two engineering presets routed via the engineering org role:

• Engineering (Linear) — cycles, triage, velocity (22 features): 8 columns, 4 views, Dashboards + Chart widgets + Cross-board relations
• Engineering (Jira) — issues, sprints, epics (25 features): 9 columns, 5 views, adds Automations + Workspaces + Timeline over Linear

Eight platform presets assigned via the Persona C import flow (single-platform selection maps to the matching preset; multi-platform maps to Operations):

• First-Agent-Board / Trello / Jira / Asana / Linear / Notion / ClickUp / Airtable — each with platform-specific columns, views, and features tailored to that tool's paradigm. Defined in PM_PRESETS alongside the lane and engineering presets.

All 13 presets are entries in PM_PRESET_IDS / PM_PRESETS in src/shared/types/pm-setup.ts. Presets control surface area, not access (PDR8).

Settings integration: once setup is complete, a "PM Setup" section appears in Settings → Mission Control showing the active preset, feature counts, a "Change Preset" button (dialog with all preset cards), and a "Retake Interview" button that reopens the wizard.

How it works (internals): the wizard uses the shared <Wizard> + WizardStepLayout + createWizardStore pattern. Steps are lazy-loaded via retryDynamicImport. Preset data lives in src/shared/types/pm-setup.ts as a Record<PmPresetId, PmPresetRecord>. Seven pmSetup* fields in missionControlSettingsSchema persist the interview answers and completion state.

• Contract: pm-setup-wizard-contract.md
• Key files: src/shared/types/pm-setup.ts (preset data + recommendation), src/renderer/src/features/mission-control/setup/ (wizard components), src/renderer/src/features/settings/sections/mission-control/MissionControlSettings.tsx (settings section)

Related

• Mission Control — the overview page this continues.
• pm-goals.md and pm-portfolios.md — the goals and portfolio surfaces in more detail.
• pm-agent-trust.md — the trust levels that decide what an agent may change on a board.