Overview

Steelframe turns one repository into a software factory: an agent that runs issues from intake and planning through implementation, review, staging, and production. The opinionated harness — hooks, skills, and gates — is one component on that floor. Coding CLIs (Claude Code, Grok, Codex, OpenCode) are tools the agent spawns — they are not the agent, and they never own the loop.

Point an agent at one GitHub repository. It picks up issues, implements changes, deploys to staging, verifies with health checks, and promotes to production — with an audit trail and safety gates around every step.

The pieces

Piece	Role
Agent	Per-project process: workflow engine, GitHub, credentials, skills, safety checks, and coding-runtime workers. This is the autonomous system.
TUI	Terminal multi-project console that connects to agents.
GUI	Multi-project graphical console (Desktop native + Web). It connects to agents.
Desktop	The native target of the GUI. Uses projects.toml + a token, like the TUI.
Web	The browser target of the GUI. One agent behind the GUI origin; hosted on the release channel, not served by the agent.
Coding runtime	A pluggable worker CLI — Claude Code, Grok, Codex, or OpenCode — selected in config.

One agent instance serves one project, typically on a dedicated VM. Multi-project is a TUI and Desktop concern (~/.config/steelframe/projects.toml plus a per-project token). Web is one agent behind the GUI origin.

TUI / GUI   ── HTTPS ──▶   agent (127.0.0.1:7700 behind nginx)
                             axum + Turso (libsql)
                             workflow engine
                             coding-runtime workers × N
                             gh / GitHub App
                                  │
                            GitHub (issues, PRs, Actions)

How work flows

1. You open a GitHub issue in the repository the agent manages, with a thorough specification. If pickup labels are configured, add one (for example steelframe:work-on-this).
2. The agent picks up the issue and runs it through the task_lifecycle workflow: triage, implement on a sf/<issue>-<slug> feature branch, open a PR, wait for CI, deploy the PR branch to staging, run health checks, then merge and deploy to production.
3. If the agent needs clarification it comments on the issue and waits. If the task fails it is parked with steelframe:needs_human and a notification.
4. Every step transition, decision, and mutation lands in the audit log.

delivery_profile=source skips the live staging/production path: once CI is green the PR is rebase-merged to main and the task is done.

Where to go next

• Getting started — install and run your first agent.
• Install — the unified binary, setup, and systemd.
• Run — agent lifecycle, config, and auto-update.
• Consoles — TUI, Web, and Desktop.
• Features — chat, dashboard, board, workflows, memory.
• Operations — auth, deploy, releases, multi-project.
• Reference — HTTP API, config keys, projects.toml, CLI.