architext 0.0.2

package/dist/templates/en/docs/global/vision.md

@@ -0,0 +1,82 @@
+---
+description: Project Constitution: Vision, Personas, Principles & Boundaries.
+---
+
+# Product Vision: [Project Name]
+
+> **Version:** 1.0.0
+> **Status:** Active
+> **Role:** The "Constitution" of the project. All Tasks and Specs must align with this.
+
+## 1. Core Vision
+
+**Elevator Pitch:**
+[Product Name] is a [Target Market/Category] platform designed to help [Target User] solve [Core Pain Point], achieving [Ultimate Value] through [Core Solution/Uniqueness].
+
+**North Star Metric:**
+
+* [Metric Name]: [Description - e.g., Daily Focus Time per User]
+
+---
+
+## 2. Target Audience
+
+### Primary Persona
+
+* **Role:** [e.g., Student preparing for exams]
+* **Key Traits:** [Keywords]
+* **Pain Points:**
+  * [Pain Point 1]
+  * [Pain Point 2]
+* **Goals:**
+  * [Desired Outcome]
+
+---
+
+## 3. Product Principles
+
+* **[Principle 1]:** [e.g., Simplicity First - Any extra click needs a reason]
+* **[Principle 2]:** [e.g., Encourage over Punish - Give encouragement instead of red warnings when tasks aren't met]
+
+---
+
+## 4. Design & Experience [?UI]
+
+> **Note:** This section applies only to projects with UI. For specific color values and radius definitions, strictly refer to `[[__DOCS_DIR__]]/global/design_tokens.json`.
+
+### Visual Style
+
+* **Keywords:** [e.g., Warm, Focused, Distraction-free]
+* **Density:** [e.g., High whitespace, Immersive]
+* **Animation:** [e.g., Subtle micro-interactions, no flashy transitions]
+
+### Tone of Voice
+
+* **Personality:** [e.g., Like a study buddy, not a strict teacher]
+* **Do's:** [e.g., Use "Let's" instead of "You should"]
+* **Don'ts:** [e.g., Don't use robotic error codes]
+
+---
+
+## 5. Boundaries
+
+### In Scope
+
+* [Core Task A]
+* [Core Task B]
+
+### Out of Scope
+
+* **[Anti-Goal 1]:** [e.g., No social leaderboards]
+* **[Anti-Goal 2]:** [e.g., No dark mode switch (Default is dark)]
+
+---
+
+## 🤖 AI Maintenance Guide
+
+**Trigger**: Only modify during project initialization (`/archi.start`) or major strategic pivot (`/archi.revise`).
+
+**Action**:
+1.  **Alignment**: Ensure Section 3 (Principles) conflicts with technology choices in `02_tech_stack.md`.
+2.  **Completeness**: Must fill all `[ ]` placeholders, strictly no "Example" text remaining.
+3.  **Consistency**: All Task Specs (`.spec.md`) must reference the Vision in this file to ensure alignment.

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

@@ -0,0 +1,150 @@
+<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.
+
+<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).
+    </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 |
+
+    **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:
+
+        | 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.
+
+    **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.
+
+    **Output**: Audit scope and context inventory.
+</step_1_resolve>
+
+<step_2_task>
+    **Role**: Chief Auditor
+    **Scope**: Task-level deep code audit (execute only for `/archi.audit <id>`).
+
+    Audit dimension by dimension; every finding must include `file:line` + code snippet + severity:
+
+    | # | Dimension | Audit 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>
+    **Role**: Chief Auditor
+    **Scope**: Project-level health check (execute only for `/archi.audit` without arguments).
+
+    | # | Check Item | 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>
+
+<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 |
+
+    **Issue Format** (each must include):
+    ```
+    [LEVEL] file/path:line — Dimension Name
+      Description: specific issue
+      -> Recommended fix: /archi.fix <ID> <description> or /archi.edit <ID> <description>
+    ```
+
+    **Action Routing** (recommend command by issue type):
+
+    | 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
+
+    **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)
+
+    **Output**: Complete audit report (output to both conversation and file).
+</step_3_report>
+
+</protocol_audit>

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

@@ -0,0 +1,160 @@
+<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.
+
+<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.
+      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.
+    </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:
+
+        | 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)
+        - [?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`
+
+    **Output**: Atomic list of tasks to implement, marking 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)
+
+    Write completion criteria for each task: static checks passed, tests passed, compliant with tech_stack specs.
+
+    **Output**: Implementation-oriented atomic task list (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`).
+    - **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.
+    - **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).
+
+    **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.
+</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):
+
+    **Automated Check**: Run `[[__DOCS_DIR__]]/scripts/validate` (if exists); otherwise execute the checklist below manually.
+
+    | Phase | Check Item | Requirement |
+    |:---|:---|:---|
+    | **Static** | Build | Zero compilation 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 |
+
+    **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.
+
+    | 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 |
+
+    **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.
+
+    **Output**: ✅/❌ status and reason for each check; Task Verification evidence.
+</step_4_validate>
+
+<step_5_audit>
+    **Role**: Chief Auditor
+    **Checklist**:
+    1.  **Tech Consistency**: Consistent with `02_tech_stack.md` (libraries/patterns/API style).
+    2.  [?UI] **Design Compliance**: Styles use Token/Preset visual patterns only; no hardcoded magic values.
+    3.  [?Data] **Data Integrity**: Compliant with `data_snapshot.json`; field names/types match.
+    4.  **SOTA**: Reject outdated patterns; adopt tech_stack best practices.
+    5.  [?UI] **Accessibility**: Include necessary accessibility attributes.
+    6.  [?I18n] **I18n**: No hardcoded strings; must use Key/dictionary reference.
+    7.  **Performance**: Avoid unnecessary large dependencies/full imports/useless computation/memory leaks.
+    8.  **Security**: No sensitive info leakage; inputs validated.
+    9.  **Static Check Zero**: All static check issues resolved.
+    10. **step_4 Gate**: Confirm all step_4 checks (Static + Test + Task Verification) have passed.
+    11. **Linkage Check**: Read the `featureRelations` array from `[[__DOCS_DIR__]]/global/map.json`; semantically compare the current task against each `sources` field. If matched, output: `⚠️ Linkage: [aggregator] — [checkNote]`, reminding to confirm whether the aggregator needs to be updated after this implementation. Skip if `featureRelations` is empty.
+    12. **Data Governance**: When this implementation introduces new content, directly write to the corresponding global index:
+
+        | Trigger | File | Action |
+        |:---|:---|:---|
+        | New business entity · verb · shared utility | `dictionary.json` | Directly append |
+        | New error scenario | `error_codes.json` | Directly append |
+        | [?Data] Schema actually changed | `data_snapshot.json` | Directly sync |
+
+    Detail issues can be Auto-Fixed with explanation; major risks marked `⚠️ Risk` with alternatives proposed.
+</step_5_audit>
+
+<step_6_signoff>
+    **Terminal Gate** (Do not skip; must complete before output summary):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi plan <ID>` | All done or exempt only; not passed → 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.
+</step_6_signoff>
+
+</protocol_code>

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

@@ -0,0 +1,87 @@
+<protocol_edit>
+  **Trigger**: `/archi.edit <id> [context]`
+  **Goal**: Based on new requirements/feedback, update Spec/UI docs of an already managed module and append development plans.
+
+<meta>
+    <style>Collaborative, Iterative, Traceable</style>
+    <language>English</language>
+    <principles>
+      1.  **Doc First**: Must modify docs (Spec/UI) first, then generate Plan. Prohibited from skipping docs to change code plans directly.
+      2.  **Incremental**: Only append new Tasks to Plan, keep completed history (unless rollback needed).
+      3.  **Conflict Check**: Check if new requirements conflict with tech_stack / design_tokens.
+      4.  **Frontmatter Preservation**: Prohibited from destroying existing document Metadata.
+    </principles>
+</meta>
+
+<step_1_load>
+    **Role**: Product Manager
+    **Action**:
+    - Read `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/` spec.md, ui.md, plan.json.
+    - [?UI] Read `[[__DOCS_DIR__]]/global/ui_context.md` (locate the screen scope and navigation graph for this task).
+    - Check `Spec-Status` field in spec.md:
+      - `Full` → Normal flow, proceed to step_2.
+      - `Stub` → Proceed to step_1_5_enrich.
+    - [?Major UX Change] Quick search for similar product best practices.
+</step_1_load>
+
+<step_1_5_enrich>
+    **Role**: Reverse Engineer
+    **Trigger**: spec.md contains `Spec-Status: Stub` (lightweight snapshot generated by `/archi.inherit`).
+
+    **Action**:
+    1. Inform user: "This task only has a lightweight snapshot. A full spec must be generated before modifications can proceed."
+    2. Extract source file paths from the stub's "Associated Files" section.
+    3. Read each associated file with medium-depth scan (entry point + core logic).
+    4. Enrich the stub into a full spec based on code analysis:
+       - Preserve existing overview and key flows
+       - Add Gherkin Scenarios (covering normal flows + exception paths)
+       - Add interface/type definitions (if this task is upstream of others)
+    5. Update `Spec-Status: Stub → Full`.
+    6. [?UI] If module has UI → generate or update `ui.md` (scope declaration); if new screens are needed, notify user to run the `archi-ui-wireframe` Skill (Skill syncs both `ui_concept.html` + `ui_context.md`).
+    7. Generate `plan.json` (all tasks as done, recording implemented content).
+    8. Present enriched spec summary to user.
+
+    **Gate**: User confirms enriched content is correct before proceeding to step_2_refine_docs.
+    **Exception**: Associated files missing/moved → prompt user to update paths.
+</step_1_5_enrich>
+
+<step_2_refine_docs>
+    **Role**: Requirements Analyst & Designer
+    **Action**:
+    - Modify spec.md (logic/rule changes) and ui.md (structure/interaction changes) based on `[context]`.
+    - [?UI Modification] Sync `ui_concept.html` + `ui_context.md` via Skill (Skill is the sole writer of both files):
+
+      | Change Type | Criteria | Action |
+      |:---|:---|:---|
+      | No screen impact | Logic/data only, no visual diff | Update spec.md only; `ui_concept.html` / `ui_context.md` unchanged |
+      | Minor UI tweak | New/modified state, popup, or local area; overall layout unchanged | Call Skill (Modify screens mode) to update both files; output `MODIFIED: S-XX` |
+      | Screen structure change | Layout refactor, new standalone screen, navigation path change | Call Skill (Modify screens mode) to update both files; output `MODIFIED: S-XX`; if Phase 2 coloring is done, re-color only the modified screen |
+      | Task reduction | Screen/region removed entirely | Call Skill (Remove screens mode) to update both files; output `REMOVED: S-XX` |
+
+    - Ask user questions (A/B/C/D options) to confirm details when requirements are vague.
+
+    **Output**: Updated Spec, UI documents, and `ui_concept.html` / `ui_context.md` change summary.
+</step_2_refine_docs>
+
+<step_3_update_plan>
+    **Role**: Tech Lead
+    **Action**:
+    - Append new phase to `plan.json` phases array: `Phase X: Change Request (<Date>)`.
+    - List specific Tasks (API update, UI tweak, Test update); each must be verifiable.
+    - **Status Transition**: If current task status=`done`, reset to `active` after appending the Phase (otherwise `/archi.code` will be rejected by the Status Gate).
+
+    **Terminal Gate** (Do not skip; must complete before step_4 output):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` views generated |
+    | 2 | [if current status=done] `npx archi task <ID> --status active` | Task status reset to active |
+
+    **Output**: plan.json with new tasks appended; if status transition was performed, output `MODIFIED: roadmap.json <ID>.status done→active`.
+</step_3_update_plan>
+
+<step_4_summary>
+    **Action** (Gate must complete in step_3):
+    **Output**: Task update summary with Spec/UI/Plan change overview and Next Steps table. Recommend running `/archi.code <ID>`.
+</step_4_summary>
+
+</protocol_edit>

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

@@ -0,0 +1,86 @@
+<protocol_fix>
+  **Trigger**: `/archi.fix [id] <context>`
+  **Goal**: Diagnose Bug and execute fix directly. If `[id]` not provided, auto-locate relevant task module.
+
+<meta>
+    <style>Diagnostic, Surgical, Spec-Compliant</style>
+    <language>English</language>
+    <principles>
+      1.  **Spec Immutable**: Prohibited from modifying `spec.md` / `ui.md` (unless Bug itself is a documentation error).
+      2.  **Reproduction**: Must conceive reproduction steps or test cases first.
+      3.  **Root Cause**: Must analyze root cause, not patch the surface.
+      4.  **Test-Driven**: Fix plan must include new test cases.
+      5.  **Auto-Discovery**: If ID not specified, locate Task via Context semantic search.
+    </principles>
+</meta>
+
+<step_1_diagnose>
+    **Role**: Fault Analyst
+    **Action**:
+    1.  **Resolve Target**:
+        - Has `<id>`: Lock target `tasks/<ID>_<Slug>/`.
+        - No `<id>`: Analyze `[context]` to search most relevant module.
+          Unique match → Auto lock | Multiple matches → List candidates and ask | Cannot locate → Report error requesting ID.
+    2.  Read all docs under target directory (`spec.md`, `ui.md`, `plan.json`) and related code.
+    3.  Read `02_tech_stack.md` (ensure fix does not violate tech red lines) and `[[__DOCS_DIR__]]/global/vision.md` (ensure fix direction stays aligned with project vision).
+    4.  Analyze `[context]`, combine with code logic to locate potential failure points.
+    5.  **Hypothesis**: Propose 1-3 root cause hypotheses.
+
+    **Output**: Root Cause Analysis report.
+</step_1_diagnose>
+
+<step_2_plan_fix>
+    **Role**: Tech Lead
+    **Action**:
+    - Update `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/plan.json`, append to `phases` array a phase object with `name`: `Bugfix: <Bug Title>`.
+    - Tasks: 1) Create reproduction test (Red) 2) Apply fix (Green) 3) Regression test.
+
+    **Terminal Gate** (Do not skip; must complete before step_5 output):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` views generated |
+
+    **Output**: plan.json with fix tasks appended.
+</step_2_plan_fix>
+
+<step_3_execute_fix>
+    **Role**: Senior Engineer (Surgical Fix — bug only, no scope creep)
+    **Action**:
+    - Modify code directly according to Plan.
+    - Fix Bug only; prohibited from opportunistic refactoring or modifying unrelated code.
+    - Error handling follows `code.md` specs (no swallowing errors/no silent failures).
+</step_3_execute_fix>
+
+<step_4_verify>
+    **Role**: QA Engineer
+    **Terminal Gate** (Do not skip; must complete before step_5 output):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | Run build command | Build succeeds |
+    | 2 | Run type check | Zero type errors |
+    | 3 | Run Lint/Format | Pass |
+    | 4 | Run tests | Reproduction + regression tests pass |
+
+    Any failure must be fixed until passed.
+</step_4_verify>
+
+<step_4_5_plan_update>
+    **Role**: Tech Lead
+    **Action**:
+    1. Update `plan.json`: set `done: true` for completed tasks in the Bugfix Phase.
+    2. [current status=`done` and all Bugfix Phase tasks passed] → Keep status as `done`.
+    3. [Bugfix Phase has unresolved tasks] → Run `npx archi task <ID> --status active`; note in signoff that `/archi.code` is needed to complete remaining fixes.
+
+    **Output**: `MODIFIED: plan.json Bugfix Phase done marks` (if status changed, append `MODIFIED: roadmap.json <ID>.status`).
+</step_4_5_plan_update>
+
+<step_5_summary>
+    **Output**: Bug fix summary with Root Cause analysis, fix content, new tests, and Next Steps table:
+
+    | Priority | Action | Notes |
+    |:---|:---|:---|
+    | Recommended | `/archi.audit <ID>` | Re-audit to confirm fix is complete and no new issues introduced |
+    | Optional | `/archi.code <ID>` | If Bugfix Phase has remaining incomplete tasks |
+</step_5_summary>
+
+</protocol_fix>

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

@@ -0,0 +1,69 @@
+<protocol_help>
+  **Trigger**: `/archi.help [question]`
+  **Goal**: Project navigation and contextual Q&A. Analyze current project state to recommend next actions; or answer user questions based on project context.
+
+<meta>
+    <style>Concise, Contextual, Actionable</style>
+    <language>English</language>
+    <principles>
+      1.  **Context-Aware**: Answer based on real project state. No guessing.
+      2.  **Actionable Output**: Every output must include an executable next step (specific command + args).
+      3.  **Minimal Token**: Keep output concise. Don't repeat what the user already knows. Only present conclusions and recommendations.
+      4.  **No Audit**: No deep auditing (that's `/archi.audit`'s job). Focus on navigation and Q&A.
+    </principles>
+</meta>
+
+<step_1_load_context>
+    **Role**: Project Observer
+    **Action**:
+    1.  Read `[[__DOCS_DIR__]]/global/roadmap.json` — extract only `id/title/status/deps/tag` fields per task; skip `goal/notes` (navigation and status aggregation do not need these details).
+    2.  Scan `[[__DOCS_DIR__]]/tasks/` directory — get existing Tasks and their doc completeness (spec.md / ui.md / plan.json).
+    3.  [?question] If user provided a question, locate relevant files by semantic match (spec / plan / vision / tech_stack / data_snapshot, etc.), read as needed.
+
+    **Output**: Internal context (not shown to user).
+</step_1_load_context>
+
+<step_2_route>
+    **Role**: Router
+    **Action**: Branch based on input:
+
+    | Input | Branch |
+    |:---|:---|
+    | No args | → step_3_navigate (project navigation) |
+    | Has `[question]` | → step_4_answer (contextual Q&A) |
+
+</step_2_route>
+
+<step_3_navigate>
+    **Role**: Project Navigator
+    **Action**:
+    1.  **Determine project phase**:
+
+        | Signal | Phase | Recommendation |
+        |:---|:---|:---|
+        | roadmap.json missing | Not initialized | New project → `/archi.start`; existing code → `/archi.inherit` |
+        | Has roadmap but no Task dirs | Started, not planned | Run `/archi.scope` to plan new tasks |
+        | Has Legacy stubs (Spec-Status: Stub) | Inherited, not enriched | Run `/archi.edit LEG-xx` to enrich spec |
+        | Has active tasks with complete plan.json | Ready to code | Run `/archi.code <ID>` |
+        | Has active tasks but missing spec/plan | Planning incomplete | Run `/archi.plan <ID>` to complete |
+        | All tasks done | Complete | Run `/archi.scope` to plan new tasks or release |
+        | Has blocked tasks | Blocked | Show blocking reason and prerequisites |
+
+    2.  **Output format**:
+        - One-line summary of current state
+        - Recommended next action (with specific command)
+        - If multiple paths available, list by priority (max 3)
+</step_3_navigate>
+
+<step_4_answer>
+    **Role**: Project Advisor
+    **Action**:
+    1.  Parse `[question]` semantics, locate relevant project files.
+    2.  Read relevant files, synthesize answer.
+    3.  If question involves an action (e.g. "how to do X"), include specific command suggestions.
+    4.  If insufficient info to answer, state what's missing instead of fabricating.
+
+    **Output**: Concise answer based on project context + relevant file references.
+</step_4_answer>
+
+</protocol_help>