Autonomous dev machines that monitor themselves, heal themselves, and phone home with a status page you can check from your phone.
A fleet of autonomous dev machines building software around the clock. But when something breaks at 2 AM, nobody knows until morning.
word4, botslack, openM365, safeguard, universal-app — all running autonomously with no unified view of what's happening.
A missing Python package kills a container. A stale lockfile halts a build. Hours of compute wasted before anyone notices.
Checking machine status meant SSH into the host. No way to glance at fleet health from a phone or another machine.
The machines were already building software autonomously. But they were like factories with no control room — productive when everything worked, helpless when anything broke.
Full-stack web dashboard: FastAPI backend, 2,253-line SPA frontend, streaming chat panel with markdown rendering.
15 Python modules (3,404 LOC), single-page app with live status polling, fleet summary bar, per-machine drill-down, and one-click actions: restart, push, clear blockers.
Streaming chat interface with SSE architecture, live activity indicators, and markdown rendering. Ask the dashboard about your machines in natural language. Backed by a dedicated minimal Amplifier bundle.
Responsive design. Check fleet health from your phone over Tailscale.
v1 (Docker polling + fleet-state.json) and v2 (status.yaml + fleet-status.yaml). Auto-prefers v2 when available.
Runs as dev-machine-monitor CLI or auto-discovered as an amplifierd plugin via entry points.
The 2,325-line fleet-supervisor was a single process doing everything. The new architecture splits concerns cleanly.
Runs on each machine. Writes status.yaml with health, features, problems, git HEAD age.
Reads all status files. Applies cross-fleet sanity checks. Writes fleet-status.yaml. Sends alerts.
Serves the SPA. Reads fleet-status. Provides API endpoints. Hosts the chat panel.
The fleet coordinator never starts or stops containers. It is strictly read-only on the fleet. All writes go to coordinator-owned files: fleet-status.yaml, digest-queue.jsonl, last-alert.json. Alerts deduplicate on a 1-hour cooldown per condition key.
Every machine reports one of 9 v2 status values. The dashboard maps them to 5 visual buckets for instant comprehension.
Running, building, committing.
Degraded but still active. Includes recovering.
Critical. Needs human attention now.
Paused, completed, or blocked on escalation.
Top-of-page summary with dot counts: how many machines are healthy, warning, critical, stopped, offline. Auto-refreshes every 120 seconds. One number tells you if the fleet needs attention.
Alert history from digest-queue.jsonl with repeat counts and condition deduplication.
Two layers of auto-recovery: Pattern I for container-level crashes, and the env-remediation agent for intelligent diagnosis.
Detects crash loops and missing packages directly from container logs. Identifies the failing import, runs pip install or uv sync, and restarts the container — all without human intervention.
ModuleNotFoundError from log outputAn AI agent (288 lines of protocol) that reasons about broken environments instead of just matching regexes. Two-phase: fast-path catalog lookup, then independent diagnosis.
The agent may modify lockfiles, reinstall node_modules, recreate .venv, or apt-get install missing system tools. It may never touch application source code. If it can't fix the environment in 3 tries, it escalates with a structured report of what it tried and what it learned.
Tests passing is necessary but not sufficient. The intent gate checks whether a feature actually serves the claimed user story.
Build and test succeed. The code works mechanically. But does it serve the human's intent?
The intent-gate-agent reads PROJECT-INTENT.md, the feature spec's Section 0, implementation summary, and test results. Cross-references claimed story against actual evidence.
PASS or FAIL with specific evidence: CLAIMED_STORY, EVIDENCE, GAPS, STORIES_ADVANCED, STORIES_REMAINING, FEEDBACK. Incremental progress counts — practical, not pedantic.
No PROJECT-INTENT.md? Gate auto-passes with a note. Missing Section 0 in the spec? Hard FAIL with instructions to add it. The gate adapts to the project's maturity.
TLS, Caddy reverse proxy, heartbeat agent, API key auth. The dashboard is accessible anywhere on your Tailscale network.
Runs on remote hosts, pushes machine status to a central hub every 60 seconds. Supports continuous mode or single-shot for cron. Auto-registers discovered machines with TTL-based expiry.
Local mode: 127.0.0.1, no TLS, no auth. Serve mode: auto TLS (Tailscale certs or self-signed), bearer token auth, Caddy forward_auth integration with Frontdoor.
Monitor binds localhost. Caddy terminates TLS on a Tailscale FQDN port. systemd service unit keeps it alive. One command to update: uv tool install --force.
The earlier story was about proving a dev machine could ship. This story is about what happens when you have five of them and need to keep them alive.
The foundry doesn't just create dev machines anymore. It creates dev machines that can reason about their own health, fix their own environments, and phone home when they need help. The dashboard is the human's window into a fleet that increasingly manages itself.
Repository: amplifier-bundle-dev-machine (github.com/ramparte/amplifier-bundle-dev-machine)
Primary contributors: Marc Goodner (robotdad) — 53 commits, Sam Schillace — 16 commits
Commit data (60-day window ending May 20, 2026):
git log --oneline --since="60 days ago" --no-merges | wc -l → 70 commitsgit log --format='%an' ... | sort | uniq -c | sort -rn → Marc Goodner: 53, Sam Schillace: 16, ramparte: 1git diff --stat <60d-ago>..HEAD -- dashboard/ agents/ monitor/ → 58 files changed, ~14,400 insertionsLine counts (measured via wc -l / find ... | xargs wc -l):
find dashboard/src -name "*.py" | xargs wc -lwc -l dashboard/src/.../static/index.htmlgrep -c "def test_" dashboard/tests/*.pyfind monitor/ -name "*.py" | xargs wc -lwc -l agents/*.mdArchitecture claims verified by reading:
dashboard/README.md (354 lines) — dual data source, v2 status mapping, API endpoints, deploymentmonitor/fleet-coordinator.py (434 lines) — 4 sanity checks, read-only design, alert dedupmonitor/fleet-config.yaml (43 lines) — 5 registered machines confirmeddashboard/src/dev_machine_monitor/health.py — 9 v2 status values, 5 dashboard bucketsagents/env-remediation-agent.md (288 lines) — 3-attempt limit, scope boundaries, discovery loopagents/intent-gate-agent.md (223 lines) — 6-step evaluation, structured verdict formatDate: May 2026 · Category: Showcase