FAQ

FAQ

How is this different from an agent-orchestration framework?

Most frameworks let an LLM decide the next step. TRON doesn't: the flow is a data table (engine/workflow.toml) run by deterministic code and lint-checked before it runs. The model is called only to build and for a few narrow, typed judgments — never to choose a transition. You get predictable, inspectable orchestration with a human in the loop, not an agent improvising a graph.

What do I need to run it?

python3 3.11 or newer, git, and a background-capable agent runtime on PATH that runs the worker agents. Optionally a Telegram bot for remote notifications/pages. See Getting Started.

Is there a hosted/SaaS version?

No. TRON is yours and runs on your machine. It's an orchestrator for your own dev work, not a service.

What happens if it crashes mid-run?

It recovers at boot: decisions are recorded as they happen (events.jsonl), stray processes are killed, unverified branches are preserved as orphan/*, and their blocks are re-dispatched fresh — no double-spawn, no lost work. See Architecture.

How does TRON know a block is really done?

The truth gate never trusts the claim. A >>DONE is challenged for per-criterion evidence (>>CONFIRMED), then verified against commits, an untouched trunk, and the engine's own test run; a reviewer judges in its own pinned checkout; the engine lands and re-runs the suite on trunk; the worker wraps. Done = landed + trunk-green + wrapped — nothing less counts.

What does TRON need from my project's blocks?

Complete, well-specified inputs. Each block must state exact acceptance criteria, declare a test the engine can run, and have every dependency and asset present before it's dispatched. The gate judges evidence, not intent — an under-specified block, a missing asset, or a test that can't run on a fresh trunk checkout will wall or halt rather than improvise. TRON front-loads the work of a robust project scaffold; it doesn't substitute for it. If a landing leaves the trunk red, the run halts — recovery is to fix the spec and restart (boot re-dispatches) or add a remediation block ahead, not an in-flight patch.

Can I run more than one reviewer lens?

Yes — add verdict phases to a project workflow.toml, one per lens (code / security / data / …). There is no scheduler; each lens is just another phase on the pass spine. The engine already ships a 5th ready-made persona for this, auditor (engine/prompts/persona_auditor.md) — an independent second reviewer that assumes the first pass caught the obvious and hunts for what it missed (edge cases, spec drift, weak tests, letter-not-intent); wire it as a second verdict phase, or bring your own. Review is a milestone: findings route back within a block, and the architect turns real findings into new blocks ahead.

Why is the architect separate from the workers?

It's forward-only and out of the worker pool so that clearing the way never competes with building. It authors the next block and turns findings into upcoming work; it never reopens finished work.

Can I change how TRON behaves?

Re-model the flow by editing engine/workflow.toml (or ship a project-specific one) — but the lint refuses any flow that drops an invariant (the truth gate, a recorded review, the single landing window). You set the bounds via [limits] (phase_turns, review_cycles, gate_fails, max_parallel). See Configuration.

How do I try it without spending tokens?

Run the SIM suite: python3 evaluation/harness.py project-01 3. It seeds a fresh git project per SIM, runs the whole engine against fake agents, and writes a stats.md from the typed events. See Getting Started.

How do I contribute?

The repo is a canon source of truth; per-project or machine-specific assumptions live in seeded instances, never here. See CONTRIBUTING.md for the workflow and the merge gates; open an issue to report a bug or float an idea.

License?

Dual-licensed: AGPL-3.0 for open-source use, or a commercial license (closed-source / SaaS) — contact ahoy@42labs.io.