This document describes the SIM-ONE Alpha product surfaces implemented in this repository and how they enter the runtime. Installation and onboarding instructions live in the documentation hub; this file owns the runtime and interface architecture. Complete critic scoring and trusted fail-closed protocol enforcement remain release gates.
sim-onesim-one-alphaThe terminal client, connectors, API routes, schedules, orchestrator, workers, and capability registries are parts of one SIM-ONE Alpha product. Workers are internal executors, not separate products or public endpoints.
| Surface | Current responsibility | Runtime boundary |
|---|---|---|
| SIM-ONE terminal UI | Local conversation, durable sessions, transcript replay, progress, and slash commands | Enters the authenticated loopback chat and session APIs as connector tui |
| Telegram | Remote messaging, pairing, allow lists, group policy, replies, and approval delivery | Verifies Telegram input, normalizes the event, and dispatches to the orchestrator |
| Secure Web API | External chat, session, knowledge, schedule, approval, telemetry, and connector administration | Applies application-owned authentication and validation before Flue or product services |
| Schedules | Recurring and one-shot agent turns with durable definitions and run history | Dispatches admitted work to the durable orchestrator agent |
sim-one capability commands |
Add, list, enable, disable, update, and remove runtime skills, tools, workers, and MCP servers | Writes the SQLite capability store and managed capability directories |
Presentation and connector code do not contain orchestration logic. Every conversation or scheduled agent turn reaches the same governing orchestrator.
flowchart TD
TUI["SIM-ONE terminal UI"]
Telegram["Telegram connector"]
API["Secure Web API client"]
Schedule["Schedule manager"]
TUI --> Gateway["Gateway and application ingress"]
Telegram --> Gateway
API --> Gateway
Schedule --> Dispatch["Durable Flue dispatch"]
Gateway --> Event["Trusted normalized event"]
Event --> Session["Owned durable session"]
Session --> Orchestrator["SIM-ONE orchestrator"]
Dispatch --> Orchestrator
Orchestrator --> Protocols["Protocol Tool and SQLite protocol bundle"]
Protocols --> Orchestrator
Orchestrator --> Capabilities["Memory, tools, workflows, MCP, and workers"]
Capabilities --> Validation["Orchestrator synthesis"]
Validation --> Outcome["Implemented approval path or response"]
Outcome --> Gateway
Gateway --> TUI
Gateway --> Telegram
Gateway --> API
Orchestrator instructions require the protocol bundle to be loaded from trusted event data. Trusted enforcement that prevents reasoning, tool execution, worker delegation, or response synthesis before lookup remains a release gate. Workers and tools return results to the orchestrator; they do not send independent final responses.
src/app.ts is the Hono application shell. It:
app.route('/', flue()).The built runtime is emitted under .gorombo/sim-one-alpha/. Mutable state is
kept outside the compiled server:
~/.gorombo/
db/
capabilities/
auth/
logs/
sim-one-alpha/
sim-one-cli/
sim-one-ratatui/
The exact root can differ in a source checkout, but the ownership boundary is the same: packaged application files are replaceable; databases, user capabilities, credentials, and operational state persist independently.
With no subcommand, sim-one launches the packaged terminal client. The same
command owns user-facing capability lifecycle operations without moving
registry logic into the terminal interface. Enabled records are loaded when the
orchestrator initializes, so a gateway process restart is required after
lifecycle changes. See the CLI Reference for executable
options and subcommands.
User or agent requests capability
-> validate id, source, URL, and built-in/runtime collisions
-> write SQLite capability record
-> materialize file-backed capability when applicable
-> apply default enablement and approval rules
-> restart gateway process
-> load enabled records during orchestrator initialization
-> attach tools, skills, MCP tools, and worker profiles to Flue
Skills added by an agent are instruction content and are enabled by default. Executable tools, workers, and MCP servers added by an agent remain disabled until user enablement. Enablement does not bypass protocols, trusted scope, owning-agent attachment, sandbox policy, or action-specific approval.