Configuration

Configuration

Two per-project files, written by the seeder and edited any time (ask TRON, or edit and restart). The behaviour (the event table) is canon and never edited per project — only these knobs are.

workflow.yaml — the knobs

knobs:
  worker_count: ~          # asked at every session start; the worker pool (engineers + reviewers).
                           # The architect is EXTRA, never counted here.
  architect_count: 1       # persistent architect queue drainers — the throughput bottleneck knob.
  git: on                  # whether the workflow commits (feature branch + review)
  silence_ping_min: 6      # worker silent this many minutes -> heartbeat ping
  silence_escalate_min: 8  # silent past this -> the engine flags a stall (> ping)

cadence:                   # PULL reviewer cadence: <type> -> completed blocks between reviews
  code: 3                  # add security:/data:/… to schedule other lenses; drop one to stop it

peer_consults: []          # who may consult whom directly (bypassing TRON)
  # - { worker: engineer, may_consult: architect, for: "technical/design questions" }

session:
  persistent_architect: true   # one architect, alive from start to session-end

• worker_count is the only per-session knob — TRON asks it on every tron start.
• architect_count is the lever for throughput: the architect clears blocks ahead of the workers, so if engineers are starved waiting for cleared work, raise it.
• cadence types are open. Each maps to a positive integer threshold.

project.yaml — the pointers

What TRON needs to know about this repo (written by the seeder, confirmed with you):

• Pointers — the agents directory (<agents>) and the specs directory (<specs>).
• Agents — the role → file map (architect.md, engineer.md, reviewer.md, …).
• Pipeline — mode: internal (TRON keeps pipeline.md) or mode: host + path (TRON adopts your existing status doc; see below).
• Repo facts — name, repo root, main branch, remote, worktrees/logs dirs, protected branches.
• Notifications — telegram and cron (see Operations). Config-driven; TRON never interrogates.

Pipeline: internal vs host

• internal — no existing status doc; TRON keeps <agents>/tron/pipeline.md (gitignored).
• host — you already track block status in a markdown table. TRON adopts it, requiring columns for Order, ID, Owner, Status (Status ∈ pending · cleared · in-progress · blocked · done · abandoned). TRON parses it once at session start into a normalized mirror, reads the mirror each tick, and writes back only on status changes — never a full rewrite. cleared and abandoned are TRON-managed.

Changing a knob

Describe the change to TRON in natural language (it owns workflow.yaml), or edit the file and restart. tron validate flags any malformed instance before it runs.

See also: Concepts · Operations.