Jarvis Engine

Status, plainly: the engineering underneath is built and heavily tested. Most AI-facing features exist but are off or tested only against fakes. Jarvis is not “live” until it passes an approved audit, a qualified release, and seven real-machine checks. It hasn’t yet.

What it is

Jarvis is an always-on helper for my AITOOLS workspace. It observes my projects without changing them, shows their status on a dashboard, supervises approved helper processes, routes alerts to me, and holds anything risky in an approval queue.

The rule the whole design hangs on:

AI may assist with decisions and work, but it must not silently acquire control of the engineering environment.

Two trust domains

The development tools (Claude Code, under my direction) can change AITOOLS projects. The running Jarvis watcher cannot. It can look, run approved read-only Git checks, and report. It doesn’t treat seeing a repository as permission to run code in it, and it doesn’t “fix” things it notices.

These are separate trust domains on purpose, not contradictory rules.

What’s in it

Design decisions worth showing

The architecture is governed by numbered decisions (D1 to D34) in a separate AITOOLS-PROTOCOL project. A few that shape the system:

Approvals bind to exact content

A vague “yes” can’t be applied to something else. Approvals are tied to the exact proposal and files, expire, can’t be replayed, and an unanswered one stays held. Pause survives restarts.

Without a new approval, Jarvis may only send its own health check-ins, alert me on channels I already authorized, use an AI provider inside an approved budget, and restart already-approved helpers. Contacting anyone, publishing, spending, starting a new program, or writing outside its own state all require me.

Helpers get supervised, not trusted

• Checked every five minutes.
• Restarted only on their already-approved version.
• Six crashes in an hour and automatic restarts stop.
• Jarvis never edits its own code or config to recover.
• A failure produces a plain-language suggested fix, without an AI call.

Known limit: a process being alive doesn’t mean it’s healthy. A hung helper can look fine.

Outbound connections are capped

At most four simultaneous outbound connections for email, push, watchdog, digests, and Claude calls. A connection holds its slot until the underlying operation actually ends, because a Python timeout doesn’t reliably kill a stuck DNS lookup.

In testing, 20 stalled DNS operations never produced more than four worker threads; the other 16 were refused immediately instead of piling up.

Honest limits: the pool is per process; a send that timed out may still have arrived, so exactly-once delivery isn’t assumed; and if all four slots stall, even the heartbeat waits, which is exactly when the external watchdog should notice.

Privacy-aware AI routing

Free-tier providers (Groq, Cerebras, OpenRouter free models) come first for general work. Sensitive material, including AITOOLS code, work data, and private memory, never goes to free providers automatically. Claude is reserved for private work. Local inference is its own lane with its own trust assumptions. No spending before v1.

Credentials go into Windows Credential Manager through a one-time script, never into source or prompts.

Filesystem guards

Jarvis’s own state writes are checked against junctions, symlinks, redirected folders, unsafe database paths, and paths that lead back into AITOOLS, including AITOOLS mounted on an unexpected drive letter.

Releases you can roll back

Each release is an immutable versioned folder, with a current junction pointing at the active one. Backups are nightly, encrypted with a key I control, keeping the last 14, and verified on restore: wrong keys, modified backups, and disallowed paths are all rejected in testing. The crypto was checked against known test vectors.

The website prospecting team

A Jarvis subsystem built on October 21, 2026: find candidate websites, score their weaknesses in an explainable way, generate an example page and a draft, and drop it in my approval queue.

It never contacts anyone. Approving a draft doesn’t send it. Generated pages are escaped and script-free. The workflow passes its tests with fixtures, but real search, page fetching, rendering, and AI connections are deliberately stubbed out until I decide on sources, budgets, and wording.

How it gets built

Architecture + decisions
        ↓
Claude Code builds + tests + handoff
        ↓
Codex independent audit ──NEEDS CORRECTIONS──→ fix, re-audit
        ↓ READY (unqualified)
Release tag → staged deploy → real-machine go-live checks

“READY WITH MINOR FIXES” doesn’t count. The same agent never gets to be both author and judge.

Test history

Plus PowerShell 5.1 and 7 script checks, 200-iteration CLI stress runs, and roughly 30-minute soak tests that confirmed the watched repositories were unchanged afterward.

Passing tests is development evidence. It isn’t production acceptance.

Timeline

What’s next

1. Codex audit of the A1-06 fix, needing an unqualified READY.
2. Tag v1.0.1 and deploy.
3. The seven go-live checks on the real machine, including: acknowledging an urgent alert on my phone, getting notified when the watchdog misses a check-in, a real backup and restore, and unplugging the AITOOLS drive to see what Jarvis does.

Until those pass, Jarvis is a well-tested release candidate, not a running service.