Sb Adopt

Establish Specs from a fixed existing implementation

Apply project language style

Before authoring any artifact or user-facing prose, read:

specbind rule read language-style --for consume

Apply returned policy only to natural-language prose. NO_CHANGE RULE_ABSENT means no additional project preference; any ERROR line stops the workflow.

Read this procedure completely only when the maintainer explicitly asks to establish Specs from existing code and tests or to resume an active reverse establishment. This is reverse establishment, not ordinary change Discovery and not a product release.

Existing code and tests are evidence, never automatic authority for what the product ought to promise. Reverse establishment creates no Tasks and never changes implementation, tests, dependencies, configuration, or Steering.

Fix the evidence and version

Run the read-only route preflight first:

specbind adoption preflight

It reports exactly one ready result:

• ADOPTION_PREFLIGHT_READY starts a new reverse establishment. Record its exact source_revision and continue with this section.
• ADOPTION_RESUME_READY proves a clean, internally consistent active reverse milestone, matching temporary record, and unchanged implementation source. Go directly to Resume an active reverse milestone.

If it stops on missing Steering, report that sb-steering is a separate maintainer-gated workflow and stop this reverse run. Do not select or perform Steering repair inline.

Only after preflight is ready, require the maintainer to name the selected area and the product version already represented by the code. If either is missing, ask only for the missing value before mutation. baseline_version names an existing version; never invent the next version or bind target_release.

Then run:

specbind steering list
specbind steering read <every-selector> --for consume

Steering must establish product purpose, technology and verification constraints, and responsibility placement. Internally contradictory Steering stops and routes to the same separate maintainer-gated sb-steering workflow; do not repair it in this run. A difference between valid Steering and observed implementation is not itself a reason to bypass the proposal: classify it below as a suspected defect or an unknown.

The revision is fixed. From now until finalization, do not change code, tests, dependencies, configuration, or Steering. A changed source makes the reverse result stale and requires a new run. Do not rebaseline it.

Collect independent evidence

Map the repository broadly, then inspect the selected area deeply. When the host exposes agent delegation, you MUST dispatch at least two fresh readers in parallel before synthesizing the boundary proposal: one for observable behavior and tests, and one for structure, dependencies, and seams. If delegation is not available, collect those evidence lines yourself and say so in the proposal. All claims are about the fixed revision.

For each candidate Spec collect precise project-relative locators for:

• externally observable behavior and acceptance evidence;
• owned responsibility, public entry points, and neighboring boundaries;
• structural constraints relevant to Design; and
• unknowns, contradictions, and suspected defects.

Shared catalogs or assets with no independent behavior may become resources in the optional project shared Contract. Do not create a reverse Spec merely to hold such files. Read specbind contract shared read and specbind schema read shared-contract/v1; include any proposed resource paths, change policy, invariants, and consumer boundaries in the evidence-led proposal below. Unknown maintained guarantees remain blocking rather than invented.

Code is evidence, never specification authority. Classify an observation as maintained requirement, Design constraint, historical constraint, implementation detail, suspected defect, blocking unknown, or deferred unknown. A deferred unknown is allowed only when every later answer leaves current Spec meaning unchanged. Otherwise it is blocking.

After the fresh readers return, build one closed contradiction ledger before synthesizing the proposal. Compare every direct claim they touched in valid Steering with the corresponding selected implementation, test, or product documentation evidence. Give every difference exactly one visible disposition: blocking unknown, deferred unknown, pending suspected-defect record, or excluded historical detail with its reason. Do not silently drop a naming, behavior, or boundary mismatch merely because it does not change a Spec's meaning. The proposal fields below are the projection of this complete ledger.

Discover the Deferred Findings Adapter rather than deriving a selector from its type name:

specbind adapter read deferred --for consume

NO_CHANGE ADAPTER_ABSENT or NO_CHANGE ADAPTER_SCAFFOLD means the project has no destination. Any ERROR stops adapter use; do not guess deferred-findings or another selector. Otherwise follow the returned active guidance.

When the active adapter accepts an exact local destination, prepare a suspected defect with source revision, locator, and claim, and inspect the destination only far enough to deduplicate on those three fields. Do not call it a confirmed bug, correct it, or write the destination before the reverse milestone exists. External posting needs separate authority. Findings never change reverse scope.

Present one complete proposal

This is one complete proposal and the only confirmation boundary for the reverse run.

Do not stop before this proposal merely because implementation evidence differs from valid Steering. Put the exact semantic question under Blocking unknowns when its answer changes maintained meaning; otherwise classify it as a suspected defect or deferred unknown.

Present exactly one proposal containing:

Mode: reverse
Source revision: <full object ID>
Baseline version: <existing product version>
Selected area: <area>
Reverse Specs: <id, responsibility, maintained intent, evidence basis>
Dependencies: <Spec edges or None>
Shared resources: <resource IDs, paths, proposed guarantees, evidence, and consumers or None>
Blocking unknowns: <questions that prevent meaningful Specs or None>
Deferred unknowns: <recorded non-semantic choices or None>
Suspected defects: <pending adapter records or None>
Excluded area: <outside the reverse scope or None>
After confirmation: create the reverse milestone and continue through
Requirements, Design, Design validation, Contract Review, and adoption finalize.
No Tasks, implementation change, or product release will be created.

The invocation is not confirmation. Revise the proposal on feedback. Do not create partial scope while any candidate has a blocking semantic unknown. After the maintainer explicitly confirms this visible proposal, do not ask for a second boundary, scope, or phase confirmation.

Create the reverse milestone

Create one external candidate JSON document with schemaVersion: 1, the confirmed baselineVersion, and only workItems.reverseSpecs. Each item has spec, summary, and optional dependsOn. Then run:

specbind milestone create --scope <external-candidate-or->

Verify that every created spec.yaml contains matching establishment.kind: reverse, source_revision, baseline_version, and milestone_id. Write each confirmed Brief and evidence-oriented Research handoff. Read specDir from .specbind.json and use that value literally for the temporary adoption record at <specDir>/adoption/reverse-discovery.yaml until finalization. Do not insert a specs/ segment: for "specDir": ".specbind", write .specbind/adoption/reverse-discovery.yaml, never .specbind/specs/adoption/reverse-discovery.yaml. The specs/ child contains durable Specs; keeping the temporary record outside it prevents the record from entering Spec discovery or the Contract graph. Record the fixed revision, selected area, proposal, observation classifications, and exact evidence locators without copying source text. For every pending suspected defect that is written, also record its exact project-relative destination; finalization uses that checkpointed field to distinguish the adapter output from source drift.

Only after milestone creation and provenance verification, rerun specbind adapter read deferred --for consume. If the same exact local destination is still active, append each pending suspected defect that is not already present. If it is absent or changed, record nothing and report the adapter mismatch; never invent or recover a destination. This post-creation write preserves the fixed clean baseline.

If the confirmed proposal includes shared resources, author only those agreements in <specDir>/shared-contract.yaml before consumer Design. The reverse milestone's confirmation supplies this authority; do not add delivery Direct items or invoke delivery shared planning. Existing implementation stays unchanged. Use Contract v2 only for Specs that consume a shared resource. Include the shared proposal in the following checkpoint and in milestone Contract Review; preserve it through adoption finalization.

Checkpoint the reverse Roadmap and Spec state, shared proposal when scoped, Briefs, Research, temporary adoption record, and the verified deferred destination when written as one Discovery unit according to the active Git Adapter. Admit no other dirty path. Never infer push authority.

Resume an active reverse milestone

Enter here only after ADOPTION_RESUME_READY and only when the maintainer explicitly asked to resume this reverse establishment. A generic request to drive an active milestone does not grant the remaining Requirements or Design Gate authority; return HUMAN_DECISION to sb-drive until the maintainer names reverse continuation.

Do not rerun repository discovery, synthesize another proposal, change the confirmed reverse scope, dispatch the initial evidence readers again, or create another temporary record. The active Roadmap, Specs, Briefs, Research, and record are the checkpointed continuation inputs. Run:

specbind milestone status --json

The result must report milestoneKind=reverse, and every actionable entry must name handler.kind=skill, handler.target=sb-adopt, and handler.mode=reverse_resume. Any other handler, inconsistent health, source drift, or dirty checkout stops the run without repair.

An explicit maintainer request to resume authorizes the remaining reverse orchestration under delegated workflow sb-adopt; it does not authorize a scope change, implementation change, release, external write, or destructive recovery. Continue only the phase-relative actions the fresh status exposes. Already approved phases remain accepted and are not repeated.

When the action is contract_review, dispatch the installed sb-contract-review workflow with this reverse continuation authority and return here after its accepted checkpoint. sb-adopt remains the status handler because it owns the reverse continuation and subsequent finalization; it does not replace the phase owner's review procedure. The review's assessment and findings must still be presented before acceptance. Do not pause for another confirmation: the explicit reverse continuation authority permits acceptance after that presentation.

Continue without routine pauses

The confirmation above authorizes this establishment orchestration, including Requirements and Design gate acceptance under delegated workflow sb-adopt. For every actionable reverse Spec, follow the installed sb-plan Requirements and Design procedures and their full checks. Run Design validation after each new Design draft, then the milestone Contract Review when status exposes that global action. Do not select or author the Tasks procedure. Design approval must report adoption_ready.

Keep progressing every independent Spec when one is blocked. Stop the affected Spec only for a question whose answer changes maintained meaning; global Contract Review and finalization wait until all such questions are resolved. Stop the whole run on source drift, invalid evidence, a failed mechanical guard, or an implementation/configuration/Steering change.

An ordinary change request arriving during this run may be explained as a future proposal, but it must not update the reverse Roadmap. Finalize reverse first, then use a new ordinary milestone. For an emergency, show the active milestone ID and ask for explicit abandonment. Only after confirmation run specbind milestone reverse abandon --milestone-id <id>; never delete lifecycle state manually. After the urgent change, reverse starts again from the new clean revision, but only after the abandonment checkpoint below closes.

After successful abandonment, verify the exact CLI-owned deletion set reported by the command: the active reverse Roadmap, accepted Contract Review when present, temporary adoption record, and every participating reverse Spec directory. Reject any additional changed path. Read specbind adapter read git --for consume and checkpoint only that verified abandonment set. If the adapter is absent or scaffolded, prohibits a commit, is ambiguous, or the checkpoint fails, report the valid abandonment and exact dirty paths and stop. Do not begin urgent source work or ordinary Discovery, and do not stash, discard, or amend the deletion delta. Those clean-gated workflows resume only after this checkpoint closes.

Finalize as an adopted baseline

When every reverse Spec is adoption_ready and the Contract Review is fresh, prepare one strict JSON document with exactly one entry per participating Spec:

{"log_entries":[{"spec":"<spec-id>","summary":"<one-line summary>"}]}

spec is the exact participating Spec ID, summary is a non-empty single line, and extra or duplicate entries are invalid. Pass its external path, or pass - and write that JSON to stdin:

specbind milestone reverse finalize --log-entries <path-or->

Finalization writes Baseline entries to each log.md, retains establishment provenance, archives Roadmap and Contract Review under baselines/, removes the temporary Brief and Research artifacts and the adoption record, and closes the milestone. It also retires this temporary Skill for every configured Agent and records adoption as disabled in .specbind.json. It must not run a Release Adapter, bind a target release, tag, publish, or claim that the product was released.

After every successful finalization, verify the exact reported finalization write/removal set, then read specbind adapter read git --for consume and checkpoint only those changes. This checkpoint is mandatory before reporting a clean handoff or performing any follow-up configuration work. If the adapter is absent or scaffolded, prohibits a commit, is ambiguous, or the checkpoint fails, the adopted baseline remains final; report its exact dirty paths and stop. Do not stash, discard, amend, or combine unrelated work with finalization.

If finalization reports that Skill retirement remains pending, the adopted baseline is still final. Checkpoint the finalization changes first, then run specbind install --without-adoption to retry only the managed retirement. Do not rerun finalization.