Dicklesworthstone/frankenterm

-purple.svg)
What's here
| If you're... | Start with |
|---|---|
| Trying it out | 10-Minute Tour → Commands → Robot Mode |
| Building a meta-agent | Robot Mode → Sample Mission/Tx Contracts → Operating Envelope |
| Operating at scale | Capacity Planning → Operator Playbook → Troubleshooting |
| Understanding how it works | Architecture → System Components → Deep Dives |
| Auditing the claims | Trust & Attestation → Threat Model → Formal Methods |
| Reading the algorithms | Algorithm & Data Structure Catalog → Pattern Engine → Cx Cancellation Model |
**A swarm-native terminal platform designed to observe, control, and audit large fleets of concurrent AI coding agents.** The retained 200-pane figures are synthetic benchmark-lane results, not a qualified native or target-class operating envelope. 83 workspace crates, 19 sub-crates carved out of the core, 536 core-library modules, 1346112 + lines of Rust, 60535 + test annotations across 1042 integration test files.
_Counts are auto-stamped by scripts/stamp-readme-counts.sh and drift fast. See Maintainers: how counts stay honest at the bottom for the exact recipe. Developer checks use the live worktree by default; release snapshots use --source=head so unrelated dirty files cannot alter the attested counts._
Quick Install
The installer verifies the DSR-published checksum and minisign signature, then
publishes ft, the mux server, the PTY guardian, and (on Apple-Silicon macOS)
a verified FrankenTerm.app candidate as one manifest-bound generation. On an
idle first install, the standalone process family is promoted automatically
through a selector-last transaction and must pass ft doctor --json; otherwise
the transaction rolls back. Active or ambiguous hosts retain a pending
candidate, as do upgrades unless --activate-if-idle is requested. In that
case, use the receipt's exact next_action command after every old GUI, mux,
guardian, and watcher has stopped. This maintenance activation is
crash-resumable, but it does not preserve live panes. The macOS GUI app remains
a separately verified candidate until its cross-launcher lifecycle and PTY
handoff transaction is production-proven. Only a current process-family
receipt authorizes ordinary ft --version and ft doctor through PATH; the
same JSON is retained at
~/.local/bin/.frankenterm-process-family/install-receipt.json for audit and
automation.
Pane/session operations require a reachable FrankenTerm/WezTerm-fork mux
endpoint. Native vendored builds prefer the direct pooled mux protocol; the
external wezterm CLI is a compatibility fallback, not a universal
prerequisite.
---
TL;DR
**The Problem.** Running large AI coding swarms across ad-hoc terminal panes is chaos. When you're driving 50–200 Claude Code / Codex / Gemini agents at once, a single undetected rate limit wastes hours of compute. A stuck agent silently burns tokens. An auth failure goes unnoticed for thirty minutes. You have no search across agent output, no audit trail, no way for one AI to safely control another, and no way to know whether your swarm is operating inside or outside its safe envelope.
**The Solution.** ft is a **full terminal platform for agent swarms** with deep observability, deterministic eventing, policy-gated automation, machine-native control surfaces (Robot Mode + MCP), and a fail-closed operating-envelope contract. It captures bounded terminal-output deltas across observed panes and records explicit gaps whenever continuity cannot be established, detects state transitions via multi-pattern matching plus Bayesian change-point detection, triggers transactional workflows in response, and exposes those surfaces through a JSON API built for AI-to-AI orchestration. The closest analogy is Kubernetes for terminal-based AI agents: observe, detect, react, audit, and refuse admission outside the envelope justified by the telemetry and evidence currently available. That envelope is deliberately narrower than the eventual 200-pane target while target-class proof remains blocked.
**Runtime model.** Cx-aware async on **asupersync**, with project-owned
structured-task and cancellation conventions. Direct tokio usage is
**banned at the dependency level** via cargo-deny and at the type level via
the RuntimeProof sealed trait. The runtime_async module is the canonical
first-party async API; its implementation layer and explicitly audited
integration seams may still name pinned asupersync types directly. The
dual-runtime era is over. Cancellation responsiveness is an operation-level contract: a wait
must checkpoint its Cx or explicitly race a cancellation signal; merely
holding a Cx does not make every suspended primitive wake on cancellation.
If you'd rather see commands than prose, jump straight to the 10-Minute Tour below.
---
10-Minute Tour
A guided walkthrough from "I cloned this" to "I have an AI driving an AI." Each step builds on the previous one.
1 · Install + verify (1 minute)
The installer selects one DSR release generation and verifies its checksum and