Implement from task

Implement From Task

Use this workflow after a task-definition.md exists and you want a human-readable operating path for implementation. It explains what to decide, which writes occur, what files to expect, how failures are handled, and what to authorize next.

Reusable agent procedure lives in Task instructions. Agent behavior depends on the connected agent or integration; the core CLI exposes policy and evidence but cannot force an unsupported agent to comply.

Decide the implementation boundary

Select one task definition and verify that it states:

• the objective and desired behavior;
• concrete implementation target paths;
• dependencies that already exist;
• acceptance criteria;
• validation commands or inspection steps;
• rollback or recovery guidance;
• constraints and unresolved questions.

The selected task is the work agreement. Its paired implementation-summary.md is the canonical technical evidence artifact. Agent mode controls check-in cadence; evidence profile controls the required completion evidence. Neither expands authority.

Review readiness before writing

Run a read-only readiness review when readiness is not already current. The review may report blockers, warnings, and a next action, but it does not authorize implementation or change task metadata.

Before authorizing readiness, confirm:

• the selected artifact and paired summary revisions are current;
• required parent and dependency paths resolve;
• the link-materialization gate has no unsafe or unresolved candidates;
• earlier required siblings are complete;
• Runtime or Hybrid work can capture a pre-write baseline;
• broad target directories are intentional and reviewable.

Use the separate readiness-authorization command only after reviewing its exact artifact pair and intended paths.

Open the implementation attempt

After readiness authorization, open one stable attempt identity. Runtime and Hybrid tasks capture an attribution baseline after the attempt opens and before the first implementation write. Contract work does not fabricate runtime attribution.

Expected file state at this point:

• task-definition.md remains the scope contract;
• implementation-summary.md contains the current attempt and, when required, its baseline;
• repository target paths remain unchanged from the accepted baseline;
• any lifecycle run records command evidence separately without replacing the canonical task pair.

If a contract must change after baseline capture, stop. Use the supported revision and attempt-recovery path; do not edit readiness or attempt history by hand.

Authorize scoped implementation

Implementation writes belong only in the task’s declared targets. Preserve unrelated user changes, credentials, derived state, release state, and every protected path outside the selected contract.

During the work, ask for concise boundary updates:

• which declared target is changing;
• whether actual paths still match expected paths;
• whether a product or design decision changed the agreed approach;
• whether discovered work remains outside the task;
• whether required validation is still executable and meaningful.

A warning is evidence to evaluate, not permission to expand scope. A failed or stale precondition stops the corresponding write.

Record validation deliberately

Day Shift distinguishes three postures: execute one explicitly selected validation command, record manual evidence, or import verified external evidence. Planning smoke and links checks are read-only evidence checks; they do not run arbitrary task commands.

For every declared validation, record:

• exact command or evidence source;
• required or advisory status;
• observed result;
• relevant scope paths;
• any semantic assertions;
• why a command was skipped, substituted, blocked, or inconclusive.

Runtime and Hybrid work needs current runtime changed paths plus executable validation evidence. A structured exception can explain a blocked validation command, but it cannot substitute for missing runtime implementation.

Build and complete implementation evidence

Use the canonical summary build command before and after authoring the evidence body. The completed summary should contain:

• a concise implementation summary;
• actual changed paths;
• acceptance-criterion results;
• validation performed and structured exceptions;
• scope classification and runtime evidence boundary;
• deviations;
• risks, discovered work, and follow-ups.

Inspect the task-scoped diff before closeout. Large unexpected deletions, file-type changes, or shrinking tests require investigation even when a validation command passes.

Implementation completion is a separate revision-bound write. It does not accept the work, close the attempt, close the task, or update parent state.

Review, disposition, and close

Run implementation-summary review as a read-only evaluation. If the receipt is current and clean, apply an explicit disposition. Then rerun review because disposition changes the summary revision; close the task only from the new close-authorizing receipt.

Use Review boundaries to keep evaluation, validation execution, disposition, receipt apply, and closure separate.

After close, re-open both task artifacts. Confirm completed status, a closed current attempt, accepted disposition, current required validations, and preserved runtime attribution.

Failure and recovery

• Not ready: repair the task contract or dependency evidence, then rerun readiness review.
• Stale preview or receipt: preserve the old evidence and obtain a current preview or review.
• Validation failure: keep the attempt open, repair inside task scope, and record a new current validation result.
• Scope expansion: stop and request a bounded contract revision; record unrelated work as discovered work.
• Interrupted command: retain the continuation handle and poll the same invocation to a terminal result.
• Partial or uncertain write: inspect transaction and canonical artifact state before any retry.
• External or destructive effect: request explicit authority for the exact action.

Agents use Stop and escalate for the corresponding evidence-preserving report.

Choose the next action

After a clean task close:

• Basic work reaches its terminal task-pair handoff.
• Structured work advances to the next declared sibling or project review.
• Governed work advances to the next declared sibling or milestone reconciliation.

Reconciliation is eligible only after every declared task summary is completed and non-placeholder. Review or follow-up findings do not create new tasks automatically; scaffold follow-up work only through a separate authorized planning request.

Continue with Evidence review and reconciliation for milestone closeout or Current work for the next selected artifact.