adopt-dev-flow

Adopt Dev Flow

Bind the existing repository to one shared core and profile-native routes. Do not replace a working planning provider, workflow runtime, or delivery provider.

Audit

Read ../../references/kernel.md and the existing repository authorities. Map project context, required briefs, any planning provider, local execution groups, execution state, delivery, scope, and observation. A provider-backed item keeps one external planning authority and a complete Planning Receipt; a standalone item uses its Captain-approved committed brief. The workflow runtime owns only its admitted snapshot, execution record, and evidence. Each item has one planning authority and one execution-record authority. Classify the relevant seams as working, broken, stubbed, or missing; repair the cheapest compatible seam. Before interpreting an existing source as Planning Receipt data, preserve repository-local free text in a repository-owned field and remove the canonical source field. Do not reinterpret provenance as provider identity.

Adopt

1. Add a concise ## Local Profile near the workflow frontmatter, bounded by exactly one start marker <!-- kc-dev-flow-static-local-profile:start --> and one end marker <!-- kc-dev-flow-static-local-profile:end -->. Bind existing authorities plus Installed contract interface, Local mods, and the repository's work-item and state authorities. The activated skill anchors its own package root and supplies ../../scripts/profile-contract-loader.py for that invocation; do not persist an installation path. A repository that supports Planning Receipts binds its provider, read-only reader, and installed engage comparator. Linear uses installed sibling linear-admission.py; other providers keep a repository-local adapter. That sibling needs LINEAR_API_KEY in the invoking process environment, which is provider credential rather than host binding, and a state authority at <workflow-dir>/.spacedock-state that is its own committed git root. It reads no other environment variable to decide whether to run, so a VM, a CI runner, and a plain shell are all supported hosts. A repository whose state lives inline in the workflow directory has no such root; the reader refuses it with state authority is not <workflow-dir>/.spacedock-state, so raise that layout as a refit requirement against the package and keep the repository-local adapter until then. Work with no planning provider at all records no Planning Receipt, invokes no reader, and needs no credential. The reader normalizes the union of current Ready items for one planning window/outcome and every currently Ready snapshot source even when it moved; it refuses a truncated result and exposes source identity, accepted goal, and non-goals without writing either system. A standalone adopter binds the Captain-approved committed brief and installs no provider adapter. Do not mirror live provider status into a Roadmap or execution record.
2. Read ../../contract-manifest.json beside the activated skill. It declares the contract interface, Local Profile interface, and exact plugin-owned runtime resources. Run its sibling installed loader from that same package; do not search host caches, inspect host names, copy canonical resources into the repository, or add a repository fallback. Provider-backed work uses its reader and installed engage-reconcile.py; standalone uses neither. The selected stage owns each typed conditional-reference trigger; installation does not load a reference. Local provider paths, README policy, local mods, and Spacedock state remain repository-owned. The manifest's resources list is the boundary for what adoption adds to the repository: adoption binds existing repository authorities and adds no repository-owned reader, adapter, script, test, or check for a capability a declared resource already supplies. A capability the package lacks is a refit requirement raised against the package, with one exception: a planning provider the package does not support keeps a repository-local adapter.
3. Select a profile before the first working stage and store the v3 receipt in the existing work item. Each item selects independently; do not create a project-global profile or another profile registry. Invoke the loader with the exact work item so simultaneous items cannot borrow each other's route. Require the Development Brief for Pilot and Production or the v3 Exploration Brief for POC. A Planning Receipt is complete or absent: provider-backed work records source, planning-window, and planning-outcome; standalone work records none of them. A partial tuple stops. Local sprint and sprint-readiness remain runtime grouping and readiness mechanics, not planning evidence. When the provider uses Issue bodies as admission packets, each body starts directly with ## The problem and omits both an ## Agent execution contract section and a ## Human-readable release brief wrapper, carrying these headings in this order: