Jarvis

Autonomous agent system for Thinking in Code — an automotive safety consulting firm specializing in ISO 26262, ASPICE, AUTOSAR, and cybersecurity.

Jarvis is being rebuilt into one local-first assistant with registry-backed modes for Ask, Research, Coding Studio, Device, Professional Writing, and Business Workspace. The old domain-agent roster is archived by default while v0.3 capabilities are proven. It runs on OpenClaw as a plugin pack, with local LLM inference via Ollama, LM Studio, or llama.cpp.

Current Release: v0.2.0-beta.1

Shipping version: 0.2.0-beta.1 (see package.json).

This is a single-node, localhost-first beta. It is not safe for remote multi-user deployment. Documented trust gaps remain open — see docs/KNOWN-TRUST-GAPS.md.

License: MIT — free to use and modify, including for commercial consulting work.

> v0.3 target notice: The sections below describe the v0.3 registry-backed > mode architecture that is being built toward. Capabilities marked real are > already shipped in v0.2.0-beta.1. v0.3.0-focused-reliable-jarvis is the > next named milestone, not the currently-shipping version.

Jarvis v0.3 exposes modes, not a legacy domain-agent zoo. The active product surface is derived from the canonical capability registry in @jarvis/core. If a capability is not listed here, it is either archived, blocked, or still prove-first.

Registry-Backed Modes

> The table below is regenerated from packages/jarvis-core/src/capabilities/registry.ts > by scripts/generate-capability-docs.ts. Edits between the BEGIN / END markers > will be overwritten. Run npm run docs:generate-modes to refresh; CI fails on > drift via npm run docs:check.

<!-- BEGIN registry-modes (generated — do not edit by hand) --> | Mode | Active capability | Label | Status | |---|---|---|---| | ask | ask.answer | Ask Answers | real | | ask | ask.escalate_freshness | Freshness Escalation | real | | ask | ask.summarize_user_text | Ask Summarization | real | | business | business.deck_outline | Deck Outline | real | | business | business.opportunity_workspace | Opportunity Workspace | real | | business | business.positioning_note | Positioning Note | real | | coding | coding.patch | Coding Patch | real | | coding | coding.specs | Coding Specs | real | | coding | coding.test | Coding Tests | real | | device | device.clipboard_read | Clipboard Read | real | | device | device.inspect_file | Inspect Allowed File | real | | device | device.list_windows | List Windows | real | | device | device.screenshot | Screenshot | real | | publish | publish.linkedin_draft | LinkedIn Draft | real | | research | research.claim_matrix | Research Claim Matrix | real | | research | research.source_table | Research Source Table | real | | research | research.web | Web Research | real | <!-- END registry-modes -->

Blocked or gated examples remain documented as unavailable. publish.linkedin_publish is unsafe_blocked until official LinkedIn API access, valid scopes, identity or organization confirmation, explicit approval, and audit evidence are all proven. Device mutations such as app opening, window focus, and clipboard writes remain approval-gated and are not advertised as automatic actions.

> v0.3 Scope Notice > > Jarvis v0.3 is a single-node, localhost-first operator system with a reduced, > registry-backed core. It does not claim remote multi-user safety, encrypted > credentials at rest, an OS sandbox, official LinkedIn publishing, or automatic > CRM writes. Known trust gaps remain — see > docs/KNOWN-TRUST-GAPS.md.

<a name="beta-install-v020-beta1"></a>

Install

Use a fresh clone or a backed-up local checkout. The mandatory v0.3 core is the local daemon, dashboard, runtime.db control plane, registry-backed modes, and at least one local model runtime. External credentials and optional integrations such as Telegram, Gmail, Google Calendar, Chrome, or LinkedIn are not required for the v0.3 local core.

# 1. Clone and install
git clone https://github.com/dturcu/jarvis.git
cd jarvis
npm install

# 2. Back up existing state (SKIP this on a fresh install — nothing to back up yet)
#    Only needed if you are upgrading from a prior Jarvis version:
# npm run ops:backup            # creates a timestamped bundle under ~/.jarvis/backups/

# 3. Run the setup wizard (creates databases, config, builds dashboard)
npm run jarvis setup

# 4. [Optional] Configure the vault passphrase (enables encrypted credential storage)
#    Without this step the dashboard and Ask/Research modes work, but agent runs
#    that need OAuth tokens (Gmail, Calendar, Telegram) will fail.
#    Pick exactly ONE of these two options:
#
#      Option A: env var (preferred for CI / scripted installs)
#        Linux/macOS:
#          export JARVIS_VAULT_PASSPHRASE=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")
#        Windows PowerShell:
#          $env:JARVIS_VAULT_PASSPHRASE = node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
#
#      Option B: file under ~/.jarvis/ (preferred for interactive installs)
#        Linux/macOS:
#          node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" > ~/.jarvis/.vault-passphrase
#          chmod 0600 ~/.jarvis/.vault-passphrase
#        Windows (PowerShell — restricts to current user only):
#          node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" > "$env:USERPROFILE\.jarvis\.vault-passphrase"
#          icacls "$env:USERPROFILE\.jarvis\.vault-passphrase" /inheritance:r /grant:r "${env:USERNAME}:(R)"
#
#    BACK THIS UP SEPARATELY FROM `runtime.db`. If both are lost together
#    the vault contents (OAuth refresh tokens, api_token, etc.) are
#    unrecoverable. `jarvis doctor` reports which source it loaded.

# 5. [Optional] Migrate any plaintext secrets in config.json into the vault
#    On a fresh install config.json has no secrets to migrate yet — this is a no-op.
#    Run it if you manually added credentials to config.json before enabling the vault.
# npm run vault:cutover                # dry-run plan, no changes
# npm run vault:cutover -- --apply     # actually migrate; auto-backs up config.json

# 6. Start everything (daemon + dashboard)
npm start

Dashboard: http://localhost:4242

Finding your API token: The setup wizard (npm run jarvis setup) prints the generated API token once. It is also stored in ~/.jarvis/config.json under

api_token. In dev mode (default), read-only endpoints are accessible without a token. Operator and admin endpoints require the token in the

Authorization: Bearer <token> header.

jarvis doctor reports the vault state under "Vault Cutover" and "Vault Passphrase".

Rollback

If you need to downgrade after installing a new version:

1. Stop Jarvis: npm run jarvis -- stop (or kill the daemon process). 2. Restore the pre-upgrade backup: npm run ops:recover (choose the backup bundle from step 2 above). 3. Check out the prior release tag: git checkout <previous-tag> and reinstall: npm install. 4. Restart: npm start.

Rollback safety is currently backup/restore only unless a future release adds and tests per-migration down paths. See docs/REBUILD-ROLLBACK.md and docs/runbooks/jarvis-recovery.md for full recovery procedures.

Backup Before Upgrade

Always run a backup before any upgrade. Two pipelines are available:

• npm run ops:backup (legacy ops bundle) — bundles runtime.db, crm.db,

knowledge.db, ~/.jarvis/config.json, and plugin manifests under

~/.jarvis/backups/<timestamp>/. Integrity is verified via SHA256 checksums on restore (npm run ops:recover). Use this for in-place rollback on the same machine.

• npm run backup:create (workspace-aware snapshot, recommended for

disaster recovery) — uses VACUUM INTO for a transactionally consistent single-file snapshot per database and re-encrypts the vault contents to a portable backup key. Requires JARVIS_BACKUP_PASSPHRASE and produces a bundle that survives restore on a fresh machine (the legacy ops:backup bundle does not include the vault salt — see docs/KNOWN-TRUST-GAPS.md). Restore with

npm run backup:restore -- --snapshot=<dir>.

See docs/runbooks/backup-restore-drill.md for the drill procedure. Known limitations of both pipelines (no retention pruner, no down-migrations) are tracked in docs/KNOWN-TRUST-GAPS.md.

Quick Start

If you have Node 22 and Ollama already installed:

git clone https://github.com/dturcu/jarvis.git && cd jarvis
npm install
npm run jarvis setup      # initializes databases, builds dashboard, prints your API token
npm start                 # starts daemon + dashboard

Open http://localhost:4242 in your browser. Log in with the token printed by

npm run jarvis setup (also in ~/.jarvis/config.json → api_token).

> Time-to-hello-world estimate: > - With Node 22 + Ollama + a model already downloaded: ~5 minutes. > - Clean Windows box (install Node, install Ollama, pull a model): ~30-60 min (dominated by model download).

See the Requirements section for the full prerequisites and the Install section for the vault / backup steps needed for credential-backed agent runs.

Run Your First Agent

After the dashboard is open:

1. Click Home in the navigation bar — you will see the active agent cards. 2. Click orchestrator (or type a question in the chat bar at the top). 3. Enter a question that uses the ask.answer capability, for example: > "What is ISO 26262 Part 4 about?" 4. The agent runs locally using your Ollama / LM Studio model. The response appears in the chat panel. No cloud API is called.

If the agent times out with "No model runtime detected", install Ollama and run ollama serve, then pull a model:

ollama pull llama3.2        # Fast, good for most tasks (~2 GB)
ollama pull qwen2.5:14b     # Better reasoning, requires 16 GB+ RAM (~9 GB)

After the model is running, reload the dashboard.

Requirements

| Requirement | Minimum | Recommended | |---|---|---| | Node.js | >=22.5.0 | 22 LTS | | OpenClaw | ^2026.4.23 | Latest | | RAM | 8 GB | 16+ GB | | Disk | 2 GB free | 10+ GB | | Model Runtime | Ollama or LM Studio | Both |

Model Runtime

Jarvis needs at least one local LLM runtime:

• Ollama — Lightweight, CLI-based. Install and run: ollama serve
• LM Studio — GUI-based with model browser. Start the local server.

After installing, pull a model:

ollama pull llama3.2        # Fast, good for most agents
ollama pull qwen2.5:14b     # Better reasoning, needs 16GB+ RAM

Architecture

Jarvis is a plugin pack for OpenClaw. OpenClaw provides the chat OS layer (session routing, plugin lifecycle, tool execution, model abstraction, channel integration). Jarvis provides the domain plugin surface and async workers that sit on top. Current package, plugin, worker, and contract counts are generated in docs/reference/repo-inventory.md.

Channels (Telegram, CLI, Web, API)
        |
OpenClaw Gateway (WebSocket + HTTP)
  |-- Plugin Manager (generated plugin surface)
  |     |-- @jarvis/core        Planning, approvals, model selection
  |     |-- @jarvis/jobs        Job queue (submit, claim, heartbeat, callback)
  |     |-- @jarvis/dispatch    Cross-session messaging
  |     |-- @jarvis/agent       Agent registration and execution
  |     |-- @jarvis/office      Excel, Word, PowerPoint automation
  |     |-- @jarvis/device      Windows desktop automation
  |     |-- @jarvis/email       Gmail search, read, draft, send
  |     |-- @jarvis/calendar    Calendar intelligence
  |     |-- @jarvis/browser     Chrome automation
  |     |-- @jarvis/files       Safe file operations
  |     |-- @jarvis/system      System monitoring and platform hooks
  |     |-- @jarvis/inference   Local LLM routing
  |     |-- @jarvis/crm         CRM pipeline management
  |     |-- @jarvis/web         Web intelligence
  |     |-- @jarvis/document    Document analysis
  |     |-- @jarvis/security    Security monitoring
  |     |-- @jarvis/scheduler   Cron scheduling
  |     |-- @jarvis/interpreter Multi-step automation
  |     '-- @jarvis/voice       Voice I/O
  |-- Native Tools (browser, fetch, exec)
  '-- Agent Execution (TaskProfile -> model routing)
        |                       |
   LM Studio (:1234)     Ollama (:11434)

Data: ~/.jarvis/
  |-- runtime.db     Control plane (runs, approvals, jobs, model registry)
  |-- crm.db         CRM pipeline (contacts, notes, stages)
  |-- knowledge.db   Knowledge store (documents, entities, decisions)
  '-- config.json    Configuration

How It Works

1. Agents define what to do (system prompts, capabilities, approval gates, schedules) 2. Plugins registered in contracts/jarvis/v1/plugin-surface.json expose tools to agents via the OpenClaw plugin SDK (definePluginEntry) 3. Tools submit deterministic job specs to the job queue 4. Workers claim jobs via HTTP, execute, and return results via callback 5. Model routing matches agent needs (TaskProfile) to available local models (SelectionPolicy)

Execution Modes

Jarvis supports two execution modes:

• Claude Code mode — Agents run as Claude Code skills (.claude/skills/*.md), using MCP integrations (Gmail, Chrome, WebSearch) directly. Good for interactive use.
• OpenClaw mode — Agents run through the OpenClaw gateway with the full plugin stack, job queue, and worker pool. Good for autonomous scheduled execution.

The dashboard also provides two read-only copilot surfaces (/api/chat/telegram and /api/godmode) with their own LLM loops for interactive queries. These cannot mutate state or trigger agents — all mutations flow through the runtime kernel. See docs/ADR-CHAT-SURFACES.md for the architectural decision behind this.

Multi-Agent Cowork + Live Observability

Multi-agent workflows on a shared codebase are coordinated by the cowork-coordinator role, which decomposes a goal, spawns specialist sub-agents (code-reviewer, test-writer, refactor-applier, doc-writer, safety-auditor, compliance-auditor, investigator, make-test-pass) into isolated git worktrees, files handoffs to humans when ambiguous, and synthesises a unified result. See docs/ADR-COWORK-COORDINATOR.md for the full architecture.

The runtime emits AgentLoopEvents (iteration_start, model_call, tool_call, tool_result, subagent_start/end, final_answer, ...) as the loop runs. Three SSE endpoints surface them:

| Endpoint | Shape | Used by | |---|---|---| | GET /api/agent/runs/:id/events | Full event stream for one run; replays history then streams live deltas | VS Code extension chat panel, dashboard LiveTracePanel | | GET /api/cowork/stream?topics=handoffs,runs | Change notifications ({topic, signature}) when handoffs / agent_run_traces tables change | Dashboard /cowork page (lists) | | POST /api/agent/run | Kick off a runAgentLoop run; returns run_id immediately | Dashboard + New run button, VS Code extension runOnSelection / delegate commands |

A coordinator run is observable from any consumer that opens the SSE endpoint — including CLI runs (npm run smoke:cowork) that write to runtime.db without going through the dashboard process. The SSE handler falls through to the SQL trace tables for runs not in memory, so the same wire contract works for live and archived runs uniformly.

For a step-by-step demo, see docs/DEMO-COWORK.md.

Agents

Transitional active agents live in packages/jarvis-agents/src/definitions/. Archived domain agents remain importable for rollback and migration reference, but are hidden from default lookup and starter packs.

| Agent | Transition role | Default state | |---|---|---| | orchestrator | Internal routing/orchestration substrate while Core Router is rebuilt | Active | | knowledge-curator | Knowledge and memory substrate for Ask, Research, and Business modes | Active | | desktop-ops | Device substrate to be gated by the permission center | Active | | self-reflection, regulatory-watch, proposal-engine, evidence-auditor, contract-reviewer, staffing-monitor | v0.2 domain-agent references | Archived |

Maturity levels:

• high_stakes: Every mutating action requires human approval before execution
• gated: Runs but all outputs held for operator review before taking effect
• trusted: Runs autonomously; outputs reviewed post-hoc

Packages

The generated repo inventory lists every TypeScript workspace package, app/service package, internal dependency edge, TypeScript project reference, and source-import path alias.

Core & Framework

| Package | Purpose | |---|---| | @jarvis/shared | Base types, OpenClaw runtime foundation, gateway utilities | | @jarvis/core | Policy engine: planning, approvals, model selection | | @jarvis/agent-framework | Agent runtime, memory, knowledge, entity graph, lesson capture | | @jarvis/agents | Transitional active agent definitions plus archived domain-agent rollback references | | @jarvis/runtime | Standalone daemon for autonomous agent execution |

Infrastructure

| Package | Purpose | |---|---| | @jarvis/jobs | Job queue: submission, claiming, callbacks, retries | | @jarvis/dispatch | Cross-session messaging and follow-ups | | @jarvis/scheduler | Cron scheduling and alert management | | @jarvis/supervisor | Agent supervision and governance | | @jarvis/inference | LLM inference coordination and model routing | | @jarvis/interpreter | Code/prompt interpretation | | @jarvis/security | Security policies and validation | | @jarvis/system | System monitoring (CPU, memory, disk, processes) | | @jarvis/voice | Voice I/O (Whisper STT, Piper TTS) | | @jarvis/device | Device integration and notifications |

Plugins (Agent-Facing Interfaces)

| Package | Purpose | |---|---| | @jarvis/agent-plugin | Agent orchestration plugin | | @jarvis/email-plugin | Email operations (Gmail) | | @jarvis/calendar-plugin | Calendar operations | | @jarvis/crm-plugin | CRM pipeline management | | @jarvis/web-plugin | Web intelligence and scraping | | @jarvis/document-plugin | Document analysis and compliance checking |

Workers (Async Job Processors)

| Package | Purpose | |---|---| | @jarvis/agent-worker | Agent execution | | @jarvis/email-worker | Email sending/receiving | | @jarvis/calendar-worker | Calendar sync | | @jarvis/crm-worker | CRM operations | | @jarvis/web-worker | Web scraping and search | | @jarvis/document-worker | Document processing | | @jarvis/browser-worker | Chrome automation | | @jarvis/office-worker | Office document handling | | @jarvis/inference-worker | LLM inference execution | | @jarvis/interpreter-worker | Code/prompt execution | | @jarvis/security-worker | Security checks | | @jarvis/system-worker | System commands | | @jarvis/voice-worker | Voice I/O processing | | @jarvis/social-worker | Social media monitoring | | @jarvis/time-worker | Time/timezone utilities | | @jarvis/drive-worker | Google Drive monitoring | | @jarvis/desktop-host-worker | Windows desktop automation |

Services

| Package | Purpose | |---|---| | jarvis-dashboard | Web dashboard (React) at http://localhost:4242 | | jarvis-telegram | Telegram bot integration | | @jarvis/browser | Chrome DevTools Protocol integration | | @jarvis/office | Office (Word, Excel, PowerPoint) operations | | @jarvis/files | File system operations |

Contract System

All job types, tool responses, and worker callbacks conform to the jarvis.v1 contract — a frozen JSON Schema specification.

• Generated inventory via npm run repo:inventory records the current job catalog entries, job-type schema families, examples, and worker callback fixtures.
• Schema validation via npm run validate:contracts validates all schemas and contract examples against full envelope/result schemas.
• Contract files live in contracts/jarvis/v1/

Job Lifecycle

Agent calls tool -> submitJob(type, input)
  -> Job queued in SQLite (status: queued)
    -> Worker claims via POST /jarvis/jobs/claim (status: running)
      -> Worker sends heartbeats to renew lease
        -> Worker posts result to POST /jarvis/jobs/callback (status: completed|failed)
          -> Agent notified via dispatch

Versioning Rules

• Additive optional fields are allowed within v1
• Breaking changes (field meaning, required fields, enum values, job types, tool names) require v2

Approval Rules

High-stakes actions require human approval before execution. Approval categories are enforced by runtime policy and architecture tests; current job catalog size is generated in docs/reference/repo-inventory.md.

| Approval | Examples | |---|---| | Required (always) | email.send, device.click, device.type_text, python.run, security.lockdown, calendar.create_event | | Conditional (policy-gated) | crm.move_stage, document.generate_report, device.open_app, files.write | | Not required (read-only) | email.search, crm.list_pipeline, device.snapshot, system.cpu_usage |

Agents with high_stakes_manual_gate maturity require approval for every mutating action.

CRM Pipeline

prospect -> qualified -> contacted -> meeting -> proposal -> negotiation -> won | lost | parked

Stage transitions require approval (warning severity).

Dashboard

Start the web dashboard:

npm run dashboard          # Production (http://localhost:4242)
npm run dashboard:dev      # Development (API :4242, UI hot-reload :4243)

Pages: Home (agent cards), CRM Pipeline (kanban), Knowledge Base (search), Decisions (audit trail), Schedule (cron tasks).

Dev Mode Ports

| Mode | URL | Notes | |---|---|---| | Production / npm start | http://localhost:4242 | Serves built static assets from dist/ | | Dev hot-reload / npm run dashboard:dev | http://localhost:4243 | Vite dev server; proxies /api to :4242 |

npm run dashboard:dev requires the daemon (:4242) to be running. The Vite server at :4243 only serves the UI; all API traffic is proxied. See packages/jarvis-dashboard/vite.config.ts for the proxy configuration (server.port = 4243).

Telegram Bot

Get agent updates and approve actions from Telegram. See docs/USAGE.md for setup instructions.

Available commands: /status, /crm, /approve <id>, /reject <id>, /help. Registry-backed mode commands appear only after their capabilities are marked available.

CLI Reference

# Getting Started
npm run jarvis setup          # Interactive setup wizard
npm run jarvis -- doctor      # Check system health
npm run jarvis -- doctor --fix  # Auto-fix what's possible
npm run jarvis -- config      # View configuration

# Running
npm start                     # Start daemon + dashboard
npm run daemon                # Start daemon only
npm run dashboard             # Start dashboard only

# Operations
npm run ops:health            # Ops health check
npm run ops:backup            # Create backup bundle (in-place rollback)
npm run ops:recover           # Restore from ops:backup bundle
npm run backup:create         # Workspace-aware portable snapshot
                              #   (requires JARVIS_BACKUP_PASSPHRASE;
                              #    safer for fresh-machine restore)
npm run backup:restore        # Restore from backup:create snapshot
                              #   (--snapshot=<dir> required)

Security

Jarvis is designed as a local operator appliance, not a cloud service.

• Localhost by default: Dashboard API binds to 127.0.0.1 (override with JARVIS_BIND_HOST)
• Token auth: API requires Bearer tokens. init-jarvis.ts generates one automatically on first run
• Fail-closed: Production/appliance mode blocks startup without tokens. Dev mode allows read-only access only
• Appliance mode: Set appliance_mode: true in config for strict enforcement (tokens required, webhook secrets checked)
• No side-door execution: Chat and Telegram surfaces are read-only — no shell, file writes, or email sending. All mutations flow through the approval-backed runtime kernel
• Rate limiting: Auth failures trigger IP blocking after repeated attempts

See docs/THREAT-MODEL.md for trust boundaries and docs/KNOWN-TRUST-GAPS.md for what's not yet enforced.

Configuration

Config lives at ~/.jarvis/config.json. The init script creates it with a secure token. Use the setup wizard to add integrations:

{
  "api_token": "generated-on-init",
  "lmstudio_url": "http://localhost:1234",
  "default_model": "auto",
  "adapter_mode": "real",
  "poll_interval_ms": 60000,
  "max_concurrent": 2,
  "log_level": "info",
  "appliance_mode": false
}

Environment variables override config file values. See .env.example for all options.

Development

npm run check              # Full pipeline: contracts + tests + build
npm test                   # Run tests (see npm run check for current count)
npm run build              # TypeScript compilation
npm run validate:contracts # Schema + example validation
npm run dashboard:dev      # Dashboard dev mode (hot reload)
npm run smoke:runtime      # OpenClaw + LM Studio integration smoke test

Docker

# Build and run
docker compose up -d

# Jarvis connects to Ollama/LM Studio on the host machine
# Make sure your model runtime is running before starting

Troubleshooting

"Jarvis cannot start -- setup required" Run npm run jarvis setup to initialize databases and config.

Dashboard shows "Not Built" page Run npm run dashboard:build then refresh.

"No model runtime detected" Install Ollama and run ollama serve, or start LM Studio.

Agent run times out on approval Check the dashboard approvals page, or use the Telegram bot to approve/reject.

Database corruption

npm run ops:backup         # Backup current state
npm run jarvis -- doctor --fix  # Attempt auto-repair
# If that fails, delete and reinit:
#   Linux/macOS:
#     rm ~/.jarvis/runtime.db
#   Windows PowerShell:
#     Remove-Item "$env:USERPROFILE\.jarvis\runtime.db"
npm run jarvis setup

Port 4242 already in use Set PORT=4243 in your .env file.

For more help: npm run jarvis -- doctor

Documentation

| Document | Description | |---|---| | CHANGELOG.md | Version history and notable changes | | USAGE.md | Detailed agent usage with examples, Telegram setup, CRM guide | | ARCHITECTURE.md | Five-plane architecture, database layout, execution model | | PRODUCTION-TARGET.md | Deployment model, trust boundaries, non-goals | | RELEASE-GATES.md | Five release gates (A-E) with pass criteria | | THREAT-MODEL.md | Trust boundaries, attack vectors, security invariants | | KNOWN-TRUST-GAPS.md | Honest list of what's not yet enforced | | REBUILD-RELEASE-NOTES.md | v0.3 rebuild release narrative, hardening evidence, and boundaries | | REBUILD-MIGRATION.md | v0.3 migration shape and data migration limits | | REBUILD-ROLLBACK.md | v0.3 rollback procedure and backup/restore-only safety evidence | | ADR-CHAT-SURFACES.md | Why chat/godmode have separate LLM loops | | OPERATOR-RUNBOOK.md | Secure installation, daily ops, failure recovery | | GLOSSARY.md | Canonical vocabulary (agent, plugin, worker, job, run, etc.) | | WHAT-JARVIS-IS-NOT.md | Explicit non-goals and boundaries | | LIFECYCLE-DIAGRAMS.md | Mermaid state machines for runs, approvals, jobs | | ARCHITECTURE-STATUS.md | Target design vs shipped implementation comparison | | alpha-operating-guide.md | Daily workflow, failure taxonomy, metrics |

Specs

| Spec | Description | |---|---| | jarvis-plugin-api-v1.md | Plugin SDK contract and tool registration | | jarvis-device-agent-v1.md | Device control plugin specification | | local-model-runtime-strategy.md | LM Studio/Ollama integration and model selection | | v1-workflows.md | Five production workflows |

Runbooks

| Runbook | Description | |---|---| | jarvis-recovery.md | Recovery procedures, backup/restore | | openclaw-lmstudio-smoke.md | Integration smoke test harness | | ROLLOUT-B5.md | B5 staged enforcement rollout runbook (Weeks 6–8 flag flips) |

License

MIT - Thinking in Code (Daniel Turcu)