Mission Control — Documents, Spreadsheets & Forms

What it is

Status: in development, on by default. The whole area sits behind one switch (pm-documents, setting pmDocumentsEnabled), and it uses the registry's third state — live for everyone, with a toggle that stays live so you can turn it off. Part of the Mission Control PM system, so it also requires missionControlEnabled.

Mission Control is Omniscio's built-in project-management system. A workspace there collects a team's work — today that means boards, dashboards, goals and portfolios. This area adds three more kinds of thing you can keep in the same place:

• A document — a title and a body of text, in one of three states: draft, published, or archived.
• A spreadsheet — a title, a description, and a saved configuration.
• A form — a title, a description, a configuration, a state (draft, active, or closed), and a count of responses received so far.

Each one belongs to exactly one workspace. Anyone who can already see that workspace can create, rename and delete them; nobody outside it can see them at all. Each type gets its own section in the left-hand navigation, its own list page, and its own detail page.

All of this is live today. It is on by default — nothing to reveal — and a single setting turns it off again.

Where to find it

Turning it off (and back on)

It is on by default, so there is nothing to reveal — the area is already live. Turn it off in Settings → Lab with the Documents, Spreadsheets & Forms toggle (pmDocumentsEnabled), or with the environment switch for the pm-documents feature. That one setting takes all three types away together — there is deliberately no way to keep documents without forms.

What you see when it is ON

• Left navigation gains three collapsible sections — Documents, Spreadsheets, Forms — listing the items in the current workspace.
• Six pages become reachable: /documents and /document/:documentId, /spreadsheets and /spreadsheet/:spreadsheetId, /forms and /form/:formId.
• Templates: the template picker's Documents, Spreadsheets and Forms categories stop reading "Coming Soon" and offer ten ready-made starters — four documents, three spreadsheets, three forms. Deploying one creates a real item of that type rather than a board.
• Recently visited starts listing documents, spreadsheets and forms alongside projects, dashboards, goals and portfolios, and its empty-state sentence names them too.

How it behaves

What happens when it is OFF

Off means invisible everywhere, not merely hidden in a menu:

• The three nav sections are not rendered, and the app does not fetch their data at all — a hidden feature must not cost you speed.
• The six paths above are not registered, so a typed address or a stale bookmark falls through to the catch-all and redirects home.
• Every command-line route for the area answers 404.
• Every internal data call is refused before it touches the database.
• The three template categories stay "Coming Soon" and none of their templates are listed, so nothing advertises an area you cannot open.
• The "recently visited" empty-state sentence keeps naming only the older kinds.

That completeness is the point: there is no combination of a bookmark, a typed address, a saved shortcut or a scripted call that reaches a half-built feature.

How it works

Storage. Three tables — pm_documents, pm_spreadsheets, pm_forms — each carrying a workspace_id, an is_deleted flag, and an index on the pair.

Nothing is ever really deleted. Deleting hides an item: it disappears from every list and every lookup, and its record stays on disk. Someone who deletes the wrong thing has lost a click, not a week. The is_deleted flag is stripped from every row handed back, so it never leaks into the interface.

You only ever reach your own workspace's content. Every read and every write is checked against the workspace the item belongs to. Knowing an item's identifier is not permission to see it, and that holds on reads exactly as firmly as on writes. Asking for an item that does not exist stays a plain "not found" rather than an authorization error, so the check cannot be used to probe for which identifiers are real.

How the interface gets its data. Mission Control runs as an isolated sub-app, so it asks its host for data across a bridge rather than talking to the database itself. The host answers all fifteen calls (list / get / create / update / delete, for each of the three types). Each answer is validated on the way back: a malformed row degrades to an empty list or a null rather than reaching the interface, and a failed delete tells the user instead of failing silently.

The switch is checked in exactly one place per layer — the main process, the command line, and the interface — and the bridge deliberately does not re-check it, so there is never a second flag that can disagree with the first.

Not finished yet

The switch is on by default, but this is still an in-development feature rather than a finished one. Still outstanding:

• No user-facing help page. This library entry exists; the public help site has nothing on the area yet.
• The detail pages now support inline editing. Documents have inline title and content editing. Spreadsheets have inline title and description editing plus an editable grid (click cells to edit, add/remove rows). Forms have inline title, description and status editing plus an editable field list with drag-to-reorder (add/remove fields, set type/label/required/options). There is no rich text editing and no form-response collection interface yet.

For agents

Command-line routes

Fifteen routes, five per type, all of which answer 404 while the feature is off:

• GET|POST /pm/documents, GET|PATCH|DELETE /pm/documents/:id
• the same five shapes under /pm/spreadsheets and /pm/forms

Key files

• The switch — src/shared/unreleased-features.ts (pm-documents), with its settings twin in src/shared/types/settings/mission-control-settings.ts (defaults to true).
• Where the switch is read — src/main/ipc/pm-feature-gate.ts (requirePmDocumentsEnabled, first statement of all fifteen handlers); src/main/services/cli/pm/pm-board-route-helpers.ts (pmDocumentsCliEnabled); and, in the interface, isPmDocumentsEnabled — supplied by the host in src/renderer/src/features/mission-control/bridges/feature-bridge.ts and read by the plugin through web/lib/session-bridge-features.ts, where it fails safe to hidden when the bridge is absent.
• Storage — migration src/main/db/migrations/20260905023000-add-pm-documents-spreadsheets-forms-tables.ts; queries in src/main/db/queries-pm-{documents,forms,spreadsheets}.ts.
• Data handlers — src/main/ipc/pm-{documents,forms,spreadsheets}-handlers.ts, authorized by requireWorkspaceAccess in src/main/ipc/pm-board-auth.ts.
• The host bridge — src/renderer/src/features/mission-control/bridges/entity-bridge.ts (the fifteen answers), spread onto the session bridge in MissionControlPanel.tsx.
• The interface — src/plugins/mission-control/web/features/{documents,spreadsheets,forms}/ (list + detail pages), the three nav sections rendered as NavListSection instances inside features/nav/LeftNav.tsx (there are no separate DocumentsSection.tsx / SpreadsheetsSection.tsx / FormsSection.tsx files), and features/shell/routes.tsx (the six gated routes).
• Templates — src/shared/pm-built-in-template-catalog.ts and src/shared/types/pm-template-categories.ts.
• The contract — .claude/memory/contracts/pm-documents-spreadsheets-forms-contract.md is the authority on what must stay true of this area.

Related

The workspace this content lives in, and the boards, dashboards, goals and portfolios it sits alongside, are described in mission-control.md. The nearest siblings inside that workspace are pm-goals.md and pm-portfolios.md for the other things a workspace collects, and boards.md for the boards themselves. A reader who arrived here from the template picker will want pm-feature-profiles.md, which decides which Mission Control features a board shows at all, and pm-onboarding-features.md for the import flows that bring content in from other platforms.