Architecture transforms a complete Product and business Domain into a current technical structure in which subsequent changes can be made safely. It does not predict a future completed blueprint, but publishes the smallest consistent foundation such that the next step does not need to newly create major technical boundaries.
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 terminating at a gate.
Enter under valid conditions
Before starting the per-target actions, open references/project-gate.mdand apply the architecture condition. Then open
references/project-knowledge.md, references/architecture-document.mdand the readable
.devflow/index.md. Only when creating or replacing a decision document, open
references/decision-document.md.
If the current member's Sketch state specifies next_route로 architecture, then before writing the file open
references/sketch-handoff.mdand complete the landing contract together with the Architecture publication.
Read the complete Product, and open only the Domain and Architecture lineage that the current technical question routes to. If the Product meaning is incomplete or contradictory, send it to product, and unabsorbed maintained brownfield meaning to adopt.
However, if an in-progress Adopt has sent a technical judgment here via state, do not send it back to Adopt but handle only that judgment.
Code, configuration, runtime, and official technical evidence that can be confirmed in the current conversation are checked first. If additional investigation or a prototype is needed and that question and context must be preserved beyond the current stewardship interval, do not leave incomplete canon but send it to sketch.
Exploration and review perspectives
When Product·Domain constraints and code/runtime evidence do not settle on a single structure, Architecture constructs, as a hypothesis, a current technical structure that can explain this, like Peirce's abduction, and distinguishes it from confirmed facts. Through systems thinking, it also considers the second-order effects of changing components, flows, operational responsibilities, and current technical boundaries. Important technical claims are connected to a verification channel in which failure can be observed, like Popper's critical test, but it does not pre-experiment with every reversible choice or inflate small decisions into a full redesign.
First create the current technical description
Before asking the user for a technical list, create a single current technical description from the Product·Domain contract, stated constraints, current decisions, and related code/runtime evidence. It reveals what must be run and deployed, which conditions change the structure, and what boundaries are already decided and what choices lack evidence.
Do not ask in turn for document items, framework names, and pattern lists. Between the current description and the common Architecture contract, keep as question candidates only the points where the actual technical boundary differs depending on the answer.
Separate out only the questions to decide now
If an empty choice requires the next step to invent a major boundary anew, handle it now. Do not decide in advance reversible local choices that can be learned cheaply during implementation.
If multiple candidates actually hold, compare the smallest candidate satisfying the current constraints by outcome, reversibility, operational responsibility, and verification cost, and Architecture recommends one. Ask only when constraints remain that only the user can decide, such as cost, operating entity, supported environment, and external contracts. In questions, explain the current understanding, the recommendation, and the structure that changes depending on the answer.
According to this criterion, only just before actually asking for the user's explanation or binding choice,
references/question-dialogue.mdopen and apply it to the question phrasing.
If a judgment received in an ongoing adoption is handed off to another route, before leaving, replace the adoption state with one route that will take over that judgment and one scoped next action.
Publish the current Architecture
references/architecture-document.mdapply the completion conditions and split/fold determination of
project/architecture.mdand configure the necessary children and replace the existing files. Even if a determination is made that a machine-readable model or automated check is needed, do not implement it in Architecture. Publish the invariants to preserve, observable violations, and unverified scope, and leave the implementation as a change handled later by direct.
If the important reason, rejected alternatives, or reconsideration conditions are needed, references/decision-document.mdopen and create or replace one current decision document. Do not create it to leave a copy of work facts, the stack list, and current rules.
In the same change, .devflow/index.mdlet route technical questions to the Architecture root and determine foundation readiness. Do not copy leaves and technical answers into the index.
If it is a judgment received in an ongoing adoption, first publish the canonical Architecture and decision and route, then according to the common gate replace the adoption state with next_route: adoptand one action to continue with. Do not continue as an independent new foundation flow.
Re-read the current outcome and route
Re-read the Architecture root and the child lineage selected for the current question. This child may be in the Architecture subtree or in one Domain's technical subtree. Also check the index and the Product and Domain boundaries. Check whether business meaning has moved or technical facts have been duplicated into another home, whether invariants and replaceable choices have been mixed, and whether the verification channel is executable or explicitly unverified.
If a judgment received in an ongoing adoption has been published, route to adoptbefore any other route.
If Architecture has declared a need for Design and there is no complete Design or experiential judgment is needed again due to this change, specify the surface and constraints to decide and route to design. If Design does not apply or the necessary Design is already complete, route the new foundation to direct. Route unresolved product premises to product,
if investigation to preserve is needed, to sketch, and active change decisions whose canonical update is complete, to direct.
Report the following.
게시한 경로:Architecture, concern, decision, index path created or replaced구조:Components, dependency direction, runtime/data flow, public seam선택 근거:Constraints and evidence that governed the structure, and a brief reason for the choice Architecture made검증:Executable channels and claims that cannot be used or are unverifiedDesign 적용 여부:One of needed, not applied, or open, and the reasonRoute와 행동:One next route and one bounded action미검증 또는 열린 항목:Technical claims that cannot be confirmed with current evidence
Do not write the business meaning of the Product or Domain, Design principles, Work artifacts, implementation, adoption inventory, or verification verdict.