2026-08-29 · Updated 2026-08-29 · 8 min read
From coding prompt to validated change
Follow one change through YYLO's governed lifecycle — task record, isolated worktree, focused validation, read-only preflight, guarded finish, and the serialized merge queue — with the documented command surface at every station.
By Juno AI INC · task-lifecycle · validated-change · yylo
Most coding-agent sessions end when the terminal closes: an agent edited some files, maybe committed, and the strongest evidence of what happened is a scrollback you can no longer read. Governed agent development replaces that ending with a different one — the prompt becomes a task record, the work happens in a checkout nothing else touches, validation runs before anyone asks for admission, and a queue merges the change only after its gates pass. Each station leaves evidence behind it, and the evidence, not the session, is what the next person reads.
This page walks one change through the whole path. The example is small on purpose — a login redirect that fails after session renewal — because the point is the shape of the journey, not the size of the change. Three installed components carry it: the YYLO control plane runs the gates, YYLO Ledger keeps the record, and YYLO Benchmark retains the evaluation evidence when a change needs it. Which component owns which boundary has its own reference in this program — the ownership definition; here the question is the trip itself.
Every command below is documented surface of the current release, and every quoted sentence is verbatim from the committed control-plane README, verified on 2026-08-29. Nothing here is roadmap: each gate described is a gate the shipped CLI enforces today.
Turn the prompt into a record a gate can read
A prompt like *fix the login redirect* is a wish; a task is a contract. The difference is acceptance: the task body says what a command must prove for the work to count, and the task is the unit the lifecycle carries through every gate that follows. Write the outcome so a test run can decide it — the redirect preserves the return URL after renewal, and the auth suite passes — and record anything that must land first as a declared blocker rather than a sentence in the body.
The record lives in the ledger, one file per task, versioned with the repository:
create writes the task; ready answers which tasks are actually actionable — blockers resolved, nothing waiting on a promise. That answer is computed, not remembered, which is what makes it safe to hand to an agent. What task truth is, why shared markdown todo lists degrade under concurrent agents, and how dependency graphs stay honest are each their own subjects with dedicated guides in this program; the fact this station contributes to the journey is narrower. The prompt now has a durable home that will outlive every session that touches it, including yours.
Give the change a checkout of its own
The control plane's first move is isolation, and the README dedicates the lane in one sentence — "Every product change uses a dedicated yy task worktree; yy merge serializes only target mutation." Hands-on, the way in is one command:
It returns a hydrated worktree to implement in. The managed path covers the same ground unattended: yy task run TASK_ID dispatches the task and runs it to a queued candidate, with merge delivery as the paired second command. Two properties follow. The blast radius of any agent session is one checkout, not the shared tree; and the base it started from is recorded, so the review later compares against a known starting point rather than a guess.
The same isolation is what makes parallel work boring instead of dangerous. "Feature worktrees are independent, so X and Y can implement concurrently from recorded exact bases" — two tasks, two checkouts, no coordination meeting, and landing stays serialized so the target never takes two writes at once. Nor is this a privilege reserved for big features: "There is no size-based exception that permits product edits in the controller or integration owner." A one-line fix rides the same rails, with a smaller task and a smaller validation bill. How Git worktrees provide the isolation, and what to do when an isolation boundary breaks, belongs to the worktree guide in this program; this page only needs the lane.
Review the evidence, not the promise
Inside the worktree, the agent implements and you steer — but the unit of progress is a commit, not a conversation. Focused tests run against the changed surface while the change is small, and the work lands as commits whose diffs a reviewer can read without trusting anyone's summary. The task record collects the agent's account of the work; the repository diff holds what actually changed; when the two disagree, the diff wins and the cycle continues or narrows.
This is also where scope discipline gets enforced by structure rather than nagging. Validation stays proportional to the touched surface during implementation — the suites that matter for the files that changed — because admission is not won by running everything now; it is won by a clean, committed tip later, with the heavy validation owned by the gates ahead. An agent working one bounded outcome in one checkout has no avenue for the classic failure of ambitious sessions: half-finished edits scattered across a shared tree with one reassuring summary message on top.
Make the evidence reusable before you ask for admission
A green test run you watched scroll past is evidence for exactly one person, once. The lifecycle wants evidence a machine can re-verify, so validation results are captured as receipts bound to the exact tip that produced them. The README states the consequence for every crossing that follows: "Verified command closures cross finish, refresh, and merge with executed/reused/invalidated counters" — a command already proven against this exact tree is reused, a changed tree invalidates it, and nothing quietly re-runs or silently carries forward.
When the question under the change is evaluative — which of two implementations survives contact with the real repository, what a repeated attempt actually costs — that evidence belongs to the Benchmark, installed and invoked through the same launcher family:
Evaluation there runs on immutable plans and isolated attempts rather than ad-hoc sessions, which keeps its results comparable long after the terminal that produced them is gone. The division is clean: the control plane proves this change is safe to admit, and the Benchmark answers questions whose evidence should outlive any single change.
Cross the admission gates in order
Admission is two gates in a fixed order: a read-only report, then a guarded write. The README compresses the whole sequence into one sentence: "Task start freezes the target SHA; read-only task preflight reports closure defects before expensive final gates; task finish queues a clean committed tip." Preflight is the read-only half — it reads the committed state and reports what would fail while fixing it is still cheap. Finish is the guarded crossing; it expects a clean tree on a committed tip and queues the candidate for merge:
Stale inputs fail closed here, on principle. Someone else landed on the target while this task was in flight; the recorded base no longer matches the world — the candidate does not bluff its way through, it goes back for revalidation against reality. "A replacement tip invalidates prior evidence", so a change can never arrive carrying receipts that describe a tree that no longer exists. And the review that follows belongs to the queue, not to the agent: "Implementation and repair agents never launch lifecycle-semantic reviewers." The thing being reviewed never gets to choose its reviewer.
The queue merges one candidate at a time, and the ledger keeps the story
Landing is mutation, so it is serialized and evidence-bound. The queue "reuses exact complete-input closures, applies bounded risk review, and advances by expected-old-SHA CAS" — compare-and-swap on the target itself, so a queue that computed its plan against commit A refuses politely if the target moved to commit B underneath it. Delivery for a finished candidate is explicit: yy merge drive --through TASK_ID on the managed path, with yy merge status for read-only observation, yy merge next as the explicit recovery mutation, and yy merge resolve TASK_ID to land a resolved conflict.
Risk decides how much review a candidate earns, and the policy is stated, not vibes: "Low risk uses no semantic reviewer. Normal risk uses at most one fresh read-only reviewer. High risk preserves Reviewer A then Reviewer B sequentially on the same frozen tip." The budget for disagreement is bounded the same way — the queue "permits one repair candidate and one delta review group, then stops as REVIEW_FINDINGS_EXHAUSTED" — so a change that cannot converge gets stopped, reported, and handed back instead of looping forever at the gate.
After landing, the story is readable end to end from durable artifacts: the task record with its acceptance and response, the commit hash bound to completion, the receipts that crossed finish and merge, the queue's own record of what was validated and admitted. Which artifact belongs to which stage — the run directory, the manifest, the receipt contracts — is documented from first step to last in the auditable-workflows guide, and operators arriving from an always-on loop will find their prompt, session, and iteration habits renamed into exactly these evidence shapes by the migration guide. A page walking one task from prompt to admitted merge is also where this page stops: publishing it is itself one task in one worktree, queued behind the same gates it describes.