This repository has been archived on 2026-04-03. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
core/ROADMAP.md
Jeffrey Smith bd703b9e0d
All checks were successful
CI/CD / detect-changes (pull_request) Successful in 24s
CI/CD / test-frontend (pull_request) Has been skipped
CI/CD / test-go-pg (pull_request) Successful in 2m30s
CI/CD / test-sqlite (pull_request) Successful in 2m37s
CI/CD / build-and-deploy (pull_request) Successful in 1m30s
Feat event bus subscriptions + trigger system (v0.2.2)
Three trigger primitives replacing the old monolithic scheduler:

- Event triggers: extensions subscribe to bus patterns via manifest,
  async handler invocation through sandbox.CallEntryPoint
- Webhook triggers: inbound HTTP at /api/v1/hooks/:pkg/:slug with
  HMAC-SHA256 verification and synchronous Starlark response
- Scheduled tasks: user-created cron scripts with restricted sandbox
  (no raw HTTP, no DB table creation), runs as creator identity

New tables: triggers, scheduled_tasks, trigger_logs (postgres + sqlite).
New permission: triggers.register. Full admin + user CRUD APIs.
SyncManifestTriggers hooked into seed and install flows.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-26 22:29:43 +00:00

7.7 KiB
Raw Blame History

Switchboard Core — Roadmap

Current: v0.2.0 — SDK & Triggers

Fork of chat-switchboard, gutted to a pure extension platform. All AI/chat features removed from the kernel. What remains is the minimum viable platform that extensions build on.

Retained kernel capabilities

  • Auth: builtin (simple), mTLS, OIDC
  • Identity: users, teams, groups, permissions (RBAC)
  • Packages: surfaces, extensions, libraries, workflows
  • Starlark sandbox: capability-gated modules
  • Storage: object storage (PVC, S3), ext_data tables
  • Realtime: WebSocket hub, presence, multi-replica HA
  • Ops: audit log, notifications, maintenance goroutine

Phase 0 (complete)

Step Status Description
1. Module rename chat-switchboardswitchboard-core
2. Delete packages 15 Go packages, 29 handler files removed
3. Gut stores/models 40 → 20 store interfaces, kernel-only models
4. Fresh migrations 9 files × 2 dialects, 27 tables
5. Fix compilation go build ./... clean, 300+ stale route lines cut
6. Fix tests 8 test packages pass, ~12K stale test lines pruned
7. Frontend gut Shell + SDK only, 50+ files of chat/notes/projects code removed
8. New ICD Full OpenAPI 3.0.3 spec — 160 operations across 22 tag groups
9. CI/CD + Dockerfile Single unified image, FE/BE split removed, DB names updated, k8s var alignment fixes (resource quantities, image name, rollout deployment name)
10. Smoke test K8s deploy live at switchboard.gobha.ai/test, nginx BASE_PATH fixed, login→admin flow verified, branding updated

v0.2.x — SDK & Triggers

The contract that extensions build against. Three trigger primitives, SDK stabilization, and the first rebuilt extension (tasks).

v0.2.0 — RBAC + Settings Cascade (complete)

Step Status Description
Admin → RBAC group surface.admin.access permission + Admins system group replaces role == "admin" checks. Admin bypass removed from permission middleware.
Settings cascade user_overridable flag, three-tier resolution (global → team → user), team settings API
Settings override model Shipped with settings cascade above

v0.2.1 — Default Surface + ICD

Step Status Description
Default surface routing / redirects to configurable default surface. No surfaces → admin. First install becomes default. Changeable in admin settings.
ICD (API contract) Full OpenAPI 3.0.3 spec — 160 operations, 22 tag groups, reusable component schemas. Served at /api/docs.

v0.2.2 — Event Bus + Triggers

Step Status Description
Event bus subscriptions Extensions register event patterns in manifest. Wired via bus.Subscribe() on startup. Async handler invocation.
Webhook triggers Inbound HTTP at /api/v1/hooks/:package_id/:slug. HMAC-SHA256 verification. Synchronous Starlark handler response.
Scheduled tasks User-created cron tasks with restricted sandbox (no raw HTTP, no DB table creation). Runs as creator identity. Templates from extensions. Dedicated schedules API.
Trigger admin API CRUD for triggers + schedules. Enable/disable, execution logs, per-package listing.

v0.2.3 — SDK + Task Extension

Step Status Description
SDK stabilization 🔲 sb.slots(), sb.actions, sb.api.ext(), sb.storage, theme tokens, primitive UI
Task extension 🔲 First proof-of-concept — full task system rebuilt as Starlark extension using triggers + ext_data + notifications

v0.3.0 — Notes Surface

Obsidian-style rich-text notes rebuilt as an installable surface package. Zero platform special-casing. Proves the full extension stack E2E.

  • Notes as .pkg archive
  • Rich text editor (ProseMirror or similar)
  • Folder tree, backlinks, tags — all extension-provided
  • Markdown import/export

v0.4.0 — MVP

Extension and operations tracks converge. First externally usable release.

  • Package registry (browse, install, update, uninstall)
  • Package distribution model (no auto-install; explicit install only)
  • Health monitoring dashboard
  • Backup/restore tooling
  • Documentation site

Post-MVP

  • Chat extension (provider registry, streaming, personas, tool system)
  • Rich media extensions: image generation, code sandbox, STT/TTS
  • Desktop app (Tauri or Electron)
  • Sidecar tier: container-based extensions
  • Federation: cross-instance package sharing
  • Plugin marketplace with signing and review
  • Mermaid diagrams extension (nice-to-have)

Design Decisions Log

Decision Rationale
Tasks → extension Scheduler was the most entangled kernel component (~3,400 lines). Rebuilding as extension validates the trigger system and removes the worst compilation debt. Three trigger primitives (time, webhook, event) replace the monolithic scheduler.
Sessions removed Channel-based sessions coupled to deleted chat system. Workflow instances need new storage model — either ext_data tables or a dedicated kernel table.
chat_onlycustom Stage mode chat_only implied chat as a kernel concept. Renamed to custom which delegates to a surface package, proving extension composability.
Providers removed from kernel Provider configs, model catalog, routing policies — all moved to extension track. Kernel provides credential storage (connections) and the Starlark provider.complete module as the interface.
Kernel permissions simplified From 16 chat-centric permissions to 6 platform permissions. Extensions define their own capability requirements in manifests.
Preact+htm retained 3KB runtime, no build step, works for extension authors without bundler config. KISS.
Single Docker image Drop the frontend/backend split. Go binary + assets + migrations in one image. Simpler deployment, fewer moving parts.
Admin → RBAC group The role column is pre-RBAC. v0.2.0 replaces it with a seeded "Admins" group + surface.admin.access grant. All users auto-join "Everyone" group. Admin middleware becomes a grant check, not a role check.
Settings cascade RBAC controls scope auth (who can set at what level). user_overridable flag controls whether lower scopes can override higher. Two orthogonal axes, composes cleanly with extension manifests.
No new migrations pre-MVP Edit existing migration SQL files in place. No migration chains until schema is in production.
Notes over Editor First surface is Obsidian-style notes (rich text, folders, backlinks) instead of a code editor. Notes is a stronger E2E proof — it exercises ext_data, storage, and the SDK more fully than a pure-browser CM6 editor.
No built-in auto-install Extensions ship in the repo but are not auto-installed. Distribution model TBD — explicit install only. Keeps the kernel clean and avoids opinionated defaults.
Chat → post-MVP Chat extension (providers, streaming, personas) is valuable but not MVP-critical. The platform must prove itself with simpler surfaces first. Chat moves to post-MVP track.
Two trigger tiers Event + webhook triggers are extension-declared (manifest contract, full sandbox). Scheduled tasks are user-created ad-hoc (restricted sandbox — no raw HTTP, no DB table creation, connections-only outbound). Separation keeps extension contracts static and user automation safe.
Scheduled task identity Tasks run as their creator (RBAC-scoped). Admin-created tasks can opt into system context. Creator deactivation pauses the schedule. Ensures audit trail and permission boundaries.