Repository navigation
Agent 0 Toolchain IO
The selected .SYSTEMX or .SYSTEMXP scope has two local read-only routes for
an operator, IDE, or harness: selected read-only project CLI commands and a
bounded JSON-lines stdio session. Agent 0 still owns canonical task selection and
acceptance. These routes expose saved pointers and advisory status; they do
not create a worker, authenticate a provider, grant access, run a coding CLI,
or sync a cloud Bot.
The tagged toolchain I/O protocol and service implementation define this beta.2 route.
From the containing project directory, use the project-local launcher:
bash .SYSTEMX/SYSTEMX.sh root roster
bash .SYSTEMX/SYSTEMX.sh session-settings --compact
bash .SYSTEMX/SYSTEMX.sh onboard status --format json
bash .SYSTEMX/SYSTEMX.sh service statusThe installed systemx package command routes these project commands through
run --target PATH --offline -- COMMAND, or an explicit registered child
through projects --target PATH -- COMMAND --project NAME. It does not accept
direct systemx root roster or systemx onboard invocations. On Windows,
the local command prefix is pwsh -File .SYSTEMX/SYSTEMX.ps1; the source's
portable command availability does not certify native host integration.
root roster derives bounded role, BOT, AUTOBOT, CLI-channel, and
access-decision references. session-settings --compact returns selected
role status, a Rules file count/absent IDs, and an aggregate revision digest
without individual file hashes or rule-file contents. onboard status --format json
reports local Agent1 and roster state plus provider
navigation. None checks the user's effective provider login or host ACLs.
Select a child explicitly; outer records never become its task state.
For an existing task, root packet --task REAL_TASK_ID reads a bounded
selected-task context packet. root delta compares saved task mappings with
recorded external observations; it does not contact a harness or BOT.
An IDE or CLI harness may start the selected Python runner with
service start --stdio, own both standard pipes, and close input or send
stop to end it. service status only reports available capability. No OS
service, listener, daemon, scheduler, shell command, credential store, MCP
server, or ACP endpoint is installed.
The process inherits its caller's effective OS permissions and does not need
elevation; start it as a normal user. Capability fields
requiresElevation:false and hostPrivileges:"inherited-from-launcher"
describe this boundary; the process does not measure or drop its effective
OS privileges.
Each request is one UTF-8 JSON line containing exactly id and method:
{"id":"roster-1","method":"roster"}For a valid framed request, each response has the matching ID, ok, and
either result or a generic error. An invalid request can produce a generic
error with id:null. The fixed method set is:
| Method | Local result |
|---|---|
ping, capabilities, stop
|
Process health, available methods/limits, or session end. |
assess |
Agent1 warning-only All-In-One local assessment; no caller path or credential. |
roster |
Selected-scope Agent 0 role/instance navigation; no worker start or external permission probe. |
settings |
Compact session settings with Rules count, absent IDs, and aggregate revision digest; no individual hashes or raw Rules text. |
onboard |
Default read-only Agent1/roster/provider navigation; no provider, dotenv path, or credential can be selected in the packet. |
The protocol limits each request line to 16 KiB, each response to 512 KiB,
and each session to 64 requests. EOF and stop end the process. The selected
root or child is fixed when it starts. The protocol accepts no arbitrary
method arguments, command, path, account, or secret field. Standard output is
reserved for JSON lines; a client should treat any other output as a transport
failure. A successful response is a local readback, not product, account, or
device acceptance. Results can contain the selected local path, project
names, and task metadata; review them before forwarding a packet to an
external model or another account.
The versioned service protocol and versioned toolchain guide are the release authorities for invocation and limits. The Agent 0 roster and provider onboarding explain the values and external access boundary.
The generic CLI/JSON-lines route can be wrapped by a host that deliberately starts the selected process and verifies its output. The public beta ships no native integration registration for the following hosts:
| Host target | Current .SYSTEMX boundary |
|---|---|
| VS Code | An integrated terminal or extension-owned process may use the CLI/stdio contract; no VS Code extension or MCP server is installed by .SYSTEMX. |
| Codex app, CLI, or IDE | A reviewed project-root AGENTS.md pointer is optional; Codex worker/tool access and any MCP or SDK bridge remain host-managed. |
| Cursor | Its IDE or generic agent CLI needs manual identity and permission checks; no Cursor ACP/MCP bridge is registered. |
| Kiro | CLI, desktop IDE, and web cloud sessions are distinct host surfaces; an offline Agent Beta reference cannot connect Kiro Web, and no Kiro ACP/MCP bridge is registered. |
| JetBrains AI Assistant | A future host-owned process adapter could call the CLI/stdio protocol; no JetBrains ACP/MCP plugin is shipped or verified. |
This JSON-lines protocol is not MCP or ACP. A future MCP/ACP adapter would need its own host registration, method translation, permissions, lifecycle, platform tests, and observed round-trip before any integration claim. Inspect the selected host's real account, project scope, data sharing, and process permissions before using it for a task. The task ledger and Access Matrix remain review records, not a substitute for those controls.
.SYSTEMX · DOT SYSTEMX · Maintained by Wayne Tech Lab LLC · Repository · User manual · Prompt cookbook · MIT license
Beta 1.11.0-beta.4 prerelease — validate the selected release in your project. Release policy. Project records, configured commands, and verified evidence determine the state of each adopted project.
DOT SYSTEMX · User manual
1. Start here
- Current beta video: chapter and scene guide
- The Guided Folder: historical 4K walkthrough
- Start with a Folder: 4K animated guide
- Introduction video and archived poster
- Advanced walkthrough: inside the coordination layer
- Choose a workspace
- Agent 0 roster: roles, bots, and CLI paths
- Agent 0 and toolchain direct I/O
- First-time setup
- Provider and harness onboarding
- Daily workflow
- One-shot project guide
- Shared workspaces, clouds, and bots
- Historical use-case workflows
- Four current system maps
- Current maps, seven agent guides, and atlas
- Agent guide text and CLI flows
- Visual guide and historical diagrams
- New chat setup prompt
- Prompt cookbook
2. Work and continuity
- SYSTEMX PROJECTS
- AUTOBOT and Agent Alpha: Tier 2
- Local DATA storage
- Planning and memory
- ROOT planning, rules, and task delta
- System MAP
- Access Matrix: 20 standard entries
- Agent Beta, Agent1, and Agenda
- Task workflow
- Agent X: events and time
- Agent Y: CLI and PR channels
- Agent Z: fixed review
- 100 review questions
- Agent 0 and subagents
- Subagent processing
- Advanced use cases
- Evidence and acceptance
- Anti-drift and long-running work
- Tokens, cost, and time
3. Setup and maintenance
- Project / VS Code
- OS directory
- Google Drive
- LLM chat
- Exact casing and alias
- Installation and updates
- Upgrading
- Uninstall and cleanup
4. Advanced reference
- Standard format
- Technical Guide
- Stack Guide
- Library integration
- CLI and Tools
- Command reference
- Configuration and quality
- Operations and troubleshooting
- Security and support
- Code review and readiness
5. Project information