The pipeline

The agent chooses the methods needed to turn your request into supported work. A compact fix needs one ticket and execution account. A larger uncertain initiative can need decisions, research, a spec, and a ticket graph. These are useful stages, not a sequence you must invoke manually.

  1. Shape

    decisions.md

    consequential uncertainty resolved

  2. Specify

    spec.md · settled intent

    a useful contract, pinned to the decisions it consumes

  3. Decompose

    tickets/

    tracer-bullet tickets, falsifiable criteria

  4. Build

    evidence/

    one ticket, one worktree, test-first

  5. Review

    reviews/

    a different session, never the builder

  6. Verify

    VERIFIED

    measured, or honestly NOT VERIFIED

  7. findings and NOT VERIFIED walk back up the line to Build

  8. Close

    complete · verified scope

    authorized work proved; lasting decisions retained

  9. DECISIONS.md

    the harvest lands here; the next initiative reads it before shaping

A larger work path. Use the stages the request needs; findings return to affected work.

Shape: decisions.md#

Consequential uncertainty is resolved before dependent work. The agent inspects the existing system and asks what evidence cannot settle. Durable decisions record alternatives and accepted costs. Broader uncertainty can use a decision map; a settled request does not need an interview for its own sake.

Specify: spec.md#

A useful spec describes behavior and acceptance. It records the exact decisions and research revisions it consumed. If those inputs change, affected work is rechecked before the agent relies on it.

Decompose: tickets/#

A larger change becomes tracer-bullet tickets: usable vertical slices with falsifiable acceptance and explicit dependencies. Tickets have global IDs. An initiative lists its members; joining one does not move a ticket's files. greenline status shows the frontier whose dependencies are complete.

Build: one ticket, one worktree#

The agent claims work within your authorization, reads the relevant methods and, with garden enabled, consults it when a choice is open, and implements against acceptance. The ticket records its result commit; its execution account records consultations, choices, and application evidence. One implementer owns a worktree.

Durable measurements keep instruments beside raw results in .greenline/work/evidence/<work-id>. Temporary output that a result relies on becomes durable evidence before completion.

Review: reviews/#

An independent context reviews the committed result. The review names the exact ticket and implementation account, even when multiple tickets share a commit. If the harness has no delegation tool, open a separate reviewing session with the committed range and its account. Until independent review is available, the implementation remains blocked for review; recording a limit does not complete it. Findings return affected work to implementation. A subsequent change requires the affected review to be checked again.

Verify: measured, not asserted#

Acceptance is proved with actual commands and observations. A performance claim needs a relevant workload and measured result; a correctness claim needs a check that can fail. VERIFIED means the valid comparison supports the claim; NOT VERIFIED means it fails the claimed behavior or threshold. Missing baselines, failed measurements, noise or confounds make the result INCONCLUSIVE, with the limit recorded. Neither negative outcome completes acceptance.

Close, and the harvest#

The agent completes authorized work only when acceptance, review, and verification are supported. You can set a different stopping boundary; ordinary completion does not require another permission merely to advance a stage.

An initiative's lasting product decisions are retained in .greenline/DECISIONS.md with source references. The next agent reads them before reopening settled ground. Engineering choices and root statements live in the same decisions book.

Decisions compound across initiatives Initiative 001 closes and harvests into the decisions book. Initiative 002 reads the book before shaping, and at its own close it harvests into the book again; the book is cumulative. initiative 001 complete harvest DECISIONS.md PD-1 · 001 D2 PD-7 · 001 D9 PD-12 · 002 D3 each entry pins its source read first initiative 002 shaping · reads the book and it harvests into the book again, at its own close
  1. initiative 001 closes, and its outliving rulings are harvested into the book
  2. DECISIONS.md the product decisions book, each entry pins its source
  3. initiative 002 reads the book before shaping, and harvests into it again at close
Settled ground is never re-decided unread.

The loop#

A review finding, bug, or changed assumption re-enters the work at the affected point. Current files preserve intent and evidence; Git preserves history. The execution ledger makes the account inspectable without replacing independent judgment.