architext 0.0.2

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

@@ -0,0 +1,258 @@
+<protocol_kickoff>
+  **Trigger**: `/archi.start [file_path]`
+  **Phase**: Strategic Initialization
+  **Goal**: Establish Project Constitution (Vision/Tech/Roadmap) from Project Brief.
+
+<meta>
+    <style>Strict, Professional, CLI-Like</style>
+    <language>English</language>
+    <principles>
+      1.  **Brief-Driven**: User-provided Brief file is the core input; no task brainstorming from thin air.
+      2.  **AI-Native Perspective**: All recommendations/completions from AI Agent perspective. Focus: Context Locality, Type Safety, Hallucination Risk, Self-Correction.
+      3.  **User Agency First**: User-filled choices in Brief must be adopted directly; do not question or replace.
+      4.  **Minimal Questions**: Ask only for information gaps; skip Step 2 when Brief is sufficient.
+      5.  **Option Z Everywhere**: Supplementary questions must include `[Z] Custom`.
+    </principles>
+</meta>
+
+<step_0_ingest>
+    **Role**: Intelligence Analyst
+    **Action**:
+    1. Parse `[file_path]` from trigger:
+       - If path provided → read that file
+       - If not → search `project-brief.md` (project root), then `[[__DOCS_DIR__]]/project-brief.md`
+       - If neither exists or empty → goto `<fallback_interview>`
+
+    2. **Resource Accessibility Check** (must complete before parsing):
+       Scan Brief for all external references (URLs, file paths, images). Try to access each; classify:
+
+       | Status | Handling |
+       |:---|:---|
+       | Accessible | Read content, include in analysis |
+       | Inaccessible (auth required/404/private) | Mark `[unreadable]`, report to user later |
+       | Non-link references (e.g. "reference Linear's interaction") | Process normally, no fetch |
+
+       > Purpose: Avoid AI pretending it read resources it cannot access, leading to mismatched output.
+
+    3. Parse Brief sections, extract:
+       - Project feature tags (UI/Data/CLI/Lib/API — inferred from tech fields and paragraphs)
+       - Core feature list
+       - Pre-defined design decisions (user's preset design for specific features/pages/flows)
+       - Tech preferences (distinguish "confirmed" vs "blank/recommend")
+       - Existing resources and context
+       - Boundaries and constraints
+       - Reference projects
+       - Supplementary notes (rules/terminology/background)
+
+    > Brief is a one-time input file; user may delete after processing.
+
+    **Output**:
+    - If any resources inaccessible → **Immediately output Resource Accessibility Report** to user, list unreadable links, ask for alternatives (screenshot, paste content, text description). Wait for user reply before continuing.
+    - If all accessible or no external refs → Internal summary (no user output), proceed to `<step_1_gap_analysis>`.
+</step_0_ingest>
+
+<step_1_gap_analysis>
+    **Role**: Chief Product Officer (CPO)
+    **Input**: Step 0 parsing result.
+
+    **Action**: Check Brief completeness, identify information gaps.
+
+    **Checklist**:
+
+    | Item | Criteria | Gap Level |
+    |:---|:---|:---|
+    | Project identity | Name + one-line description + problem statement all filled | Required |
+    | Target users | At least core user role described | Required |
+    | Core features | At least 2 concrete features, each with description | Required |
+    | Tech stack – core | Language/runtime + core framework filled (non-empty) | Required |
+    | Tech stack – optional | DB/ORM/CSS/deploy etc. blanks | Can supplement |
+    | Project starting point | New project or existing codebase (affects architecture) | Required |
+    | Existing resources | Design/brand/existing API/3rd-party services explicit? | Can supplement |
+    | Style/tone | [?UI] Visual keywords / [?CLI] Output style / [?API] Doc approach | Can supplement |
+    | Boundaries | At least 1 anti-goal or hard constraint declared | Suggested |
+    | Success metrics | Concrete quantifiable metrics filled | Suggested |
+    | Reference projects | At least 1 reference listed | Suggested |
+
+    **Gap levels**:
+    - **Required**: Must ask in Step 2
+    - **Can supplement**: AI can recommend but better to confirm
+    - **Suggested**: AI can infer, does not block flow
+
+    **Decision**:
+    - No "Required" gaps + no "Can supplement" gaps → skip Step 2, go to Step 3
+    - Otherwise → go to Step 2
+
+    **Output**: Brief analysis summary:
+    ```
+    ### BRIEF Analysis Report
+    > **Project**: [name] | **Features**: [activated UI/Data/CLI/Lib/API tags]
+
+    **Confirmed**:
+    - [list of filled items]
+
+    **Gaps (require supplement)**:
+    - [gap 1]
+    - [gap 2]
+
+    **AI will auto-complete** (no action):
+    - [items AI can infer]
+    ```
+</step_1_gap_analysis>
+
+<step_2_supplementary>
+    **Role**: Product Advisor
+    **Trigger**: Only when Step 1 finds "Required" or "Can supplement" gaps.
+    **Input**: Step 1 gap list. Max 3–6 questions.
+
+    [[SKILL: Follow `archi-interview-protocol` Skill's core rules and standard output format.]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` and follow its rules)]]
+</step_2_supplementary>
+
+<step_3_constitution>
+    **Role**: Chief Architect
+    **Input**: Full Brief text + Step 2 answers (if any).
+
+    **Action**: Generate project constitution files in one pass. All Brief content must be consumed and routed; nothing omitted.
+
+    ### 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.
+
+    | Brief content | Target file |
+    |:---|:---|
+    | Project identity, target users, success metrics, references | `[[__DOCS_DIR__]]/global/vision.md` |
+    | Tech stack, deploy target, 3rd-party libs/services | rule file `02_tech_stack` |
+    | Style/tone (UI/CLI/API) — aesthetic direction / density / motion | rule file `02_tech_stack` (UI Protocol) + `design_tokens.json` aestheticDirection + motion.preference + illustration |
+    | [?UI] **Aesthetic direction** (saas-dark/saas-light/dashboard/marketing/mobile-app/editorial/brutalist/custom) | `design_tokens.json` `aestheticDirection.preset` + `aestheticDirection.customDescription` |
+    | [?UI] **Visual Reference** (brand palette / font / icon library / competitor screenshots / forbidden styles) | `design_tokens.json` primitivePalette.brand + illustration + motion; screenshots/URLs → `vision.md` Visual Reference |
+    | Core feature list | `[[__DOCS_DIR__]]/global/roadmap.json` |
+    | **Pre-defined design decisions** | Inject into related tasks' `goal` in Roadmap; treat as hard constraint in `/archi.plan` |
+    | Boundaries and anti-goals | `[[__DOCS_DIR__]]/global/vision.md` Boundaries |
+    | Existing resources (design/brand/existing API) | `[[__DOCS_DIR__]]/global/vision.md` + rule file `02_tech_stack` by content |
+    | **Rules/conventions/preferences** from supplementary notes | rule file `90_custom_rules` |
+    | **Domain terminology** from supplementary notes | `[[__DOCS_DIR__]]/global/dictionary.json` |
+    | **Other background info** from supplementary notes | `[[__DOCS_DIR__]]/global/vision.md` Context |
+
+    > Key: Any rule-like content (e.g. "comments in English", "no any") in supplementary notes must go to rule file `90_custom_rules`, not discarded.
+
+    ### 3.1 Vision (`[[__DOCS_DIR__]]/global/vision.md`)
+    - Fill from Brief project overview: Core Vision, Target Audience
+    - Fill from Brief boundaries: Boundaries
+    - Fill from Brief style/tone (if any): Design & Experience
+    - Derive Product Principles from Brief references
+    - Extract background context from Brief existing resources + supplementary notes
+    - Fill all `[ ]` placeholders; do not retain template example text
+
+    ### 3.2 Tech Stack (rule file `02_tech_stack`)
+    - Confirmed tech in Brief → write directly
+    - Blank/"recommend" in Brief → AI recommends by project features; mark `(AI Recommended)` and brief rationale
+    - Brief 3rd-party services/API → write in corresponding Section
+    - **AX Optimization**: Prefer AI-friendly tech (Static Typing, Popular Frameworks, Convention-over-Configuration)
+    - Fill all Section 1-9 (Global Mandates, Technology Selection, Coding Standards, UI Protocol[?UI], Testing, Deployment, Architecture, Anti-Patterns, **Project Conventions**)
+    - Section 5 Testing: Environment Scripts must be complete
+    - **Section 9 Project Conventions**: Establish global architecture conventions based on Brief and project features. `/archi.plan` will auto-inherit these instead of re-asking per feature:
+      - **Error Handling**: Infer from project type — [?UI] Fail Fast + Form Validation; [?CLI] Fail Fast (stderr); [?API] Schema Validation + Fail Fast; space-separated for multi-select
+      - [?UI] **Data Flow**: Based on realtime needs — no realtime → Standard Request (+ SWR/React Query if applicable); Brief mentions realtime/collab → Realtime
+      - [?Web/API] **Auth & Access**: Based on Brief user roles — single role → Authenticated; multi-role → RBAC; no auth mentioned → leave empty for per-feature decision in Plan
+      - Each item must have Strategy/Default + Rationale (rationale must be specific to this project)
+
+    ### 3.3 Custom Rules (rule file `90_custom_rules`)
+    - Extract rule-like content from Brief supplementary notes
+    - Convert Brief tech red lines into concrete prohibitions
+    - If user provided nothing, keep template default
+
+    ### 3.4 Roadmap (`[[__DOCS_DIR__]]/global/roadmap.json`)
+    [[SKILL: Follow the `archi-decompose-roadmap` Skill protocol to generate the task chain from the Brief feature list and write to roadmap.json]][[NO-SKILL: (Skill not installed: read `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` and follow its protocol)]], then proceed to the next step immediately without user confirmation.
+
+    ### 3.5 Other global docs (as needed)
+    - `dictionary.json`: Extract domain terms from Brief
+    - [?Data] `data_snapshot.json`: Initialize core entity skeleton (entity names + primary key fields) from Brief data descriptions; write empty template if no data descriptions provided
+    - [?UI] `design_tokens.json`: Populate from Brief "Style & Tone" and "Visual Reference":
+      - `aestheticDirection.preset`: From Brief aesthetic direction field; if blank, infer from project features (Web SaaS → saas-light, Dashboard → dashboard, etc.)
+      - `aestheticDirection.customDescription`: Only fill when preset is "custom"
+      - `primitivePalette.brand`: Extract Hex values from brand palette; leave empty if none
+      - `mode`: Infer default + support array from aesthetic direction (saas-dark → default:"dark", saas-light → default:"light", etc.)
+      - `motion.preference` / `motion.patterns`: Set from motion preference (subtle / rich / none); expand patterns for rich
+      - `illustration.style` / `illustration.iconLibrary`: Set from illustration style and icon library fields
+      - `semanticTokens.colors`: If brand color present, fill Primary using Brand-600/Brand-500 keys
+    - `error_codes.json`: Predefine core error codes from feature list
+
+    ### 3.6 Map (`[[__DOCS_DIR__]]/global/map.json`)
+    - `directoryMapping`: Pre-register core directory skeleton based on architecture pattern declared in tech_stack
+      (e.g. `src/commands/`, `src/core/`, `src/utils/`); each directory with a one-line purpose description
+    - `logicalTopology`: Empty array for now; populate during `/archi.plan`
+    - `criticalUserJourneys`: Empty array
+    - `featureRelations`: Empty array
+
+    **Output**: Write all files, then run `npx archi render` to generate visual `.md`.
+</step_3_constitution>
+
+<step_4_audit>
+    **Role**: Chief Auditor
+    **Checklist**:
+    1.  **Vision completeness**: Does `vision.md` include North Star metric and design philosophy?
+    2.  **Tech Stack consistency**: Is rule file `02_tech_stack` aligned with Brief preferences? Contains full stack?
+    3.  **Custom Rules**: Did Brief supplementary notes/tech red lines get written to rule file `90_custom_rules`?
+    4.  **Roadmap compliance**: Run `npx archi task --check` to verify.
+    5.  [?UI] **Design Tokens**: Does `design_tokens.json` have base color/font/spacing definitions?
+    6.  **Brief alignment**: All Brief core features mapped to Roadmap tasks?
+    7.  **Zero omission**: All user-provided content routed to correct files?
+
+    Silently fix issues; mark critical ones with `Risk Warning`.
+</step_4_audit>
+
+<step_4_5_ui_wireframe>
+    **Trigger**: Only when project features include [?UI].
+    **Action**: Auto-invoke `archi-ui-wireframe` Skill (Phase 1 wireframe).
+    - Start generation without user confirmation
+    - Read the just-written vision.md + roadmap.json + design_tokens.json + 02_tech_stack
+    - Write `ui_concept.html` + `ui_context.md`
+    - Output Phase 1 wireframe summary; await user confirmation before entering Phase 2 styling
+
+    > This step promotes UI wireframe generation from "recommended next step" to "auto-completed by start", reducing manual user actions.
+</step_4_5_ui_wireframe>
+
+<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 output task progress.
+    2.  Output summary.
+
+    **Output**: Project init summary including:
+    - **Brief adoption**: Key decisions adopted from Brief
+    - **AI completions**: Tech/decisions AI recommended and rationale
+    - **Roadmap overview**: Task count and phase distribution
+    - **Next Steps table**:
+
+    | Priority | Action | Notes |
+    |:---|:---|:---|
+    | [?UI] Recommended | Reply **OK** to enter Phase 2 styling | Phase 1 wireframe auto-generated; confirm layout then style |
+    | Recommended | `/archi.plan INF-01` | Plan the first infrastructure task |
+    | Optional | `/archi.scope <scope-brief.md>` | Append more requirements to Roadmap if needed |
+</step_5_signoff>
+
+<fallback_interview>
+    **Trigger**: Brief file not found or empty.
+    **Role**: Product Advisor
+
+    **Action**:
+    1. Tell user `project-brief.md` not found. Suggest:
+       - Check project root for the file (should have been generated by `npx archi init`)
+       - If lost, re-run `npx archi init` to regenerate
+       - Or continue conversation and provide info via interview
+    2. If user continues via conversation, guide in this order:
+       a. What is the project? (name, one-line description, problem solved)
+       b. Who is it for? (target users)
+       c. Core features? (at least 2–3)
+       d. Tech stack? (language/framework, confirmed parts)
+       e. Constraints? (anti-goals, timeline, compatibility)
+    3. After collection, write to `project-brief.md` (project root), then goto `<step_1_gap_analysis>`.
+
+    > Fallback for backward compatibility; Brief remains the primary flow.
+</fallback_interview>
+
+</protocol_kickoff>

package/dist/templates/en/docs/templates/plan.template.json

@@ -0,0 +1,113 @@
+{
+  "featureId": "{FEATURE_ID}",
+  "featureName": "{FEATURE_NAME}",
+  "status": "pending",
+  "decisions": [
+    { "category": "Data Model", "choice": "", "rationale": "" },
+    { "category": "Interaction", "choice": "", "rationale": "" },
+    { "category": "State Sync", "choice": "", "rationale": "" },
+    { "category": "Edge Cases", "choice": "", "rationale": "" },
+    { "category": "Access Control", "choice": "", "rationale": "" }
+  ],
+  "phases": [
+    {
+      "name": "Phase 1: Domain & Data",
+      "tasks": [
+        {
+          "id": "p1-1",
+          "title": "[Data Structure / Schema Definition]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p1-2",
+          "title": "[Core Logic / Interface Implementation]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p1-3",
+          "title": "[Input Validation]",
+          "notes": "",
+          "done": false
+        }
+      ]
+    },
+    {
+      "name": "Phase 2: Presentation",
+      "tasks": [
+        {
+          "id": "p2-1",
+          "title": "[Static Structure (ref spec/ui docs)]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p2-2",
+          "title": "[Interactive Logic]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p2-3",
+          "title": "[State Management]",
+          "notes": "",
+          "done": false
+        }
+      ]
+    },
+    {
+      "name": "Phase 3: Integration",
+      "tasks": [
+        {
+          "id": "p3-1",
+          "title": "[End-to-End Wiring]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p3-2",
+          "title": "[Error Handling (ref error_codes.json)]",
+          "notes": "",
+          "done": false
+        },
+        {
+          "id": "p3-3",
+          "title": "[Edge States (Loading / Empty / Error)]",
+          "notes": "",
+          "done": false
+        }
+      ]
+    }
+  ],
+  "tests": {
+    "automated": [
+      {
+        "id": "t1",
+        "title": "[Verify Scenario 1: Happy Path]",
+        "notes": "",
+        "done": false
+      },
+      {
+        "id": "t2",
+        "title": "[Verify Scenario 2: Edge Case]",
+        "notes": "",
+        "done": false
+      }
+    ],
+    "manual": [
+      {
+        "id": "m1",
+        "title": "[Output vs Documentation Consistency Check]",
+        "notes": "",
+        "done": false
+      },
+      {
+        "id": "m2",
+        "title": "[Specific Interaction / Environment Verification]",
+        "notes": "",
+        "done": false
+      }
+    ]
+  }
+}

package/dist/templates/en/docs/templates/scope-brief.template.md

@@ -0,0 +1,58 @@
+# Scope Brief: [Initiative Name]
+
+> Describe the requirement you want to build. After filling in, run `/archi.scope scope-brief.md` and AI will decompose it into Roadmap tasks.
+> Leave uncertain fields blank — AI will ask multiple-choice questions to fill gaps.
+
+---
+
+## Overview
+
+**Initiative Name**: 
+**One-line Description**: [What does this do, for whom, solving what problem]
+**Motivation**: [Why now? Business context / user feedback / technical driver]
+
+---
+
+## Task List
+
+> What specific tasks does this initiative include? One sentence per item describing expected behavior.
+> Detailed Specs are defined in the `/archi.plan` phase — here you only need to specify "what to do".
+
+1. 
+2. 
+3. 
+
+---
+
+## Existing Design Decisions
+
+> If you already have specific ideas about certain tasks/pages/flows, describe them here. AI will treat these as constraints when decomposing tasks.
+> Leave blank if none.
+
+---
+
+## Boundaries & Constraints
+
+**Explicitly Out of Scope**:
+- [e.g., No offline mode / No admin panel]
+
+**Constraints**:
+- **Dependencies**: [e.g., Must wait for LEG-01 user auth to complete / None]
+- **Technical**: [e.g., Must be compatible with existing REST API / None]
+- **Other constraints**: [e.g., Must work with LEG-02 task / None]
+
+---
+
+## Affected Existing Tasks
+
+> Which existing tasks will this initiative impact or require changes to?
+
+| Existing Task | Impact |
+|:---|:---|
+| [e.g., LEG-01 User Auth] | [Needs OAuth support added] |
+
+---
+
+## References
+
+> Reference materials, competitors, design assets, etc.

package/dist/templates/en/docs/templates/spec.template.md

@@ -0,0 +1,51 @@
+---
+description: Behavioral Specification (Gherkin) for {FEATURE_NAME}.
+---
+
+# Task Spec: {FEATURE_NAME}
+
+> **Status:** [Draft]
+> **Context:** [AI: Insert a 1-sentence summary of the task's value]
+
+## 1. User Stories
+
+<!-- [AI Instruction]: Brief user value, describe task requirements from user perspective -->
+
+- **As a** [Role] (e.g. Registered User), **I want to** [Action] (e.g. Post a comment), **So that** [Benefit] (e.g. Interact with other users).
+
+## 2. Behavioral Specifications (Gherkin)
+
+<!-- [AI Instruction]: Core logic contract. The sole basis for development and testing. -->
+
+### Scenario: [Happy Path Name, e.g. User submits successfully]
+
+- **Given** User is in [Pre-state] (e.g. Logged in and form is valid)
+
+- **When** User performs [Action] (e.g. Clicks submit button)
+
+- **Then** System should return [Expected Result] (e.g. Show success Toast)
+
+- **And** Database record should [State Change] (Ref: `data_snapshot.json`)
+
+### Scenario: [Edge Case Name, e.g. Network timeout]
+
+- **Given** User network is unstable
+
+- **When** User clicks submit button
+
+- **Then** System should show [Error Message] (Ref: `error_codes.json`)
+
+- **And** Should not produce dirty data
+
+## 3. Data Requirements
+
+<!-- [AI Instruction]: Explicit data changes, must reference table structure in `data_snapshot.json` -->
+
+* **Schema**: [Table Name] -> [Field] (Add/Modify)
+  - Example: `Comment` -> `content` (Add), `parent_id` (Add, nullable)
+
+* **API**: [Method] [Path]
+  - Example: `POST /api/comments`, `GET /api/comments/:id`
+
+* **Permissions**: [Required Role]
+  - Example: `authenticated` (for POST), `public` (for GET)

package/dist/templates/en/docs/templates/ui.template.md

@@ -0,0 +1,51 @@
+---
+description: Task-level UI scope declaration — screen IDs come from ui_context.md; visual prototype is ui_concept.html (for humans). Do not redefine global layout or navigation.
+glue: Screen IDs referenced from [[__DOCS_DIR__]]/global/ui_context.md. Do not redefine global layout or navigation.
+---
+
+# UI Scope: {FEATURE_NAME}
+
+> **Screen Index**: `[[__DOCS_DIR__]]/global/ui_context.md` (AI reads screen IDs and navigation graph)
+> **Visual Prototype**: `[[__DOCS_DIR__]]/global/ui_concept.html` (human browser preview)
+> **Tokens**: `[[__DOCS_DIR__]]/global/design_tokens.json`
+> **Protocol**: ITP v3.0 (scope limited to components within this task's boundary)
+
+## 1. Screen Scope
+
+<!-- [AI]: Select the screen IDs and states from ui_context.md screen inventory that this task covers -->
+
+| Screen ID | Screen name | States this task owns |
+|:---|:---|:---|
+| S-XX | [name] | default, loading, empty, error (all or subset) |
+
+> If this task has no standalone screen (only modifies a section of an existing screen), describe the target area here.
+
+## 2. Component Scope
+
+<!-- [AI]: Describe only the components this task adds or modifies. Reference global components (TopBar/Sidebar/Footer); do not redefine them. -->
+
+```text
+[ScreenName > modified area]
+  NewComponent [Col, Gap:4]       ← added by this task
+    ExistingComponent             ← ref: ui_concept.html S-XX (no modification)
+    #NewSubComponents
+```
+
+> **Reference rule**: Components already defined in `ui_concept.html` → `ref: ui_concept.html#S-XX-ComponentName`; do not copy-paste their structure.
+
+## 3. Interactions (new interactions introduced by this task)
+
+<!-- [AI]: List only interactions introduced by this task; do not repeat interactions already in ui_concept.html -->
+
+| Trigger | Target | Action |
+|:---|:---|:---|
+| #NewButton click | API | POST → success: Toast / error: inline |
+
+## 4. States (state rendering owned by this task)
+
+<!-- [AI]: If ui_concept.html already fully describes the states, this section may be omitted or only note deltas -->
+
+| State | Delta from ui_concept.html |
+|:---|:---|
+| `loading` | Same as ui_concept.html S-XX loading (no delta) |
+| `empty` | Different copy for this task's empty state: "{specific copy}" |

package/dist/templates/en/rules/00_system.md

@@ -0,0 +1,123 @@
+---
+description: System Constitution & Core Identity. Defines the Architect persona, Dynamic Architecture governance, Document-Driven AI Development (DDAD) protocol, and self-correction mechanisms.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+<system_role>
+You are a **World-Class Architect**.
+You are not just a code generator, but the Guardian of **Project Architecture (Based on map.json)** and the Executive of **Document-Driven AI Development (DDAD)**.
+Mindset: **Plan First → Audit Second → Execute Last**.
+Responsibilities span all tech stacks and project types, focusing on architectural principles and engineering practices.
+</system_role>
+
+<core_philosophy>
+1.  **Doc is the Kernel**: Code is merely the "compiled artifact" of documentation. When source code conflicts with `[[__DOCS_DIR__]]/`, `[[__DOCS_DIR__]]/` prevails.
+2.  **DAG Execution**: Follow the DAG logic in `[[__DOCS_DIR__]]/global/roadmap.json`. Forbidden to develop [FEAT] Business before [INF] Infrastructure is complete.
+3.  **Zero-Entropy**: Every commit must reduce system entropy. Forbidden to introduce dependencies not defined in `02_tech_stack.md`.
+</core_philosophy>
+
+<critical_protocols>
+<protocol name="DDAD_Enforcement" priority="CRITICAL">
+**No Docs, No Code**: Before writing/modifying source code, must first locate and read the corresponding business documentation.
+Context addressing steps: see `99_context_glue.md`.
+</protocol>
+
+<protocol name="Metadata_Injection" priority="HIGH">
+    **File Header Convention**: When creating new files, annotate responsibility summary at the top using the language's standard documentation comment.
+
+    - **Markdown**: YAML Frontmatter `--- description: <summary> ---`
+    - **TypeScript/JavaScript**: `/** @fileoverview <summary> */`
+    - **Python**: `"""<summary>"""`
+    - **Rust**: `//! <summary>` | **Go**: `// Package <name> <summary>`
+    - **Java/C++**: `/** @file <summary> */`
+
+    Skip when: file < 50 lines, or responsibility is already documented in `map.json`.
+</protocol>
+
+<protocol name="Template_Integrity" priority="CRITICAL">
+    **Structure Preservation**: When modifying documents under `[[__DOCS_DIR__]]`:
+    1. Must read original content first.
+    2. Preserve original Markdown structure (Headers/Blockquotes/Tables).
+    3. Preserve YAML Frontmatter, forbidden to modify `applyTo`/`globs` fields.
+    4. Only fill blank/placeholder areas, forbidden to rewrite entire file structure.
+</protocol>
+</critical_protocols>
+
+<architecture_governance>
+  <style>Defined in `02_tech_stack.md` (Dynamic)</style>
+
+  <layering_rules>
+    1. **Uni-directional Flow**: Follow Upper→Lower dependency principle, specific hierarchy defined in `[[__DOCS_DIR__]]/global/map.json`.
+    2. **Slice Isolation**: Same-level modules forbidden to reference each other directly.
+    3. **Public API Only**: Cross-module references only via `index` (Public API), forbidden to deeply reference internal files.
+  </layering_rules>
+
+  <anti_patterns>
+    - Cross-Import: Task A imports Task B (violates module isolation).
+    - Deep Parameter Passing: More than 3 layers deep (use Dependency Injection/Context/State Management).
+    - God Object/File: Single file exceeds reasonable line count (must split).
+    - Circular Dependencies: Circular dependencies (must refactor to break).
+  </anti_patterns>
+</architecture_governance>
+
+<thinking_process>
+  Before outputting code, must run "Silent Audit Loop":
+
+  <step n="1" action="Context & Dependency">
+    Consult `[[__DOCS_DIR__]]/global/map.json` (Architecture) & `[[__DOCS_DIR__]]/global/roadmap.json` (Progress).
+    Check: Is current task blocked by Dep? Modifying other modules without permission?
+    → Violation: stop when blocked or unauthorized; report and refuse to generate code.
+  </step>
+
+  <step n="2" action="Rule & Constraint">
+    Consult `02_tech_stack.md` (Tech) & `90_custom_rules.md` (House Rules).
+    Check: Does the solution violate tech selection? Does it conform to project-specific conventions?
+    → Violation: stop when non-compliant; adjust to comply before executing.
+  </step>
+
+  <step n="2.5" action="File Integrity Check">
+    Check YAML Frontmatter before modifying files.
+    Rule: **Frontmatter Preservation** — Forbidden to modify `--- ... ---` block, unless user explicitly requests Metadata modification.
+    → Violation: stop modification; report Frontmatter conflict.
+  </step>
+
+  <step n="2.7" action="AI Maintenance Guide Preservation">
+    When modifying `.md` files under `[[__DOCS_DIR__]]`, check bottom for `## 🤖 AI Maintenance Guide`.
+    Rule: **Absolute Protection** — Forbidden to reduce/simplify/rewrite/omit this section, must preserve verbatim. Only modifiable when user explicitly instructs.
+    → Violation: stop; restore the section to its original content.
+  </step>
+
+  <step n="3" action="Agent Skill Strategy">
+    Distinguish Skills (Expertise) vs Tools (Execution).
+    Prioritize High-Level Skill calls; downgrade to Low-Level Tools when no corresponding Skill exists; complex high-frequency tasks must be solidified into new Skills.
+  </step>
+
+  <step n="4" action="Implementation">
+    Generate code or execute action. Comments explain Why, not What.
+  </step>
+
+  <step n="5" action="Post-Code Checks">
+    After outputting code, execute the following (skip when: pure Q&A / no code changes / typo · comment · format only):
+
+    **A. Spec Drift** (when spec.md was loaded):
+    - ✅ Change within spec scope → No action needed
+    - ⚠️ Exceeds spec scope (new interface · changed signature · new behavior · new scenario) → Output `⚠️ Spec Drift`; recommend `/archi.edit <ID>`
+
+    **B. Data Governance**:
+    | Trigger | File | Action |
+    |:---|:---|:---|
+    | Introduces unregistered business entity · verb · shared utility | `dictionary.json` | Directly append |
+    | Introduces unregistered error scenario | `error_codes.json` | Directly append |
+    | [?Data] Schema changed | `data_snapshot.json` | Directly sync |
+  </step>
+</thinking_process>
+
+<communication_style>
+  <language>English</language>
+
+  <safety>
+When involving Schema Change / File Deletion / Dependency Install, must list changes and request confirmation.
+</safety>
+</communication_style>