Base the technical solution for the current change on real project evidence, and compile a solution document that first allows the team to understand the big picture, then enables developers to grasp the implementation boundaries.

Only retain the current solution conclusions in the main document. Place research processes, candidate solutions, issues, decision records, review materials, and change history in a secondary directory with the same name next to the main document; the main document must be understandable without relying on these materials.

This skill is the sole deliverable owner for the technical design phase. It can call research or read requirements, migration, and UI materials, but only modifies the technical solution and its secondary materials during this phase, and does not rewrite requirement conclusions, migration dispositions, task plans, production code, or downstream completion status at the same time. Return to the corresponding phase when upstream gaps are found; do not fill in gaps on behalf of others in this phase to continue the design.

Enable new members who are unfamiliar with this session to answer the following questions solely by reading the main document:

Do not write the main document as a stack of architecture terms, file lists, database dictionaries, or implementation task lists.

The agent is responsible for the correctness of the solution. The user is responsible for deciding on clearly presented product or architecture trade-offs, and is not responsible for discovering missing call chains, existing capabilities, state conflicts, or verification gaps from the code. User confirmation is a handover gate, not proof of technical correctness or a basis for exemption.

First understand the problem, objectives, and existing requirements, then review the code, configurations, interfaces, data, tests, and project documents directly related to the implementation. Formal requirement documents are optional inputs, not prerequisites for starting the design.

If there is already a formal requirement document corresponding to the current change in the project, first check its status, pending decisions, current status and reference processes, and consistency with the user's current expression. Only the main document that has been clearly approved by the user and is in a "confirmed" status or equivalent project status can be used as input for the solution; if it is still a draft, contains pending decisions that will change user behavior, or conflicts with the user's current expression, return to the requirement phase first. The confirmed status cannot cover visible gaps in the main document: if the design investigation finds that the requirement statement retains a certain capability but does not specify specific behaviors, or the same state has different product meanings or observable results conflict with each other, the requirement must be reopened, and conclusions cannot be supplemented on behalf of the user in the solution.

When there is no formal requirement document, design can start directly based on the user's current request, but the minimum target contract must still be written at the beginning of the current conversation or solution: user objectives, main scenarios, observable results, scope, and pending items that will change product behavior. Clarify first if such pending items exist; do not force the creation of a formal requirement document or task plan if they do not exist. Under no circumstances should the current implementation, technical solutions proposed by the user, function names, or reference projects be directly regarded as requirements.

When the requirements provide a product responsibility diagram, independent flow chart, or state diagram, consume them as product behavior contracts, and first establish a mapping of "product nodes/connections → technical components/contracts". The design can choose the implementation mechanism, but cannot silently change the execution subject, trigger relationship, independent process boundaries, or convert data dependencies into control calls; return to the requirement phase if code facts prove the model is invalid.

When the user enters the design directly from a clear objective without a formal requirement document, the requirement phase is not mandatory, but complex changes still need to establish an equivalent minimum product model at the beginning of the solution: participants, business objects, independent triggers, control/data relationships, and observable results. This model is only used to prevent the technical solution from being based on incorrect product relationships, and is not expanded into a formal requirement process; pause the design and ask the user only if there are real disagreements in the model that will change product behavior.

Distinguish the following before forming the solution:

When the user provides a technical solution, first check whether it utilizes existing capabilities, truly solves the problem, matches the call chain and data facts, and introduces unnecessary complexity. Retain the reasonable main line, clearly correct invalid premises, and do not directly regard the user's solution or the agent's suggestions as project facts.

Prioritize reusing existing contracts and real links. Before proposing new fields, interfaces, tables, states, or services, first confirm that there are no equivalent capabilities in the project; if confirmation is not possible, continue the investigation or clearly mark it as pending confirmation, and do not create designs based on review questions.

Non-simple local changes must maintain in the secondary directory with the same name as the main document. Do not only list file names; record real links according to affected capabilities:

User or system entry → Page/caller → Route or interface → Responsible module → Data or external system → Return and side effects

Record the actual code, configuration, or document location and facts related to the current solution for each node. Walk through the real call and data flow, and do not infer that the link is connected based on file names, type names, or test names.

When involving user interfaces or visible interactions, walk through both the reference capabilities specified in the requirements and the current implementation to be modified, and record the reference baseline, current status of the target, and requirement objectives respectively. For each "continue to be available, remain consistent, reuse existing capabilities" in the requirements, establish an impact list, and locate the entry, page or component, field source, operation object, permission verification, result feedback, and management entry one by one. The main solution document must explain how they connect to the new link; reusing only styles, interfaces, or underlying data does not mean that user capabilities have been retained. Any visible behavior deviation from the confirmed requirements must be returned to the requirement phase for confirmation, and cannot be silently rewritten with technical solutions.

When the requirements provide fixed source code, pages, screenshots, or submissions as visual baselines, the design phase is responsible for converting them into implementable and comparable interface solutions. First count the covered pages and their requirement-related states such as loading, empty, normal, error, disabled, expanded, and narrow/wide, then form a mapping of layout, components, style resources, design tokens, responsive rules, and interaction feedback; do not require the user to first retell the pixels and controls in the baseline in text.

"1:1 restoration" means that within the baseline scope, active degradation due to component library, framework, or theme system replacement is not allowed by default. The implementation technology can be different, but any visible deviation must come from target hard constraints, license restrictions, or clear decisions by the user. The solution must define side-by-side screen-by-screen or screenshot difference verification, and include all key states in the comparison; only writing "close to the original interface", "use the target component system", or passing component tests cannot prove that the visual contract has been accepted.

The solution scope is jointly determined by the requirement objectives and actual technical impact. After initially determining the overall solution, list the pages, main processes, public components, protocol adaptation layers, state ownership, and data responsibilities that will be reused, rewritten, replaced, or bypassed, and check their existing users and accessible capabilities against the evidence baseline one by one. When the actual impact exceeds the user processes reviewed in the requirement phase, return to the requirement phase first to complete the user-visible baseline; if there is a reference migration, restore to a draft at the same time, and complete the compatibility items of the new target bearing surface. Do not regard the public bearing surface being replaced as out of scope just because the solution theme is narrow.

When users, requirements, or project materials mention other projects, templates, old versions, or existing implementations, first determine their roles in this work respectively: behavior baseline, visual reference, SDK/framework/platform candidate, data or protocol source, implementation evidence. Only the "behavior baseline" that the user requires to retain, replicate, or adapt its complete user behavior uses to establish and confirm dual baselines; visual references only investigate relevant interface semantics and visual constraints, technical candidates are used for selection, data sources are used for contract compatibility, and implementation evidence only supports corresponding mechanisms.

Do not upgrade the entire project to a feature migration just because the user uses the word "reference", provides a source code path, or a project has multiple referenceable parts. When a project assumes multiple roles, limit the scope of capabilities respectively, and do not merge them into an infinitely expanding migration contract.

When a behavior baseline exists, the user-visible differences, changes, or removals in the migration baseline must have been clearly decided by the user currently, or fall into the confirmed requirement main document; if there are no such pending items, you can directly enter the design with the user's current objectives and confirmed migration baseline. Migration materials prove the source behavior and target impact, and cannot replace the target requirement decision.

For behavior baselines, before the migration baseline meets the following conditions, the overall architecture, main link, or announcement of solution review completion that depends on this migration cannot be determined:

When the source project and target project use different frameworks, SDKs, or dependency versions, check the real code and respective version contracts of both ends at the same time. The fact that the source project adopts a certain implementation does not prove that the target version should still be the same; the fact that the target dependency provides another capability does not prove that the reference function can be omitted. It must be explained whether the semantics are still valid, whether the difference is caused by version or project constraints, and why the target solution retains or changes this behavior.

When the reference implementation or target bearing surface cannot be run or read, record the missing evidence, the cross-validation adopted, and its impact on the design conclusion as blocked items. When key user links, target compatibility capabilities, core rules, or lifecycle boundaries still cannot be confirmed, stop the corresponding solution conclusion, and cannot use "confirm during subsequent implementation" or user confirmation to replace the dual baseline investigation.

First determine the end-to-end main link, then determine the local mechanism. Do not use the number of tables, services, files, lines of main document text, or "complexity red line" to replace solution correctness. A simple solution is the one with the fewest mechanisms after meeting all confirmed behaviors and real project constraints; if the requirement mapping, existing capabilities, or failure boundaries are no longer closed after deleting a mechanism, the deletion is over-simplification.

First undertake the participants, independent triggers, control edges, and data edges in the product model one by one, then expand the technical call chain. Three or more components, multi-stage states, or two or more independent processes must be expressed with diagrams for technical mapping; clearly indicate which edges undertake product control relationships and which only read and write shared data in the diagram. The technical diagram cannot use sequential arrows to forcefully串联 independent synchronous, scheduling, Agent execution, or recovery processes that run independently in the product.

For background execution, streaming, asynchronous, approval, recovery, or cross-service changes, model the following independent lifecycles respectively, and cannot use a single , , , or summary state to control all behaviors:

Define the entry conditions, exit conditions, and recovery basis after refreshing for each state at the same time; a state with only entry conditions and no exit conditions is not considered closed. Each operation access control and completed interaction must correspond to a persistent fact that is still valid after refreshing; client memory, temporary projections, or current connection status cannot be used as the only basis.

Clarify the transition conditions and interactions between lifecycles. For example, when a long connection still exists, the business execution may be waiting for user input; at this time, whether the page allows approval, response, or sending the next message must be determined by the business contract, not by whether the connection ends.

When involving external side effects, cross-service calls, or writes that cannot be submitted atomically, check along each irreversible boundary:

Only design failure windows that actually exist under requirements, existing project constraints, or supported operation modes. Do not add a general state machine to cover theoretical risks, and do not omit existing failure contracts to avoid complexity.

When key source code, dependency versions, or real operation evidence overturn the basic premises of the overall architecture, end-to-end main link, state ownership, or protocol boundary, immediately abolish the solution conclusions, mappings, and review results that depend on this premise, and return to the evidence baseline to re-model. Do not downgrade the change of basic premises into a local patch, and continue to use the original "review closed" conclusion after continuously adding mechanisms.

If the change also overturns the reference role, target user process, or observable results used in the requirements, return the specific affected items to the requirement phase and stop the corresponding design. The design phase cannot "incidentally solve" requirement gaps by changing page entries, default behaviors, state displays, or operation objects.

When there are concurrent actions such as sending, approving, deleting, canceling, or background updating for the same business object, clarify which actions are mutually exclusive, where the atomic access control is located, how stale snapshots are rejected, and how conflicting actions are prevented before external side effects occur. Do not only describe each sequential process separately while ignoring their interleaving.

Investigate facts that can be clarified from the project on your own. Only discuss matters that must be decided by the user or team and will significantly change the technical direction.

By default, merge independent key decisions into a single round of 2–5 numbered questions. Only ask a single question if the current answer will determine whether the remaining questions are valid, or if there is indeed only one architectural disagreement.

Each question must include:

Do not ask about parameters that can be chosen by developers independently, such as function writing, field naming, SQL form, or retry seconds. Do not automatically add low-probability defense, release rituals, rollback mechanisms, or general platform capabilities to the solution; only discuss them when required by requirements, existing project constraints, or real risk evidence.

New mechanisms, user-visible behaviors, or risk handling must be mapped to confirmed requirements, existing project constraints, or specific failure paths generated by this change under supported operation modes. Only "the industry usually does this" or "it may happen in theory" cannot be used as a basis for expanding the scope or increasing the blocking level; delete the design if the mapping cannot be established, or return to the requirement phase to confirm whether it is needed.

After receiving answers, uniformly update the relevant solution chapters and change records, then process the next batch of affected decisions. Do not add scattered questions around the same topic round by round.

Create or update the main document as early as possible, and continuously integrate conclusions with research and discussions. Complex solutions adopt a layered reading order; titles can be adapted to the project, but the first layer of shared explanation cannot be omitted.

Mark the status according to project specifications when creating the main document for the first time; mark it as "Draft" if there is no project agreement. Drafts can continuously record investigations and confirmed solution conclusions, but cannot be handed over to the planning or implementation phase as a confirmed solution.

Place it at the very beginning of the main document, so that product, development, and testing teams can understand it without first understanding the code:

The shared overview only covers content that the team needs to reach consensus on, and does not include table fields, locks, hashes, leases, or file paths. When professional terms appear, explain their business meanings first, then attach the code names.

Chapterize by function links instead of mechanically dividing by database, backend, or frontend, and explain:

Each chapter first writes the conclusion and the problem it solves, then writes the mechanism and constraints. Each paragraph only expresses one central idea; use ordered lists for processes, tables for precise mappings, and prefer small flowcharts for relationships between three or more components or multi-stage states. Avoid continuous long paragraphs, stacks of abbreviations, and repeated contracts in multiple places.

Do not write all possible exceptions into the main document. Only retain boundaries that will change the shared implementation direction or cross-module collaboration; leave specific algorithms, functions, SQL, error codes, and scheduling parameters to development plans and implementation.

List the modules and key files that are expected to be added or modified, grouped by capability or link phase. For each group, first explain the responsibility changes, then list the key files and reasons for modification; when there are many files, only retain the files that determine collaboration boundaries in the main document, and place the complete list that can be mechanically derived in the secondary materials. The file list cannot be written as task steps.

Use a concise mapping to check whether each requirement behavior, scope statement, retained capability, and key boundary is undertaken by the solution; place the complete mapping in the secondary directory when there are many items, and retain the part that determines collaboration boundaries in the main document:

Requirement behavior or constraint → Solution mechanism → Responsible module → Observable verification point

Check item by item whether the modules in the mapping have been located in the evidence baseline, and whether the mechanism covers the complete link from entry to side effects. Only writing "reuse existing capabilities", "handled by frontend", or "forwarded via relay" without a real landing point does not count as undertaking.

Reverse check whether each new solution mechanism has a source from confirmed requirements, project constraints, or specific failure paths. Mechanisms without sources cannot be retained just because they can be implemented or seem more complete; return to the requirement phase when requirement gaps are found, and do not create product conclusions in the solution.

Verification priorities describe what needs to be proven, at which operation level it must be proven, and what real boundaries are used, without expanding test code or exhaustive use cases:

Cross-layer or high-risk public contracts should specify a representative end-to-end vertical closed loop in the verification design, requiring the execution phase to connect and verify it first, then expand similar work in batches. Verification points must cover the normal main process, important recovery scenarios clearly specified in the requirements, and verified failure windows.

If there is an existing relevant requirement document, follow its version and Chinese work name. Follow the user-specified path first; otherwise, follow the project specifications, and write to by default. Use "number-Chinese function name" when there is an existing item number. Link the actual existing requirement document at the beginning of the main document; do not create false links if there is none. Do not arbitrarily change the path due to title or wording changes after the document is referenced downstream.

Create a secondary directory with the same name next to the main document, and maintain an independent . Add a brief record after the solution meaning changes, explaining what was changed and why; pure typesetting, typos, and wording adjustments that do not change the meaning are not recorded. The final solution conclusions in the secondary materials must be refined back into the main document.

Enter the review cycle after the main document is basically stable. Do not assume that all problems can be found in one review, and do not mechanically re-review the entire document just because it has been modified; determine the scope of the next round based on the findings and modification impact of this round.

User review comes after solution self-inspection, and is not a means to discover technical omissions. Before submitting confirmation to the user or claiming "only review is left", complete the evidence baseline check, two-way requirement mapping, end-to-end link review, and specified independent review for the current version, fix all problems that can be verified independently, then conduct targeted review or full re-review based on the modification impact, until no new substantive problems are found in the current review. When the overall architecture, main link, reference baseline, public contract, or rules shared by multiple chapters change, the old review conclusions become invalid, and the main document remains in "Draft/Self-Inspection".

First, the main agent conducts a full-coverage review in the first round:

Summarize all findings of this round first, deduplicate and verify item by item before modifying the main document. Classify each finding before processing:

Focus on handling all substantive problems in this round; do not find one, modify one, and immediately start a new round. Review questions are only clues, not sources of solutions; any new conclusion must be traceable to requirements, project evidence, or user decisions. Do not write all details just because the independent reviewer says "not sure".

When the solution spans multiple services, involves high-risk data changes, or the main agent cannot reliably simulate the target readers, independent candidate question review must be conducted; ordinary local solutions can decide whether to use it based on risk. The number of candidate questions is not a completion standard; the review must cover two-way requirement mapping, existing capabilities, end-to-end links, independent lifecycles, real failure boundaries, and verification levels. Each candidate question must point to a specific location in the main document, explain possible different implementations and their impacts; blind reviewers can only judge whether the main document is sufficient to form a consistent understanding, and cannot assert that the project lacks capabilities, risks must be handled, or the solution needs to be expanded.

Subsequently, reviewers who can view requirements, solutions, and relevant project evidence verify the candidate questions item by item, and at least walk through one representative user link completely, checking the actual modules, lifecycle states, operation access control, persistent facts, and verification methods step by step. Record requirement basis, code or configuration facts, specific failure paths, impact scope, and processing classification. The inability of the main document to answer only proves that there may be expression or design gaps, and does not automatically prove that the project lacks contracts. Only problems that will still change the overall implementation, key contracts, module responsibilities, scope, or verifiable results after verification can become formal findings, solution decisions, or user clarification questions. When multiple perspectives are needed, try to conduct them in parallel in the same round, summarize and verify before modifying uniformly, to avoid reviewers expanding or over-simplifying the solution sequentially.

After each round of modification, determine the next step based on the impact scope:

Ordinary solutions end after no substantive problems are found in one round of review. Solutions involving cross-services, high-risk data changes, or affecting multiple teams can require no new substantive problems in two consecutive rounds. Substantive problems only include differences that will lead to different understandings of the overall implementation, key contracts, module responsibilities, scope, or verifiable results; implementation parameters, wording preferences, and speculative reinforcement do not trigger a new round.

Do not specify a fixed number of candidate questions, formal findings, or review rounds. Place the scope of each round, candidate questions and verification basis, substantive findings, processing results, unaccepted items, and reasons for continuing the review in the secondary directory with the same name, and do not write "review passed" in the main document.

Completion of the solution phase does not mean that no unknown problems exist. Only when the specified investigation and review have been executed, each bearing surface and its users in the actual impact have been identified, the evidence baseline covers all affected links, the dual baselines of the specified reference implementation have been confirmed and each source capability and target compatibility item has a solution disposition, each requirement and retained capability has a real solution undertaking, independent lifecycles and real failure boundaries have been closed, verification levels are sufficient to prove delivery behaviors, candidate questions have been verified and classified, substantive problems have been solved, and the user has reviewed and clearly approved the current main document, can the main document be marked as confirmed and allowed to directly enter execution or planning as needed.

If omissions that the agent should have found through code investigation, reference implementation reverse-engineering, version difference checking, link walkthrough, requirement mapping, or solution review are found after user confirmation, treat them as solution defects and reopen the main document, and cannot attribute them to the user's previous confirmation. When the overall architecture, main link, data ownership, public contract, scope, or verifiable results change, re-mark it as draft and confirm the affected content; if the change comes from omitted reference behaviors or incorrect version assumptions, reopen the migration baseline and full-coverage review at the same time.