architext 0.0.4 → 0.0.6

package/dist/templates/en/docs/prompts/audit.md

@@ -1,150 +1,136 @@
 <protocol_audit>
-  **Trigger**: `/archi.audit [id]`
-  **Goal**: Independent deep code audit. With `<id>`, audit the task's code implementation; without `<id>`, execute project-level health check. No code modifications — output audit report and fix tickets only.
+  **Trigger**: `/archi.audit [id]` | Auto-loaded by Workflow Dispatch on natural language trigger
+  **Goal**: Independent deep code review. With `<id>` review that task's code implementation; without `<id>` run project-wide health check. Do not modify code; output review report and fix work items only.
 
 <meta>
     <style>Investigative, Thorough, Evidence-Based</style>
     <language>English</language>
     <principles>
-      1.  **Read-Only**: Prohibited from modifying any code files. Audit ≠ Fix.
-      2.  **Evidence-Based**: Every finding must include file path, line number, and code snippet.
-      3.  **Actionable Output**: Every issue must include a recommended fix command (`/archi.fix`, `/archi.edit`, etc.).
-      4.  **Vision Anchored**: Always use `vision.md` as directional baseline to detect deviations.
-      5.  **Report Persistence**: Audit results must be written to file — task-level → `tasks/<id>_*/audit.md` (overwrite), project-level → `audits/YYYY-MM-DD.md` (date-archived, same-day overwrite).
+      1.  **Read-Only**: Do not modify any code files. Review ≠ Fix.
+      2.  **Evidence-Based**: Each finding must include file path, line number, code snippet.
+      3.  **Actionable Output**: Each issue must include recommended fix command (`/archi.fix`, `/archi.edit`, etc.).
+      4.  **Vision Anchored**: Always use `vision.md` as direction anchor; detect drift.
+      5.  **Report Persistence**: Review results must be written to file — task-level → `tasks/<id>_*/audit.md` (overwrite); project-level → `audits/YYYY-MM-DD.md` (date archive).
+      6.  **IDE-Native First**: Leverage IDE native capabilities to drive execution rhythm; this protocol defines quality standards and checkpoints, not fight IDE planning/execution mechanisms.
     </principles>
 </meta>
 
 <step_1_resolve>
-    **Role**: System Analyst
     **Mode Gate**:
 
     | Input | Mode | Next Steps |
     |:---|:---|:---|
-    | `/archi.audit <id>` | Task-level deep audit | step_2_task → step_3_report |
-    | `/archi.audit` | Project-level health check | step_2_project → step_3_report |
+    | `/archi.audit <id>` | Task-level deep review | step_2a_task → step_3_report |
+    | `/archi.audit` | Project-level health check | step_2b_project → step_3_report |
 
     **Task-level — Resolve ID**:
-    1.  Parse `<id>` from `[[__DOCS_DIR__]]/global/roadmap.json` → Task Name, Slug, status.
-    2.  **Status Gate** — Only `active` or `done` can be audited:
+    1.  Parse `<id>` from roadmap.json → Task Name, Slug, status.
+    2.  **Status Gate** — only `active` or `done` may be reviewed:
 
         | Status | Handling |
         |:---|:---|
         | `active` / `done` | Pass |
-        | `pending` | Reject — no code to audit, run `/archi.plan` + `/archi.code` first |
-        | `blocked` | Reject — prerequisites not completed |
-
-    3.  **Load Context**:
-        - `[[__DOCS_DIR__]]/global/vision.md` — Project directional baseline
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — Task logic
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — Task checklist
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — Task UI scope declaration (if exists)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_context.md` — AI screen index (locate corresponding screen IDs)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_concept.html` — read-only visual reference (source of visual truth for #10 compliance comparison)
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md` — Previous audit report (if exists, for comparison)
-        - `02_tech_stack.md` — Technical red lines
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
-    4.  Read all code files corresponding to this task.
+        | `pending` | Reject — no code to review |
+        | `blocked` | Reject — upstream deps incomplete |
+
+    3.  **Load**: vision.md (direction anchor) + task docs (spec/plan/ui) + prior audit.md (for comparison) + project context (tech_stack/design_tokens/data_snapshot/ui_context/screens/). Read all code files for this task.
 
     **Project-level — Load Overview**:
-    1.  Read `[[__DOCS_DIR__]]/global/vision.md`, `roadmap.json`, `map.json`.
-    2.  Read `02_tech_stack.md`.
-    3.  Scan `[[__DOCS_DIR__]]/tasks/` directory structure.
-    4.  Read project code entry points and key modules.
+    1.  Read vision.md, roadmap.json, map.json, tech_stack.md.
+    2.  Scan tasks/ directory structure.
+    3.  Read project code entry points and key modules.
 
-    **Output**: Audit scope and context inventory.
+    **Output**: Review scope and context checklist. Enter step_2a_task or step_2b_project.
 </step_1_resolve>
 
-<step_2_task>
+<step_2a_task>
     **Role**: Chief Auditor
-    **Scope**: Task-level deep code audit (execute only for `/archi.audit <id>`).
+    **Scope**: Task-level deep code review (only when `/archi.audit <id>`).
 
-    Audit dimension by dimension; every finding must include `file:line` + code snippet + severity:
+    Review dimension by dimension; each finding must include `file:line` + code snippet + severity:
 
-    | # | Dimension | Audit Focus |
+    | # | Dimension | Review focus |
     |:---|:---|:---|
-    | 1 | **Vision Alignment** | Does the implementation direction conflict with or deviate from `vision.md` |
-    | 2 | **Spec Completeness** | Does code cover all scenarios and edge cases in `spec.md` |
-    | 3 | **Plan Truthfulness** | Are tasks marked `done` actually implemented in code (detect false marks) |
-    | 4 | **Logic Correctness** | Business logic errors, contradictions, missing branches, state machine defects |
-    | 5 | **Bug Hunting** | Null/undefined, race conditions, resource leaks, infinite loops, off-by-one |
-    | 6 | **Error Handling** | Swallowed errors, silent failures, error propagation chain integrity, user-visible feedback |
-    | 7 | **Tech Stack Compliance** | Against `02_tech_stack.md`: forbidden patterns, outdated APIs, hardcoded values |
-    | 8 | **Security** | Sensitive info leakage, unvalidated input, injection risks, permission checks |
-    | 9 | **Performance** | Unnecessary full imports/large loops/useless computation/memory leaks/N+1 queries |
-    | 10 | [?UI] **Design Compliance** | Styles use visual patterns from Tokens; no hardcoded magic values; implementation visually consistent with corresponding screen in `ui_concept.html` |
-    | 11 | [?Data] **Data Integrity** | Field names/types consistent with `data_snapshot.json` |
-    | 12 | [?I18n] **I18n Compliance** | No hardcoded strings; must use Key/dictionary references |
-    | 13 | **Orphan .gitkeep** | Dir has other files but still contains `.gitkeep` — must remove |
-    | 14 | **Spec-Code Drift** | Do code interfaces/types/behaviors match `spec.md`; have manual changes been synced to docs |
-    | 15 | [?UI] **UI Reference Integrity** | Are `ref: ui_concept.html#S-XX` pointers in `ui.md` still valid; have referenced screens/components been renamed or removed after edit/revise |
-
-    **Output**: Findings list grouped by dimension, each with severity, location, description.
-</step_2_task>
-
-<step_2_project>
+    | 1 | **Vision alignment** | Implementation direction conflicts or drift from `vision.md` |
+    | 2 | **Spec completeness** | Code covers all scenarios and boundaries in `spec.md` |
+    | 3 | **Plan truthfulness** | Tasks marked `done` actually implemented (prevent false completion) |
+    | 4 | **Logic correctness** | Business logic errors, contradictions, missing branches, state machine defects |
+    | 5 | **Bug hunting** | null/undefined, race conditions, resource leaks, infinite loops, off-by-one |
+    | 6 | **Error handling** | Swallowing, silent failure, error propagation chain, user-visible feedback |
+    | 7 | **Tech Stack compliance** | Per `tech_stack.md`: forbidden patterns, outdated API, hardcoding |
+    | 8 | **Security** | Sensitive info leak, unvalidated input, injection risk, permission checks |
+    | 9 | **Performance** | Unnecessary full imports, large loops, dead computation, memory leaks, N+1 queries |
+    | 10 | (When this task involves UI) **Design compliance** | Token usage; no hardcoded magic values; visual consistency with `screens/S-XX.html` |
+    | 11 | (When this task involves data) **Data consistency** | Field names/types match `data_snapshot.json` |
+    | 12 | (i18n projects only) **I18n compliance** | No hardcoded strings; must use Key/dictionary refs |
+    | 13 | **Orphan .gitkeep** | `.gitkeep` exists when dir has other files — remove |
+    | 14 | **Spec-Code drift** | Interface/type/behavior match `spec.md`; manual changes synced to docs |
+    | 15 | (When this task involves UI) **UI ref completeness** | `ui.md` `ref: screens/S-XX.html` pointers still valid |
+
+    **Output**: Finding list grouped by dimension; each with level, location, description. Enter step_3_report.
+</step_2a_task>
+
+<step_2b_project>
     **Role**: Chief Auditor
-    **Scope**: Project-level health check (execute only for `/archi.audit` without arguments).
+    **Scope**: Project-level health check (only when `/archi.audit` no args).
 
-    | # | Check Item | Description |
+    | # | Check | Description |
     |:---|:---|:---|
-    | 1 | **Vision Drift** | Are `roadmap.json` task directions consistent with `vision.md` |
-    | 2 | **Architecture Consistency** | `map.json` vs actual directory structure — drift or unregistered modules |
-    | 3 | **Roadmap Health** | Consistency + progress stats + long-term blocked tasks + dependency cycle detection |
-    | 4 | **Documentation Completeness** | Each Task has spec.md + plan.json; detect orphan directories |
-    | 5 | **Tech Stack Global Compliance** | Spot-check key entry points and modules for global violations |
-    | 6 | **Cross-Task Consistency** | Duplicate logic, naming conflicts, interface inconsistencies |
-    | 7 | **Orphan .gitkeep** | Dir has other files but still contains `.gitkeep` — must remove |
-
-    After scanning, prioritize and recommend Tasks needing deep audit:
-    - `done` but plan not fully completed
-    - Large codebase but no tests
-    - Long-term `active` with no progress
-
-    **Output**: Project health overview + deep audit recommendation list.
-</step_2_project>
+    | 1 | **Vision drift** | `roadmap.json` task directions align with `vision.md` |
+    | 2 | **Architecture consistency** | `map.json` vs actual dir structure; drift or unregistered modules |
+    | 3 | **Roadmap health** | Consistency + progress stats + long blocked + dep cycle detection |
+    | 4 | **Doc completeness** | Each Task has spec.md + plan.json; orphan directories |
+    | 5 | **Tech Stack global compliance** | Spot-check key entry points and modules |
+    | 6 | **Cross-Task consistency** | Duplicate logic, naming conflicts, interface inconsistency |
+    | 7 | **Orphan .gitkeep** | `.gitkeep` exists when dir has other files |
+
+    After scan, recommend tasks for deep review (`done` but plan incomplete / large codebase no tests / long `active`).
+
+    **Output**: Project health overview + deep review recommendation list. Enter step_3_report.
+</step_2b_project>
 
 <step_3_report>
-    **Role**: Report Writer
     **Action**:
 
     **Issue Classification**:
 
     | Level | Meaning | Example |
     |:---|:---|:---|
-    | `CRITICAL` | Must fix, blocks release | Logic errors, security vulnerabilities, data corruption risk |
-    | `WARNING` | Should fix, carries risk | Missing error handling, performance hazards, incomplete Spec coverage |
-    | `INFO` | Suggested improvement | Naming conventions, missing comments, simplifiable code |
+    | `CRITICAL` | Must fix, blocks release | Logic error, security hole, data corruption risk |
+    | `WARNING` | Should fix, risk exists | Missing error handling, performance hazard, Spec coverage gap |
+    | `INFO` | Suggested optimization | Non-standard naming, missing comments, simplifiable code |
 
     **Issue Format** (each must include):
     ```
-    [LEVEL] file/path:line — Dimension Name
-      Description: specific issue
+    [LEVEL] file:line — Dimension name
+      Description: specific problem
       -> Recommended fix: /archi.fix <ID> <description> or /archi.edit <ID> <description>
     ```
 
-    **Action Routing** (recommend command by issue type):
+    **Action Routing**:
 
     | Issue Type | Recommended Command |
     |:---|:---|
-    | Bug (logic error, edge case miss) | `/archi.fix <ID> <description>` |
-    | Spec gap (task not fully implemented) | `/archi.edit <ID> <supplement>` |
-    | Architecture-level issue (global violation) | `/archi.revise <description>` |
-    | Incomplete task (plan falsely marked done) | `/archi.code <ID>` |
-    | Minor issue (naming, comments, simplification) | Address in next `/archi.code` |
-
-    **Report Structure**:
-    1.  Audit summary (mode, scope, date)
-    2.  Findings list (sorted by severity: CRITICAL → WARNING → INFO)
-    3.  Statistics summary (count per severity level)
-    4.  Fix ticket summary (directly executable command list)
-    5.  Next Steps table
+    | Bug | `/archi.fix <ID> <description>` |
+    | Spec gap | `/archi.edit <ID> <supplement description>` |
+    | Architecture-level | `/archi.revise <description>` |
+    | Feature incomplete | `/archi.code <ID>` |
+    | Minor | Address in next `/archi.code` |
+
+    **Pre-signoff Checklist** (confirm each item before writing report file):
+    □ (Task-level) All 15 review dimensions covered; inapplicable items marked N/A (not silently skipped)
+    □ (Project-level) All 7 checklist items evaluated
+    □ Each CRITICAL/WARNING finding includes `file:line` + code snippet
+    □ Each finding includes a recommended fix command (/archi.fix / /archi.edit etc.)
+    □ Report written to correct file (task-level: tasks/<id>/audit.md; project-level: audits/YYYY-MM-DD.md)
+
+    **Report Structure**: Review summary → Finding list (CRITICAL → WARNING → INFO) → Stats summary → Fix work items → Next Steps.
 
     **Write Report File**:
     - Task-level → `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md` (overwrite)
-    - Project-level → `[[__DOCS_DIR__]]/audits/YYYY-MM-DD.md` (date-archived, same-day overwrite)
+    - Project-level → `[[__DOCS_DIR__]]/audits/YYYY-MM-DD.md` (date archive)
 
-    **Output**: Complete audit report (output to both conversation and file).
+    **Output**: Full review report (to conversation and file).
 </step_3_report>
 
 </protocol_audit>

package/dist/templates/en/docs/prompts/code.md

@@ -1,153 +1,163 @@
 <protocol_code>
-  **Trigger**: `/archi.code <id>`
-  **Goal**: Based on the `tasks/<id>_<Slug>/plan.json` task list, complete task implementation; follow `02_tech_stack.md` ([?UI] also follow `design_tokens.json`); pass build, type check, lint, formatting, test and audit.
+  **Trigger**: `/archi.code <id>` | Auto-loaded by Workflow Dispatch on natural language trigger
+  **Goal**: Complete feature development per `tasks/<id>_<Slug>/plan.json` task list; follow `tech_stack.md` (UI projects only: also follow `design_tokens.json`); pass build, types, Lint, format, tests and audit.
 
 <meta>
     <style>Deterministic, Type-Safe, SOTA-First</style>
     <language>English</language>
     <principles>
-      1.  **Frontmatter Preservation**: Prohibited from modifying existing files' YAML Frontmatter.
-      2.  **Follow Conventions**: Use only existing repo libraries and patterns; read before modify.
-      3.  **Security First**: Prohibit introducing/printing secrets; sensitive info must not be written to disk.
-      4.  **SOTA Pattern Check**: Reject outdated practices; adopt best practices defined in tech_stack.
+      1.  **Frontmatter Preservation**: Do not change existing files' YAML Frontmatter.
+      2.  **Follow Conventions**: Use only repo-existing libs and patterns; read before modify.
+      3.  **Security First**: Do not introduce/print secrets; sensitive info must not be persisted.
+      4.  **SOTA Pattern Check**: Reject outdated patterns; use tech_stack defined best practices.
       5.  **No Commit Policy**: Do not commit without authorization; present changes as patches.
-      6.  **Static Check First**: Must pass all static checks (Type/Lint/Format).
-      7.  **Plan Completion Gate**: Verify Plan completion before signing off. All AI-completable tasks must be finished; only "Human Intervention" and "Force Majeure" are exempt.
+      6.  **Static Check First**: Must pass all static checks (types/Lint/format).
+      7.  **Plan Completion Gate**: Verify Plan completion before finish. All tasks AI can complete must be done; only exempt "manual intervention" and "force majeure".
+      8.  **IDE-Native First**: Leverage IDE native capabilities to drive execution rhythm; this protocol defines quality standards and checkpoints, not fight IDE planning/execution mechanisms.
     </principles>
 </meta>
 
 <step_1_resolve>
-    **Role**: System Analyst
     **Action**:
-    1.  **Resolve ID**: Parse `<id>` → Task Name, Slug, phase/status from `[[__DOCS_DIR__]]/global/roadmap.json`.
-    2.  **Status Gate** — Only `active` can enter code workflow:
+    1.  **Resolve ID**: Parse `<id>` from roadmap.json → Task Name, Slug, phase/status.
+    2.  **Status Gate** — only `active` may enter code flow:
 
         | Status | Handling |
         |:---|:---|
         | `active` | Pass, continue |
         | `pending` | Reject — prompt to run `/archi.plan <ID>` first |
-        | `blocked` | Reject — prerequisites not completed |
-        | `done` | Reject — already completed, use `/archi.edit <ID>` for modifications |
-
-    3.  **Load Context** (Use Roadmap `📁 Slug` to locate):
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — Logic & Scenarios
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — task UI scope declaration (if exists)
-        - [?Complex] `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/design.md` — Technical design (if exists): state machine/pipeline/protocol definitions, parameter table, invariants
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_context.md` — AI screen index (screen IDs / routes / states / navigation graph / shared components)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_concept.html` — read-only visual reference (calibrate layout against this during implementation; do not redesign — design is already locked in ui.md)
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — Task breakdown (contains `notes` shorthand; must reference during execution)
-        - `02_tech_stack.md` — Technical Red Lines
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
-        - **Read Refs** (if any): Read `[[__DOCS_DIR__]]/refs/index.json` (if exists); match by tags and spec.md tech domain semantics; load only matched ref files as supplementary context; skip if `refs/` missing or empty.
-
-    **Output**: Atomic list of tasks to implement, marking dependencies and order.
+        | `blocked` | Reject — upstream deps incomplete |
+        | `done` | Reject — already done; use `/archi.edit <ID>` for changes |
+
+    3.  **Load**: task docs (spec/ui/design/plan) + project context (tech_stack/design_tokens/data_snapshot/ui_context/screens/) + refs (match by tags; load only matched files).
+
+    **Output**: Atomic task list to implement with dependencies and order.
 </step_1_resolve>
 
 <step_2_plan>
-    **Role**: Tech Lead
     **Action**:
-    Generate execution blueprint (dynamically adjusted by project type):
-    - **Phase A (Domain/Data/API)**: Data models/interfaces/validation
-    - **Phase B (UI/Presentation)**: Component structure/styling (use Design Tokens only); non-UI projects adjust to corresponding presentation layer
-    - **Phase C (Integration)**: End-to-end wiring (state management, routing, data flow, error handling)
+    Generate execution blueprint (adjust by project type):
+    - **Phase A (Domain/Data/API)**: Data models / interfaces / validation
+    - **Phase B (UI/Presentation)**: Component structure / styles (Design Tokens only); non-UI projects adjust to corresponding presentation layer
+    - **Phase C (Integration)**: End-to-end wiring (state, routing, data flow, error handling)
 
-    Write completion criteria for each task: static checks passed, tests passed, compliant with tech_stack specs.
+    Each task must have completion criteria: static checks pass, tests pass, comply with tech_stack.
 
-    **Output**: Implementation-oriented atomic task list (Checkbox).
+    **Output**: Atomic task list for implementation (Checkbox).
 </step_2_plan>
 
 <step_3_implement>
-    **Role**: Senior Engineer
     **Protocol**:
-    - **Read First**: Must read target file before modification; follow existing code style.
-    - **Use Existing Stack**: Use only technologies and libraries declared in `02_tech_stack.md`.
-    - [?UI] **Design Tokens Only**: Styles strictly use visual patterns defined by Tokens/Presets; prohibited hardcoding magic values (colors, sizes, spacing, etc.).
-    - **Type-Safe**: Complete type definitions; use the project tech stack's type system to guard boundaries.
-    - **Code Organization**: Follow the architecture pattern and file placement strategy defined in `02_tech_stack.md`.
-    - **Comments**: Explain Why, not What; reject nonsense comments.
-    - **Naming**: Self-documenting names; reject `a`, `b`, `tmp` etc. (except loop variable `i`).
-    - [?Complex] **Design Adherence**: When `design.md` exists, implementation must strictly follow its state machine/pipeline/protocol definitions; parameters must reference design.md § 3 values (no hardcoding other values); must satisfy all § 4 Invariants (use assert or runtime checks).
-    - **Error Handling**: Prohibit swallowing errors/silent failures; must properly propagate errors and provide observable feedback to callers (UI: Toast; CLI: Exit Code; API: Status Code + Body).
-    - **Robustness**: Explicitly handle edge cases (Loading/Error/Empty/Timeout); prohibit writing only Happy Path.
+    - **Read First**: Must read target file before modify; follow existing project code style.
+    - **Use Existing Stack**: Use only tech and libs declared in `tech_stack.md`.
+    - (When this task involves UI) [[INCLUDE: shared/ui-redlines.md]]
+    - **Type-Safe**: Complete type definitions; use project type system to guard boundaries.
+    - **Code Organization**: Follow `tech_stack.md` architecture and file placement.
+    - **Comments**: Explain Why, not What.
+    - **Naming**: Self-explanatory names; no meaningless names.
+    - Complex tasks only: **Design Adherence**: When `design.md` exists, implementation must strictly follow its state machine/pipeline/protocol; params reference § 3 values; must satisfy all § 4 Invariants.
+    - **Error Handling**: No swallowing/silent failure; propagate and give callers observable feedback.
+    - **Robustness**: Explicitly handle boundaries (Loading/Error/Empty/Timeout); no Happy Path only.
     - **SOTA**: Follow tech_stack best practices; reject explicitly forbidden outdated patterns.
-    - **Scaffold Safety**: Scaffolds in non-empty directories may overwrite files — must generate in new directory and protect `[[__DOCS_DIR__]]/`; delete/overwrite operations must list manifest and confirm first.
-    - **.gitkeep Cleanup**: Empty dirs may use `.gitkeep` for Git tracking; when adding other files to a dir, must remove that dir's `.gitkeep`.
-    - **Patch Output**: Output changes as patches, with Code References.
-    - **Progress Tracking**: After completing each task, immediately update the corresponding task's `done: true` in `plan.json`; prohibited from batch-updating at signoff (progress will be lost if session is interrupted).
+    - **Scaffold Safety**: Non-empty dirs must protect `[[__DOCS_DIR__]]/`.
+    - **.gitkeep Cleanup**: Remove `.gitkeep` when adding files to dir.
+    - **Patch Output**: Output changes as patches with Code Reference.
+    - **Progress Tracking**: After each task, update `plan.json` corresponding `done: true` immediately; do not batch at signoff.
 
-    **Action**: Implement Phase A/B/C step by step; produce complete, production-quality code (with necessary tests); new files/directories must align with tech_stack.
+    **Action**: Implement phase A/B/C item by item; produce complete, production-ready code (including necessary tests).
 </step_3_implement>
 
 <step_4_validate>
-    **Role**: Validation Engineer
-    **Action** (Fix and re-run on failure; commands subject to `02_tech_stack.md` Section 5):
+    **Action** (on failure fix and re-run; commands per `tech_stack.md` Section 5):
 
-    **Automated Check**: Run `[[__DOCS_DIR__]]/scripts/validate` (if exists); otherwise execute the checklist below manually.
+    **Automated Check**: Check `scripts/validate`:
+    - **Exists** → Must run, results per script output
+    - **Not exists** → Execute checklist below
 
-    | Phase | Check Item | Requirement |
+    > **Scripts Check**: If `scripts/` directory does not exist → Suggest running `/archi.script` to generate automation scripts first.
+
+    | Phase | Check | Requirement |
     |:---|:---|:---|
-    | **Static** | Build | Zero compilation errors |
+    | **Static** | Build | Zero compile errors |
     | | Type Check | Zero type errors |
-    | | Lint | Zero lint errors (warnings must explain reason) |
-    | | Format | Compliant with format rules (if failed, auto-fix then re-check) |
-    | **Test** | Existing Tests | Run existing test suite, all pass; must not break existing tests |
-    | | New Coverage | Add tests for newly added/modified critical logic; pure styling exempt |
+    | | Lint | Zero Lint errors (warnings require reason) |
+    | | Format | Compliant (auto-fix then re-check if fail) |
+    | **Test** | Existing Tests | All pass; do not break old tests |
+    | | New Coverage | Add tests for new/modified critical logic |
 
-    **Task Verification (Mandatory)**
+    **Task Verification (mandatory)**
 
-    > Prohibited from marking complete via code review or automated tests alone; must actually run and verify the target task.
-    > If dev server is not running, execute `[[__DOCS_DIR__]]/scripts/dev-up` first.
-    > **Read `notes.Verify` first**: Read the `Verify: [...]` portion at the end of the current task's `notes` field and use that operation as the concrete e2e step. Fall back to the table below only if the `notes` field has no `Verify` entry.
+    > Do not mark complete by code review only; must actually run target feature and verify.
+    > **Prefer `notes.验证`**: First read current task `notes` end `Verify: [...]` and run e2e; fallback to table by type when no verify field.
 
     | Project Type | Verification Action | Pass Criteria |
     |:---|:---|:---|
-    | [?Web] | Browser-navigate target task path | Renders correctly, no interaction errors, clean console |
-    | [?API] | Call new/modified endpoints | Status code and body match spec |
-    | [?CLI] | Execute target command (normal args + edge cases) | stdout as expected, correct exit code |
-    | [?Lib] | Run example code or playground to verify exported API | No runtime errors, correct return values |
-    | [?Mobile] | Emulator/device operate target task | UI renders, interactions respond |
-    | [?Desktop] | Launch app operate target task | Window renders, task functional |
+    | When this task involves UI | Browser: operate target feature path | Render OK, interaction no errors |
+    | When this task involves API | Call new/modified endpoint | Status and Body match spec |
+    | When this task involves CLI | Execute target command (normal + edge params) | stdout expected, exit code correct |
+    | When this task involves lib | Run sample code to verify exported API | No runtime error, return correct |
+    | When this task involves mobile | Simulator/device: operate | UI OK, interaction responsive |
+    | When this task involves desktop | Launch app and operate | Window OK, feature works |
 
-    **Evidence**: Output must include verification results (command output summary / screenshot / error log).
-    **Fallback**: If verification keeps failing and environment issues suspected → `[[__DOCS_DIR__]]/scripts/dev-reset` → `[[__DOCS_DIR__]]/scripts/dev-up` → retry.
+    **Evidence**: Attach verification result (command output summary / screenshot / error log).
+    **Fallback**: If verification keeps failing → `scripts/dev-reset` → `scripts/dev-up` → retry.
 
-    **Output**: ✅/❌ status and reason for each check; Task Verification evidence.
+    **Output**: Each check ✅/❌ status and reason; Task Verification evidence.
 </step_4_validate>
 
 <step_5_verify>
     **Role**: Independent Reviewer
 
     **5A. Code quality review**:
-    [[SUBAGENT: archi-silent-audit|mode: code-impl, context: Review step_3 implemented code (Tech/SOTA/Security/Performance + conditional dimensions)]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`, follow mode: code-impl review dimension table item by item)]]
+    [[SUBAGENT: archi-silent-audit|mode: code-impl, context: Review step_3 implemented code (Tech/SOTA/Security/Performance + conditional dimensions)]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`, follow mode: code-impl review dimension table)]]
 
     **5B. Linkage check**:
-    [[SUBAGENT: archi-feature-relations|mode: check, context: Semantically compare this implementation with featureRelations sources]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-feature-relations/SKILL.md`, follow mode: check logic)]]
+    [[SUBAGENT: archi-feature-relations|mode: check, context: Compare implemented feature with featureRelations sources semantically]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-feature-relations/SKILL.md`, follow mode: check logic)]]
 
     **5C. Data governance sync**:
-    [[SUBAGENT: archi-data-sync|context: Scan this implementation for new business entities/error codes/Schema; incremental sync per 03_data_governance.md rules]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-data-sync/SKILL.md`, follow its execution protocol)]]
+    [[SUBAGENT: archi-data-sync|context: Scan new business entities/error codes/Schema from implementation; incrementally sync per 00_system.md]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-data-sync/SKILL.md` and follow its protocol)]]
 
     [[INCLUDE: shared/verify-result-handling.md]]
 </step_5_verify>
 
 <step_6_signoff>
-    **Terminal Gate** (Do not skip; must complete before output summary):
+    **Terminal Gate** (do not skip):
     | Step | Command | Pass Condition |
     |:---|:---|:---|
-    | 1 | `npx archi plan <ID>` | All done or exempt only; not passed → return to step_3 |
+    | 1 | `npx archi plan <ID>` | All complete or exempt only; if fail do not sign off, return to step_3 |
     | 2 | `npx archi task <ID> --status done` | Task status updated |
-    | 3 | `npx archi task --check` | No ERROR-level issues |
-    | 4 | `npx archi render` | `.md` views generated |
-
-    **Action** (After Gate passes):
-    1.  Confirm all task `done` marks in `plan.json` are updated (should be done in real-time during step_3; this is a final check).
-    2.  **Drift Warning**: Compare code changes against `spec.md`'s key checkpoints (interface signatures, return types, key operations in Gherkin scenarios). If code exceeds spec coverage → mark `⚠️ Spec Drift`, suggest running `/archi.edit <ID>` to sync docs.
-    3.  Output completed task list with patch links (Code Reference).
-    4.  Provide next step suggestions and Git Commit Suggestion (Conventional Commits).
-
-    **Checkpoint** (Confirm before Output): □ Terminal Gate all executed
-
-    **Output**: Completion summary with completed tasks, exempt items (if any), Git Commit suggestion, Next Steps table.
+    | 3 | Standard check (task --check + render) | No ERROR + views generated |
+
+    **Action** (after Gate passes):
+    1.  Confirm `plan.json` each task `done` flag updated.
+    2.  **Drift Warning**: Compare code changes with `spec.md` key points. If beyond spec coverage → mark `⚠️ Spec drift`, suggest `/archi.edit <ID>`.
+    3.  Output completed task list and patch links.
+    4.  Provide next steps.
+
+    **Pre-signoff Checklist** (confirm each item before Output):
+    □ plan.json — every task done flag updated in real-time (not batch-updated at signoff)
+    □ Step 4 — Build / type check / Lint / format all passed
+    □ Step 4 — Task Verification executed for each project type with Evidence attached
+    □ Step 5A Silent Audit — executed, all CRITICAL issues resolved
+    □ Step 5B featureRelations check — executed
+      - Check if modified files affect other linked files
+    □ Step 5C data governance sync — executed:
+      - dictionary.json + error_codes.json + env_registry.json — required
+      - (UI projects only) design_tokens.json + ui_context.md
+      - (Data projects only) data_snapshot.json
+      - (API projects only) api_snapshot.json
+      - (CLI projects only) command_api.json
+      - (Lib projects only) public_api.json
+    □ Terminal Gate — npx archi plan <ID> all complete (exempt items only)
+
+    **Output**: Completion summary with completed tasks, exempt items (if any), Next Steps:
+
+    | Priority | Action | Notes |
+    |:---|:---|:---|
+    | (If no scripts/) | `/archi.script` | Generate automation scripts (validate/dev-up/dev-reset) |
+    | Recommended | `/archi.audit <ID>` | Independent review of implementation |
+    | (If Spec drift) | `/archi.edit <ID>` | Update docs before continuing |
+    | (If next pending task) | `/archi.plan <next pending ID>` | Plan the next task |
 </step_6_signoff>
 
 </protocol_code>