continue-dev-flow

Continue Dev Flow

Continue by the selected profile's smallest sufficient route.

Resolve authority before policy

1. Locate the workflow README via the nearest repository instructions. Require the unique ordered kc-dev-flow-static-local-profile start/end marker pair, with ## Local Profile immediately after start. Read only its frontmatter and marked block; never infer boundaries from headings or open the full README.
2. Recheck the worktree, branch, shared-state owner, and remote delivery state. When this item is delivered through a reviewable delivery artifact, list the open artifacts before creating or reusing a branch. An open unmerged artifact that carries work this item builds on is the default base: branch from its source branch and stack, rather than branching from the trunk or waiting for it to merge. delivery-branch-base.md owns the rule and its exceptions, and applies whoever owns the delivery ceremony.
3. Read the exact committed work item and selected brief. A Pilot or Production new admission requires one Development Brief containing the problem, accepted outcome, complete non-goal list, route-back conditions, and one canonical ## Acceptance criteria section with unique ascending AC-N bullets. A POC item uses its complete v3 decision, falsifier, budget, and stop condition as the Exploration Brief. Do not read current execution state or revalidate and rewrite an already-admitted item's historical headings.
4. Classify its optional Planning Receipt before provider access. The receipt is exactly source, planning-window, and planning-outcome:
   • when all Planning Receipt fields are absent, use the Captain-approved committed brief as planning authority and do not invoke a provider reader or comparator;
   • when all Planning Receipt fields are present, run provider reconcile only for the provider-backed branch below. For a new Pilot or Production admission, first invoke the repository-local profile loader's explicit --validate-admission mode; default continuation never selects that mode; and
   • otherwise report planning receipt incomplete and stop before reading execution state or mutating it.
5. In the provider-backed branch, follow the exact work item's source to the accepted planning item and invoke the repository-local read-only planning reader. Read the item for the problem, decision, success condition, priority, and human-facing status, and obtain the union of the provider's current Ready set for the recorded planning window/outcome and every currently Ready snapshot source even when its current window or outcome moved. Refuse a truncated provider result. If source is not a resolvable planning link, report planning source unavailable and stop before reading execution state. If the reader or its inputs are unavailable, report planning reconcile unavailable and stop at the same boundary. Do not promote the admission snapshot into planning authority or invent, migrate, or rewrite its planning item.
6. Still in that branch, compare the current Ready set with the committed execution snapshot selected through the adapter's local grouping. Compare source identity and membership, planning-window, planning-outcome, accepted goal, and non-goals; classify each difference as added, removed, changed, or moved. Normalize both sets into ephemeral JSON lists whose items contain source, planning-window, planning-outcome, accepted-goal, and string-list non-goals. Do not commit or reuse those files. Refuse the snapshot unless every item shares the exact window and outcome read from the engaged item.
7. Invoke the repository-local read-only engage comparator only in the provider-backed branch.