ft — FrankenTerm
<div align="center" <img src="frankentermillustration.webp" alt="ft - Swarm-Native Terminal Platform for AI Agent Fleets" </div
scripts/demo.tape (CLI tour) and scripts/demo-full.tape (10-pane live swarm) are the vhs sources; the swarm recording is tracked under ft-xl2kc.1 / ft-xxfwy.21 and must be captured from real agents, not staged output, before it is linked here. --
<div align="center"
</div
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. <!--count:workspacemembers--83<!--/count-- workspace crates, <!--count:coresubcrates--19<!--/count-- sub-crates carved out of the core, <!--count:coretoplevelmodules--536<!--/count-- core-library modules, <!--count:coreloc--1346112<!--/count--+ lines of Rust, <!--count:testcount--60535<!--/count--+ test annotations across <!--count:corerusttestfiles--1042<!--/count-- 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.
<div align="center" <h3Quick Install</h3
curl -fsSL https://raw.githubusercontent.com/Dicklesworthstone/frankenterm/main/install.sh | bashThe 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 nextaction 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.
</div
---
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 runtimeasync 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.