Documentation · prototype
Documentation
Tavronus Forge is an interactive product prototype of an autonomous software-engineering control center. This page documents how the prototype works today, the workflow it demonstrates, and exactly where simulation ends and planned capability begins.
What Tavronus Forge is
The Forge is a control center for delegated engineering work. Its agent is called VULCAN. The core idea: instead of steering an assistant keystroke by keystroke, you cast a complete task. VULCAN analyzes the codebase, proposes a plan you approve, executes in an isolated workspace, runs the tests, recovers from failures by replanning, verifies the result, reviews its own work, and hands back a reviewable diff that you temper — approve — or send back.
What exists today is a demonstration workspace: a local, deterministic simulation of that entire workflow, running in your browser. There is no backend and no real repository execution. Try it at /forge, and see the roadmap for what is planned versus what is built.
The task lifecycle
Every task moves through three visible states — Queued → Forging → Tempered — and a longer internal pipeline underneath:
- 01CastYou describe a complete task: what to change, what success looks like, what must not break.
- 02AnalyzeVULCAN reads project memory first, then the relevant code, and builds a model of the change.
- 03PlanIt produces an explicit, step-by-step plan: files it will touch, tests it will run, risks it sees.
- 04ApproveWith the plan gate on, nothing executes until you approve the plan. You can edit or reject it.
- 05ExecuteThe task runs in an isolated workspace. Every file edit and command is recorded.
- 06Fail / replanWhen a step fails — a test breaks, an assumption is wrong — VULCAN backtracks and produces a revised plan rather than pushing through.
- 07VerifyThe full acceptance criteria are checked: tests, lints, and the task's own success conditions.
- 08Self-reviewVULCAN reviews its own diff for correctness, scope creep, and convention violations before you ever see it.
- 09ReviewYou receive the verification report, the self-review, and an annotated diff.
- 10TemperYou approve. The task cools from Forging to Tempered — done, recorded, and added to memory where relevant.
Anatomy of a VULCAN task
A task is not a chat message. It has structure:
- Prompt
- The complete description of the work: intent, scope, and what done means. Vague prompts produce plans that surface the vagueness back to you at the approval gate — not silent guesses.
- Mode
- An execution mode — Fast, Balanced, Deep, Maximum, or Auto-route — that sets how much analysis and review the task warrants. See execution modes.
- Permissions
- What the task is allowed to do without asking — and which actions stop and wait for a human. Detailed below.
- Acceptance criteria
- Explicit success conditions: which tests must pass, which behaviors must not regress. Verification checks these; a task cannot temper without them.
Plan approval
When the plan gate is on, execution never starts before a human approves the plan. VULCAN presents the files it intends to change, the order of operations, the tests it will run, and the risks it has identified. You can approve, edit, or reject. This is the first of two human checkpoints — the second is the diff review at the end. The gate exists so that autonomy never means surprise.
Permissions
Each capability a task might exercise is either allowed within the task's scope or gated behind explicit approval:
| Capability | Scope | Gate |
|---|---|---|
| File edits | Scoped to the task workspace | Allowed within scope by default |
| Test execution | Runs the project's suites in isolation | Allowed by default |
| Dependency changes | Adding, removing, or upgrading packages | Requires explicit approval |
| Network access | Any outbound call during execution | Requires explicit approval |
| Git operations | Commits, branches, pushes | Requires explicit approval |
In the prototype these gates are simulated; in the intended architecture they are enforced by a policy layer between the control center and the runner. See security architecture.
Project memory
Project memory is the Forge's core differentiator: an inspectable ledger of what VULCAN knows about your codebase. Every entry is visible, editable, and categorized. Entries are either explicit (a human wrote them down) or inferred (VULCAN derived them from the code), and inferred entries carry a confidence level so you can see how much weight they are given.
| Category | What it captures |
|---|---|
| Convention | How this codebase does things: naming, file layout, error-handling style. |
| Architecture decision | Deliberate structural choices and the reasoning behind them. |
| Constraint | Hard limits: supported versions, performance budgets, API contracts. |
| Team preference | Choices with no single right answer that your team has settled. |
| Known gotcha | Traps that have bitten before — flaky tests, misleading names, ordering hazards. |
| Security rule | Non-negotiables: secret handling, input validation, dependency policy. |
| Testing rule | What must be tested, how, and which suites gate a merge. |
| Deployment rule | How changes reach production and what must never ship directly. |
| Inferred pattern | Patterns VULCAN has noticed on its own — always marked as inferred, never silently treated as fact. |
Memory is read before code: at analysis time, VULCAN consults the ledger before opening a single file, so conventions and gotchas shape the plan rather than getting caught in review.
The review workflow
When a task finishes forging, you receive three artifacts together:
- ◆Verification report — the acceptance criteria, each checked, with test output.
- ◆Self-review — VULCAN's own critique of the diff: scope, correctness, convention adherence, and anything it is uncertain about.
- ◆Annotated diff — the actual change, ready for line-by-line review.
Your options are approve (the task tempers), request changes (VULCAN replans against your notes), or reject (the workspace is discarded, and the reason can be written to memory so it is not repeated).
Demo controls
The /forge demo is deterministic: the same cast replays the same trace every time. You can pause the simulation, skip to the next checkpoint (plan approval, failure, review), or restart from the beginning. If your system requests reduced motion, the demo shortens its delays and drops decorative animation.
Prototype limitations
Prototype boundaries
- ◆No real repository connection — the codebase in the workspace is demo content.
- ◆No code leaves the browser — there is no backend and no model provider connected.
- ◆Analytics on the dashboard are illustrative, not measurements of real work.
- ◆Execution traces are deterministic replays, not live inference.
FAQ
- Is VULCAN running a real model right now?
- No. The /forge workspace replays a deterministic simulated trace. No model provider is connected, and no inference happens anywhere.
- Does the prototype read or modify my repository?
- No. There is no repository connection of any kind. Everything you see — files, diffs, test output — is illustrative demo content shipped with the site.
- Does any of my data leave the browser?
- No. Demo state lives in localStorage in your browser. Nothing is transmitted to a server, including early-access form submissions. See the privacy page for details.
- Are the dashboard numbers real?
- No. The analytics on the dashboard are illustrative demo data, labeled as such. There are no customers and no production workloads.
- Why build a simulation instead of the real thing first?
- The hard part of autonomous engineering is the workflow contract between human and agent — plan approval, permission gates, review artifacts. The prototype lets us design and test that contract precisely before real infrastructure exists.
- When will real execution ship?
- The roadmap lists a real repository connection and runners as planned work, with the honest caveat that order and scope may change. We do not publish dates we cannot stand behind.
- How do I get involved?
- The early-access program is the channel. It is currently a preview form; submissions are not yet transmitted, and the page says so.