Continuous

continuous - complete the build plan one local feature at a time

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

First action: Before project inspection, preflight, or any other tool call, publish running to blueprint/.state/run.json using the dashboard activity contract in AGENTS.md.

Where this sits in the workflow:

/status  ->  [continuous]  ->  final review packet
(ready)      (feature loop,    (local main only,
              local history)    never pushed)

Continuous Mode is an explicit opt-in loop for completing planned features without pausing at normal review prompts. It preserves the same file-backed state, small steps, verification, findings ledger, branches, archives, and one clean main commit per feature that a careful human workflow would produce.

A direct Continuous request authorizes these local actions for this run:

• create and switch local feature branches
• create configured checkpoint commits on those branches
• create required immutable independent-review checkpoints
• create the final local feature commit
• squash-merge a completed feature into the local default branch
• delete the merged local feature branch
• repeat with the next unchecked build-plan item

It does not authorize push, deploy, publish, send, remote changes, destructive actions, database resets, irreversible migrations, finding acceptance, failed check waivers, or product decisions. It always stops before those actions.

Input and target selection

Before selecting an item or requiring a live active spec, inspect pending completion using the installed Complete skill and ../complete/reference/completion-recovery.md. Use its read-only candidate screen first: settled clean default-branch history needs no historical transient objects for a new run. An actual completion candidate or an explicit request to resume interrupted completion requires full recovery proof, using this run's scoped Git authority and qualityGates.continuous. Do not repeat archival or a work commit/merge. Missing, conflicting, or unprovable recovery evidence stops before next-feature work. An active feature with no completion candidate resumes implementation normally; its ordinary resume does not require an archive or completion proof.

With no argument after pending completion has been reconciled:

1. Resume an active feature in blueprint/context/current-feature.md.
2. Otherwise select the next unchecked leaf item in blueprint/build-plan.md.
3. Continue in build-plan order until no unchecked leaf remains or continuous.maxFeatures completed features have been counted.

resume explicitly resumes the active feature or its pending completion. A feature number or name may set the starting item only when no different work item is active. After that item, continue with the next unchecked leaf items in normal build-plan order.

Continuous Mode handles planned features only. If the active work is a fix or rollback, stop and point to its normal reviewed workflow. Never overwrite active work to make the requested target fit.

Step 1 - preflight once

Read:

• AGENTS.md
• blueprint/config.json
• blueprint/project-plan.md
• blueprint/build-plan.md
• blueprint/context/project-overview.md
• blueprint/context/current-feature.md
• blueprint/context/findings.md
• blueprint/context/coding-standards.md
• blueprint/context/ai-interaction.md
• git branch, status, default branch, upstream state already known locally, and recent log

A missing config means built-in defaults. If it exists but is invalid, stop and point to /doctor.

Start only when the state is safe:

• The project is a Git repository.
• The working tree is clean on the default branch, or all dirty work belongs to the active feature on its matching configured feature branch, including a proven pending completion handled through the recovery contract.
• The build plan is a valid ordered checkbox plan with at least one remaining leaf, unless resuming an active feature or its pending completion.
• The overview is current. If it is stale but both plans are clear and consistent, refresh it using the /overview behavior and include that change with the first feature. Stop when refreshing it needs a product decision.
• Existing P0 or P1 findings are not open or fixed.
• Project commands and the exact Verify command, when declared, are usable.
• The requested feature does not conflict with active work.

Do not fetch, pull, install dependencies, start an unauthorized server, alter remote settings, or clean unrelated work during preflight. A known-behind default branch is a stop, not permission to pull.

Record the starting default-branch commit. This bounds the optional final integration audit and the final report.

The initial blueprint/.state/run.json record required by AGENTS.md must already show command continuous and status running before preflight begins. After preflight passes, enrich it with boundary local-only, the current feature, and completed-feature progress against the smaller of the remaining queue or configured limit. Update it when a feature starts, after every passing build step, after each quality gate, and after each local main commit. On a stop, set status blocked with /continuous resume when resuming is safe. At the end of the queue or limit, set status completed and retain the final progress. Activity reporting must never weaken or block the workflow itself.

Step 2 - run one feature lifecycle

Repeat this section serially. Never have two feature branches or specs active at once.

2.1 Select and spec

When resuming, keep the active spec and continue from its first unchecked build step.

For a new item, apply the /feature behavior to the selected build-plan leaf, write blueprint/context/current-feature.md, and self-review the spec before coding. Correct missing unhappy paths, oversized steps, undefined contracts, scope drift, vague done-whens, missing design references, and missing testing plans.

Do not invent an unanswered product, data, architecture, auth, billing, or visual decision. Stop with the exact decision needed. Follow the proportional-engineering contract in AGENTS.md throughout this run.

2.2 Create or resume the feature branch

Use the exact **Branch:** frozen in the spec, including its **Build attempt:** suffix when applicable; do not derive a new branch or attempt from the title. Validate it against git.featureBranchPrefix and Feature's history rules, then create it from the current local default branch. When resuming, require the existing branch and active spec to agree; keep Complete's legacy attempt handling for older specs rather than renaming a reviewed branch.

If switching would strand unrelated work or the default branch changed in a way that makes the active branch unsafe to integrate, stop. Never stash, reset, or discard work automatically.

2.3 Implement small steps

Build the spec in order, one small diff at a time. Continuous Mode does not pause for workflow.stepReview; its explicit invocation replaces those review prompts with self-review plus the final packet.

For each step:

1. Implement only that step.
2. Show or retain a readable diff and explain it in the ongoing progress update.
3. Run the exact documented Verify command when present. Otherwise run the documented build and existing relevant tests.
4. Enforce verification.logicTests and verification.uiEvidence.
5. Self-review scope, error paths, security boundaries, project conventions, and tests.
6. Repair failures within scope, rerun affected evidence, and check off the step only when it passes.
7. When workflow.checkpointCommits is enabled, create a conventional local checkpoint commit containing that passing step and its checked spec state. When disabled, keep the work uncommitted until feature completion.

Never collapse an oversized step into an unreadable diff. Split the step in the spec and continue. A dependency install, new service, destructive operation, or decision outside the approved plans is a hard stop.

2.4 Apply Continuous quality gates

Use qualityGates.continuous, not the regular or Autopilot gates:

• Audit: manual skips automatic audit; when-sensitive runs /audit current for authentication, authorization, payments, secrets, personal or user data, migrations, destructive operations, external side effects, security boundaries, or unusually broad changes; always audits every feature.
• Independent review: manual skips automatic independent review; when-sensitive requires a fresh reviewer for the same sensitive categories as Audit; always requires a fresh reviewer for every feature. A passing independent receipt satisfies the Audit gate for that feature.
• Check: manual skips automatic /check; when-behavioral runs it when a done-when needs observed runtime behavior such as a click, request, CLI command, download, background job, or multi-screen flow; always checks every feature.
• Try guide (qualityGates.continuous.tryGuide): use /check guide. manual skips automatic generation; when-user-facing generates a guide for UI, navigation, copy, public API or CLI, output, or another workflow a person directly uses; always generates one for every feature.

Run required gates in this order: check, review, then try guide. Use independent review instead of a builder-session audit when both are selected. manual means the capability remains available later but is not automatic during this run. A try guide is instructions for human review, never proof it was performed.

When a gate cannot run, stop instead of recording a pass. Existing P0/P1 ledger blockers always apply even when audit is manual.