anyone-can-architect 0.3.0 → 0.4.0

package/CONTEXT.md

@@ -72,7 +72,7 @@ _Avoid_: "subsection", "second-level heading", "clause"
 ### subsection
 
 Subsection
-`#### N.N.N Title`, the third level of division below a section and the deepest level, appearing only in blocks specified by a pattern
+`#### N.N.N Title`, the third level of division below a section and the deepest level, used at positions specified by a doc design or pattern
 _Avoid_: "third-level heading"
 
 ### drill-down
@@ -97,7 +97,7 @@ _Avoid_: "imprint", "marker", "version block"
 - [doc-design](#doc-design) references the guiding principles for drill-down and specifies which parts to [drill-down](#drill-down) into
 - [module](#module) uses the module [document-set](#document-set), with [repo-type-spec](#repo-type-spec) determining when to use it
 - [aca-footer](#aca-footer) determines the project's [repo-type](#repo-type)
-- [chapter](#chapter) contains many [section](#section), [section](#section) contains many [subsection](#subsection), and doc designs specify structure only down to section
+- [chapter](#chapter) contains many [section](#section), [section](#section) contains many [subsection](#subsection)
 
 ## Flagged ambiguities
 

package/README.md

@@ -106,5 +106,5 @@ Run `bash tests/run-tests.sh` before opening a pull request
 
 ---
 
-> 📦 **Anyone Can Architect v0.3.0**
-> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.3.0 · Repo-Type: `guideline`
+> 📦 **Anyone Can Architect v0.4.0**
+> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.4.0 · Repo-Type: `guideline`

package/SSOT.md

@@ -32,6 +32,11 @@
 
 - [RFC 9110 (HTTP Semantics)](https://www.rfc-editor.org/rfc/rfc9110): Defines HTTP semantics, including methods, status codes, fields, safety, and idempotency
 - [OWASP API Security Top 10](https://owasp.org/API-Security/): Summarizes common API security risks, including authorization, authentication, resource consumption, and configuration issues
+- [Socket.IO Event Types](https://socket.io/docs/v4/typescript/): Defines how to declare client and server events by direction, with type declarations and runtime validation taking separate responsibilities
+- [Socket.IO Events and Acknowledgements](https://socket.io/docs/v4/emitting-events/): Defines bidirectional events, acknowledgements, and timeouts
+- [Socket.IO Client Options](https://socket.io/docs/v4/client-options/) and [Namespaces](https://socket.io/docs/v4/namespaces/): Define the connection path, namespaces, and how clients connect
+- [Socket.IO Connection Authentication](https://socket.io/docs/v4/middlewares/): Defines how auth credentials are passed and how connection rejections are reported
+- [Socket.IO Delivery Guarantees](https://socket.io/docs/v4/delivery-guarantees/): Defines the default message delivery guarantees and where the application must add its own guarantees
 
 ## 7 Platforms and Tools
 

package/VERSION

@@ -1 +1 @@
-0.3.0
+0.4.0

package/axioms/writing.md

@@ -26,6 +26,8 @@
 - 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

package/dist/antigravity/aca/SKILL.md

@@ -43,7 +43,7 @@ flowchart TD
 | `/aca-specify` | Reason through new requirements or improve existing designs, then proceed to Design after confirming the solution |
 | `/aca-design` | Write and check design docs within the current scope, then determine the next scope or complete the overall closeout |
 | `/aca-walkthrough` | Walk through design docs in business language, confirm design decisions unit by unit, and correct identified issues on the spot after confirmation |
-| `/aca-review` | Determine the review subject and scope, statically review the design or code and test implementation, without modifying the docs or code under review or running code |
+| `/aca-review` | Determine the review subject and scope, statically review the design or the overall code structure, without modifying the docs or code under review or running code |
 | `/aca-implement` | Plan the file structure based on the design, then write production code and test code according to module dependencies |
 | `/aca-test` | Select and run minimal tests based on the current implementation scope or the design boundary crossed by changes, testing only without modifying files |
 | `/aca-repo-audit` | Check repository documentation and verify the implementation as needed, with read-only access and no changes |

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

@@ -41,6 +41,8 @@ Change only documentation, not code
 - 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
@@ -167,11 +169,13 @@ If neither the repo-type spec nor the document set specifies an order, arrange w
      Keep plain text in headings, code blocks, Mermaid labels, and product copy
 4. Synchronize affected test designs
    - Identify affected black-box and white-box test designs based on contracts, flows, and internal mechanisms added, revised, or deleted in this round
+   - Against the confirmed design, check the affected existing test code, fixtures, and the behavior they actually verify
    - Update test designs in sequence according to the corresponding doc designs and [test cases](~/.gemini/config/skills/aca/doc-design/patterns/testcase.md)
      1. Update fixtures
      2. Update test scenarios and their references to design rationale
      3. Update test cases based on the scenarios
         Add missing cases, revise changed cases, and delete or replace invalid cases
+   - Leave actual changes to test code and fixtures to `/aca-implement`
    - If only wording is revised and verified behavior has not changed, check that test designs and references remain valid
    - If solution decisions or as-is evidence required for test design are missing, handle them under §3
    - If affected docs are outside the current scope, record their locations and the content that needs synchronization
@@ -256,8 +260,10 @@ Perform the following steps after writing and scope checks are complete for all
    After all applicable checks pass, commit only actual closeout changes, then push to the remote
    If there are no actual changes, do not create an empty commit, and push existing commits from this round
    If committing or pushing is not possible, record completed work, incomplete actions, and the resumption point, and report incomplete under §8
-5. Continue to review
-   After all closeout requirements are complete, the next step is `/aca-review`
+5. Determine whether design review is needed and continue
+   After all closeout requirements are complete, check whether the design in this round is cross-module (involving multiple modules, the project-level architecture, the module division, or cross-module interfaces and collaboration contracts)
+   - Cross-module: the next step is `/aca-review` for a design review
+   - Not cross-module (only changes inside a single module or local design changes): skip design review and go directly to the next step (`/aca-implement` when this round needs code, or `/aca-release` according to the confirmed version progression plan when this round changes only design docs)
 
 ## 8 Output
 
@@ -275,16 +281,16 @@ Perform the following steps after writing and scope checks are complete for all
 
    | Item | Result |
    | --- | --- |
-   | Scope | <current scope and progress in this round> |
+   | Scope | <current scope, progress in this round, and whether it is cross-module> |
    | Inputs | <solution or as-is state and actual sources> |
    | Docs | <files added, revised, moved, or deleted / none> |
    | Checks | <actual results, basis for reuse, and unverified items> |
    | Commits | <commit and push results / not committed> |
    | Pending | <incomplete items, reasons, and resumption point / none> |
-   | Next step | <target skill and pending scope / fill corresponding gaps / none> |
+   | Next step | </aca-review after cross-module closeout, /aca-implement or /aca-release directly after non-cross-module closeout, or fill corresponding gaps> |
    ```
 
 3. Determine the next step
-   After this round is fully closed out, the next step is `/aca-review`
+   After this round is fully closed out, continue to `/aca-review`, `/aca-implement`, or `/aca-release` according to whether the design is cross-module, as in step 5 of 7.2
    If the current scope is complete but another scope remains, determine the next path under 7.1
    If work is incomplete, fill the corresponding gaps, and do not judge Design complete solely because files have been written

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

@@ -54,6 +54,8 @@ Preserve existing changes outside the scope of this implementation
    - List deliverables and their completion criteria based on the confirmed design and implementation scope
 2. **Compile the code and test change list**
    - Compare delivery requirements with existing code and tests, and list what to reuse, modify, add, or remove
+   - Correct or remove outdated or wrong test cases and fixtures according to the confirmed design
+   - When changing test expectations, base the change on the confirmed design or a verified test error
 3. **Orchestrate the corresponding test scope**
    - List the test cases and fixtures to write or update in this run based on the black-box and white-box test designs
    - Record the units under test and test case scope corresponding to the current implementation scope for direct execution by `/aca-test`
@@ -141,12 +143,16 @@ Preserve existing changes outside the scope of this implementation
 
 ## 6 Output
 
-When all completion criteria for the current scope are satisfied, mark the goal and task status as complete
-If incomplete, report remaining work, reasons for blockers, and actions to resume
-After this implementation is complete, use `/aca-review` to run an implementation review on this scope
-Provide Review and subsequent `/aca-test` with the overall goal, corresponding design, implementation scope, orchestrated test scope, and comparison baseline
-Identify the commits and uncommitted changes under review
-Use the following format for the final report, filling in the title and results according to the actual status
+1. **Update the task status**
+   - All completion criteria for the current scope are satisfied: mark the goal and task status as complete
+   - Completion criteria are not satisfied: report remaining work, reasons for blockers, and actions to resume
+2. **Check for module and code structure changes and determine the next step**
+   - Check whether the changes are cross-module or change a module's overall code structure (module structure, overall code distribution, function construction)
+   - Cross-module or the module's overall code structure changed: use `/aca-review` to run an implementation review on this scope, then go to `/aca-test` after the review passes
+   - Only inside a module, with no change to the module's overall code structure (such as internal module logic, local function implementation, or test details): skip implementation review and go directly to `/aca-test`
+   - Provide the following `/aca-review` or `/aca-test` with the overall goal, corresponding design, implementation scope, orchestrated test scope, and comparison baseline, and identify the commits and uncommitted changes in this run
+3. **Output the implementation report**
+   Use the following format for the final report, filling in the title and results according to the actual status
 
 ```markdown
 # 🛠️ Implement: <complete / incomplete>
@@ -156,9 +162,10 @@ Use the following format for the final report, filling in the title and results
 | Goal | <overall goal and completion criteria satisfaction> |
 | Scope | <implementation scope and module progress> |
 | Changes | <main production code and test code changes> |
+| Structural change | <yes (cross-module or module's overall code structure changed) / no (only internal module logic or local changes)> |
 | Test scope | <units under test and test case scope orchestrated for /aca-test> |
 | Commits | <commit records / uncommitted> |
 | Blockers | <blockers and reasons / none> |
 | Recommendations | <extension recommendations / none> |
-| Next step | <one immediately actionable step> |
+| Next step | </aca-review when there is a structural change, /aca-test directly when changes are only inside a module with no structural change> |
 ```

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

@@ -97,14 +97,10 @@ If execution cannot continue in Chapters 4 through 7, report completed facts, th
 1. Run `bash ~/.gemini/config/skills/aca/bin/aca-release-notify-check .` to check the announcement configuration
    Record the check result and the corresponding configuration location
 2. Act on the check result
-
-   | Result | Action |
-   | --- | --- |
-   | `NOTIFY_NONE` | Record that no transport is configured and continue the release |
-   | `NOTIFY_WIRED` | Record the platform and consumer point and continue the release |
-   | `NOTIFY_UNWIRED` | Stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected |
-   | Unable to complete the check | Stop and report the reason and resume conditions |
-
+   - `NOTIFY_NONE`: record that no transport is configured and continue the release
+   - `NOTIFY_WIRED`: record the platform and consumer point and continue the release
+   - `NOTIFY_UNWIRED`: stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected
+   - Unable to complete the check: stop and report the reason and resume conditions
 3. Use the configuration check result for the [Announcement Cross-Check](#72-cross-check-the-release-announcement)
    Check again after the configuration is corrected
    The configuration check confirms that the summary is integrated
@@ -305,15 +301,11 @@ Release announcements are generated from the NOTIFY block in the annotated Tag
 1. Locate the delivery results
    Use the [announcement configuration](#33-announcement-configuration) and the repository release workflow to find tasks, logs, or delivery receipts for this Tag
 2. Record the delivery status based on evidence
-
-   | Status | Basis for determination |
-   | --- | --- |
-   | Sent | Evidence of successful delivery for this Tag |
-   | Pending delivery | Confirmed to still be waiting or in progress |
-   | Delivery failed | An explicit failure result |
-   | Unconfirmed | Insufficient evidence to determine the delivery status |
-   | Transport not configured | Configuration checks confirm that no delivery mechanism is configured |
-
+   - Evidence of successful delivery for this Tag exists: mark as sent
+   - The task is confirmed to still be waiting or in progress: mark as pending delivery
+   - An explicit delivery failure result exists: mark as delivery failed
+   - Evidence is insufficient to determine the delivery status: mark as unconfirmed
+   - Configuration checks confirm that no delivery mechanism is configured: mark as transport not configured
 3. Handle follow-up actions
    If delivery fails, recover or resend according to repository conventions
    If the status is unconfirmed, report the missing evidence

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

@@ -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

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

@@ -1,13 +1,13 @@
 ---
 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
+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
 
@@ -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 code and test 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 facts in code and docs
+   Determine issues and review conclusions from facts in the code structure and docs
 4. **Scope constraints**
    Limit review conclusions to the current scope
 
@@ -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
@@ -81,11 +83,11 @@ Reference: [ASD-STE100](~/.gemini/config/skills/aca/SSOT.md#1-writing-rules)
 flowchart TD
     Start([Receive review request]) --> Scope["Confirm review scope and execution models · §3"]
     Scope --> Check["Determine review type and prepare sources · §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"}
+    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
 ```
@@ -115,23 +117,17 @@ flowchart TD
 
 ### 3.2 Agent and Model Selection
 
-1. **Scan available Agent environments and models**
-   - 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, and information that cannot be verified is marked as unknown
-2. **Propose execution combinations**
-   - 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, without prescribing a brand, model, or order of attempts
-   - If no other suitable and callable candidate is available, propose using the current model
-3. **Confirm execution combinations**
-   - 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 before running the review
-   - Reuse the existing confirmation if the confirmed selection and availability conditions have not changed
-4. **Handle execution fallback**
-   - Use the confirmed execution combinations for [Model and Task Orchestration](#53-model-and-task-orchestration)
+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 actual selection, fallback, and reasons in the report
+   - 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
 
@@ -139,9 +135,8 @@ flowchart TD
 flowchart TD
     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 --> Results["Handle check results · §4.4"]
-    Implementation --> Next(["Proceed to independent review orchestration · §5"])
-    Results --> Next
+    Design --> Next(["Proceed to independent review · §5"])
+    Implementation --> Next
 ```
 
 ### 4.1 Determine Review Type
@@ -149,23 +144,24 @@ flowchart TD
 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, tests, or runtime configuration, and run both review types separately when both are involved)
+   - 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 branches when both review types are selected
 
 ### 4.2 Design Review
 
+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 item-by-item verification
-2. **Determine target paths for mechanical checks**
-   - 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, stating the original results and reuse conditions 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
+   - 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>
@@ -173,109 +169,90 @@ Run both 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 design and implementation conventions**
-   - Read the confirmed design, test design, and repository implementation conventions for the current scope
-2. **Read code and tests under review**
-   - Read the current diff and changed files against the established comparison baseline
-   - Read affected callers and dependency code
-   - Read the functions, classes, test files, and related call chains containing the changes to understand their execution context
-3. **Map design to implementation**
-   - Map the production code implementation and test code implementation to the design conventions and test scenarios respectively for item-by-item static review in Chapter 5
-   - Implementation review does not run code, tests, or builds directly, and runtime verification is executed by `/aca-test` after the review passes
-
-### 4.4 Handle Check Results
-
-Handle mechanical checks for design reviews 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
 
-Statically 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 assertions in black-box and white-box test code completely cover 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 cross-module wiring conforms to the flows and contract boundaries in the design
-
-### 5.3 Model and Task Orchestration
-
-1. **Create independent review tasks**
-   - 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 models**
-   - 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**
-   - 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 mechanical check results and evidence from Chapter 4
-   - The diff, changed files, test files, affected callers and dependency code, and repository implementation conventions needed for the implementation review
-
-### 5.4 Run the Review
-
-1. **Verify checklist items individually**
-   - 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. **Record verification results and issues**
-   - For each check, record the verification result, corresponding file location, and basis for judgment
-   - For each issue, record the location, problem, impact, and recommended changes using the issue format in [Review Report](#81-review-report)
-3. **Return summary to the main agent**
-   - Return the complete check records, issue list, and incomplete items to the main agent
-
-## 6 Recheck and Summarize
-
-1. **Read sub-agent check records**
-   - The main agent reads each sub-agent's check records and checks whether the check evidence corresponds to the current content under review
-2. **Recheck and merge issues**
-   - Check the files and evidence for each issue and include it in the report only after confirming it
+   - 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
-3. **Check review coverage**
-   - 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 and recheck the results
-   - Mark review items or checks that still cannot be completed as incomplete and state the reasons
-4. **Form the basis for the verdict**
-   - Summarize confirmed issues and check completion status as the basis for the verdict
+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
 
-## 7 Verdict
+### 6.2 Verdict
 
 | Verdict | Criteria |
 | --- | --- |
@@ -287,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
 
@@ -298,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 design review mechanical checks / not applicable for implementation review> |
+| 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> |
 
@@ -311,28 +289,15 @@ 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: <mechanical check commands actually run and their results, or original results reused and basis for reuse / not applicable for implementation review>
-
-| 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
 
@@ -341,9 +306,9 @@ Select the next step based on the review verdict and progress in the current rou
 | 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 or test implementation issues | `/aca-implement` Fix the implementation |
+| 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 implementation corrections, review the affected scope again through `/aca-review`
+After design or code structure corrections, review the affected scope again through `/aca-review`