Roadmap & API status
The whole platform Silo is building toward — and what's real today. This page is the source of truth for what you can build on now vs. what's still being designed. As a primitive ships, its badge flips from
planned to stable.The goal: a small, stable core, after which most new features are extensions built on these primitives — first-party and third-party alike. When the core table below is all green, we've hit that inflection point.
Legend: stable available now ·
experimental usable, may change ·planned designed, not yet implementedCore (ctx) primitives
| Primitive | Status | |
|---|---|---|
Registration (register*) | stable | docs |
executeCommand | stable | docs |
ctx.workspaces | stable | docs |
ctx.layout | stable | docs |
ctx.process (persistent sessions) | stable | docs |
ctx.process.exec (one-shot subprocess) | stable | docs |
ctx.processes (foreground process observer) | stable | docs |
ctx.agents (coding-agent activity + resume hints) | beta | How it works |
Extension-API mechanism (getExtension) | stable | docs |
ctx.editors (documents) | stable | docs |
ctx.terminals (terminal tabs) | stable | docs |
Tab adornments (editors / terminals setIcon / setIndicator / setActivity / …) | stable | docs · ADR 0029 · ADR 0030 |
Activity chrome (Activity kind + SDK ActivityGlyph) | stable | ADR 0030 · workspace status + tab adornments |
ctx.terminals.registerTabDecoration (deprecated shim) | stable | docs — prefer bindIndicator / bindActivity |
| Side-panel tab adornments (owner handle) | planned | RFC 0022 |
ctx.registerToolbarItem | stable | docs · RFC 0021 |
ctx.terminals.focus | stable | docs |
ctx.terminals.subscribeOsc | stable | docs |
ctx.terminals.getActive / subscribeActive | stable | docs |
ctx.terminals.subscribeOutput | stable | docs |
ctx.workspaces status / badges (set / clear / bind) | stable | docs · adorn verbs; registerStatus / registerBadge deprecated shims |
ctx.workspaces.registerSection | stable | docs |
ctx.files | stable | docs |
ctx.theme + ctx.theme.registerPreset | stable | docs |
ctx.dnd (drag-and-drop) | stable | docs |
useServiceState (reactive reads) | stable | docs |
useFocusGroup (keyboard nav for a group) | stable | docs |
Tooltip (styled hover popup) | stable | docs |
| Design-system components (modal kit) | stable | docs · RFC 0016 |
--silo-list-* tokens + .silo-scroll | stable | docs |
ctx.ui (pickers + notify w/ actions + menus) | stable | docs |
ctx.ui (confirm / prompt) | stable | docs |
ctx.ui.showModal (custom modal content) | stable | docs |
ctx.ui.openExternal (open a URL out) | stable | docs |
ctx.ui.getActiveSelectionText | stable | docs |
ctx.net (server-side HTTP, bypasses CORS) | stable | docs |
ctx.system (OS, arch, Silo version) | stable | docs |
ctx.search (cross-file content search) | stable | docs |
ctx.search (replace-in-files) | planned | design |
ctx.ui (quickPick / progress) | planned | design |
ctx events (typed Event<T>) | stable | docs |
ctx.editors.getState / subscribe | stable | docs |
path (cross-platform path utilities) | stable | docs |
| per-extension settings (page + persistence) | stable | docs |
ctx.storage (global / workspace) | stable | docs |
ctx.secrets (host-mediated credentials) | planned | RFC 0004 |
ctx.webview (cross-origin iframe bridge) | stable | docs |
| context-menu contributions (workspace, terminal/link, editor/tab, terminal/tab) | stable | docs |
| context-menu contributions (explorer/item) | planned | design |
ctx.workspaces.registerPropertyPage | stable | docs |
Extension-owned features
Features that ship built-in but are implemented as extensions on the primitives above — so a third party could build the same.
| Feature | Status | Built on | Publishes |
|---|---|---|---|
| Git | stable | process.exec + files | GitAPI |
| Markdown Preview | stable | registerEditor + files | — |
| Terminal | stable | process sessions + dock panel | — |
| Theme management | stable | theme + files + ui | — |
| Search (find-in-files) | stable | search + editors | — |
Each ships as a real extension package (
core.*/silo.*) that touches the app only throughctx— the same surface a third party gets. The core primitives they lean on (the terminal'sprocesssessions, the theme domain service) still live in the host; that split is by design. The decisions behind the model are recorded as ADRs indocs/decisions/.
Extension distribution
How a third-party extension gets from a package into the running app. See Extensions (install / Browse / updates) and Publishing an extension.
| Capability | Status | |
|---|---|---|
Author against @silo-code/sdk from npm | stable | docs |
| Install from local folder | stable | docs |
| Enable / disable / uninstall (runtime) | stable | docs |
| First-party built-ins listed (disable-only, branded) | stable | docs |
| Load on launch + persisted registry | stable | docs |
silo install / silo uninstall CLI | stable | docs |
npx create-silo-extension scaffold | stable | docs |
| Install from URL (tarball / GitHub release) | stable | docs |
| Install from npm registry | stable | docs |
| Update checking + apply | stable | docs |
| Extension registry — browse / search / install | stable | docs · catalog |
Registry website (extensions.getsilo.dev) | stable | extensions.getsilo.dev |
| Private / team registries (federated index) | planned | design |
| Permissions / capability model | stable | docs |
Updates: "Update checking + apply" is the P1 registry feature — the app polls registry.getsilo.dev, shows a badge, and applies Update / Update all from Settings → Extensions. That is not the same as Safe update below (stage → validate → swap + rollback on a bad install), which is still planned.
Extension model & safety
The contract + lifecycle work that makes the system survivable at scale. The designed pieces are RFCs in docs/proposals/ (esp. 0005 / 0006); the rest is tracked in the table above.
| Capability | Status |
|---|---|
Manifest id / path validation | stable |
Declarative contributes + activation events | planned |
engine compatibility enforcement | planned |
| Sandbox / capability gating (untrusted code) | planned |
| Storage cleanup on uninstall | planned |
| Safe update (stage-validate-swap + rollback) | planned |
| Failed-load error surfacing + collision reporting | planned |
Designed surfaces (planned)
The shape of each planned surface is now designed in an RFC under docs/proposals/ (subject to change until it ships):
| Planned surface | RFC |
|---|---|
ctx.ui slice 2 — quickPick / inputBox / progress | RFC 0001 |
Typed ctx events (Event<T>, domain-owned, no global bus) | RFC 0002 |
ctx.secrets — host-mediated credentials (storage global / workspace shipped) | RFC 0004 |
Declarative contributes + activation events | RFC 0005 |
| Extension permissions + sandbox | RFC 0006 |
| Extension authoring toolchain | RFC 0007 |
| Package format + remote install (GitHub / npm) | RFC 0008 |
Language intelligence (TS/JS via tsserver) | RFC 0009 |
| Context-menu contributions (explorer/item, editor/tab, terminal/tab) | RFC 0013 |
Tooling
Not part of the extension SDK — host-side developer/test surfaces.
| Surface | Status | |
|---|---|---|
silo <path> CLI | stable | docs |
| Automation RPC (dev) | experimental | design |
| Nightly release channel | stable | docs |
silo <path> CLI stable
A terminal entry point: silo <dir> foregrounds (or launches) Silo and opens/activates a workspace for that folder; silo <file> opens the file in the active workspace. Built on tauri-plugin-single-instance — a second launch is forwarded to the running instance rather than opening a new window. Install the command from File → Install silo Command in PATH. See the silo command.
Automation RPC experimental
A dev-only loopback HTTP RPC for driving the real running app from a test suite, CI, or an agent — works around macOS having no WKWebView automation hook. Excluded from release builds (Cargo automation feature + frontend DEV guard); in dev it's always on but every request must carry an X-Silo-Automation header and a loopback Host, so a web page you visit can't drive it. Ops include ping, exec (run a registered command), activeElement / editorsDetail (focus introspection), workspace/file test-driver ops, contextKeys, and eval. See docs/automation.md.