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 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

With no argument:

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. 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.
• The build plan is a valid ordered checkbox plan with at least one remaining leaf, unless resuming an active feature.
• 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.

2.2 Create or resume the feature branch

Use git.featureBranchPrefix from config and a name derived from the spec. Create the branch from the current local default branch. When resuming, require the existing branch, active spec, and branch prefix to agree.

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: 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.

2.5 Repair and re-review findings

Validate audit findings before editing. Repair confirmed P0 and P1 findings only when the repair stays within feature scope and needs no user decision. Use continuous.maxRepairAttempts as the maximum attempts for the same failing check or finding; 0 disables automatic repair.

After a repair, rerun affected verification and acceptance evidence, then re-audit the repaired area. Move fixed to closed only when the audit confirms the defect is gone and no worse issue was introduced.

Report P2 and P3 findings. Fix only small defects directly caused by the current feature and clearly required by project standards. Never mark a finding accepted for the user or suppress a failing check.

Any P0 or P1 left open or fixed stops the loop before completion.

When independent review is selected, ensure the feature is in an approved clean checkpoint. First rerun final verification and the selected Check gate, set the spec status to verified, and include that exact spec in the checkpoint. Then prepare /audit independent current, set activity to ready, and stop with the selected adapter and model handoff. Continuous Mode never performs its own independent review. On /continuous resume, continue only with a current passed receipt. For changes-requested, repair within the configured attempt limit, obtain a new checkpoint, and prepare a new handoff. Review the whole new target again.

2.6 Complete locally like a human

Apply the /complete safety, logging, and archive behavior without asking the normal commit and local-merge prompts, because the explicit Continuous request already authorized those local actions.

For the finished feature:

1. Run the final documented verification in the current session.
2. Confirm the current spec's **Status:** is verified. When an independent receipt exists, do not rewrite the reviewed spec before archival.
3. Confirm all steps are checked, configured gates ran, no unrelated files are mixed in, adapters remain aligned, and no P0/P1 blocker remains.
4. Archive the spec under blueprint/history/features/, archive resolved findings and any passing independent-review receipt, update the exact build-plan item and parent, and reset current-feature.md and review.md.
5. If a try guide was generated, add a concise ## Manual try guide section to that feature archive so the opt-in work survives the loop.
6. Commit remaining branch work with one conventional feature-level message.
7. Switch to the local default branch, squash-merge the feature branch, and create one conventional commit containing product work, tests, and Blueprint history.
8. Delete the merged local feature branch.
9. Confirm the default branch is clean before selecting the next feature.

Never merge a partial or failing feature. Never push the default branch.

Count the feature toward continuous.maxFeatures only after its local main commit succeeds.

Step 3 - optional final integration audit

After the loop reaches its feature limit or the end of the build plan, run this step only when continuous.finalIntegrationAudit is true.

Audit the combined default-branch diff from the recorded starting commit through the current HEAD, focusing on cross-feature contracts, integration seams, security boundaries, regression risk, and missing tests. Record findings in the ledger.

For a confirmed P0 or P1 introduced by this run, automatic repair may use one dedicated configured fix branch and the same repair-attempt limit only when no product decision or scope expansion is required. Spec, verify, archive, locally squash-merge, and delete that fix branch like normal Blueprint fix work. Re-audit the repair before closing the finding.

Otherwise stop with the finding open. Do not hide it, widen into general hardening, or present the run as fully ready.

Step 4 - stop and report

A successful stop occurs when:

• every build-plan leaf is checked, or
• continuous.maxFeatures successful features were completed.

A blocked stop occurs immediately for:

• invalid or conflicting Blueprint state
• unrelated dirty work or branch drift
• an unanswered user or architecture decision
• missing design evidence for visual replication work
• unauthorized dependency, network, external-service, or destructive work
• failed verification or a gate that cannot run
• the configured repair-attempt limit
• an unresolved P0 or P1 finding
• a pending, changes-requested, malformed, or stale independent review
• merge conflict or default-branch integration drift

On a mid-feature stop, preserve the feature branch, checked steps, commits, and working tree exactly as they stand. Do not merge or delete it. A later /continuous resume picks up from that state.

On any stop, report:

• starting and ending default-branch commits
• features completed this run, each local commit, and branch cleanup state
• active feature and next unchecked step, if blocked mid-feature
• exact checks and quality gates run per feature
• generated try-guide archive locations
• audit findings and repairs
• current build-plan progress and next unchecked item
• why the loop stopped
• default branch ahead-of-upstream state already known locally
• explicit reminder that nothing was pushed

Rules

• One project, one feature, and one branch at a time.
• No user-supplied feature list is required. The build plan is the queue.
• Preserve small implementation steps and one clean local main commit per completed feature.
• workflow.stepReview does not pause Continuous Mode.
• workflow.checkpointCommits controls step checkpoints, not the required feature-level local history.
• Continuous quality gates control automatic audit, independent-review, check, and try-guide work. They never weaken Verify, testing, UI evidence, or P0/P1 blockers.
• Explicit Continuous invocation authorizes only the local Git lifecycle described here.
• Never push, deploy, publish, send, mutate remote services, or perform destructive actions.
• Never accept findings, waive failures, or make product decisions for the user.
• Stop truthfully. A resumable blocked run is better than fabricated progress.

Formatting

Follow blueprint/context/ai-interaction.md. Keep progress updates concise and feature-oriented. The final packet must be readable without the intermediate updates.