The process

Phase B - Forge (The Autonomous Loop)

Overview

From your perspective, the Forge phase is a black box. You triggered a ticket; it is now "In Progress". You can go do other things. The agents will reach out only if they hit a genuine blocker that requires human judgment.

Inside the box, a structured loop is running.

The internal loop

Triggered
   │
   ▼
Analytic writes affected use-case specs
(API contracts, data model, components,
 test scenarios, flow diagrams)
   │
   ▼
Dev builds (FE + BE)
   │
   ▼
Reviewer audits code ──── FAIL ───► Dev revises
   │
 PASS
   │
   ▼
DevOps spins ephemeral env
   │
   ▼
Tester runs suite ──── FAIL ───► Dev fixes + Reviewer re-audits
   │
 PASS
   │
   ▼
Validation Package assembled
   │
   ▼
You are notified

Each transition in the loop is gated. An agent cannot skip a gate. A Dev cannot start coding before the Analytic's use-case specs exist. A Dev cannot push code that has not passed Review. A Tester cannot sign off on a suite that has not run against the ephemeral environment. The loop enforces quality at every step without requiring your attention.

What each agent does

Analytic agent

The Analytic agent runs first in the Forge loop. It reads the staged ticket and produces full use-case specifications for every part of the product the change affects. A use-case spec typically contains:

  • A short narrative of the use case and its actor
  • A Mermaid sequence diagram covering the happy path and the alternative branches
  • The API contract (endpoint, request body, response shape, status codes)
  • Frontend and backend validation tables (field, constraints, size, pattern, notes)
  • Data-model changes (new entities, columns, migrations)
  • A test-case matrix (positive, negative, edge cases)

In short, the Analytic turns "we want feature X" into a deterministic blueprint that Dev, Reviewer, and Tester can all execute against without further input from you. Real examples of this format live under documentation/usecases/ - one file per use case, indexed in a per-domain README.

Dev agents (FE + BE)

Dev agents pick up the Analytic's use-case specs and implement them. They produce code, migrations, configuration changes, and documentation updates exactly as the spec describes.

FE and BE Devs work in parallel where possible. Shared contracts (API schemas, TypeScript interfaces) are established first to allow concurrent work.

Reviewer agent

The Reviewer reads every diff before it is promoted. It checks for:

  • Adherence to the accepted technical specification
  • Security issues (injection risks, auth gaps, secrets in code)
  • Performance regressions
  • Code style and maintainability

If the Reviewer fails a diff, it returns a structured list of issues to the Dev. The Dev revises and resubmits. This inner loop runs silently.

DevOps agent

Once code passes Review, DevOps spins up an ephemeral environment - a clean, isolated deployment that mirrors production configuration. This environment is used exclusively by the Tester for this ticket and is torn down after the Validation Package is assembled.

Tester agent

The Tester executes the test suite against the ephemeral environment. The suite includes:

  • Unit tests generated during Dev
  • Integration tests against the API contract
  • End-to-end tests covering the acceptance criteria defined in the Feed phase

A failure returns a structured report to the Dev, and the inner loop restarts.

The interruption protocol

Agents interrupt you only when they encounter a decision that genuinely requires human judgment and cannot be resolved by re-reading the spec or making a reasonable inference.

An interruption looks like this:

Ticket #142 - Interruption required The payment webhook spec requires idempotency handling, but it does not specify the idempotency window. Options:

  • 24 hours (Stripe default)
  • 7 days (conservative)
  • Configurable via environment variable

Which should we implement?

Interruptions are specific, offer concrete options, and require a one-word or one-sentence answer. They are never vague and never ask you to re-explain the requirement.

Note: A well-written ticket spec should result in zero interruptions. If a ticket type consistently generates interruptions, the Analytic agent's instructions for that ticket type need refinement.

Next
Finish - The Outlet