Skip to main content
Use this process to deliver one change from a written request to an approved result without a model account. The first draft passes its own tests but misses a requirement. The review panel catches the miss and sends it back. The line repairs the work, proves it again, and approves the exact final bytes.

Graph

  1. The analyse stage turns the issue into typed acceptance criteria before any code runs. Work with no accepted criteria fails the line.
  2. The implement stage writes the change as real files: src/retry.js and its tests. The first draft covers two of the three criteria.
  3. The test stage runs the tests as a command gate. The line advances only when the command exits 0, never on a self-report.
  4. The review stage is a panel of three reviewers, and two votes pass it. Round one fails with findings, and the panel sends them back to implement as a kickback, bounded by the line’s kickback budget.
  5. The re-run of implement is the repair: it reads the last review’s findings and covers the third criterion. The test and review stages re-run with it, so nothing passes on the strength of the fix alone.
  6. The approve stage binds the approval to the sha256 of the final source. The request, the claim, the answer and the digest are durable events in an approval record beside the run record. The stage reads the answer, and a no fails the line.

Contract

Source

Copy examples/production-lines/feature-delivery.line.ts from the repository. The example imports only the public package exports.

Run the line

From an Obversa checkout, run:
The result is:
The line reads its own record back before it exits. implementRuns and reviewRounds count the recorded stage runs, and acceptedKickbacks counts the accepted dag:kickback events, so the numbers come from the record rather than from memory. The approval answer lands in its own durable record beside the run record. After you copy the source into a project that has @obversa/runtime and tsx installed, pnpm exec tsx feature-delivery.line.ts runs the same line.

Failure behavior

The line allows two kickbacks. If the panel keeps rejecting the work, the budget is spent, the review’s failed verdict stands, and the process exits with code 1. A refused approval fails the line the same way: the approver who answers no stops the ship, and the no is a durable event in the approval record. The line never advances past a failing test command, so an unproven draft cannot reach the panel or the approval.

Pause, resume, and retry behavior

This line does not pause and stores nothing outside its own temporary directory, which is removed when it exits. It changes nothing a reader owns, so a full retry from the start is safe.

Engine lanes

This line uses function jobs. It does not call an engine, and it needs no model account. Each stage names where an engine goes: replace implement’s fnJob with agentJob and an engine, and the same line drives a model that writes the change; replace the panel’s reviewer jobs with agentCheck conditions and models read the code; put a person behind the approval gate in place of the scripted submit, answering through the same claim and digest protocol against the same record. The stages, the kickback, and the records stay the same.