architext 0.0.2

package/dist/templates/en/rules/01_workflow.md

@@ -0,0 +1,93 @@
+---
+description: Command Dispatcher & Workflow Controller. Handles /archi.start, /archi.plan, and mode transitions between Discussion, Planning, and Implementation.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Workflow Dispatcher
+
+> **Role**: Mode Switcher. Default to "General Architect" mode, only load specific protocol when explicit command is detected.
+
+> ⛔ **STOP CHECK** — Self-check before each response; stop immediately and explain if any item is triggered:
+> | Violation | Correct Action |
+> |:---|:---|
+> | Received `/archi.*` command but started executing without loading the protocol file | Stop → Load protocol file first |
+> | User request involves behavior change but code was modified directly | Stop → Route to the appropriate command |
+> | Ran a Terminal Gate command without confirming working directory (see `04_cli_tools.md`) | Stop → Pass Working Directory Gate first |
+
+## 1. Explicit Command Routing
+
+**Trigger**: When user input starts with `/archi.`, immediately load the corresponding protocol template.
+
+| Command | Target Template | Action |
+|:---|:---|:---|
+| `/archi.start` | `[[__DOCS_DIR__]]/prompts/start.md` | Load CPO → Project Initiation |
+| `/archi.inherit` | `[[__DOCS_DIR__]]/prompts/inherit.md` | Load Legacy Analyst → Reverse Engineering |
+| `/archi.scope` | `[[__DOCS_DIR__]]/prompts/scope.md` | Load Strategist → Requirement Decomposition |
+| `/archi.plan` | `[[__DOCS_DIR__]]/prompts/plan.md` | Load Planner → Deep Interview |
+| `/archi.edit` | `[[__DOCS_DIR__]]/prompts/edit.md` | Load Editor → Spec Modification |
+| `/archi.revise` | `[[__DOCS_DIR__]]/prompts/revise.md` | Load Chief Architect → Global Revision |
+| `/archi.code` | `[[__DOCS_DIR__]]/prompts/code.md` | Load Developer → Coding & Auditing |
+| `/archi.audit` | `[[__DOCS_DIR__]]/prompts/audit.md` | Load Chief Auditor → Deep Code Audit |
+| `/archi.fix` | `[[__DOCS_DIR__]]/prompts/fix.md` | Load Debugger → Diagnosis |
+| `/archi.map` | `[[__DOCS_DIR__]]/prompts/map.md` | Load Surveyor → Map Refresh |
+| `/archi.remove` | `[[__DOCS_DIR__]]/prompts/remove.md` | Load Surgeon → Task Decommission |
+| `/archi.help` | `[[__DOCS_DIR__]]/prompts/help.md` | Load Manual → Display Guide |
+
+> **Protocol Load Gate** (forbidden to skip; three steps must complete in order):
+> 1. **Read** target `.md` full text → if file not found, stop and output: `Protocol file not found, execution aborted`
+> 2. **Override** `00_system` partial settings
+> 3. **Execute** `<step_1>` — forbidden to execute any protocol content before step 1 is complete
+
+---
+
+## 2. Natural Language Passthrough
+
+**Trigger**: User input is not `/archi.` command text.
+
+### 2.1 Intent Detection
+
+**Role**: Intelligent Dispatcher. Detect user intent and decide to execute directly or route to a command based on impact level.
+
+**Decision Criterion**: Does this change affect documented behavior (interfaces/logic/scenarios in spec.md, interactions/structure in ui.md, implementation steps in plan.json)?
+
+| Intent Type | Action |
+|:---|:---|
+| Pure conversation / code reading / architecture discussion | ✅ Answer directly, enhanced by base rules |
+| Trivial edits (typo/comments/formatting/log messages) | ✅ Execute directly |
+| Behavior change (logic/interface/type/UI) | 🔀 Route → `/archi.edit` + `/archi.code` |
+| Bug fix | 🔀 Route → `/archi.fix` |
+| New feature | 🔀 Route → `/archi.scope` or `/archi.plan` |
+| Large-scale refactoring | 🔀 Route → `/archi.revise` |
+
+### 2.2 Guided Dispatch
+
+When routing (🔀), must:
+1. Explain in one sentence why a command is needed (which document would be affected)
+2. Recommend the specific command + parameters
+3. Ask the user whether to proceed
+
+> ⛔ **Prohibited**: Modifying code first and then suggesting the command as an afterthought. Violations require reverting the change and re-routing.
+
+### 2.3 Unmanaged Code
+
+When the target of modification is not registered in `map.json` and has no corresponding Task:
+- Inform the user that the module is not managed
+- Suggest `/archi.inherit` or `/archi.scope` to bring it under management
+- After user confirms "temporary adjustment", proceed with direct modification
+
+### 2.4 Base Rules
+
+All scenarios (including routing and pure conversation) rely on the following base rules:
+
+| Layer | File | Role |
+|:---|:---|:---|
+| Core | `00_system.md` | Identity, core principles |
+| Tech | `02_tech_stack.md` | Tech red lines, coding standards |
+| Custom | `90_custom_rules.md` | Team-specific constraints |
+| Context | `99_context_glue.md` | Auto-associate context documents |
+
+**End of Dispatcher.**
+
+> Mandatory CLI execution rules: see `04_cli_tools.md`.

package/dist/templates/en/rules/02_tech_stack.md

@@ -0,0 +1,197 @@
+---
+description: Technical Standards & Technology Stack. Contains language versions, framework choices, coding conventions, naming rules, and forbidden patterns. Consult when writing code.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Tech Stack & Engineering Standards: [Project Name]
+
+> **Role:** The "Law" of the codebase. Defines tools, structure, and engineering workflows.
+> **Status:** [Active]
+> **Note:** This is a template file. Needs to be filled with specific content based on project type (Web/CLI/Backend/Library/Mobile, etc.).
+> Certain sections (like UI Protocol) apply only to UI projects and should be adjusted or removed as needed.
+
+## 1. Global Mandates
+
+* **No Hardcoding:** All secrets and API addresses must use environment variables. Hardcoding is strictly forbidden.
+* **No Dead Code:** Committed code must be clean. Commented-out code blocks or useless `TODO`s are strictly forbidden.
+* **Comments for Why:** Comments explain "Why" (business context), not just "What".
+
+---
+
+## 2. Technology Selection
+
+### Core Stack
+* **Framework:** [e.g. Next.js 14 (App Router) / NestJS / Express / FastAPI / Gin]
+* **Language:** [e.g. TypeScript (Strict Mode) / Python 3.11+ / Rust / Go 1.21+]
+* **Styling** (if project has UI): [e.g. TailwindCSS + Shadcn/UI / CSS Modules / Styled Components]
+* **State** (if project has frontend state management): [e.g. Zustand (Client) + React Query (Server) / Redux / MobX]
+* **Database** (if project has data layer): [e.g. PostgreSQL + Prisma ORM / MongoDB / SQLite / Redis]
+
+### Infrastructure
+* **Package Manager:** [e.g. pnpm / npm / yarn / cargo / go mod / pip]
+* **Runtime:** [e.g. Node.js 20+ / Python 3.11+ / Rust / Go 1.21+ / Bun]
+* **Build Tool:** [e.g. tsup / vite / webpack / cargo / go build]
+
+---
+
+## 3. Coding & Naming Standards
+
+### Naming Conventions
+* **Files:** [e.g. `kebab-case` (e.g., `user-profile.ts` / `user_profile.py` / `user_profile.rs`)]
+* **Components/Classes:** [e.g. `PascalCase` (e.g., `UserProfile` / `UserService` / `UserRepository`)]
+* **Functions/Methods:** [e.g. `camelCase` (e.g., `handleSubmit`) or `snake_case` (Python/Rust)]
+* **Constants:** [e.g. `UPPER_SNAKE_CASE` (e.g., `MAX_RETRY` / `MAX_RETRY_COUNT`)]
+* **Private Members:** [e.g. `_privateMethod` (JavaScript) / `__private` (Python) / `private_field` (Rust)]
+
+### Code Patterns
+* **Export Style:** [e.g. Must use Named Export (`export const`), Default Export is strictly forbidden.]
+* **Type Definitions:** [e.g. Must use `interface` for objects, `type` for unions.]
+* **Error Handling:** [e.g. Must use Result type (Rust) / Exception handling (Python/Java) / Error return (Go)]
+* **Async Patterns:** [e.g. Prefer Async/Await, avoid `.then()` chains.]
+
+---
+
+## 4. UI Protocol: ITP v3.0 (Dual-Artifact) [Optional - Only for UI Projects]
+<!-- Core UI Description Protocol -->
+> **Note:** If project has no UI (e.g. CLI, Backend API, Library), remove this section.
+
+### 4.1 Dual-Artifact Strategy
+
+UI artifact hierarchy:
+
+| Artifact | Format | Reader | Responsibility |
+|:---|:---|:---|:---|
+| `ui_concept.html` | Single-file HTML | Human (browser) | **Global visual source of truth** — wireframes/styled screens for the entire project |
+| `ui_context.md` | Structured Markdown | AI (plan/code/audit/edit) | **AI screen index** — lightweight list of screen IDs / routes / states / navigation graph / shared components |
+| `ui.md` | ITP v3.0 DSL | AI (code/audit) | Task-level UI scope declaration — which screens/components this task covers |
+- `ui_concept.html` is generated by the `archi-ui-wireframe` Skill, covering all user-visible screens; for human browser preview only
+- `ui_context.md` is generated by the same Skill simultaneously; it is the sole AI entry point for UI structure; do not edit manually
+- `ui.md` only declares "which screens/states in ui_context.md this task is responsible for"; do not redefine global layout
+- Code phase uses `ui.md` (task design) + `ui_context.md` (structure/navigation) + `design_tokens.json` (visual constraints) as source; also uses `ui_concept.html` as **read-only visual reference** to calibrate layout; implement equivalent visual effect with the **project's own tech stack**
+
+### 4.2 Naming (PrefixFunction)
+Component naming must follow `Prefix+Function` format:
+* **Btn**: Button | **Inp**: Input | **Txt**: Text/Label
+* **Box**: Container | **Img**: Image/Icon | **List/Card/Modal**: As named.
+
+### 4.3 Syntax Structure
+* **Definition**: `Name [Layout] (Style/Content) -> #Interaction`
+* **Layout Keywords**: `[Row]`, `[Col]`, `[Center]`, `[Between]`, `[Fill]`, `[Grid]`
+* **Example**:
+```
+    BoxHeader [Row, Between]
+      TxtTitle [H2] (Text: "Login")
+      BtnClose [Ghost] (Icon: X) -> #CloseModal
+```
+
+### 4.4 Design Tokens
+`design_tokens.json` defines project-specific visual language, generated by `/archi.start` from the Brief:
+- `primitivePalette`: raw color scales (neutral grays + brand colors)
+- `semanticTokens`: semantic colors (Background/Primary/Text…) + typography specs
+- `layout`: radius / shadow / spacing scales
+- `motion`: duration / easing / preference
+- `illustration`: illustration style / icon library
+- **Code phase**: all color / size / motion values must come from the corresponding fields in this file; no hardcoded magic values
+
+### 4.5 Delta Syntax
+* **Usage**: Used to modify existing UI snapshots.
+* **Format**: `@Locator { + Add, ~ Modify, - Remove }`
+
+---
+
+## 5. Testing & Verification
+
+### Static Analysis (Commands)
+* **Build:** [e.g. `pnpm build` / `cargo build` / `go build` / `python -m py_compile`]
+* **Type Check:** [e.g. `pnpm type-check` / `mypy .` / N/A]
+* **Lint:** [e.g. `pnpm lint` / `ruff check .` / `cargo clippy` / `golangci-lint run`]
+* **Format:** [e.g. `pnpm format:check` / `ruff format --check` / `cargo fmt --check`]
+
+### Test Suite
+* **Unit:** Tool: [e.g. Vitest / Jest / pytest / cargo test / go test]  Scope: [e.g. Utils functions, core business logic, algorithms]  Rule: [e.g. Must Mock external deps; no snapshot tests for volatile UI]
+* **Integration:** Tool: [e.g. Vitest + Testcontainers / pytest + Docker]  Scope: [e.g. API→DB write chain / CLI full execution flow]
+* **E2E:** Tool: [e.g. [?Web] Playwright / Cypress  [?API] Supertest / httpie  [?CLI] bats / shell script  [?Lib] example project + automation script  [?Mobile] Detox / Maestro]  Scope: [e.g. [?Web] Critical user journeys  [?API] Key endpoint full chain  [?CLI] Key command full flow  [?Lib] Public API typical usage scenarios]
+* **Test Command:** [e.g. `pnpm test` / `pytest` / `cargo test` / `go test ./...`]
+
+### Environment Scripts
+> **AI Internal Tooling**: These scripts are auto-generated by AI during INF-01 based on command definitions above. Implementation details (script structure, failure strategy, execution method) are AI-decided; prohibited from asking user. Generate `.sh` / `.ps1` per OS to `[[__DOCS_DIR__]]/scripts/`.
+
+* **`[[__DOCS_DIR__]]/scripts/validate`** — Automated quality check (AI runs after every code change): all Static Analysis items + Test Command.
+* **`[[__DOCS_DIR__]]/scripts/dev-up`** — Bring up dev environment: Install → Build → Start Dev Server → Health Check.
+  - **Install:** [e.g. `pnpm install` / `pip install -r requirements.txt` / `cargo build` / `go mod download`]
+  - **Dev Command:** [e.g. `npm run dev` / `python manage.py runserver` / `cargo run` / N/A]
+  - **Health Check:** [e.g. `curl http://localhost:3000/api/health` / `./bin/cli --version` / `python -c "import mylib"`]
+* **`[[__DOCS_DIR__]]/scripts/dev-reset`** — Environment reset (when environment is broken): Kill Processes → Clean Cache → Reinstall → Rebuild → Restart.
+
+---
+
+## 6. Deployment & Release
+
+### CI Pipeline
+* **Pre-commit:** [e.g. Must pass Linter and Formatter checks (ESLint/Prettier / ruff/black / clippy / golangci-lint).]
+* **Merge Gate:** [e.g. PR must pass all Unit/Integration tests before merge.]
+* **Build Check:** [e.g. Must pass build check (`npm run build` / `cargo build` / `go build`).]
+
+### Environment
+* **Secrets:** [e.g. Production secrets must be configured via CI platform, strictly forbidden to commit `.env` / `.env.local`.]
+* **Database Ops** (if project has DB): [e.g. Schema changes must use Migration files, manual modification of production DB is forbidden.]
+* **Binary Distribution** (if project is CLI/Library): [e.g. Use GitHub Releases to publish binaries, support multi-platform builds.]
+
+---
+
+## 7. Architecture & File Placement Strategy
+
+### Repository Architecture
+* **Strategy:** [e.g. Monorepo (Turborepo) or Single Repo]
+* **Workspace:** [e.g. pnpm workspaces, shared dependencies hoisted to Root.]
+
+### Directory Structure
+* **Pattern:** [Architecture Pattern Name]
+* **Philosophy**: [Architecture Philosophy]
+* **Key Paths**:
+    * `[Path_1]`: [Description]
+    * `[Path_2]`: [Description]
+* **Constraint**: [Architecture Constraints]
+
+### File Placement Rules
+> *Context*: Defines where different types of files should be created. **Must adapt to project type (Web/CLI/API/Lib) and directory structure in `map.json`**; table below is placeholder.
+> **Critical**: Check this table before creating any new file. Once populated, this table is a hard constraint — placement must not rely on AI's default training bias.
+
+| File Type | Placement Strategy | Example (adapt per project) |
+| :--- | :--- | :--- |
+| **Unit Tests** | [e.g. Centralized or Colocation] | `__tests__/utils/date.test.ts` / `utils/date.test.ts` |
+| **Interfaces/Types** | [e.g. Near usage or Global types] | `types/user.d.ts` / `domain/user.entity.ts` |
+| **Assets/Images** [?UI] | [e.g. Public or Module assets] | `public/images` / `assets/` |
+| **Styles** [?UI] | [e.g. Per-component or Global] | `Button.module.css` / `global.css` |
+| **DTOs/Models** [?Data] | [e.g. Domain or Shared] | `domain/user/dto` / `models/` |
+
+---
+
+## 8. Anti-Patterns
+* **No Orphan .gitkeep:** Empty dirs may use `.gitkeep` for Git tracking; remove `.gitkeep` when dir has other files.
+* **No Rogue File Placement:** Check §7 File Placement Rules before creating any new file — placement must not rely on AI training-data defaults (especially for test files).
+* **No [Tech 1]:** [e.g. No Redux - This project is too heavy, do not use.]
+* **No [Tech 2]:** [e.g. No Raw SQL - Must use ORM to prevent injection.]
+* **No [Pattern 1]:** [e.g. Forbidden to fetch data directly inside components, must encapsulate in Service layer.]
+* **No [Pattern 2]:** [e.g. Forbidden to use `any` type (TypeScript) / Forbidden to use `unsafe` code (Rust).]
+* **No [Pattern 3]:** [e.g. Forbidden to use `console.log` in production code, must use unified Logger.]
+
+---
+
+## 9. Project Conventions
+> Global architecture conventions established by `/archi.start`. `/archi.plan` auto-inherits these; no per-task re-asking unless the task has specific needs.
+> If a task needs to deviate from a convention, the deviation rationale must be stated in the proposal.
+
+### Error Handling
+* **Strategy:** [e.g. Fail Fast + Form Validation / Fail Fast (stderr) / Schema Validation + Fail Fast]
+* **Rationale:** [e.g. Form-heavy app requiring frontend validation + backend fail-fast]
+
+### Data Flow [?UI]
+* **Default:** [e.g. Standard Request + SWR / Realtime (Socket) / Polling]
+* **Rationale:** [e.g. Most pages are CRUD; SWR for cache and revalidation]
+
+### Auth & Access [?Web/API]
+* **Mechanism:** [e.g. JWT + RBAC / Session + Owner Only / API Key]
+* **Rationale:** [e.g. Multi-role admin system requiring fine-grained access control]

package/dist/templates/en/rules/03_data_governance.md

@@ -0,0 +1,102 @@
+---
+description: AI collaboration governance rules for JSON data files. Defines read/write specs, update timing & format constraints for global data files.
+globs: "**/*.json"
+applyTo: "**/*.json"
+alwaysApply: true
+---
+
+# Data Governance Protocol
+
+> **Role**: Data Steward. Ensure consistency, integrity & traceability of global JSON data files.
+
+## 1. Data File Registry
+
+| File | Type | Read When | Write When |
+|:---|:---|:---|:---|
+| `roadmap.json` | Roadmap | `/archi.plan`, `/archi.code` start | `/archi.start` creates; AI direct edit or `npx archi task` updates status |
+| `map.json` | Architecture Map | When touching code (via context_glue) | `/archi.plan` Step 3 (global sync); `/archi.inherit` Step 3.6; `/archi.map` |
+| `dictionary.json` | Glossary | When generating variable names | `/archi.plan` Step 3; step_5 auto-appends after code/fix |
+| `design_tokens.json` | Design Tokens [?UI] | When generating UI code | `/archi.start` creates; update on design changes |
+| `data_snapshot.json` | Data Snapshot [?Data] | `/archi.plan` Q1 design; `/archi.code` implementation | Plan phase designs Schema; Code phase syncs actual changes |
+| `error_codes.json` | Error Contracts | When writing error handling | `/archi.plan` Step 3; step_5 auto-appends after code/fix |
+
+---
+
+## 2. General Rules
+
+### 2.1 Format Constraints
+
+- **JSON Only**: The single source of truth for global data is `.json` files. `.md` views are auto-generated by `npx archi render`; prohibited from editing `.md` views directly.
+- **Schema Stability**: Managed in two tiers:
+  - **Tier 1 (Strict)**: `roadmap.json`, `plan.json` — CLI rendering/commands depend on these directly; structure is validated by Zod Schema; prohibited from changing fields arbitrarily.
+  - **Tier 2 (Flexible)**: `dictionary.json`, `error_codes.json`, `data_snapshot.json`, `design_tokens.json`, `map.json` — Only top-level keys are validated. If existing fields cannot adequately describe what needs to be recorded, you may freely extend fields (add new keys or new properties in array items) without modifying the CLI.
+- **Valid JSON**: Must ensure valid JSON after writing (no trailing commas, no comments).
+
+### 2.2 Read/Write Discipline
+
+| Scenario | Rule |
+|:---|:---|
+| Need to consult data | Read `.json` file; prohibited from reading `.md` view (may be stale) |
+| Need to update Roadmap task status | Prefer `npx archi task <ID> --status <s>`; batch updates may edit JSON directly |
+| Need to update other data files | AI directly edits `.json` file |
+| After updates | Run `npx archi render` to regenerate `.md` views |
+
+---
+
+## 3. File-Specific Rules
+
+### `roadmap.json`
+
+- **Structure**: `phases[] → tasks[]`, each task must have `id`, `title`, `status`, `deps`.
+- **Status values**: `pending` | `active` | `done` | `blocked`.
+- **Dependency integrity**: IDs in `deps` must exist in tasks.
+- **Slug rule**: `slug` is used for tasks folder naming, format `Snake_Case`.
+
+### `map.json`
+
+- **Directory Mapping**: Must reflect the real physical file tree.
+- **Logical Topology**: Must register each Task Module's responsibility.
+- **Feature Relations** (field `featureRelations`): Records linkage relationships between aggregator tasks and their sources. Each entry: `{ aggregator, sources, evidence, checkNote }`. Written by AI during `/archi.plan` (when planning an aggregator task) or `/archi.inherit` (during reverse scanning); no manual maintenance needed.
+- **Self-Correction**: If code references violate the hierarchy defined in topology, must report error and stop generation.
+- **Extensible**: If existing fields cannot adequately describe the project architecture, you may add fields to items (e.g. `tags`, `owner`) or add new top-level keys.
+
+### `dictionary.json`
+
+- **Naming Authority**: This file is the supreme law of naming.
+- **Boundary**: Only register **project business domain** content. Architext framework concepts (scripts, scaffold, roadmap, plan, etc.) are prohibited from registration.
+- **entities**: Must consult `entities[].codeName` before generating variable names; prohibited from using words in `forbiddenSynonyms`.
+- **verbs**: Business action naming must consult `verbs[].codeName` for project-wide verb consistency.
+- **utilities**: Shared tools (e.g. logger, AppError, fetchClient) must be registered; AI must use registered utilities instead of raw APIs (refer to `replaces` field).
+- **components** [?UI]: Must search existing components before creating new ones; prioritize reuse.
+- **Extensible**: If existing fields cannot adequately describe a term/tool, you may add fields to array items (e.g. `tags`, `scope`, `deprecated`) or add new top-level arrays (e.g. `enums`, `constants`).
+
+### `design_tokens.json` [?UI]
+
+- **Token Only**: Styles must strictly use Tokens; prohibited from hardcoding Hex/px/rem.
+- **Dark Mode**: Must define both `light` and `dark` values.
+- **Extensible**: If existing Token structure cannot cover project needs (e.g. `motion`, `breakpoints`, `z-index`), you may add new properties freely.
+
+### `data_snapshot.json` [?Data]
+
+- **Structure**: `models[]` (name, fields, types, constraints) + `relationships[]` (inter-model relations: 1:1/1:N/M:N/self-ref).
+- **Design First**: Plan phase must define model structure and field types; prohibited from writing "TBD"; must be precise to field names and types.
+- **Sync Back**: After Code phase completion, must sync actual changes back to this file.
+- **Extensible**: If existing fields cannot adequately describe data models (e.g. need to record `indexes`, `triggers`, `seedData`), you may add fields to model items or at the top level.
+
+### `error_codes.json`
+
+- **Boundary**: Only register **project business domain** errors. Framework infrastructure errors (scripts/validate, dev-up, dev-reset, etc.) are handled by scripts themselves via exit code + stderr; prohibited from registration here.
+- **Structure**: `protocolMapping [?API]` (status code → behavior mapping) + `businessErrors` (business error registry).
+- **Code Format**: `ERR_[MODULE]_[REASON]` (e.g. `ERR_AUTH_INVALID_TOKEN`).
+- **statusCode**: Fill per project type (HTTP status / Exit code / leave empty).
+- **Design Before Code**: Must register error codes here before writing error handling code, including `message` and `recovery`.
+- **Extensible**: If existing fields cannot adequately describe error info (e.g. need to record `severity`, `retryable`, `httpBody`), you may add fields to items freely.
+
+---
+
+## 4. Plan JSON (`plan.json`)
+
+- **Location**: `tasks/<ID>_<Slug>/plan.json`
+- **Checkbox Updates**: AI sets `done` to `true` directly after completing steps during `/archi.code`.
+- **Append Rule**: `/archi.edit` appends new Phases while preserving completed history.
+- **Verification**: Run `npx archi plan <ID>` to verify completion after finishing.

package/dist/templates/en/rules/04_cli_tools.md

@@ -0,0 +1,50 @@
+---
+description: CLI Reference Manual. Working directory rule and command syntax for npx archi task/plan/render.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# CLI Reference
+
+> **Role**: Command quick-reference. Provides syntax and parameters for `npx archi` commands, for use during Terminal Gate execution.
+
+## ⛔ Working Directory Gate
+
+**Must pass this check before executing any `npx archi` command, otherwise stop**:
+
+| Check | Pass Condition |
+|:---|:---|
+| Current directory | Must be project root (directory containing `[[__DOCS_DIR__]]/`) |
+| If unsure | Confirm current directory first; forbidden to guess |
+| In subdirectory | Must `cd` to root before executing |
+
+---
+
+## Command Syntax
+
+### `npx archi task`
+
+| Subcommand | Purpose | Example |
+|:---|:---|:---|
+| `npx archi task` | List all tasks with progress | `npx archi task` |
+| `npx archi task <ID> --status <s>` | Update task status | `npx archi task INF-001 --status done` |
+| `npx archi task --check` | Check Roadmap consistency | `npx archi task --check` |
+
+**Valid status values**: `pending` / `active` / `done` / `blocked`
+
+### `npx archi plan`
+
+| Subcommand | Purpose | Example |
+|:---|:---|:---|
+| `npx archi plan <ID>` | Check Task's Plan completion | `npx archi plan SUB-01` |
+
+Automatically identifies Manual Verification sections and excludes them from automated statistics.
+
+### `npx archi render`
+
+| Subcommand | Purpose | Example |
+|:---|:---|:---|
+| `npx archi render` | Render all JSON data files into human-readable `.md` views | `npx archi render` |
+
+> `.md` views are auto-generated; forbidden to edit directly. Modifications must go through `.json` source files.

package/dist/templates/en/rules/90_custom_rules.md

@@ -0,0 +1,22 @@
+---
+description: Project Specific Rules & Constraints. High-priority user overrides, team preferences, and business-specific invariants that supersede general defaults.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Custom Project Rules
+
+> **Priority:** [High]
+> **Role:** The "House Rules" of this project. When general `02_tech_stack` cannot cover certain details, or there are specific business constraints, this file prevails.
+
+## 1. Team Conventions
+
+
+## 2. Business Constraints
+
+
+## 3. Specific Anti-Patterns
+
+
+## 4. ...

package/dist/templates/en/rules/99_context_glue.md

@@ -0,0 +1,53 @@
+---
+description: Context Navigation & Document Indexing. Bridges source code to documentation using the Map registry. Essential for locating specs and plans.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Context Glue Protocol
+
+> **Role**: Context Navigator. Prevent AI amnesia, use Map Look-up to determine the business document corresponding to the current code.
+
+## 1. Context Discovery
+
+When reading or editing code files, must execute the following addressing steps:
+
+**Step 1: Check Global Map**
+- Read `[[__DOCS_DIR__]]/global/map.json`.
+- Find the module the current file belongs to in `directoryMapping` / `logicalTopology`.
+- Load the Docs Link (Spec/UI/Plan) registered for that module.
+
+**Step 2: Check Explicit Context**
+- Scenario: Newly created file or Map not yet updated.
+- Check if user Prompt explicitly specified a document path, if so must load it.
+
+**Step 3: Fallback**
+- Not registered in Map and user did not specify → **STOP & ASK**.
+- Prompt: "Spec document for current code not found. Please provide the path, or run `/archi.map` to update the architecture map."
+
+---
+
+## 2. Mandatory Loading Rules
+
+| Code Type | Required Context | Source of Truth |
+|:---|:---|:---|
+| **Business Logic** (Tasks/Entities) | Spec Document | `[[__DOCS_DIR__]]/global/map.json` → Module Entry |
+| **UI Components** (Pages/Widgets) [?UI] | UI Document + `[[__DOCS_DIR__]]/global/design_tokens.json` | `[[__DOCS_DIR__]]/global/map.json` + Global Rules |
+| **Data Schema** (ORM/SQL/Models) [?Data] | Data Snapshot | `[[__DOCS_DIR__]]/global/data_snapshot.json` |
+| **Config / Infra** (Package.json...) | Tech Stack | `02_tech_stack.md` |
+
+---
+
+## 3. Anti-Hallucination
+
+- Code is the downstream artifact of documentation.
+- Forbidden to guess business logic based on variable names without reading Spec.
+- When code is found inconsistent with documentation: do not arbitrarily fix either, must pause and report the inconsistency.
+
+---
+
+## 4. Maintenance Hook
+
+- **Trigger**: When creating a new file or new module.
+- **Action**: Must automatically update `map.json` to establish mapping between code path and document path; only ask user when the mapping relationship is unclear.