anyone-can-architect 0.2.0 → 0.4.0

package/dist/antigravity/aca-repo-audit/SKILL.md

@@ -34,7 +34,7 @@ Use `/aca-review` when you need to judge whether business goals and design solut
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.gemini/config/skills/aca/SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item
@@ -53,6 +53,8 @@ Use `/aca-review` when you need to judge whether business goals and design solut
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context
@@ -181,16 +183,17 @@ When an implementation audit is included, cross-check all design items in scope
 
 ### 5.2 Runtime Verification
 
-1. Determine verification requirements
-   Read the full test and build commands specified by the repository
+1. **Determine verification requirements**
+   Determine the test and build commands required for the current scope according to the boundary rules in `/aca-test` and the repository `release` doc
+   Run full tests and builds by default when the repository does not specify tiered verification
    Check the required environment, configuration, and fixtures
-2. Run verification or reuse its results
-   Reuse existing results if they cover the required verification and the content under review, tests, fixtures, configuration, dependency environment, and commands have not changed
+2. **Run verification or reuse its results**
+   Reuse existing `/aca-test` or build results if they cover the required scope and the commit under review, tests, fixtures, configuration, dependency environment, and commands have not changed
    State the original verification results and the basis for reuse in the report
-   Run the corresponding verification in an isolated environment if the reuse conditions are not met
+   Run the required tests and builds in an isolated environment following the execution rules of `/aca-test` if the reuse conditions are not met
    Static reading cannot replace verification by execution
    Do not modify project source code, design docs, or commit history during verification
-3. Record results and handle exceptions
+3. **Record results and handle exceptions**
    Record the results and supporting evidence when verification passes
    Verify diagnostics and record confirmed issues when verification fails
    Mark the corresponding verification as incomplete and explain why if the environment is unavailable or execution is not possible
@@ -223,7 +226,7 @@ When an implementation audit is included, cross-check all design items in scope
 | Incomplete | Pass conditions are not met, and no confirmed must fix items exist |
 
 Required checks include reading documentation, mechanical checks, and content checks in the current scope
-When an implementation audit is included, they also include all consistency cross-checks, full tests, and builds
+When an implementation audit is included, they also include all consistency cross-checks and the tests and builds required for the current scope
 When both must fix items and incomplete checks exist, set the verdict to action required and list the incomplete items
 Optional trim does not affect a pass
 
@@ -273,7 +276,8 @@ Choose one immediately executable action based on the nature of the issues and t
 | Verification prerequisites are missing | Meet the prerequisites, then continue this audit through `/aca-repo-audit` |
 | The solution still needs reasoning | Use `/aca-specify` to reason through the solution |
 | The revised solution is clear and only docs need changes | Use `/aca-design` to revise the docs |
-| Implementation deviates | Use `/aca-implement` to fix and verify |
+| Implementation deviates | `/aca-implement` Fix code or tests |
+| Tests or builds incomplete | `/aca-test` Run verification |
 | Audit passes | Return to the caller and continue with the confirmed arrangements |
 
 Audit the affected scope again after the issues are corrected

package/dist/antigravity/aca-review/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: aca-review
-description: Review the design docs or code implementation in the current scope, determine pass, needs changes, or incomplete, and do not modify the docs or code under review
+description: Review the design docs or code structure in the current scope, determine pass, needs changes, or incomplete, and do not modify the docs or code under review
 ---
 <!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
 <!-- Regenerate: bash scripts/build-skills.sh --host antigravity -->
 
 # aca-review
 
-Review the design docs or code implementation in the current scope and determine pass, needs changes, or incomplete
-Do not modify design docs, project source code, or test code
+Review the design docs or code structure in the current scope and determine pass, needs changes, or incomplete
+Do not modify design docs, project source code, or test code, and do not run the code or tests under review
 Use `/aca-repo-audit` for the repository-wide audit before release
 
 ## 1 Principles
@@ -17,11 +17,11 @@ Use `/aca-repo-audit` for the repository-wide audit before release
 
 1. **Source-driven review**
    Review the design against confirmed requirements and applicable rules
-   Review the implementation against the confirmed design
+   Review the modularity and overall structure of the code against the confirmed design
 2. **Independent judgment**
-   Form conclusions independently for each review task
+   Form conclusions independently for each review dimension
 3. **Evidence-based verdict**
-   Determine issues and review conclusions from item-by-item verification results and evidence
+   Determine issues and review conclusions from facts in the code structure and docs
 4. **Scope constraints**
    Limit review conclusions to the current scope
 
@@ -36,7 +36,7 @@ The writing axiom applies to reviews of design doc prose and the wording of revi
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.gemini/config/skills/aca/SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item
@@ -55,6 +55,8 @@ The writing axiom applies to reviews of design doc prose and the wording of revi
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context
@@ -80,12 +82,12 @@ Reference: [ASD-STE100](~/.gemini/config/skills/aca/SSOT.md#1-writing-rules)
 ```mermaid
 flowchart TD
     Start([Receive review request]) --> Scope["Confirm review scope and execution models · §3"]
-    Scope --> Check["Determine review type and run the corresponding checks · §4"]
-    Check --> Audit["Orchestrate and run independent reviews for the selected review type · §5"]
-    Audit --> Verify["Recheck and summarize · §6"]
-    Verify --> Issues{"Confirmed must-fix items exist · §7"}
-    Issues -- Yes, needs changes --> Report(["Output and next step · §8"])
-    Issues -- No --> Complete{"All pass criteria are met · §7"}
+    Scope --> Check["Determine review type and prepare sources · §4"]
+    Check --> Audit["Run independent reviews by review type · §5"]
+    Audit --> Verify["Recheck and determine the verdict · §6"]
+    Verify --> Issues{"Confirmed must-fix items exist · §6.2"}
+    Issues -- Yes, needs changes --> Report(["Output and next step · §7"])
+    Issues -- No --> Complete{"All pass criteria are met · §6.2"}
     Complete -- Yes, pass --> Report
     Complete -- No, incomplete --> Report
 ```
@@ -94,81 +96,72 @@ flowchart TD
 
 ### 3.1 Subject, Scope, and Prerequisites
 
-1. If the developer has specified the review subject and scope, follow that specification first
-   Otherwise, use the review subject and scope already specified by the caller
-2. If the subject or scope is unclear, determine it from current workspace changes and recent relevant commits
-   Read the descriptions and diffs of recent relevant commits to understand the intent and content of the changes
-3. If the review subject or scope is still unclear, ask the developer to specify it
-4. Record the review subject, scope, and comparison baseline
-   Specify the commits under review and any uncommitted changes included in the review
-5. Run `bash ~/.gemini/config/skills/aca/bin/aca-repo-type-check` to check the repo type
-   If the repo type is missing or invalid, mark the repo-type spec check as incomplete and recommend running `/aca-init`
-   If the repo type is not yet supported, mark the repo-type spec check as incomplete and note that the corresponding rules are missing
-6. If the input does not include the design doc location, locate it through the documentation entry in the root README
-   If the review source material or files under review cannot be located, ask the developer to provide their locations
-   Until the locations are clear, mark checks that depend on this content as incomplete
-
-7. Read the general review source material
-   Read the confirmed problems, goals, and change scope for this review
-   If the repo type is valid and supported, read the corresponding Repo Type rules
-   Read `CONTEXT.md` and check the business concepts and definitions involved in this review
-   Read the design docs for the current scope and follow references to read any additional docs needed for understanding and verification
+1. **Confirm the review subject and scope**
+   - Developer has specified the review subject and scope: follow that specification first
+   - Developer has not specified them: use the review subject and scope already specified by the caller
+   - Subject or scope is still unclear: determine it from current workspace changes and recent relevant commits, reading the descriptions and diffs of recent relevant commits
+   - Review subject or scope still cannot be determined: ask the developer to specify it
+2. **Record the comparison baseline**
+   - Record the review subject, scope, and comparison baseline
+   - Specify the commits under review and any uncommitted changes included in the review
+3. **Check the repo type**
+   - Run `bash ~/.gemini/config/skills/aca/bin/aca-repo-type-check` to check the repo type
+   - Repo type is missing or invalid: mark the repo-type spec check as incomplete and recommend running `/aca-init`
+   - Repo type is not yet supported: mark the repo-type spec check as incomplete and note that the corresponding rules are missing
+4. **Locate and read general review sources**
+   - When the input does not include the design doc location, locate it from the documentation entry in the root README, or ask the developer for its location if it cannot be located and mark checks that depend on this content as incomplete until the location is clear
+   - Read the confirmed problems, goals, and change scope for this review
+   - If the repo type is valid and supported, read the corresponding Repo Type rules
+   - Read `CONTEXT.md` and check the business concepts and definitions involved in this review
+   - Read the design docs for the current scope and follow references to read any additional docs needed for understanding and verification
 
 ### 3.2 Agent and Model Selection
 
-1. Scan the current AI Agent environment and other AI Agent environments already available on this machine
-   Record the Agent tool types and actual model identifiers in each environment and compare them with the main agent
-   Use existing tool entry points, configuration, and model lists to verify invocation methods and availability
-   Installation or configuration alone does not prove that an environment can be invoked
-   Mark information that cannot be verified as unknown
-2. Propose execution combinations based on the scan results
-   Prefer callable flagship models and assess flagship status using information that can currently be verified
-   Prefer combinations whose Agent environment and model both differ from those of the main agent
-   Do not prescribe a brand, model, or order of attempts
-   If no other suitable and callable candidate is available, propose using the current model
-3. Show each candidate's Agent, model, availability, invocation method, and differences from the main agent
-   Explain the recommendation and available alternative combinations, and ask the developer to confirm
-   Run the review only after the developer confirms
-   Reuse the existing confirmation if the confirmed selection and availability conditions have not changed
-4. Use the confirmed execution combinations for [task orchestration](#53-model-and-task-orchestration)
-   If the selected combination cannot be invoked, use a confirmed alternative
-   If no alternative has been confirmed, report the change and ask the developer to confirm a new combination
-   Record the actual selection, fallback, and reasons in the report
+1. **Reuse the confirmed model first**
+   - Developer has specified an Agent environment or model: run with that specification
+   - A review model has already been confirmed and its availability conditions have not changed: reuse the last confirmed Agent environment and model by default, and skip the environment scan and confirmation
+2. **Scan and confirm the model on the first review**
+   - On the first review with no model specified, scan the current AI Agent environment and other AI Agent environments on this machine, and the models that can be invoked
+   - Prefer recommending a callable flagship model that differs from the main agent; if no other suitable and callable candidate is available, propose using the current model
+   - Show each candidate's Agent environment, model, availability, and the reason for the recommendation, and ask the developer to confirm before running the review; later reviews reuse this confirmation by default
+3. **Handle execution fallback**
+   - Use the confirmed or reused execution combination for [Task Orchestration and Execution](#53-task-orchestration-and-execution)
+   - If the selected combination cannot be invoked, use a confirmed alternative, or report the change and ask the developer to confirm a new combination if no alternative has been confirmed
+   - Record the Agent environment and model actually used, whether they were reused, and the reasons for any fallback in the [Review Report](#71-review-report)
 
 ## 4 Read Source Material and Run Checks
 
 ```mermaid
 flowchart TD
-    Kind["Determine review type · §4.1"] -- Design review --> Design["Design review · §4.2"]
-    Kind -- Implementation review --> Implementation["Implementation review · §4.3"]
-    Design --> Results["Handle check results · §4.4"]
-    Implementation --> Results
+    Kind["Determine review type · §4.1"] -- Design review --> Design["Design review preparation and mechanical checks · §4.2"]
+    Kind -- Implementation review --> Implementation["Implementation review source preparation · §4.3"]
+    Design --> Next(["Proceed to independent review · §5"])
+    Implementation --> Next
 ```
 
 ### 4.1 Determine Review Type
 
-1. If the developer has specified the review type, follow that specification first
-   Otherwise, use the review type already specified by the caller
-2. If the review type is unclear, determine it from the subject under review and the actual changes
-   - Design docs: run a design review
-   - Code, tests, or runtime configuration: run an implementation review
-   - Both design and implementation: run both review types separately
-3. If the review type is still unclear, ask the developer to specify it
+1. **Determine the review type for this run**
+   - Developer has specified the review type: follow that specification first
+   - Developer has not specified it: use the review type already specified by the caller
+   - Review type is not specified: determine it from the subject under review and the actual changes (run a design review for design docs, run an implementation review for code, and run both review types separately when both are involved)
+   - Review type still cannot be determined: ask the developer to specify it
 
-Run both check branches when both review types are selected
+Run both branches when both review types are selected
 
 ### 4.2 Design Review
 
-1. Read the document set, Doc Design, and Patterns actually used for the current scope
-   Extract their applicable checklist items as the basis for item-by-item verification
-2. Determine target paths for mechanical checks based on the current review scope
-   Prose checks cover all docs under review, including project-level records within the review scope
-   For the doc graph check, select a doc tree that includes the docs under review and has a README entry
-   Mechanical checks for Context verify structure and formatting, while content is verified against the corresponding Doc Design checklist
-3. Run or reuse mechanical checks
-   Existing mechanical check results from this session can be reused if they cover the same scope and the relevant files, check rules, and tools have not changed
-   When reusing results, state the original check results and the reuse conditions met in this review in the report
-   If the reuse conditions are not met, replace the placeholder paths in the following commands with the actual paths determined in step 2 and run them
+By default, design review applies to cross-module design changes (involving multiple modules, the project-level architecture, the module division, or cross-module interfaces and collaboration contracts), or to a design review the developer explicitly requests
+
+1. **Extract applicable checklist items**
+   - Read the document set, Doc Design, and Patterns actually used for the current scope
+   - Extract their applicable checklist items as the basis for verification in the design review
+2. **Reuse or run mechanical checks**
+   - Existing mechanical check results from this session can be reused directly if they cover the same scope and the relevant files, check rules, and tools have not changed, stating the original results and the basis for reuse in the report
+   - If the reuse conditions are not met, replace the placeholder paths in the following commands with the actual paths of the docs under review and run them
+     - Prose checks cover all docs under review, including project-level records within the review scope
+     - For the doc graph check, select a doc tree that includes the docs under review and has a README entry
+     - Mechanical checks for Context verify structure and formatting
 
    ```bash
    bash ~/.gemini/config/skills/aca/bin/aca-doc-graph-check <doc directory>
@@ -176,111 +169,94 @@ Run both check branches when both review types are selected
    bash ~/.gemini/config/skills/aca/bin/aca-prose-check <paths to all docs under review>
    ```
 
-### 4.3 Implementation Review
-
-1. Read the confirmed design, test design, and repository implementation conventions for the current scope
-2. Read the current diff and changed files against the established comparison baseline
-   Read affected callers and dependency code
-   Read the functions, classes, and related call chains containing the changes to understand their execution context
-3. Map the implementation and tests to the design conventions and test scenarios respectively
-4. Based on the impact scope of the current changes, run or reuse the tests, builds, and static checks required by the design and repository conventions
-   Verify behavior that the design requires checking through actual execution by running the corresponding test cases
-   Existing verification results can be reused if they cover the same content under review and the test cases, fixtures, configuration, and dependency environment have not changed
-   When reusing results, state the original verification results and the reuse conditions met in this review in the report
-   Run the corresponding checks if verification evidence is insufficient or reuse conditions are not met
-   Use an isolated verification environment as specified by the test design
-   Do not modify commit history during verification
-
-### 4.4 Handle Check Results
-
-Handle tool checks for both review types as specified in this section
+3. **Handle mechanical check results**
 
 | Check status | Action |
 | --- | --- |
-| Pass | Record the results and verification evidence |
+| Pass, or reuse conditions met | Record the results and the verification or reuse evidence |
 | Failure returned | Check the diagnostics and list confirmed issues as must fix |
 | Cannot run or diagnostics cannot be verified | Mark the corresponding check or issue verification as incomplete and state the reason |
 
+### 4.3 Implementation Review
+
+1. **Read the structural design and organization conventions**
+   - Read the architecture design, module boundaries, interface definitions, internal composition, and repository code organization conventions for the current scope
+2. **Read the overall structure of the code under review**
+   - Against the established comparison baseline, read the directory and file distribution, module dependencies, function and class definitions, and cross-module assembly wiring involved in the changes
+3. **Define the review boundary**
+   - By default, implementation review applies to cross-module changes or changes to a module's overall code structure (changes that stay inside a module and do not change its overall code structure skip implementation review and go directly to `/aca-test`)
+   - Implementation review checks only the overall structure (module structure, overall code distribution, and function construction), and does not check specific code details or implementation logic
+   - Implementation review does not run code, tests, or builds directly, and runtime verification is executed by `/aca-test` after the review passes
+
 ## 5 Review Orchestration and Execution
 
 ### 5.1 Design Review Dimensions
 
-1. **Product perspective**
+Design review is one overall review task that checks the design docs under review against the following four items
+
+1. **Requirements and scope coverage**
    Check whether the design fully addresses the confirmed problems, goals, and scope
-2. **Design perspective**
-   Check whether the division of responsibilities and boundaries matches the division of business work
-   Check whether the collaboration and processing mechanisms can achieve the confirmed business goals
-   If user interaction is involved, check whether users can achieve their goals by following the designed workflow
-   Check whether each interaction state and each success and failure path provides clear feedback and action guidance
-3. **Implementation perspective**
-   Check whether module dependencies and interface conventions are sufficient to guide module collaboration
-   Check whether data, state changes, error handling, and boundary behavior are sufficient to guide detailed implementation
+2. **Responsibility boundaries and collaboration mechanisms**
+   Check whether the division of responsibilities and boundaries, module dependencies, and interface conventions match the division of business work and are sufficient to guide module collaboration
+   Check whether the collaboration and processing mechanisms, data and state changes, error handling, and boundary behavior are sufficient to guide detailed implementation
+   If user interaction is involved, check whether the interaction flow, each interaction state, and each success and failure path provide clear feedback and action guidance
+   Check whether the design contains ambiguities that would lead to different business behavior, and whether additional design decisions are still needed before implementation
+3. **Completeness of the verification design**
    Check whether the test design specifies fixtures, scenarios, execution methods, and expected results
    Check whether test results can determine if the corresponding acceptance criteria are met
-   Check whether the design contains ambiguities that would lead to different business behavior
-   Check whether additional design decisions are still needed before implementation
-4. **Overall perspective**
+4. **Cross-doc consistency and writing rules**
    Check whether the documentation entry and references accurately locate the current design and its dependencies
    Check related docs for design omissions, conflicting conventions, duplicate definitions, or inconsistent terminology
+   Check whether the checklist items of the applicable document set, Doc Design, and Patterns are met
 
 ### 5.2 Implementation Review Dimensions
 
-Check the following items individually against the confirmed design docs
-
-1. **Structural setup**
-   Check whether the division of modules and files, responsibility assignments, interface definitions, and dependencies conform to the design
-2. **Detailed logic implementation**
-   Check whether inputs, outputs, and processing flows conform to the design
-   Check whether data and state changes, error handling, and boundary behavior conform to the design
-   Check whether fixtures, scenarios, and expected results in black-box and white-box tests conform to the corresponding test design
-   Check whether test assertions can detect deviations between actual behavior and expected results
-3. **Overall structural implementation**
-   Check whether module assembly, call chains, and collaboration methods conform to the overall architecture design
-   Check whether integrated behavior conforms to the cross-module flows and acceptance criteria in the design
-
-### 5.3 Model and Task Orchestration
-
-1. Create independent review tasks for the selected review type
-   For design reviews, assign an independent sub-agent to each perspective
-   For implementation reviews, assign independent sub-agents to structural setup, detailed logic implementation, and overall structural implementation
-   Each sub-agent forms conclusions independently without reading other sub-agents' review results beforehand
-2. Arrange execution using the combinations confirmed in [Agent and Model Selection](#32-agent-and-model-selection)
-   Keep review tasks independent even when using the current model
-3. Provide task context to each sub-agent
-   - Assigned review items and applicable checklist items
+Implementation review is one overall review task that uses the confirmed design docs as its basis, checks only the modularity and overall structure of the code, and does not check specific code details or implementation logic
+
+1. **Module structure**
+   Check whether the division of modules and submodules, responsibility assignments, interface boundaries, dependencies, and cross-module assembly wiring conform to the design
+2. **Overall code distribution**
+   Check whether the directory and file organization conforms to the design, whether each file has a single responsibility and clear ownership, and whether responsibilities are mixed or layers are coupled across boundaries
+3. **Function construction**
+   Check whether the responsibility split, signature design, granularity, and level of abstraction of functions and classes are clear and reasonable
+
+### 5.3 Task Orchestration and Execution
+
+1. **Dispatch independent review tasks by review type**
+   - When only a design review or only an implementation review runs, create 1 independent sub-agent task to complete all check items of that dimension
+   - When both design and implementation reviews run, create 1 independent sub-agent task for the design review and 1 for the implementation review
+   - Run each review task according to [Agent and Model Selection](#32-agent-and-model-selection), and form conclusions independently
+2. **Provide task context**
+   - The assigned review type, its check items, and applicable checklist items
    - Review subject, scope, and comparison baseline, including commits under review and uncommitted changes included in the review
    - Locations of the content under review and the corresponding design source material
-   - Existing check results and evidence from chapter 4, with the basis for execution or reuse
-   - The diff, changed files, affected callers and dependency code, and repository implementation conventions needed for the implementation review
-
-### 5.4 Run the Review
-
-1. Each sub-agent verifies its assigned checklist items individually
-   If a checklist item does not apply to the current scope, record it as not applicable and state the basis
-2. For each check, record the verification result, corresponding file location, and basis for judgment
-3. For each issue, record the location, problem, impact, and recommended changes using the issue format in [Review Report](#81-review-report)
-4. Return the complete check records, issue list, and incomplete items to the main agent
-
-## 6 Recheck and Summarize
-
-1. The main agent reads each sub-agent's check records
-   Check whether tool checks and verification evidence correspond to the current content under review
-2. Check the files and evidence for each issue and include it in the report only after confirming it
-   Exclude disproven issues
-   Mark issues with insufficient evidence as incomplete verification
-   The main agent can add issues it finds independently after applying the same evidence verification
-   Merge duplicate issues while retaining their locations, evidence, and impact
-3. Summarize the check records for all review items and check each checklist item's applicability and verification result
-   If a sub-agent did not cover its assigned scope, omitted checks, or lacked verification evidence, assign the corresponding supplementary checks
-   The main agent rechecks the supplementary results
-   Mark review items or checks that still cannot be completed as incomplete and state the reasons
-4. Summarize confirmed issues and check completion status as the basis for the verdict
-
-## 7 Verdict
+   - For design review, the mechanical check results and evidence from Chapter 4
+   - For implementation review, the directory and file structure, changed files, module dependencies, and repository code organization conventions
+3. **Run an issue-oriented review**
+   - The sub-agent verifies each check item and applicable checklist item of its dimension
+   - When it finds an issue, it records the file location, problem, impact, and recommended change using the issue format in the [Review Report](#71-review-report)
+   - When a check item cannot be completed, it records the incomplete item and the reason
+   - Pass and not-applicable items are not itemized; the sub-agent returns the list of issues found, incomplete items, and its review conclusion to the main agent
+
+## 6 Recheck and Verdict
+
+### 6.1 Recheck and Merge
+
+1. **Recheck issue evidence**
+   - The main agent checks the files and evidence for each issue returned by the sub-agents and includes it in the report only after confirming it
+   - Exclude disproven issues and mark issues with insufficient evidence as incomplete verification
+   - The main agent can add issues it finds independently after applying the same evidence verification
+   - Merge duplicate issues while retaining their locations, evidence, and impact
+2. **Check review coverage**
+   - Confirm that the selected review dimensions and their check items have all been verified
+   - If a sub-agent did not cover its assigned scope or omitted check items, check the corresponding content and recheck the results
+   - Mark review dimensions or checks that still cannot be completed as incomplete and state the reasons
+
+### 6.2 Verdict
 
 | Verdict | Criteria |
 | --- | --- |
-| Pass | All selected review tasks are complete, all applicable checklist items have passed verification, all applicable tool checks have passed, and there are no must-fix items |
+| Pass | All selected review tasks are complete, all applicable checklist items have passed verification, all applicable mechanical checks have passed, and there are no must-fix items |
 | Needs changes | Confirmed must-fix items exist |
 | Incomplete | Pass criteria are not met and there are no confirmed must-fix items |
 
@@ -288,9 +264,9 @@ If must-fix items and incomplete checks both exist, the verdict is needs changes
 Optional improvements do not affect a pass
 After the content under review changes, review the affected scope again and update the corresponding conclusions
 
-## 8 Output and Next Step
+## 7 Output and Next Step
 
-### 8.1 Review Report
+### 7.1 Review Report
 
 Output the review results in the current conversation using the following template without writing to project files
 
@@ -299,12 +275,13 @@ Output the review results in the current conversation using the following templa
 
 | Item | Result |
 | --- | --- |
-| Subject | <design docs / code implementation / both> |
+| Subject | <design docs / code structure / both> |
 | Scope | <modules, files, or changes under review> |
 | Baseline | <comparison baseline, commits under review, and uncommitted changes> |
+| Execution model | <Agent environment and model actually used, reuse status, and fallback reasons> |
 | Verdict basis | <how pass criteria are met, or issues and incomplete checks preventing a pass> |
 | Must fix | <issue count and main impact / none> |
-| Tool checks | <pass, failure, and incomplete status of tests, builds, or mechanical checks> |
+| Tool checks | <pass, reuse, failure, and incomplete status of design review mechanical checks / not applicable for implementation review> |
 | Incomplete | <incomplete review tasks and checks within the current scope, and reasons / none> |
 | Next step | <one immediately actionable step> |
 
@@ -312,39 +289,26 @@ Output the review results in the current conversation using the following templa
 
 - <doc section link / code file link and line number>
   - Problem: <actual content, design conventions or checklist items violated, and specific deviations>
-  - Impact: <impact on design understanding, implementation, or runtime behavior, and conditions under which it occurs>
+  - Impact: <impact on design understanding, implementation, or maintenance of the code structure, and conditions under which it occurs>
   - Change: <content to correct or confirm, and conventions or checklist items to satisfy after correction>
 
 ## Optional Improvements
 
 - <suggested improvements that do not affect a pass, corresponding locations, and expected benefits>
-
-## Check Scope
-
-- Read: <files actually read in this review>
-- Checklist: <criteria and sources, item-by-item verification results, basis for non-applicability, and reasons for incomplete checks>
-- Tools: <commands actually run and their results, or original results reused and basis for reuse>
-
-| Review item | Agent environment | Model | Completion status | Notes |
-| --- | --- | --- | --- | --- |
-| <design review perspective / implementation review item> | <actual Agent environment> | <actual model and verifiable version> | <complete / incomplete> | <reason for fallback or incomplete status / none> |
 ```
 
-For design reviews, list the four perspectives: product, design, implementation, and overall
-For implementation reviews, list the three items: structural setup, detailed logic implementation, and overall structural implementation
-
-### 8.2 Follow-Up Actions
+### 7.2 Follow-Up Actions
 
 Select the next step based on the review verdict and progress in the current round
 
 | Verdict | Situation | Next step |
 | --- | --- | --- |
-| Incomplete | Inputs, verification environment, or verification conditions are missing | Report the conditions for resuming and continue this review through `/aca-review` once they are met |
-| Needs changes | Implementation issues | Fix and verify through `/aca-implement` |
-| Needs changes | The design solution still needs reasoning or decisions | Extend or revise the solution through `/aca-specify` |
-| Needs changes | The solution is clear and only design docs need revision | Revise the docs through `/aca-design` |
-| Pass | Only the design review has passed and implementation is needed in this round | `/aca-implement` |
-| Pass | The implementation review has passed and implementation tasks remain in this round | Continue implementation through `/aca-implement` |
-| Pass | All work in this round is complete and all required reviews have passed | Proceed to `/aca-release` according to the confirmed version progression plan |
-
-After design or implementation corrections, review the affected scope again through `/aca-review`
+| Incomplete | Inputs or verification conditions are missing | Report the conditions for resuming and continue this review through `/aca-review` once they are met |
+| Needs changes | The design solution still needs reasoning or decisions | `/aca-specify` Extend or revise the solution |
+| Needs changes | The solution is clear and only design docs need revision | `/aca-design` Revise the docs |
+| Needs changes | Code structure issues | `/aca-implement` Adjust the code structure |
+| Pass | Design review passed and code implementation is needed in this round | `/aca-implement` |
+| Pass | Design review passed and only design docs are changed in this round | Proceed to `/aca-release` according to the confirmed version progression plan |
+| Pass | Implementation review passed | `/aca-test` Run test verification for the current scope |
+
+After design or code structure corrections, review the affected scope again through `/aca-review`