Overview

CYSJavis Pack: the Built-in Multi-Agent OS

Layer Contents Source
Core (machine functions) Bidirectional sockets · approval Feed · watchdog/ledger · event push · session persistence cys-terminal core
CYSJavis pack Role-based absolute directives · deterministic operational tools · hooks · skills cys init-pack
Personal layer soul.md (priorities/red-lines) · long-term memory accumulated by you as you use it

The four roles are distinct: master decides and supervises, worker implements, the CSO is the first responder for system/resource matters, and two heterogeneous reviewers verify and rebut (they are not workers — they are the master's dedicated verification/adversary reviewers).

Master-declaration hierarchy fallback — the owner's single sentence "you are the master" auto-boots a 5-node team (boot and task-start are separated). A second declaration is not a conflict (rejected) but auto-creates a new department, and on the first department the existing master is auto-promoted to CEO. The department-creation path is thus extended beyond the GUI button to a "declaration path." A declaration delivered or executed by an agent, however, is stopped by a machine-origin gate and does not trigger this fallback (human channel only).

soul.md and memory/ ship as intentionally empty skeletons — the design belief is that operating taste and long-term memory are not borrowed but filled in by the user. Autonomous piloting (running an approved roadmap to completion unattended) turns on only when the owner grants it explicitly in soul.md, and a kill-switch that instantly pauses on any owner input has top priority. Symmetrically, the authority to start an autonomous run comes only from the owner channel — even with unfinished work in the queue, if no mission is assigned, a mission gate reports and halts, guarding the start side opposite the kill-switch.

Details: Architecture & Philosophy §2–4; operations: User Manual §12.

What you get — three configurations compared#

cys-terminal is different from a traditional terminal even if you just connect plain claude with no Jarvis onboarding. Three configurations were compared across 33 items × 6 areas (fresh-machine E2E measurement skeleton + v0.14.x release-code tracing + pack-number re-measurement):

  • Traditional terminal (iTerm, …) + claude CLI
  • cys-terminal + plain claude (everyday use, no Jarvis onboarding)
  • cys-terminal + Jarvis onboarding ("you are the master" → 5-node full system, the baseline)

The ①→② gap is what you get from installation alone — auto-deployment of the full skill set (a 570+ file pack) into an isolated config, observation, inter-pane communication, ~/.claude protection, and skills, categories that simply do not exist in a traditional terminal. The ②→③ gap is organization, memory, and autonomy (Jarvis's unique value): team formation, ticket/reviewer/RSI/eval loops, cross-session recovery (SESSION_STATE/RECOVERY), radio finding-sharing, and autonomous piloting with a denylist boundary. The only real friction in ② is two one-time gates:

F1 = Claude Code's own first-run dialog (5 steps: Enter → security note → terminal setup → folder trust → bypass warning) needs one human pass. F2 = the isolated config keeps Keychain credentials per config path (Claude Code-credentials-<sha256(path)[:8]>), so it needs its own /login once.

Moving from ② to ③ is a single sentence: "you are the master."

Jarvis-native features (22)#

Design thesis: every operational duty the directives ask the orchestrator to perform by hand = a feature gap in the terminal. ① convention → daemon-guaranteed mechanization ② self-report first, screen-parsing is the fallback ③ 3-tier automation safety (alert → escalate → act, deny-by-default).

  • T1 — identity & reporting: self-reported status/context%/task (cys set-status); one-call fleet board (cys status, cys fleet); sender identity + role→role ACL (kernel peer-pid from verification).
  • T2 — resilience: context-cycle executor (save → file gate → clear → re-inject → resume, cys cycle-agent); instant agent-death detection + optional recovery (blocked on auth error); org restore (topology persistence + bulk re-boot/re-inject); directive drift detection/re-injection (cys reinject); orchestrator dead-man (master.deadman).
  • T3 — coordination: todo watch (per-role TODO mtime → progress rollup); one-shot timers with fresh TTL; role-glob broadcast (cys send --to 'reviewer-*'); feed-aging re-alert; input safety (typing guard, atomic authority delivery); delta read + wait (cys read-screen --since N, cys watch --until <re>).
  • T4 — safety & attestation: kill-switch (cys pause/resume, cys gate-check); approval escalation (screen scan → event + feed, never auto-answers); health-rule action binding (opt-in, pauses queued delivery only); transcript hash-chain attestation (cys attest pin/verify, producer≠evaluator); recall retention policy.
  • T5 — cognition & attribution: radio — parallel workers share findings, FACT truth-checking (file·line·snippet, unverified is auto-demoted), BLOCKER gate, decision traffic forbidden (javis_radio open/send/wait/read); BOOT_SNAPSHOT — restores memory as a read-only ledger digest after clear/compact (javis_snapshot generate); attribution-arbitration ledger — on suspected pane-text forgery, the delivery ledger is consulted before any fix begins; no-evidence attribution is void (javis_mission delivery-path, machine-origin).

Resource governance (three mitigations)#

Mitigation What it does Command / event
① Login-loss detection Every output line is matched against health rules (default: Not logged in · 401 · token expired · rate limit) → 30 s debounced push. Self-amplification is blocked: alert lines mask their own triggers (send-side sealing) and lines discussing an alert are excluded from matching (receive-side isolation). health.alert · cys add-health-rule <name> <regex>
② Short work units Idle detection (default 300 s of no output) pushes → split/check decision. pane.idle event
③ Forced server teardown Scoped execution (new process group + ledger, torn down as a group on exit) · close-surface (child tree killed) · watchdog (load / child-count / duplicate-command detection). cys run -- <cmd> · cys ps · cys kill <pid> · watchdog.*

Approval Feed · in-flight queue#

cys feed push --wait --title "approve git push" --body "..."   # blocks until decided (exit 0=allow, 2=deny, 3=timeout)
cys feed reply <request_id> allow                              # CLI, or the UI Allow/Deny buttons

There is no auto-answer (human-in-the-loop) — the daemon even refuses a requesting node's self-approval. Repeated-risk commands are passed by signing once with cys approval sign (master-only, HMAC signed-prefix).

  • Default send (cys send) = steer: injected into stdin immediately, absorbed as steering while the target is running.
  • cys send --queued = followup: delivered one item per beat once the target has been quiet for 3+ seconds.

Control Center (overview)#

A dedicated full panel in the app — cysd serves fleet, usage, and system over a single RPC (no external dashboard needed); persistent analytics accumulate in cysd's embedded SQLite (analytics.db, graceful degrade if it can't open). Philosophy: local-first (data never leaves the machine) · zero extra infrastructure · 0 ms agent latency (hooks are fire-and-forget).

Nine tabs: Live (node fleet · per-core CPU / GPU / NPU / memory at 2 s · today's tokens/cost/model-mix · alert strip) · Cost & Efficiency (persistent aggregates, token 4-way split, per-model cost with unknown-price flagged, cache savings/reuse) · Skills & Agents (skill/tool/delegation call counts, failure rate, repeat failures) · Sessions (timeline, activity ribbon, transcript-excerpt drill-down, favorites, PII redaction) · Trends & Weekly (WoW deltas, efficiency leaders, skill assets) · Learning (RSI round timeline, adopt/rollback, cumulative discoveries) · Skill Board (a curated skill button = a one-shot worker run with HITL preview) · Work (current tasks across every department × node, observe-only, self-report vs. derived trust badges) · Approval Feed (Allow/Deny). Plus: ⌘K Command Palette, Glance mode (⌘G, a summary screen for non-technical users), workspace groups, departments (project isolation via independent daemons), and RBAC PII redaction (CYS_CONTROL_REDACT=1).

Full tab-by-tab detail on the monitoring dashboard: User Manual: Control Center.


Back to Overview · See also Fleet Operations

Was this page helpful?