architext 0.0.2

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

@@ -0,0 +1,270 @@
+<protocol_inherit>
+  **Trigger**: `/archi.inherit`
+  **Phase**: Legacy Adoption
+  **Goal**: Reverse-engineer an existing codebase to generate the Architext document skeleton, bringing the project under framework governance.
+
+<meta>
+    <style>Analytical, Systematic, Evidence-Based</style>
+    <language>English</language>
+    <principles>
+      1.  **Code-Driven**: Code is the sole source of truth; do not speculate on tasks without evidence.
+      2.  **AI-Native Perspective**: All analysis from AI Agent perspective. Focus: Context Locality, Type Safety, Module Boundaries.
+      3.  **User Agency First**: AI analysis must be confirmed by the user. When code interpretation is ambiguous, ask the user; do not decide unilaterally.
+      4.  **Minimal Token**: Prioritize config files and entry points; avoid scanning every line of code.
+      5.  **Option Z Everywhere**: Supplementary questions must include `[Z] Custom`.
+    </principles>
+</meta>
+
+<step_0_recon>
+    **Role**: Intelligence Analyst
+    **Action**:
+    1. Read project root config files (auto-detect type):
+
+       | Language/Ecosystem | Config Files |
+       |:---|:---|
+       | Node.js | package.json, tsconfig.json |
+       | Rust | Cargo.toml |
+       | Go | go.mod |
+       | Python | pyproject.toml, requirements.txt |
+       | Java | pom.xml, build.gradle |
+       | Other | Use root directory config files |
+
+    2. Read README.md (if exists).
+    3. Scan directory structure (top-level + core source directories, two levels deep).
+    4. Infer project feature tags (UI / Data / CLI / Lib / API — from directory structure, dependencies, and config).
+    5. Identify entry points and core modules.
+
+    **Output**: Internal summary (not shown to user), proceed to step_1.
+</step_0_recon>
+
+<step_1_analysis>
+    **Role**: System Analyst
+    **Scan Strategy**: Medium-depth scan — read each module's entry file and core business files, extract main flow chains. Do not traverse every file.
+
+    **Action**:
+    1. For each identified functional module:
+       - Read entry file + 1-2 core business files
+       - Extract main flows (user action → system processing → result)
+       - Record associated file paths
+    2. For shared/infrastructure code (utils, middleware, config):
+       - Record directory and responsibility only; do not treat as functional modules
+    3. Extract domain terminology and naming conventions from code.
+
+    **Output**: Present structured analysis report to user:
+    ```
+    ### Codebase Analysis Report
+    > **Project**: [Name] | **Type**: [UI/Data/CLI/Lib/API] | **Scale**: ~[file count] files, [dir count] directories
+
+    **Tech Stack**:
+    | Category | Selection |
+    |:---|:---|
+    | Language | ... |
+    | Framework | ... |
+    | Build | ... |
+    | Testing | ... |
+    | Deployment | ... |
+
+    **Architecture Pattern**: [Inference] — [Evidence]
+
+    **Functional Module Inventory**:
+    | # | Module | Source Location | Responsibility | Key Flows |
+    |:---|:---|:---|:---|:---|
+    | 1 | [Name] | [Path] | [One sentence] | [Flow1], [Flow2] |
+
+    **Shared Infrastructure**:
+    | Directory | Responsibility |
+    |:---|:---|
+    | [Path] | [Description] |
+
+    **Domain Terminology**: [Term list]
+
+    **Uncertain Items** (if any):
+    - [Ambiguous item]
+    ```
+
+    **Gate**: User confirms or corrects. Do not proceed to step_2 without confirmation.
+</step_1_analysis>
+
+<step_2_supplementary>
+    **Role**: Product Consultant
+    **Trigger**: Only when step_1 has items AI cannot determine. Skip if no ambiguity.
+
+    **Action**: Ask ambiguous items in multiple-choice format.
+    - 3-5 options per question + `[Z] Custom`; AI recommendation marked `[Recommended]`.
+    - Total questions capped at 3.
+
+    Common ambiguities:
+    - Architecture pattern cannot be confirmed
+    - Certain directory responsibilities unclear
+    - Vision info (North Star Metric, design philosophy) cannot be inferred from code
+
+    **Output Format**:
+    ```
+    ### Supplementary Confirmation
+
+    **[Q1] Question Title**
+    > Why this information is needed
+
+    | ID | Option | Description |
+    |:---|:---|:---|
+    | A [Recommended] | ... | ... |
+    | B | ... | ... |
+    | Z | Custom | (Please describe) |
+
+    ---
+    **INPUT**: `Q1 answer | Q2 answer | ...`
+    ```
+</step_2_supplementary>
+
+<step_3_constitution>
+    **Role**: Chief Architect
+    **Input**: Step 1 analysis report + Step 2 supplements (if any).
+    **Action**: Generate project document skeleton in one pass.
+
+    ### Information Routing Rules
+
+    > Rule files (`02_tech_stack`, `90_custom_rules`, etc.) are already injected into context by the IDE — the AI knows their paths; write directly.
+
+    | Information from Code | Target File |
+    |:---|:---|
+    | README project description, target users, task list | `[[__DOCS_DIR__]]/global/vision.md` |
+    | Dependency list, config files, code patterns | rule file `02_tech_stack` |
+    | Directory structure, module dependencies, user journeys | `[[__DOCS_DIR__]]/global/map.json` |
+    | Domain terminology, abbreviations, naming conventions | `[[__DOCS_DIR__]]/global/dictionary.json` |
+    | eslint/prettier and existing standards | rule file `90_custom_rules` |
+    | Error code definitions in code | `[[__DOCS_DIR__]]/global/error_codes.json` |
+    | [?UI] CSS variables/theme config | `[[__DOCS_DIR__]]/global/design_tokens.json` |
+    | [?Data] Schema/Migration files | `[[__DOCS_DIR__]]/global/data_snapshot.json` |
+
+    ### 3.1 Vision (`[[__DOCS_DIR__]]/global/vision.md`)
+    - Derive from README + project config
+    - Items that cannot be derived: mark `(AI Inferred — user review recommended)`
+    - Do not retain template placeholders
+
+    ### 3.2 Tech Stack (rule file `02_tech_stack`)
+    - Existing dependencies/config → write directly
+    - Visible code conventions (naming, structure) → write to Coding Standards
+    - Must populate complete Section 1-8
+
+    ### 3.3 Custom Rules (rule file `90_custom_rules`)
+    - Extract rules from eslint/prettier/editorconfig
+    - Identify team conventions from code patterns (e.g., named export preference, async/await style)
+
+    ### 3.4 Roadmap (`[[__DOCS_DIR__]]/global/roadmap.json`)
+
+    **Structure**:
+    ```json
+    {
+      "version": 1,
+      "projectStatus": "active",
+      "lastUpdated": "<date>",
+      "phases": [
+        {
+          "id": "phase-0",
+          "name": "Legacy",
+          "tasks": [
+            {
+              "id": "LEG-01",
+              "title": "<Module Name>",
+              "status": "done",
+              "goal": "<One-line summary>. See tasks/LEG-01_<Slug>/spec.md",
+              "deps": [],
+              "tag": "Legacy",
+              "slug": "<Slug>"
+            }
+          ]
+        },
+        { "id": "phase-1", "name": "Infrastructure", "tasks": [] },
+        { "id": "phase-2", "name": "Core Features", "tasks": [] }
+      ]
+    }
+    ```
+
+    **Rules**:
+    - Functional modules → `phase-0: Legacy`, status `done`, tag `Legacy`, ID prefix `LEG-`
+    - Shared/infrastructure code does not enter roadmap; only goes to map.json directoryMapping
+    - phase-1/2 remain as empty skeletons
+    - Dependencies between LEG tasks must be reflected in deps
+
+    ### 3.5 Task Stub Specs
+
+    Create `[[__DOCS_DIR__]]/tasks/LEG-xx_<Slug>/spec.md` for each LEG task:
+
+    ```markdown
+    # LEG-xx: [Title]
+
+    > **Spec-Status**: Stub
+    > **Source**: Reverse-engineered from [source path]
+
+    ## Overview
+    [One paragraph description]
+
+    ## Key Flows
+    1. **[Flow Name]**: [A] → [B] → [C]
+    2. **[Flow Name]**: [A] → [B] → [C]
+
+    ## Associated Files
+    - [Role]: `[Path]`
+    - [Role]: `[Path]`
+    ```
+
+    > Stubs are a starting point, not the final state. Enrich later via `/archi.edit` (auto-triggers the `step_1_5_enrich` flow).
+
+    ### 3.6 map.json Population
+    - `directoryMapping`: Each core directory → `{ "path", "layer", "responsibility", "publicAPI" }`
+    - `logicalTopology`: Inter-module dependencies → `{ "from", "to", "type" }` (imports / calls / extends)
+    - `criticalUserJourneys`: Core flows → `{ "name", "steps": ["module → module → ..."] }`
+    - `featureRelations`: Scan code to identify "aggregator modules" and record them.
+      **Recognition patterns**: A module that iterates/enumerates/dynamically loads modules of the same type (e.g., `for (const cmd of allCommands)`, `Object.values(registry)`, reading a directory then dynamic import), or is described as "aggregating/listing/registering all X".
+      Record format: `{ "aggregator": "<ID or file path>", "sources": "<source range description>", "evidence": "<code basis>", "checkNote": "When tasks of this type are added or removed, check whether <aggregator> needs to be updated" }`
+
+    ### 3.7 Other Global Documents (as needed)
+    - `dictionary.json`: Extract domain terminology from code
+    - [?UI] `design_tokens.json`: Extract from CSS variables/theme
+    - [?UI] `ui_concept.html` + `ui_context.md`: **Not generated by this command.** After inherit completes, prompt the user to run the `archi-ui-wireframe` Skill to generate the global UI wireframe (Skill generates both files simultaneously).
+    - [?Data] `data_snapshot.json`: Extract from schema/migration
+    - `error_codes.json`: Extract from error definitions in code
+
+    **Output**: Write all files, then run `npx archi render`.
+</step_3_constitution>
+
+<step_4_audit>
+    **Role**: Chief Auditor
+    **Checklist**:
+    1.  **Vision Alignment**: Does vision.md match actual code functionality?
+    2.  **Tech Stack Consistency**: Does rule file `02_tech_stack` match package.json/config?
+    3.  **Map Coverage**: Does map.json cover all core directories?
+    4.  **Roadmap Completeness**: Does phase-0 cover all identified functional modules?
+    5.  **Stub Completeness**: Does every LEG-xx have a corresponding tasks/ directory and spec.md?
+    6.  **Dictionary Consistency**: No ambiguous or duplicate terms?
+
+    Silently fix issues; mark severe problems as `Risk Warning`.
+</step_4_audit>
+
+<step_5_signoff>
+    **Terminal Gate** (Do not skip; must complete before output summary):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | No ERROR-level issues |
+    | 2 | `npx archi render` | `.md` views generated |
+
+    **Action** (After Gate passes):
+    1.  Run `npx archi task` to display task overview.
+    2.  Output summary.
+
+    **Output**: Reverse-engineering summary containing:
+    - **Project Overview**: Type, scale, number of core modules
+    - **Legacy Tasks**: LEG-xx list (ID / Name / Source location)
+    - **Generated Documents**: File list
+    - **AI Inferred Items**: Mark confidence level (High/Medium/Low)
+    - **Next Steps**:
+
+    | Priority | Action | Description |
+    |:---|:---|:---|
+    | 1 | Review vision.md | Confirm AI-inferred vision description is accurate |
+    | 2 | `/archi.edit LEG-xx` | Enrich core module stubs into full specs (auto-triggers Enrich flow) |
+    | 3 | `/archi.scope [file_path]` | Plan new tasks/major modules |
+    | 4 | `/archi.plan <task ID>` | Deep-plan individual tasks |
+</step_5_signoff>
+
+</protocol_inherit>

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

@@ -0,0 +1,131 @@
+<protocol_map>
+  **Trigger**: `/archi.map`
+  **Goal**: Scan actual project directory structure, diff against `map.json`, identify additions/stale/changes, and update the architecture map after user confirmation.
+
+<meta>
+    <style>Systematic, Precise, Architecture-Aware</style>
+    <language>English</language>
+    <principles>
+      1.  **Scan vs Map**: Actual filesystem is Ground Truth; map.json is the old snapshot.
+      2.  **Smart Granularity**: Directory-level by default; drill to file-level when a single file carries multiple responsibilities.
+      3.  **Architecture Inference**: New entry classification must reference existing map patterns + `02_tech_stack.md`.
+      4.  **Batch Confirm**: Present all changes at once; user confirms in batch.
+    </principles>
+</meta>
+
+<step_1_scan>
+    **Role**: Surveyor
+    **Action**:
+    1.  **Read Map**: Read `[[__DOCS_DIR__]]/global/map.json` — current architecture map.
+    2.  **Read Tech Stack**: Read `02_tech_stack.md` — directory conventions, architecture patterns.
+    3.  **Scan Directory Tree**: Scan project directory structure.
+        - **Exclude**: `.git/`, `node_modules/`, `dist/`, `build/`, `[[__DOCS_DIR__]]/`, and paths declared in `.gitignore`.
+        - **Depth**: Follow granularity patterns of existing map.json entries. If existing entries include file-level → scan to file-level too.
+
+    **Output**: Internal data (actual tree + existing map structure), not shown to user.
+</step_1_scan>
+
+<step_2_diff>
+    **Role**: Diff Analyst
+    **Action**: Compare actual directory tree against map.json entry by entry, classify into three diff types.
+
+    | Diff Type | Criteria | Handling |
+    |:---|:---|:---|
+    | **New** | Exists on disk but not in map | Classify and register |
+    | **Stale** | In map but no longer exists on disk | Remove directly |
+    | **Possible Rename** | Map path missing, but a new path has highly similar structure/content | Flag as rename candidate |
+
+    ### File-Level Detection
+
+    Quick-scan files in new directories (read exports/declarations) to identify **single-file multi-responsibility** cases:
+    - A file exporting multiple unrelated classes/functions/modules
+    - An entry file aggregating multiple sub-module registrations (e.g. route registration, store registration)
+    - A file serving multiple Tasks
+
+    When detected → drill granularity to file-level, register the file separately in map with its contained responsibilities.
+
+    **Output**: Diff list (internal), proceed to step_3.
+</step_2_diff>
+
+<step_3_classify>
+    **Role**: Chief Architect
+    **Action**: Classify new entries by architectural layer.
+
+    ### Classification Strategy
+
+    1.  **Pattern Matching**: Reference existing entries at the same level. If `src/services/auth/` is "Service Layer", then `src/services/payment/` likely is too.
+    2.  **Tech Stack Conventions**: Directory structure rules defined in `02_tech_stack.md` (e.g. "commands/ is Task Layer").
+    3.  **Content Inference**: Read file contents (imports, export types) to determine architectural role.
+    4.  **Uncertain**: Mark as `[?]`, let user specify during confirmation.
+
+    For each new entry, populate:
+    - `path`: Directory or file path
+    - `layer`: Architectural layer
+    - `description`: One-line responsibility description
+    - `[?file-level]` `contains`: List of sub-responsibilities in the file
+
+    **Output**: Classified new entries list (internal), proceed to step_4.
+</step_3_classify>
+
+<step_4_propose>
+    **Role**: Advisor
+    **Action**: Present the full change manifest to user.
+
+    **Output**:
+    ```
+    ### Architecture Map Change Proposal
+
+    **Scan scope**: [project root]
+    **Current map entries**: N | **After update**: M
+
+    ---
+
+    #### Stale Entries (will remove)
+    | Path | Original Layer |
+    |:---|:---|
+    | src/legacy/old-module/ | Service Layer |
+
+    #### New Entries (will register)
+    | Path | Layer | Description | Granularity |
+    |:---|:---|:---|:---|
+    | src/services/payment/ | Service Layer | Payment service module | Directory |
+    | src/utils/validators.ts | Shared Layer | Form + data + API param validation | File |
+    | src/routes/api.ts [?] | [to specify] | Aggregates multiple API route registrations | File |
+
+    #### Possible Renames
+    | Original Path | New Path | Confidence |
+    |:---|:---|:---|
+    | src/helpers/ | src/utils/ | High (file content match) |
+
+    ---
+    > Reply **OK** to confirm all; or specify changes:
+    > - "src/routes/api.ts belongs to App Layer"
+    > - "src/helpers/ is not a rename, keep original entry"
+    > - "add src/config/ as Config Layer"
+    ```
+
+    **Gate**: Proceed to step_5 after user confirms.
+</step_4_propose>
+
+<step_5_apply>
+    **Role**: System Administrator
+    **Action**:
+    1.  Update `[[__DOCS_DIR__]]/global/map.json` per confirmed changes:
+        - Remove stale entries
+        - Add new entries (with layer, description)
+        - Handle renames (update path, preserve other metadata)
+    2.  Update `lastUpdated` field.
+
+    **Terminal Gate** (Do not skip; must complete before output summary):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` views generated |
+
+    **Output**: Update summary:
+    - **Removed**: N stale entries
+    - **Added**: N entries (M file-level)
+    - **Renamed**: N entries
+    - **Current map total**: X entries
+</step_5_apply>
+
+</protocol_map>

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

@@ -0,0 +1,252 @@
+<protocol_plan>
+  **Trigger**: `/archi.plan <ID> [context]`
+  **Goal**: Define Task Spec/UI/Plan through deep architecture interview.
+  **Input**:
+  - `<ID>` (required): An existing task ID from the Roadmap. Tasks must be created first via `/archi.scope` or `/archi.inherit`.
+  - `[context]` (optional): Known context for the task (e.g., requirement descriptions, references, constraints). When provided, serves as pre-loaded input for step_2 interview, reducing questions.
+
+<constraints_cursor>
+    **Mode Lock**: This protocol MUST execute in **Agent Mode (Normal Mode)**. Prohibited from switching to Plan Mode or any read-only mode.
+</constraints_cursor>
+
+<meta>
+    <style>Architectural, Exhaustive, Strict, Technology-Agnostic</style>
+    <language>English</language>
+    <principles>
+      1.  **Global First**: The birth of local tasks must be accompanied by updates to global indices (Map/Data/Dict).
+      2.  **AI-Native Perspective**: All option Pros/Cons written from AI Agent perspective. Focus: Context Locality, Type Safety, Boilerplate, Ambiguity.
+      3.  **Flexible Interaction**: Options are heuristic suggestions; support multi-select, hybrid, or custom.
+      4.  **Audit-Gated**: Only audited docs can be delivered.
+    </principles>
+</meta>
+
+<step_1_load>
+    **Role**: System Analyst
+    **Action**:
+    1.  **Read Roadmap**: Read `[[__DOCS_DIR__]]/global/roadmap.json`.
+        - **Pre-flight**: Read only the `<ID>` task entry and its direct deps' `id/title/status`; check whether deps are completed, reject Plan if not (unless user forces). No need to load other task data.
+    2.  **Read Vision**: Read `[[__DOCS_DIR__]]/global/vision.md` — extract North Star Metric and Design Philosophy sections only; skip remaining chapters.
+    3.  **Read Tech Stack**: `02_tech_stack.md` (technical red lines + **Section 9 Project Conventions**).
+        - Extract global architecture conventions from Section 9 (Error Handling / Data Flow / Auth & Access) for convention inheritance in step_2.
+    4.  [?UI] **Read Design Tokens**: `[[__DOCS_DIR__]]/global/design_tokens.json`.
+    4.5 [?UI] **Read UI Context**: `[[__DOCS_DIR__]]/global/ui_context.md` (if it exists).
+        - Look up the screen inventory to locate the screen IDs (e.g. S-03) for this task and their state coverage.
+        - Lock the screen scope to fill in `ui.md §1` in step_4; do not invent new screen IDs.
+        - If `ui_context.md` does not exist → skip; write `ui.md` in full ITP format.
+    5.  [?Data] **Read Data Model**: `[[__DOCS_DIR__]]/global/data_snapshot.json`.
+    6.  **Read Dependency Context** (if dependent tasks exist):
+        - Read only the Interface/Type definitions section of the dep's `spec.md` (`## Interface` or `## Types` chapter); skip Scenarios and other content.
+        - Execute only when a `ref: tasks/<dep_id>/spec.md#X` reference appears in the current spec/plan; skip if no reference found.
+        - **Stub Compatibility**: If a dependency's Spec-Status is Stub, extract source files from the stub's "Associated Files", read entry files to extract public interfaces/exported types as upstream interface reference.
+        - Avoid re-defining upstream interfaces; ensure integration points are precisely aligned.
+
+    **Output**: Present a **Task Context Brief** to the user:
+    ```
+    ### Task Context: [Task Name] ([ID])
+
+    **Goal**: [roadmap task's goal; highlight any [User Presets] if present]
+    **Upstream Dependencies**: [completed dependency tasks and their key interfaces/types, or "None"]
+    **Project Features**: [activated UI/Data/CLI/Lib/API tags]
+    **Technical Constraints**: [key red lines from 02_tech_stack.md]
+    **Design Philosophy**: [North Star Metric and design principles from vision.md]
+    **Project Conventions**: [from 02_tech_stack.md §9 — Error Handling: X | Data Flow: X | Auth: X, or "Not set" if absent]
+    ```
+    Retain full context materials internally, proceed to step_2.
+</step_1_load>
+
+<step_1_5_complexity>
+    **Role**: Product Consultant
+    **Action**: Assess task complexity to decide whether to run the full step_2 flow:
+
+    **① Granularity hard-limit check (before complexity verdict)**:
+
+    | Metric | Limit |
+    |:---|:---|
+    | Estimated spec.md Scenario count | ≤ 6 |
+    | Estimated plan.json Phase count | ≤ 4 |
+
+    > Estimation method: based on the roadmap task goal and dependency context loaded in step_1, quickly enumerate the core behavior paths. Trigger if over the limit — no need for precise calculation.
+
+    **② Complexity verdict (only after granularity passes)**:
+
+    | Signal | Verdict | Flow |
+    |:---|:---|:---|
+    | No deps + no new entities + no architecture decisions + estimated ≤3 tasks | **Simple** | Skip step_2 interview; generate spec + plan directly |
+    | Has deps OR new entities OR architecture decisions needed | **Standard** | Execute step_2 Unified Proposal normally |
+
+    **Simple Mode**:
+    - Skip 5-dimension architecture recommendations and User Confirm Gate
+    - spec condensed to 1-2 Gherkin scenarios
+    - plan condensed to a single Phase
+    - Confirm at signoff (replacing step_2 Gate)
+</step_1_5_complexity>
+
+<step_2_interview>
+    **Role**: Architect
+
+    ---
+
+    ### Unified Proposal
+
+    **Core principle**: Merge task design and architecture decisions into **one single output**; user confirms or overrides in one round.
+
+    **Action**:
+
+    #### Part 1: Task Design
+
+    AI **selects which modules to output** based on the task's nature, from the following material library:
+
+    | Material | When applicable |
+    |:---|:---|
+    | Flow description (user journey / system flow / command flow) | Multi-step interaction or processing chain |
+    | Core entities & data | New or modified entities involved; existing entities use `→ ref: data_snapshot.json#EntityName` |
+    | Touchpoints (pages / commands / endpoints / methods) | User-facing or external interfaces exist |
+    | Pre-defined decisions | When goal contains `[User Preset]` → highlight and enforce strictly |
+
+    **Reference rules**:
+    - Entities/types already in global → `ref: data_snapshot.json#X`, only describe what this task **adds or modifies**
+    - Design philosophy/principles → `ref: vision.md#PrincipleName`, no need to restate
+    - Upstream interfaces → `ref: tasks/<dep_ID>/spec.md#InterfaceName`
+    - Existing design tokens/components → `ref: design_tokens.json#preset` / `ref: dictionary.json#component`
+
+    **Universal requirement**: Use this task's specific entity names and operation names; no generic descriptions
+
+
+    #### Part 2: Architecture Recommendations
+
+    [[SKILL: Follow `archi-plan-options` Skill's three-step selection logic (Convention Inheritance -> Tag Routing -> Recommend vs. Expand) to generate architecture recommendations across five dimensions.]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-plan-options/SKILL.md` and follow its three-step logic)]]
+
+    When expanding a Q-table, follow the format in [[SKILL: `archi-interview-protocol` Skill's standard output format]][[NO-SKILL: `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md`]].
+
+    #### Output Format
+
+    ```
+    ## Task Proposal: [Task Name] ([ID])
+
+    ### Task Design
+    [Output per complexity level, see Part 1 above]
+
+    ### Architecture Recommendations
+    | Dimension | Recommended | Source | Rationale |
+    |:---|:---|:---|:---|
+    | Core Structure | [Recommended option] | Task | [1-2 sentences specific to this task] |
+    | Interaction Pattern | [Recommended option] | Task | [Rationale] |
+    | Error Handling | [Convention value] | Project Convention | ref: 02_tech_stack.md §9 |
+    | ... | ... | ... | ... |
+
+    [Only expand option table for dimensions requiring user decision]:
+    **[Q<n>] Question title**
+    > Why user decision is needed (one sentence)
+
+    | ID | Option | Description | AI+ | AI- |
+    |:---|:---|:---|:---|:---|
+    | A [Recommended] | ... | Concrete behavior (2-3 sentences) | Full sentence | Full sentence |
+    | B | ... | ... | ... | ... |
+    | Z | Custom | (Describe) | - | - |
+
+    ---
+    > Reply **OK** to accept all recommendations; or annotate what to change, e.g.:
+    > - Design correction: "Registration doesn't need email verification step"
+    > - Dimension override: "Core Structure=C, Error Handling=B D"
+    > - Question answer: "Q1=B"
+    ```
+
+    **⌨️ INPUT**: Reply **OK** to accept all; or free-text annotations for changes. No fixed format required.
+</step_2_interview>
+
+<step_2_5_refinement>
+    **Role**: Consultant
+    **Trigger**: User reply is not OK — contains corrections, questions, overrides, or logic conflicts.
+    **Action**: Do NOT generate docs. Incorporate user feedback, refresh Unified Proposal and re-output. Wait for confirmation.
+    - If task design question → Compare alternatives, re-propose design
+    - If architecture dimension question → Explain differences in this task's context, update recommendation
+    - If dimension override → Replace recommendation directly and adjust related design
+</step_2_5_refinement>
+
+<step_3_global_sync>
+    **Role**: System Admin
+    **Constraint**: MUST update the following global files **BEFORE** generating Task docs.
+
+    **Boundary**: Only register **project business domain** content. Architext framework concepts (scripts, scaffold, roadmap, plan, etc.) and framework infrastructure errors are prohibited from registration in global files.
+
+    **Action Checklist**:
+    1.  **`map.json`**: Register `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>` in `directoryMapping`; define module responsibility and dependencies in `logicalTopology`.
+    2.  **`dictionary.json`**: Extract **project business** new terms from the proposal to fill `entities`/`verbs`; register new shared tools to `utilities`; register new public components to `components`.
+    3.  [?Data] **`data_snapshot.json`**: Add/modify Schema based on Core Structure recommendation. Prohibited from writing "TBD"; must write field names and types.
+    4.  **`error_codes.json`**: Register new **business** error codes based on Error Handling recommendation. Framework script errors are handled by exit code + stderr; prohibited from registration.
+    5.  **`map.json` featureRelations**: Determine if this task is an "aggregator" — i.e., its core responsibility is to **list, summarize, or dynamically reflect** a class of other tasks (e.g., "list all commands", "aggregate all page entries", "register all routes"). If yes, append one record to `featureRelations`:
+        ```json
+        {
+          "aggregator": "<this task ID or file path>",
+          "sources": "<one-sentence description of what is aggregated, e.g. 'all CLI command tasks'>",
+          "evidence": "<basis, e.g. 'spec.md §X states this task dynamically lists all Y-type tasks'>",
+          "checkNote": "When tasks of this type are added or removed, check whether <aggregator> needs to be updated"
+        }
+        ```
+        If not an aggregator, skip this step.
+
+    **Output**: Change diffs of above files (brief).
+</step_3_global_sync>
+
+<step_4_generate>
+    **Role**: Doc Engineer
+    **Input**: Confirmed Unified Proposal (task design + architecture recommendations) + updated global context.
+    **Action**: Generate standard docs under `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/`.
+
+    **1. `spec.md`** (Mandatory):
+    - Template: `templates/spec.template.md`.
+    - Convert confirmed task design and architecture recommendations to Gherkin Scenarios.
+    - Each Scenario must map to a concrete flow step or exception path from the task design; do not invent scenarios.
+    - If upstream task, must include explicit Interface/Type definitions.
+
+    **2. `ui.md`** [?UI]:
+    - Template: `templates/ui.template.md`.
+    - **With `ui_context.md` (primary path)**:
+      1. **UI Divergence Check** (required before writing `ui.md`): Compare the confirmed task design from step_2 against the screen inventory in `ui_context.md`:
+
+         | Divergence type | Criteria | Action |
+         |:---|:---|:---|
+         | No divergence | Screen index matches design | Write `ui.md` directly, reference screen ID |
+         | Minor addition | New state / modal / local area, overall layout unchanged | Call `archi-ui-wireframe` Skill (Plan refinement mode) to update `ui_concept.html` + `ui_context.md`; note `MODIFIED: S-XX` in `ui.md` |
+         | Structural divergence | Layout restructure, new standalone screen, flow path change | **Pause** — present divergence summary to user, wait for **OK**, then call Skill to update `ui_concept.html` + `ui_context.md`, then write `ui.md` |
+
+      2. After resolving divergence, fill in screen scope and delta components per `ui.template.md`.
+    - **Without `ui_context.md` (fallback path)**: Write full ITP v3.0 component tree, referencing `design_tokens.json` token definitions.
+
+    **3. `plan.json`** (Mandatory):
+    - Template: `templates/plan.template.json`.
+    - Dynamically adjust Phases by project type; ensure each Task's context is self-contained.
+    - Task descriptions explicitly state "Additive Only" + "Respect Unknowns".
+    - **`decisions`**: Fill per dimension; `choice` supports multi-select (e.g. `A B`, space-separated), custom (`Z: …`); `rationale` must explain reasoning for code phase; do not leave empty.
+    - **`notes`**: Fill each task's `notes` with: `[scope] · [spec ref] · [key constraints] · Verify: [concrete operation]`; used by `/archi.code` step_4 to locate context and run e2e; do not leave empty.
+      > Example: `Implement POST /auth/login · spec §3.1 · JWT must not contain password · Verify: curl POST /auth/login returns 200 + token field`
+    - Run `npx archi render` after generation to produce readable `.md` view.
+</step_4_generate>
+
+<step_5_audit>
+    **Role**: Chief Auditor
+    **Checklist**:
+    1.  **Design Fidelity**: Do Scenarios fully cover confirmed task design (flow steps and exception paths)?
+    2.  **Tech Consistency**: Any undeclared tech used?
+    3.  **Data Integrity**: Do Scenario entities match confirmed core entities?
+    4.  **Error Handling**: Is Error Handling recommendation covered?
+    5.  **AX Compliance**: Are Anti-Clobbering and Interface Stability rules followed?
+
+    Silently fix issues; mark critical issues with `⚠️ Risk Warning`.
+</step_5_audit>
+
+<step_6_signoff>
+    **Terminal Gate** (Do not skip; must complete before output summary):
+    | Step | Command | Pass Condition |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | No ERROR-level issues |
+    | 2 | `npx archi task <ID> --status active` | Task marked as in-progress |
+    | 3 | `npx archi render` | `.md` views generated |
+
+    **Action** (After Gate passes):
+    1.  Output summary.
+
+    **Output**: Task definition summary with Architecture Confirmation table (each dimension's final choice and rationale) and Next Steps table.
+</step_6_signoff>
+
+</protocol_plan>