|
| 1 | +--- |
| 2 | +name: extensions |
| 3 | +description: Build, modify, explain, validate, package, or install Mantis extensions and custom vertical panels. Use when a user asks for reusable Mantis UI, extension commands or events, a .mantisx package, or an optional Python-backed extension action. |
| 4 | +--- |
| 5 | + |
| 6 | +# Mantis Extensions |
| 7 | + |
| 8 | +Mantis extensions are trusted packages that add reusable workspace functionality without changing the core app. They can contain: |
| 9 | + |
| 10 | +- sandboxed panel UIs, available under **Verticals > Extensions** |
| 11 | +- an extension host for durable commands, subscriptions, activation, and state |
| 12 | +- an optional Python backend for work that should not run in the browser |
| 13 | + |
| 14 | +Panel code uses `window.mantis`; host code uses `mantis`. Both use the same asynchronous, permission-gated SDK. Panels are short-lived and run in `allow-scripts` iframes without same-origin access. The host runs in a Web Worker and survives panel closure until the extension deactivates. |
| 15 | + |
| 16 | +## First step |
| 17 | + |
| 18 | +Run this before any other Mantis command or tool, unless it already ran this turn: |
| 19 | + |
| 20 | +```bash |
| 21 | +mantis use get_space_context |
| 22 | +``` |
| 23 | + |
| 24 | +Use the returned space id when installation needs a target. Never guess a space, map, field, or permission. |
| 25 | + |
| 26 | +## Documentation routing |
| 27 | + |
| 28 | +The docs are authoritative. Read the pages relevant to the requested contribution; do not invent manifest fields, SDK methods, permissions, package layouts, or lifecycle behavior. |
| 29 | + |
| 30 | +| Need | Read | |
| 31 | +|---|---| |
| 32 | +| Architecture or choosing host vs panel | [Overview](https://mantis.csail.mit.edu/docs/features/extensions/overview.html) | |
| 33 | +| Any new or changed package | [Manifest](https://mantis.csail.mit.edu/docs/features/extensions/manifest.html) | |
| 34 | +| Panel layout and lifecycle | [Custom panels and verticals](https://mantis.csail.mit.edu/docs/features/extensions/custom-panels-and-verticals.html) and [Panel UI](https://mantis.csail.mit.edu/docs/features/extensions/panel-ui.html) | |
| 35 | +| Mantis data, state, commands, or events | [SDK API](https://mantis.csail.mit.edu/docs/features/extensions/sdk-api.html) | |
| 36 | +| Server-side execution | [Python backend](https://mantis.csail.mit.edu/docs/features/extensions/python-backend.html) | |
| 37 | +| Producing or checking an archive | [Packaging and installation](https://mantis.csail.mit.edu/docs/features/extensions/packaging-and-installation.html) | |
| 38 | +| A concrete SDK pattern | [Examples](https://mantis.csail.mit.edu/docs/features/extensions/examples.html) | |
| 39 | +| Permissions, trust, or platform limits | [Security and limits](https://mantis.csail.mit.edu/docs/features/extensions/security-and-limits.html) | |
| 40 | + |
| 41 | +For a normal panel extension, read the overview, manifest, relevant panel/SDK sections, packaging, and security guidance. Read backend documentation only when server-side execution is actually needed. Use examples as patterns, not as a substitute for the reference pages. |
| 42 | + |
| 43 | +## Build workflow |
| 44 | + |
| 45 | +1. Clarify the user-visible workflow, what Mantis data it reads or writes, whether behavior must survive panel closure, and the target space if installation is requested. |
| 46 | +2. Inspect the existing extension project before choosing its build system or layout. Preserve established conventions. |
| 47 | +3. Design the smallest useful contribution: |
| 48 | + - use panel-local code for UI and temporary view state |
| 49 | + - add a host `main` only for durable commands, subscriptions, activation, or state |
| 50 | + - add Python only when the browser SDK cannot do the required work |
| 51 | +4. Declare the narrowest supported permission set. Explain every write, command, backend, or network capability. |
| 52 | +5. Build self-contained browser output. Do not import from the parent Mantis app; bundle host and panel dependencies into the extension output. |
| 53 | +6. Validate manifest paths and ids, contribution entries, activation events, permissions, backend actions, and referenced assets. |
| 54 | +7. Run the project's tests/build when present, package it, then inspect the archive layout before reporting success. |
| 55 | + |
| 56 | +## Manifest and SDK rules |
| 57 | + |
| 58 | +- Every package needs `mantis.extension.json`. |
| 59 | +- Keep extension, panel, and command ids stable. Use globally unique dotted ids for extensions and prefix command ids with the extension id. |
| 60 | +- Declare only documented permissions: `maps:read`, `selection:read`, `selection:write`, `bags:write`, `panels:write`, `commands:execute`, and `backend:invoke`. |
| 61 | +- Use `context.workspaceState` / `window.mantis.workspaceState` for state scoped to the current space and `globalState` for user-level extension state. |
| 62 | +- Put durable command registrations and event subscriptions in host `activate(context)` and add returned disposables to `context.subscriptions`. |
| 63 | +- Dispose panel-local subscriptions when the panel unloads. |
| 64 | +- Do not use raw `rpc` unless debugging the bridge and the documented helper cannot serve the request. |
| 65 | +- Do not use unsupported `contributes.menus` or `contributes.settings` fields. |
| 66 | + |
| 67 | +## Python backend decision |
| 68 | + |
| 69 | +Python backends are supported but optional. Add one only for server-side computation, Python-only dependencies, or work that cannot safely or practically run in the panel/host SDK. |
| 70 | + |
| 71 | +When a backend is needed: |
| 72 | + |
| 73 | +- request `backend:invoke` |
| 74 | +- allowlist actions in `backend.actions` |
| 75 | +- validate every payload and return JSON-serializable values |
| 76 | +- pin and minimize requirements |
| 77 | +- keep `network: false` unless external access is essential and explicitly disclosed |
| 78 | +- never treat the backend context as secret storage |
| 79 | + |
| 80 | +Do not describe the backend as deprecated unless the current docs say so. |
| 81 | + |
| 82 | +## Security |
| 83 | + |
| 84 | +- Treat extensions as trusted code even though panels are sandboxed and SDK calls are permission-gated. |
| 85 | +- Never add same-origin access to a panel or reach into the parent DOM, cookies, or browser storage. |
| 86 | +- Do not embed API keys or other secrets in browser or backend assets. |
| 87 | +- Avoid sending Mantis data to external services; if required, make the data flow and backend network access explicit. |
| 88 | +- Prefer explicit user actions for writes, clear progress for slow work, and visible errors for permission or backend failures. |
| 89 | +- Review publisher/source, permissions, dependencies, backend actions, and network access before installation. |
| 90 | + |
| 91 | +## Package and install |
| 92 | + |
| 93 | +Prefer `.mantisx` or `.zip` for real extensions; use inline JSON only for small fixtures or debugging. The archive must contain `mantis.extension.json` at its root or inside one single top-level folder. Browser assets must not be under `backend/`; Python backend files must be under `backend/`. Paths must be safe, relative, and UTF-8 text. |
| 94 | + |
| 95 | +Installing changes a Mantis space. Install only when the user asks for it or the task explicitly includes installation: |
| 96 | + |
| 97 | +```bash |
| 98 | +mantis use install_extension --file extension.mantisx --space-id <space-id> |
| 99 | +``` |
| 100 | + |
| 101 | +The API-key user must own the target space. Installation is personal to that user within the space. Report the extension id/version, panels and commands, requested permissions, backend/network status, archive path, and installation result. |
0 commit comments