v0.3.1 — phone remote, one-click local AI, install anywhere

0.3.1

• Fix: the running version is now the release tag (Settings and the update check showed a hard-coded 0.1.1).

• Fix: scripts/build-agent-images.sh --sync-only runs without a .env —
  the release build in a fresh checkout stopped with exit 2 before any image
  was built.

v0.3.0 was tagged but its image build failed before any image existed; it
was never published (no images, no GitHub release). Tags are protected, so
the fix ships as 0.3.1. Everything below is part of 0.3.1.

Included from 0.3.0

The release behind the new README: Mission Control as a phone remote for
coding agents on your own models, and a fresh install that works again
from zero on Linux, macOS and a Raspberry Pi.

Highlights

• The chat is your remote control (ADR-090): live tool output and a diff
  per edit, a Changes panel with Revert / Commit / Open PR, the agent's todo
  list as the task checklist, tool screenshots, question cards and plan
  mode for omp agents (ask → tap → it continues; plans wait for approval).
• One-click DGX Spark recipe: GLM-5.3-Flash (EXL3 4-bit, TensorFold) on
  two boxes from the Runtimes page; switch lock while serving; credits in
  CREDITS.md.
• Optional live voice in the chat (preview, ADR-091): talk to the agent,
  stop it by voice, a daily budget, silence and max-length hang-up, cost in
  Insights.
• Fresh install fixed (ADR-092): the installer installs the latest
  release — code and prebuilt images of the same version, amd64 and arm64;
  prerequisites checked in one pass; headless servers get the first admin
  in the terminal before MC is opened to the network; Linux runs as your own
  user id (PUID/PGID); the setup wizard opens by itself after the first
  login; release images are verified before they are tagged.

Security

• The host helper (cli-bridge.py) listens on 127.0.0.1 only and requires
  a shared token (HTTP and WebSocket).
• SSH host keys are pinned on first use; a changed key is refused before any
  password is sent.
• 422 validation errors no longer echo the submitted input (passwords,
  tokens, credentials).
• The login screen no longer shows a fixed location.

Upgrade notes

• Existing installs: update with
  curl -fsSL https://raw.githubusercontent.com/argyelan-ai/mission-control/main/install.sh | bash -s -- --update.
  Migrations run on start (up to 0216).
• After updating, reinstall the host helper once: make bridge-install
  (it replaces an older hand-made service and creates the token).
• One-off commands into the backend now need -u mcuser
  (docker compose exec -u mcuser backend …).

Further changes since 0.2.0

Added

• Disk preflight in front of every build, plus a watchdog that reports
  before the disk hits 95 %. docker system df measured 75.8 GB of build
  cache — Docker never garbage-collects it on its own — and
  docker compose up --build then died mid-layer-write with a raw
  "no space left on device", after minutes of work and with nothing pointing
  at the cause. Every build path (make up/build/build-dev, install.sh,
  scripts/start-all.sh --build, scripts/build-agent-images.sh,
  scripts/vault-cleanup-orchestrate.py, the backend's compose recreate
  paths) now runs docker/shared/disk-preflight.sh first and refuses below
  the threshold with both numbers, the variable that set it, and the fix in
  the message; after a SUCCESSFUL build it bounds the build cache with
  docker builder prune --keep-storage. An unreadable df never blocks a
  build (unknown is not zero). Thresholds come from the project's config path
  (BUILD_MIN_FREE_GB / BUILD_CACHE_KEEP_GB / DISK_WATCHDOG_PERCENT),
  never hardcoded. The watchdog reports only — it never deletes anything
  and never changes a status; it fires at DISK_WATCHDOG_PERCENT (default
  95) with severity=critical (a warning would wait up to 30 minutes in
  the Discord digest) and is deduped per threshold via Redis.
• Lead-escalation second stage. A stage-1 lead message
  (watchdog_notify from the silent-card watchdog, blocker_lead_notify
  from blocker lead-triage) that got no Board-Lead reaction for 30
  minutes is reported to the operator — exactly once per silent phase.
  "Reaction" is explicit: a Lead-authored comment on the card or a
  Lead-authored status change after the message. Report-only: pending
  lead_escalation approval + push, no status change, no new schema.
• Silent-card watchdog. Cards in in_progress or waiting with no
  agent turn and no (non-system) comment for 30 minutes are reported once
  to the Board Lead via watchdog_notify. Status is never auto-changed.
  One message per silent phase (DB-dedup, not a Redis TTL).
• ACP is an omp-harness property (ADR-084, supersedes ADR-081). The
  driver decision moved from the OMP_ACP_AGENT_SLUGS name list to
  harness_compat.omp_driver_for(harness) — every omp agent, including one
  created minutes ago, runs the ACP path. The single rollback knob is
  OMP_DRIVER_DEFAULT=native (whole fleet); a per-service
  OMP_DRIVER=native entry still survives re-rendering. New
  HARNESS_CAPABILITIES matrix consolidates the scattered per-harness
  conditions (hooks/statusLine, shared-mcp, host launcher, plugin/skill
  support), and switching to a pluginless harness now warns visibly in the
  switch result. Tier-2 recovery skips omp/ACP agents via the harness, the
  explicit RECOVERY_TIER2_SKIP_AGENT_SLUGS opt-out stays for host agents.

Changed

• Security: terminals, the plugin shell and typing into a live agent
  session are admin-only. Before, any logged-in user of any role (viewer
  included) could open an agent container or host-agent terminal, the plugin
  shell, or type text/keys into an agent's tmux pane through the Sessions
  chat — all of it command execution on the box. The WebSockets
  (/agents/{id}/terminal, /agents/{id}/terminal/ws,
  /agents/{id}/terminal/{task_id}/ws, /host-agents/{id}/terminal,
  /plugins/shell/ws) now close with 4003 for non-admins (4001 stays
  "not logged in"); the HTTP endpoints (POST /agents/{id}/terminal/{task_id}/input,
  DELETE /agents/{id}/terminal/{task_id}, POST|DELETE /plugins/shell,
  POST /agents/{id}/chat/input|keys|effort) answer 403. Shared helpers
  auth.has_role / auth.authorize_websocket sit next to require_role.
  Reading stays open: chat history, session lists and the view-only browser
  live stream are unchanged. DELETE /plugins/shell was shadowed by the
  catch-all DELETE /plugins/{plugin_key:path} (it reached
  remove_plugin("shell")); the shell routes are now registered first. No
  agent or service token calls any of these endpoints, so no exception was
  needed. The UI shows a short hint (EN/DE) instead of the terminal, the
  plugin shell and the chat composer for non-admins. Plugin keys in
  POST /plugins/install, POST /plugins/{key}/update and
  DELETE /plugins/{key} must now look like name@marketplace (400
  otherwise): a key like shell%23 was cut at the # on its way to the
  bridge and started/stopped the plugin shell on the plain login. Scope: this
  gates terminals, the plugin shell and keystrokes only. Plugin
  install/update/remove, agent provisioning and container/host-agent
  start/stop/restart still run on the plain login (follow-up).

• Your agent fleet leaves version control.
  docker/docker-compose.agents.yml describes your machine — agent names,
  project references, mount paths — and Mission Control rewrites it while it
  runs. It sat in the repo anyway, so every commit published its author's
  fleet. Shipped from now on is the agent-free template
  docker/docker-compose.agents.example.yml; setup.sh makes your copy from
  it, and the copy is git-ignored.

  Upgrade note for existing installs (one time, required): a plain
  git pull either deletes your file without a word or refuses to run — so
  ./install.sh --update on the installer you currently have stops at the
  pull. Carry your fleet across by hand once:

  cp docker/docker-compose.agents.yml ../my-agent-fleet.yml
  git checkout -- docker/docker-compose.agents.yml
  git pull --ff-only
  cp ../my-agent-fleet.yml docker/docker-compose.agents.yml

  Your hand-added mounts survive that; the renderer would not have recreated
  them. From then on ./install.sh --update wraps every pull in
  scripts/migrate-agents-yml.sh save / restore and you never think about
  it again. Details: docs/setup/updating.md.

• The file indexer no longer holds a database transaction while it walks
  the filesystem. The periodic walk (every 600 s, all ~/.mc roots) used
  to run inside one session — measured on 2026-09-14 as the oldest open
  transaction in the database (1789 s; a backend restart alone did not clear
  it, the worker had to die too). The walk now runs with no session open and
  writes in short committed batches (longest open transaction on the same
  data set: 33.8 s → 0.7 s). Its 50 000-entry cap comes with a real
  exclusion list (build/test noise: target, venv, .pytest_cache,
  .gradle, out, coverage caches, *.egg-info, …, matched
  case-insensitively) so the cap is not hit every round by counting noise —
  and if it is hit, the warning fires once per state with the count and the
  root instead of an identical line every 600 s.

Removed

• Board groups are gone — migration 0209_drop_board_groups DROPS the
  board_groups table and the column boards.board_group_id. Board groups
  had an API (/api/v1/board-groups*) but no page, script or row. Removed in
  the same change, all without a caller: phase create/edit/delete
  (POST /api/v1/projects/{id}/phases, PATCH/DELETE /api/v1/projects/{id}/phases/{phase_id} — listing and completing phases
  stay), the board-scoped approval list GET /api/v1/boards/{id}/approvals
  (the inbox reads /api/v1/approvals)...

v0.2.0 — install anywhere, first agent without a build

Release highlights

• Problem-first README with a platform matrix (Linux/NAS, Runtipi, Portainer, macOS, Windows via WSL2, Windows Server/ESXi) and an 18-page user handbook (docs/handbook/)
• Prebuilt agent images on GHCR — mc-claude-agent and mc-agent-base ship multi-arch (amd64+arm64); your first agent no longer needs a local Docker build
• make bridge-install — the cli-bridge provisioning helper runs as a supervised service (launchd/systemd) instead of a hand-held terminal
• setup.ps1 is a Windows WSL2 bootstrapper — checks/installs WSL2 + Docker Desktop, then runs the standard installer; verified end-to-end on real hardware
• Demo crew — a fresh install seeds four named agents with assigned tasks, so the board looks alive from minute one
• Agent archive/restore fixed (was a guaranteed 500), wizard fully English with a German locale, fresh screenshots, compose no longer inherits the maintainer's host layout

Upgrading an existing install with a local agent fleet: run ./scripts/build-agent-images.sh once after pulling (dual-tags your local builds so they shadow the registry pull), or pin MC_AGENT_IMAGE_PREFIX="" in .env.

Full details: CHANGELOG.md

v0.1.1 — App-store packages & catalog-friendly secrets

Added

• App-store packages (deploy/catalogs/) — prepared submissions for
  Umbrel (digest-pinned multi-arch images, exports.sh secret derivation)
  and Runtipi (custom-store layout), plus a Portainer template and a fixed
  CasaOS manifest. All bundle a small Caddy proxy: the prebuilt frontend
  makes same-origin API calls, so /api/* must be routed alongside it.
• Makefile — self-documenting entry points (make help): setup, up,
  test, build, seed, update.
• Dev/release Docker targets — make build-dev builds backend/frontend
  images with hot reload and test extras; untargeted builds stay production.
• Vertical tutorial — docs/setup/build-a-vertical.md
  (community contribution, #9).
• README: full feature list, supported-runtimes matrix, live sessions
  screenshot.

Changed

• SECRETS_ENCRYPTION_KEY may now be any passphrase — the backend derives
  a proper Fernet key from non-Fernet values (app-store installs can only
  supply random strings). Existing valid keys are used unchanged.

Fixed

• Watchdog: review-stuck escalation no longer fires for tasks on archived
  boards.
• CI: all actions SHA-pinned (org policy); leak gate runs the license-free
  gitleaks CLI, digest-pinned.

v0.1.0 — Initial public release

Initial public release. 🎉

Highlights

• Multi-runtime agent fleet — CLI agents in Docker (Claude Code or any
  OpenAI-compatible runtime via the omp bridge) plus optional host-side
  agents, all dispatched through a poll-based lifecycle with ACK handshake,
  review gates and a safety watchdog (silent-abort auto-block, ADR-046).
• Boards & pipeline view — tasks flow inbox → in_progress → review →
  done across swim lanes; phase-based orchestration with a board lead that
  plans, delegates and reviews.
• Runtime switching — move an agent between LLM runtimes (Anthropic ↔
  local vLLM/LM Studio/Ollama) with one PATCH; containers are recreated
  atomically with rollback (ADR-027/028).
• Agent git workflow — repo per project, branch per task, PR on review,
  squash-merge on approve.
• Knowledge base & memory — board memory, agent lessons, global
  knowledge with timeline view; optional Obsidian vault export.
• Secrets vault — encrypted provider keys (Fernet), agent tokens hashed
  with PBKDF2, scope-based agent permissions (16 scopes).
• Security posture — backend reaches Docker only through a filtering
  socket-proxy (ADR-047); lean-core default boot with voice/browser
  compose profiles; honest threat model in SECURITY.md.
• One-line install — curl -fsSL .../install.sh | bash checks
  prerequisites, pulls the prebuilt GHCR images (multi-arch, local build
  as fallback), boots, migrates and opens the browser; install.sh --update updates an existing install. CI runs the installer end-to-end
  on every push (empty DB → full migration chain → first API call).
• First-run wizard — registering the first admin lands in a guided
  setup: connect an LLM provider key (encrypted vault), seed a demo
  board, provision the first agent.
• Update story — the UI hints when a newer release exists (daily
  check, silent offline); pin versions via MC_IMAGE_TAG.
• Windows (experimental) — WSL2 path or native PowerShell
  (setup.ps1); see docs/setup/windows.md.

Notes

• Licensed under AGPL-3.0: free to use, self-host and modify; modified
  versions offered as a service must be published under the same license.

• Parts of the UI and code comments are German (the project's working
  language) — see the language note in the README.

• The private development history is not part of this repository; releases
  are published as sanitized snapshots (see docs/decisions/043).