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 |
Extension-API mechanism (getExtension) | stable | docs |
ctx.editors (documents) | stable | docs |
ctx.terminals (terminal tabs) | stable | docs |
ctx.files | stable | docs |
ctx.theme + registerThemePreset | stable | docs |
ctx.dnd (drag-and-drop) | stable | docs |
useServiceState (reactive reads) | stable | docs |
useFocusGroup (keyboard nav for a group) | 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.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>) | planned | design |
ctx.settings / configuration | planned | — |
ctx.storage (global / workspace / secret) | planned | — |
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 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 |
| Install from URL (git / release tgz) | planned | — |
| Install from npm registry | planned | — |
npx install/uninstall CLI | planned | — |
| Update checking + apply | planned | — |
| Permissions / capability model | stable | docs |
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 |
General ctx.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.settings — per-extension configuration | RFC 0003 |
ctx.storage — global / workspace / secret | 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 |
| Self-owned PTY host daemon | RFC 0010 |
Tooling
Not part of the extension SDK — host-side developer/test surfaces.
| Surface | Status | |
|---|---|---|
silo <path> CLI | stable | docs |
| Automation RPC (dev) | experimental | design |
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.