architext 0.0.3 → 0.0.5

package/dist/templates/en/briefs/_base.md

@@ -6,7 +6,7 @@
 
 ## Project Overview
 
-**Project Name**: 
+**Project Name**:
 **One-line description**: [What the project is, who it serves, what problem it solves]
 **Problem statement**: [Core pain points for target users? Where do existing solutions fall short?]
 
@@ -20,12 +20,27 @@
 
 ## Core Tasks
 
-> MVP must-have tasks (recommend 3–7), each in one sentence describing expected behavior.
+> Must-have tasks, each in one paragraph describing expected behavior.
 > Detailed specs are defined in `/archi.plan`; here just clarify "what to build."
 
-1. 
-2. 
-3. 
+1.
+2.
+3.
+
+---
+
+## Business Process
+
+> If your project has clear user journeys or core workflows, describe them here.
+> No need for diagrams—describe steps in text; AI will infer system behavior from this.
+> Leave blank if not applicable; AI will derive from core tasks.
+
+<!-- Format reference:
+### [Process name]
+1. User [action] → System [response]
+2. User [action] → System [response]
+3. ...
+-->
 
 ---
 
@@ -36,7 +51,7 @@
 >
 > Format:
 > - **[Task/page name]**: Describe behavior, flow, constraints
-> - May include screenshot/sketch links
+> - May include screenshot/sketch (see "Design Assets" below)
 
 ---
 
@@ -45,7 +60,7 @@
 > Fill in what's confirmed. Leave blank or write "recommend" for the rest; AI will recommend based on project characteristics.
 
 **Project type**: [[__PROJECT_TYPE__]]
-<!-- Auto-filled by archi init; if writing manually, refer to the project type table in the archi-decompose-roadmap SKILL -->
+<!-- Auto-filled by archi init; if writing manually, choose from ui/data/api/cli/lib/mobile/desktop/miniapp/extension/realtime/ai -->
 **Language/runtime**: [e.g.: TypeScript + Node.js 22]
 **Core framework**: [e.g.: Next.js 15 / Fastify / Tauri]
 **Package manager**: [e.g.: pnpm / npm / yarn / cargo]
@@ -78,14 +93,33 @@
 > What already exists that AI should know—to avoid reinventing or making conflicting decisions.
 
 **Project starting point**: [Greenfield / based on existing repo (brief status and tech debt)]
-**Design assets**: [Figma link / design mockup screenshots / none (AI designs)]
-**Brand guidelines**: [Existing logo/colors/fonts → describe or link / none]
 **Existing API/backend**: [API docs link / brief available endpoints / none (build from scratch)]
 **Third-party services**: [Confirmed services, e.g.: Auth0, Stripe, AWS S3, Resend...]
 **Existing data**: [Existing DB/data sources? Format? Migration needed? / none]
 
 ---
 
+## Design Assets
+
+> Provide visual/design input for AI—directly impacts UI and architecture decision quality.
+> Two ways to provide files:
+> 1. **Local files**: Place files in `brief-assets/` directory, reference by format below
+> 2. **External links**: Paste URL directly
+>
+> Reference format: `- [semantic label] ./brief-assets/filename`
+>
+> Format reference:
+> - [Competitor reference - home] ./brief-assets/linear-dashboard.png
+> - [My sketch] ./brief-assets/sketch-v1.png
+> - [Brand palette] ./brief-assets/brand-colors.pdf
+> - [API docs] ./brief-assets/api-spec.yaml
+> - [Database Schema] ./brief-assets/schema.sql
+
+**Design mockups/screenshots**: [Reference local files per format above / Figma link / none (AI designs)]
+**Brand guidelines**: [Existing logo/colors/fonts → reference file or describe / none]
+
+---
+
 <!-- @slot:style -->
 
 ## Scope & Constraints
@@ -94,7 +128,6 @@
 - [e.g.: No i18n this release / no mobile adaption / no paid features]
 
 **Hard constraints**:
-- **Timeline**: [e.g.: 4-week MVP / no hard deadline]
 - **Compatibility**: [e.g.: Chrome 90+ / Node 18+ / iOS 15+]
 - **Performance**: [e.g.: First paint < 2s / API P99 < 500ms / no special requirements]
 - **Compliance/accessibility**: [e.g.: WCAG 2.1 AA / GDPR / none]
@@ -112,4 +145,4 @@
 
 ## Additional Notes
 
-> Anything not covered above: background story, special requirements, rationale for decisions, team tech preferences, etc.
+> Anything not covered above: background story, special requirements, rationale for decisions, etc.

package/dist/templates/en/briefs/_modules.md

@@ -5,10 +5,37 @@
 <!-- @tech:data -->
 **Database**: [e.g.: PostgreSQL / MongoDB / SQLite]
 **ORM / Query Builder**: [e.g.: Prisma / Drizzle / TypeORM]
+
+### Data Model Draft
+
+> If you already know core data entities and relationships, describe them here. No need for full schema—list entity names and key fields.
+> AI will generate detailed data model in `/archi.plan`; here just clarify "what data exists."
+> Leave blank if not applicable; AI will derive from core tasks.
+
+<!-- Format reference:
+- **User**: email, name, role (admin/user), avatar
+- **Post**: title, content, status (draft/published), author → User
+- **Comment**: body, author → User, post → Post
+- User 1:N Post, Post 1:N Comment
+-->
+
 <!-- @end -->
 
 <!-- @tech:api -->
 **API style**: [e.g.: RESTful / GraphQL / gRPC / tRPC]
+
+### Existing API Endpoints
+
+> If you have existing backend API (self-hosted or third-party), list core endpoints here. Or place full docs in `brief-assets/`.
+> Leave blank if not applicable.
+
+<!-- Format reference:
+- `POST /auth/login` → returns JWT token
+- `GET /users/:id` → user detail
+- `POST /posts` → create post (auth required)
+- Full docs: [API docs] ./brief-assets/api-spec.yaml
+-->
+
 <!-- @end -->
 
 <!-- @tech:cli -->
@@ -44,8 +71,8 @@
 
 ### Visual Reference
 
-> Provides aesthetic input for AI — directly impacts `ui_concept.html` quality.
-> Fill in any of the fields below; the more you provide, the closer AI can match your vision.
+> Provides aesthetic input for AI—directly impacts `ui_concept.html` visual quality.
+> Any field below is valid; the more you fill, the better AI can match your expected style.
 
 **Competitor/inspiration screenshots**: [paste image / Figma link / URL]
 **Brand palette**: [primary color Hex / gradient description / none (AI generates from aesthetic direction)]
@@ -116,7 +143,7 @@
 **Real-time transport**: [e.g.: Socket.io / native WebSocket / SSE / WebRTC]
 **Real-time framework/hosting**: [e.g.: Ably / Pusher / Liveblocks / self-hosted]
 **Room/channel model**: [e.g.: subscribe by user ID / room by document ID / broadcast]
-**[?CRDT] Conflict resolution**: [e.g.: Yjs / Automerge / not needed (broadcast only)]
+**(CRDT projects only) Conflict resolution**: [e.g.: Yjs / Automerge / not needed (broadcast only)]
 **Offline support**: [e.g.: offline queue + reconnect sync / not needed]
 <!-- @end -->
 
@@ -125,7 +152,7 @@
 **AI framework**: [e.g.: Vercel AI SDK / LangChain / LlamaIndex / direct API calls]
 **Tool/Function Calling**: [e.g.: needed (list tool names) / not needed]
 **Memory approach**: [e.g.: vector DB (pgvector/Pinecone) / sliding window history / none]
-**[?MCP] MCP protocol**: [e.g.: @modelcontextprotocol/sdk / not needed]
+**(MCP projects only) MCP protocol**: [e.g.: @modelcontextprotocol/sdk / not needed]
 **Streaming output**: [e.g.: SSE streaming / batch response]
 <!-- @end -->
 

package/dist/templates/en/docs/global/api_snapshot.json

@@ -0,0 +1,24 @@
+{
+  "endpoints": [
+    {
+      "method": "[GET | POST | PUT | DELETE | PATCH]",
+      "path": "[/resource/:id]",
+      "description": "[One-sentence endpoint responsibility]",
+      "auth": "[required | public | optional]",
+      "requestBody": "[Schema description or N/A]",
+      "responses": {
+        "200": "[Success response structure]",
+        "[4xx]": "[ref: error_codes.json#ERR_CODE]"
+      },
+      "owner": "[FEAT-xxx | INF-xxx]"
+    }
+  ],
+  "protocolMapping": [
+    {
+      "statusCode": "[400 | 401 | 403 | 404 | 500 | ...]",
+      "code": "[ERR_CODE]",
+      "meaning": "[Meaning]",
+      "action": "[Caller behavior: Toast / Redirect / Retry / ...]"
+    }
+  ]
+}

package/dist/templates/en/docs/global/command_api.json

@@ -0,0 +1,26 @@
+{
+  "commands": [
+    {
+      "name": "[command-name]",
+      "aliases": ["[alias]"],
+      "description": "[One-sentence command responsibility]",
+      "args": [
+        {
+          "name": "[arg-name]",
+          "required": true,
+          "description": "[Argument description]"
+        }
+      ],
+      "flags": [
+        {
+          "name": "--[flag-name]",
+          "short": "-[f]",
+          "type": "[string | boolean | number]",
+          "default": "[Default or null]",
+          "description": "[Flag description]"
+        }
+      ],
+      "owner": "[FEAT-xxx | INF-xxx]"
+    }
+  ]
+}

package/dist/templates/en/docs/global/env_registry.json

@@ -0,0 +1,12 @@
+{
+  "variables": [
+    {
+      "name": "[ENV_VAR_NAME]",
+      "required": true,
+      "default": null,
+      "description": "[Purpose]",
+      "example": "[Example value]",
+      "owner": "[FEAT-xxx | INF-xxx]"
+    }
+  ]
+}

package/dist/templates/en/docs/global/map.json

@@ -81,6 +81,11 @@
       "category": "UI/UX",
       "purpose": "Task-level UI scope declaration — references screen IDs from ui_context.md to define this task's screen/component scope"
     },
+    {
+      "file": "design.md",
+      "category": "Technical Design",
+      "purpose": "[?Complex] Technical design — state machine/pipeline/protocol definitions, parameter table, invariants"
+    },
     {
       "file": "plan.json",
       "category": "Plan",

package/dist/templates/en/docs/global/public_api.json

@@ -0,0 +1,12 @@
+{
+  "exports": [
+    {
+      "name": "[exportName]",
+      "type": "[function | class | type | constant | enum]",
+      "signature": "[TypeScript signature]",
+      "description": "[One-sentence export responsibility]",
+      "stability": "[stable | experimental | deprecated]",
+      "owner": "[FEAT-xxx | INF-xxx]"
+    }
+  ]
+}

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

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