adopt

Transferring Brownfield knowledge ownership

Adopt moves the authority to understand an unmanaged existing project .devflow/ inward. It does not require the user to summarize old documents for permanent reference, migrate the previous Devflow format, or re-explain facts that can be confirmed from maintenance sources.

Before performing this skill, open references/communication.mdand apply it to natural language sent to readers or stored in documents during execution. This includes guidance sent when exiting at a gate.

Enter the unmanaged project gate

Before performing target-specific actions, open references/project-gate.mdand apply the adopt row. Then open references/project-knowledge.md. If a readable .devflow/index.mdalready exists, read it first and determine whether this is an in-progress adoption or a newly discovered brownfield boundary.

Before composing or replacing Product or Domain documents, open references/product-document.mdand apply it to the document's content and completion criteria.

Before composing or replacing an Architecture root or concern child, references/architecture-document.mdopen. Open references/decision-document.mdonly when creating or replacing the current decision document for Product, Architecture, or Design.

Before composing or replacing a Design root or concern child, open references/design-document.md.

Enter only when the user has explicitly requested adoption of an existing project, or when another Devflow route has discovered maintained brownfield material without an internal foundation. A clear new brief goes to product, an uncertain new idea goes to sketch, and changes to a managed project go to its owning route. Do not recognize legacy Devflow files as an upgrade protocol or import them as a runtime fallback.

Before writing, inspect Git status and identify the repository boundary. Preserve unrelated dirty bytes. Ask only when the maintained source boundary itself cannot be determined from repository evidence. Generated output, dependencies, caches, and VCS metadata are not maintained knowledge merely because they exist.

Account for all maintained sources

Into a recoverable current workspace, create .devflow/adoption/. Publish state.md, sources.md, conflicts.mdwith a common routing header. state.mdis a single snapshot that is replaced.

next_route: adopt
next_action: <하나의 범위가 정해진 inventory, reconstruction, decision 또는 disposition 행동>
blockers: []

Do not put the coverage table, conflict copies, progress, phase, conversation, or source file list into state. If management authority may change before the current action is completed, replace state first. The actor of the published route owns the snapshot. If management authority is ambiguous, do not overwrite; send it to the user.

Fixed key adoptionIf there is a note with a defined scope corresponding to, or a local delta that must be preserved even after handoff, environment-specific context, or provisional context, then references/team-context.mdis opened. Otherwise, skipped.

sources.mddefines the maintained input universe and divides it into scoped source groups. For each group, record the following.

Exact include path or glob, and complementary exclusions that reveal overlap
Source nature and authority: intent prose, executable behavior, test, configuration, operation, generated evidence, or another specific role
The kind of knowledge sought and one internal target home
Current disposition: landed, conflict, pending, retained live evidence, noncanonical preservation, pointer replacement, move, or deletion
Total number of uncovered maintained paths

Maintained prose each has a disposition. Homogeneous code, test, or configuration may be grouped only when the include/exclude boundary can be checked and they actually share authority, sought knowledge, target, and disposition. Coverage is complete when a group omits no maintained path. This is not evidence that its meaning was understood.

At the same adoption boundary, a small .devflow/index.mdis created or updated. It does not duplicate answers but indicates project direction and routes current Product, Domain, Architecture, Design, and adoption questions. For immediate recovery, it exposes only the team/<current-member>/sketches/*/state.md, adoption/state.md, work/*/state.md glob and derives readiness from current canon and adoption status. It does not enumerate source groups or active artifact IDs.

Reconstructs meaning, not prose

각 source를 sources.mdis read according to the authority recorded in. Executed code and tests can confirm current behavior, but cannot silently choose a conflicting product promise. Intent prose can confirm user meaning, but cannot override observed runtime behavior without revealing divergence. Configuration is current state and confirms the environment only in the scope in which it is actually used.

Existing ADRs or decision records are split into the current rule, the current reason to keep following that rule, and the historical record. The current rule stays in its original canonical home, and the reason is reconstructed into the current decision document only when still needed. Completed migrations and superseded past conclusions are disposed of according to the existing disposition rules.

A maintained source is treated as a knowledge unit only when it asserts some content or explicitly asks a question, or when current execution is needed to interpret such a source-backed claim. Do not turn other absences, untested cases, or possible future decisions into facts or unknowns. Each knowledge unit is classified as one of the following.

An observed fact directly supported by a current source or execution
An interpretation with evidence, remaining uncertainty, and confirmation condition alongside it
An unknown explicitly raised by a maintained source but resolved by no source. Record it only once, together with the decision it would change.
A conflict where maintained sources support mutually incompatible current answers

If there is no claim in any maintained source that supports the product's purpose, target, or core promise and thus a self-contained Product cannot be created, do not infer intent from behavior. Distinguish the behavior that the current source confirms from product meaning that cannot be determined by that behavior alone, and productsend to .

First reconstruct the current structure from the current code, configuration actually in use, and runtime evidence. Only when the technical boundary cannot be determined from this evidence alone and depends on user constraints and is absolutely necessary to complete the Architecture, do not make it a conflict but set the state to next_route: architectureand record the necessary judgment in next_actionreplace with .

Each unit has as its internal home one document of the decision route that resolves it, and places it next to the sentence that defines it. Other homes may link to that unit but do not catalog it again for completeness.

complete current .devflow/project/product.md, necessary .devflow/project/domains/<domain>/index.md Domain parent, project/architecture.mddisclose . project/design.mdis disclosed only when the Architecture says Design applies and there are current interaction, presentation, accessibility, component, or review rules in the maintained source that can be reconstructed. A Product promise or goal for any surface is not Design knowledge. If Design applies but there is no such rule in the source, do not disclose a placeholder Design. The Architecture reveals applicability, and after the preceding adoption decision is closed, the next foundation route becomes design.

Apply the common split test before creating a conditional concern child. Product owns the user, promise, boundary, shared language, and cross-domain composition. Each Domain owns only its own work state and rules. Architecture owns technical seams, dependency direction, runtime/data behavior, verification channels, and Design applicability. Design owns experience principles and review surfaces. Do not duplicate facts; reference these homes to one another.

Every disclosed document must be understandable even after outdated prose is removed. Replace external references with self-contained current statements, not summaries that require reopening the input. Code, tests, and live operational assets may remain as current evidence, but their paths do not become a second project knowledge canon.

reveal only unresolvable conflicts

conflicts.mdcontains only contradictions that cannot be resolved by source authority and current evidence alone. For each, write the incompatible claims, evidence on both sides, the affected current judgment, interpretations already excluded, the exact decision needed, the owning route, and the resolution confirmation condition. If nothing remains, write so directly. Do not preserve resolved conflict history as current truth.

Product or Domain meaning is sent to product, technical meaning to architecture, experience meaning to design. That decision route owns the conflict and absorbs the answer into the question's canonical home. Even when the owner must choose, put the Domain rule in the corresponding Domain index, and the promise or boundary in Product. next_route: userOnly a sufficiently constructed choice that has written the decision route to absorb the answer into action can be delivered. Ask the user only after showing the competing answers and consequences. Do not polish an answer fabricated to make the foundation appear complete. Only immediately before actually asking for the user's explanation or binding choice, references/question-dialogue.mdis opened and applied to the question expression.

Distinguish between cases where product meaning conflicts between materials and cases where there is no material to support the product meaning. The former is conflicts.mdrecorded in. The latter is not made into a conflict, and the state is replaced with next_route: productand the necessary product judgment and the source path for Product to read, written in next_action. Do not duplicate confirmed facts in the state.

When the route that received the decision posts the answer to the corresponding canonical home and returns the state to next_route: adopt, the conflict resolved by that answer is erased from conflicts.md, and the remaining source accounting and foundation completion continue based on the posted meaning. Before that, do not guess the necessary meaning to make the canon appear complete or close adoption.

Open work only within proven boundaries

Adoption can proceed as a vertical slice, but the entire repository that has not yet been accounted for is not ready. The requested tracked change boundary is eligible only when all three of the following facts can be confirmed in the current files.

All maintained sources that could affect that change have a disposition in sources.md.
The Product, Domain, Architecture, Design, and cross-domain canon necessary for the change are self-contained.
No unresolved conflict affects that change boundary.

This is derived evidence, not a status field. If all three conditions are true, the state can send that exact boundary and scoped change to direct, and other adoptions remain open. If any one is uncertain, next_route: adopt or maintain one decision route and do not create Work.

Migrate or discard outdated prose

Existing documentation loses project truth authority only after all of its unique current knowledge has been reflected or made into an explicit conflict. The final disposition is one of: deletion, moving outside the current search surface, replacement with the minimum pointer required by the host, or preservation with a clear statement that it is not Devflow project truth and has no unique project knowledge. Before destructive handling or purpose changes that are not already authorized, ask for user decision.

Do not mark outdated documents as noncanonical while leaving a unique fact behind. Do not leave the entire old manual next to the new canon for reassurance. Runtime code, tests, and configuration remain in the positions required by their operational roles. Disposition changes knowledge authority and does not change execution role.

Close only after fully migrating

Close adoption when every maintained source group is landed, retained live evidence, is in an explicit conflict or noncanonical state according to the above rules, uncovered paths are 0, all conflicts are resolved, and the complete Product, Architecture, applicable Design, Domain, and decision knowledge is self-contained. After updating the index so that readiness and the next route reflect this result, adoption/and all team/*/adoption.md files are removed. Git preserves the reconstruction history.

After closure, test meaning, not file existence. In a state where the old prose is absent or intentionally contradictory, .devflow/project/use only to answer representative Product, Domain, and Architecture questions. A fresh reader must choose the internal canon and report remaining contradictions as non-authoritative. If this was not observed, external input independence is unproven.

Return the following.

Coverage: maintained source groups, excluded paths, number of paths not included
Published: all canonical projects and adoption paths created or replaced
Conflicts와 unknowns: open decisions and routes, or none
Ready boundary: the requested change boundary that satisfies the three readiness facts, or none
Source disposition: old prose and live source handling still needed
Route와 행동: one next route and one scoped action

Does not implement product changes, create Work contracts, migrate legacy Devflow state, or claim that path coverage proves semantic completeness.