Concepts

Concepts

The model in one page. Everything else is detail.

Blueprint first, model second. TRON's founding principle: a deterministic blueprint — a closed trigger grammar and an explicit event table — decides the flow; the model is called only to build and to answer two bounded judgments, never to choose a step. Everything here follows from it.

The pipeline

Your work is a pipeline of blocks. Each block ties to a spec (by ID) and carries a status:

Status	Meaning
pending	exists, not yet cleared
cleared	architect-cleared — the only dispatchable status
in-progress	a worker is building it
blocked	walled, awaiting your decision
done	built + released
abandoned	you dropped it

Pipeline order is your preference; a spec's dependencies are the hard gate.

The roles

• Architect — one persistent agent, excluded from the worker pool, draining a FIFO queue. It is forward-looking only: it reviews the work ahead and marks the next block cleared (forward-review), and it turns reviewer findings into upcoming blocks (log-review). It never reopens a done block — remediation is always a new block ahead. It's also the standing peer-consult.
• Engineers — build one cleared block each: read the spec, work on their branch, validate against every acceptance criterion, report done. Fresh worker per block.
• Reviewers — dispatched on a cadence; deliver a findings log for one lens (code / security / data / …).

Engineers and reviewers share the worker pool (size = worker_count). The architect does not.

Review is a milestone, not a verdict

A reviewer doesn't pass/fail anything. It hands back a findings log; the architect's log-review decides what (if anything) becomes a new block. The fleet keeps moving.

Cadence is pull

Reviewers aren't fired on a timer. A per-type counter ticks on every completed block; when it reaches that type's threshold, the dispatch loop pulls a reviewer and resets the counter. You set the thresholds (cadence: {code: 3, …}).

The dispatch loop (PULSE + SWITCHBOARD)

The engine spine is code, never an LLM call:

• PULSE — the standing loop. It runs at start and on every completion signal.
• SWITCHBOARD — what PULSE runs each tick, in order:
  1. Fill slots — for each free worker slot, dispatch in priority: oldest cleared adhoc block → a due cadence reviewer → next cleared block.
  2. Clear ahead — enqueue the architect to clear every pending block (keeps the buffer ahead).
  3. Wait — nothing dispatchable right now; re-enter on the next signal.
  4. Session end — only when the whole pipeline is settled.

A block is dispatchable iff cleared; dispatch flips it cleared → in-progress.

Walls go to you

Anything no worker can clear — an operator-only task (deploys, secrets, production), an external blocker, human eyes on a screen, a true impasse after the architect was consulted — is walled. The block parks blocked, its slot frees, and TRON contacts you. You reply: resume, amend (re-clear via the architect), or abandon. A blocked block holds the session open, not closed.

The two judgments

The LLM is asked exactly two questions into the flow, both schema-in / schema-out:

• classify_message — put an inbound worker/operator message in exactly one tag.
• assess_wall — for an ambiguous input, is this really the operator's problem?

It never returns prose that steers a transition. Review verdicts, findings triage, and stall detection are not LLM calls — they're the architect's job or the engine's.

Crash-safe by design

Each wake is one bounded tick: read inbound, advance as far as signals allow, persist atomically, exit. Dispatch intent is committed before any spawn, and messages are processed at-least-once — a crashed wake retries cleanly without double-spawning or losing work.

See also: Architecture · Operations.