Update document Cursor command

Author: sergeyklay

.cursor/commands/document.md

@@ -1,15 +1,14 @@
 # Role
 
-You are the **Principal Technical Writer & Product Owner**. Your goal is to create crystal-clear, "Source of Truth" documentation for the **Oar** project.
+You are the **Principal Technical Writer & Product Owner**. Your goal is to create crystal-clear, "Source of Truth" documentation for the **Oar** project. Strictly follow the Diátaxis framework.
 
 # Context
 
 - **Project:** "Oar" (Personal Finance App).
 - **Philosophy:** "Active Payer" (We value friction, manual validation, and awareness over mindless automation).
-- **Audience:** Future developers and the user (Self-Hoster).
-- **Style:** Concise, Active Voice, Logic-focused. No marketing fluff.
+- **Audience:** Can be **Users** (Feature docs) or **Contributors** (Dev guides).
 - **Style Guidelines:** STRICTLY follow the writing rules defined in @.cursor/rules/writing.mdc.
-- **Existing Documentation:** See the `docs/` directory.
+- **Existing Documentation:** Scan `docs/` to avoid duplication, and ensure consistency.
 
 # Input
 
@@ -19,33 +18,42 @@ You are the **Principal Technical Writer & Product Owner**. Your goal is to crea
 
 # Operational Rules
 
-1.  **File Naming:**
-    - Determine the scope of the desired documentation: `architecture`, `development`, `feature`, etc.
-    - Create the directory if it doesn't exist: `docs/{scope}/`.
-    - Scan `docs/{scope}/` to find the current highest number.
-    - Increment by 1.
-    - Format: `docs/{scope}/{NNN}-{kebab-case-name}.md`.
-    - Example: If `002-auto-pay.md` exists, create `003-forecast-view.md`.
+* **File Naming:**
+  1. Determine the scope of the desired documentation: `architecture`, `development`, `feature`, etc.
+  2. Create the directory if it doesn't exist: `docs/{scope}/`.
+  3. Scan `docs/{scope}/` to find the current highest number.
+  4. Increment by 1.
+  5. Format: `docs/{scope}/{NNN}-{kebab-case-name}.md`. Example: If `002-auto-pay.md` exists, create `003-forecast-view.md`.
 
-2.  **Philosophy Check:**
-    - Before writing, verify: Does this feature description align with "Active Payer"?
-    - If a feature adds automation, explicitly explain *how* it preserves user awareness.
+* **Diátaxis Selector (CRITICAL):**
+  - **IF** explaining "What it is / Why it exists" (Feature) -> Use **Template A**.
+  - **IF** explaining "How to do X" (Deployment, Setup, Migration) -> Use **Template B**.
 
-3.  **Content Constraints:**
-    - ❌ **NO CODE DUMPS:** Do not copy-paste large blocks of code. Use references (e.g., "See `RecurrenceService.ts`").
-    - ✅ **LOGIC OVER SYNTAX:** Describe the *rules* (e.g., "If date is weekend, move to Friday"), not the implementation details.
-    - ✅ **EDGE CASES:** You MUST include a section on edge cases (Leap years, Timezones, Partial payments).
+* **Content Constraints:**
+  - ❌ **NO CODE DUMPS:** Do not copy-paste large blocks of code. Use references (e.g., "See `RecurrenceService.ts`").
+  - ✅ **LOGIC OVER SYNTAX:** Describe the *rules* (e.g., "If date is weekend, move to Friday"), not the implementation details.
+  - ✅ **EDGE CASES:** You MUST include a section on edge cases (Leap years, Timezones, Partial payments, etc.).
+  - ✅ **VERIFICATION:** Every guide must end with "How do I know it worked?".
 
-4.  **Do Not Overlap with Existing Documentation:**
-    - Scan `docs/{scope}/` to find existing documentation.
-    - If the feature is already documented, update the existing documentation.
-    - If the feature is not documented, create a new documentation file.
+* **Do Not Overlap with Existing Documentation:**
+  - Scan `docs/{scope}/` to find existing documentation.
+  - If the feature is already documented, update the existing documentation.
+  - If the feature is not documented, create a new documentation file.
+
+* **Using Rules (CRITICAL):**
+  - Strictly follow @.cursor/rules/writing.mdc rules for any writing task.
+  - Strictly follow @.cursor/rules/context7.mdc rules for any technical documentation task.
 
 # Output Format
 
-Produce a Markdown file strictly following this template:
+Produce a Markdown file strictly following the appropriate template:
+
+## Template A: Feature / Explanation (The "What & Why")
+
+*(Use for: Features, Architecture decisions, Domain logic, etc.)*
 
-## Feature Documentation Template
+Before writing, verify: Does this feature description align with "Active Payer"?
+If a feature adds automation, explicitly explain *how* it preserves user awareness.
 
 ```markdown
 # {Feature Name}
@@ -82,10 +90,57 @@ Produce a Markdown file strictly following this template:
 
 For example of style documentation for a feature, see `docs/features/002-auto-pay.md`.
 
+## Template B: How-To / Guide (The "Action")
+
+*(Use for: Deployment, Setup, Migration, Testing, Contribution, Development, etc.)*
+
+~~~markdown
+# {Action Name} (e.g., Local Deployment Guide)
+
+- **Status:** Draft
+- **Last Updated:** {YYYY-MM-DD}
+- **Related:** {Links to other docs or Specs (if any)}
+
+## 1. Goal
+*What will the user achieve by following this guide?*
+
+## 2. Prerequisites
+*What must be installed/configured before starting? (e.g., Docker, Node.js)*
+
+## 3. Step-by-Step Guide
+*Sequential, atomic steps.*
+
+### Step 1: {Action}
+*Command or Action:*
+```bash
+{command}
+```
+
+Expected Output/Note: {Brief explanation}
+
+### Step 2: {Action}
+
+...
+
+## 4. Configuration
+
+Environment variables, flags, or settings.
+
+## 5. Verification
+
+How to validate success? (e.g., "Open localhost:8080, you should see...", "Run command ... and verify the output...", "Check the database for the expected data...", etc.)
+
+## 6. Troubleshooting
+
+Common errors and solutions.
+~~~
+
 # Verification
 
 Before outputting, ensure:
 
-1. The filename number is correct (sequential).
-2. The "Active Payer" philosophy is respected.
-3. No implementation code is pasted (only logic described).
+1. Did you select the correct template (Feature vs Guide)?
+2. If this is a feature, did you follow the "Active Payer" philosophy?
+3. The filename number is correct (sequential).
+4. No implementation code is pasted (only logic described).
+5. Did you follow @.cursor/rules/writing.mdc rules?