@mind-fold/open-flow 0.2.11 → 0.2.13

package/dist/templates/markdown/structure/backend/quality-guidelines.md.txt

@@ -26,11 +26,11 @@ pnpm test
 ### Non-Null Assertions
 
 ```typescript
-// ❌ FORBIDDEN
+// [X] FORBIDDEN
 const name = user!.name;
 const data = response!.data;
 
-// ✅ REQUIRED
+// [OK] REQUIRED
 const user = await getUser(id);
 if (!user) {
   throw new NotFoundError('User not found');
@@ -41,11 +41,11 @@ const name = user.name;
 ### Console.log
 
 ```typescript
-// ❌ FORBIDDEN
+// [X] FORBIDDEN
 console.log('Debug:', data);
 console.error('Error:', error);
 
-// ✅ REQUIRED
+// [OK] REQUIRED
 logger.debug('processing_data', { data });
 logger.error('operation_failed', error);
 ```
@@ -53,12 +53,12 @@ logger.error('operation_failed', error);
 ### Await in Loops
 
 ```typescript
-// ❌ FORBIDDEN
+// [X] FORBIDDEN
 for (const id of ids) {
   await db.select().from(users).where(eq(users.id, id));
 }
 
-// ✅ REQUIRED
+// [OK] REQUIRED
 const results = await db
   .select()
   .from(users)
@@ -68,11 +68,11 @@ const results = await db
 ### Type Assertions Without Validation
 
 ```typescript
-// ❌ FORBIDDEN
+// [X] FORBIDDEN
 const data = input as UserData;
 const config = JSON.parse(str) as Config;
 
-// ✅ REQUIRED
+// [OK] REQUIRED
 const data = userDataSchema.parse(input);
 const config = configSchema.parse(JSON.parse(str));
 ```
@@ -80,11 +80,11 @@ const config = configSchema.parse(JSON.parse(str));
 ### Any Type
 
 ```typescript
-// ❌ FORBIDDEN
+// [X] FORBIDDEN
 function process(data: any) { ... }
 const result: any = await fetch(...);
 
-// ✅ REQUIRED
+// [OK] REQUIRED
 function process(data: unknown) {
   const validated = schema.parse(data);
   ...
@@ -151,11 +151,11 @@ if (!user) {
 ### Comments
 
 ```typescript
-// ✅ GOOD: Explain WHY, not WHAT
+// [OK] GOOD: Explain WHY, not WHAT
 // Skip validation for internal calls to avoid performance overhead
 const data = trustInternalData(input);
 
-// ❌ BAD: Obvious comment
+// [X] BAD: Obvious comment
 // Get user by id
 const user = await getUser(id);
 ```

package/dist/templates/markdown/structure/backend/type-safety.md.txt

@@ -77,7 +77,7 @@ export const userSummary = userSchema.pick({
 ### Problem
 
 ```typescript
-// ❌ BAD: Crashes if user is null
+// [X] BAD: Crashes if user is null
 const user = await getUser(id);
 const name = user!.name;  // TypeScript trusts you, runtime doesn't
 ```
@@ -85,7 +85,7 @@ const name = user!.name;  // TypeScript trusts you, runtime doesn't
 ### Solution: Guard with Local Variable
 
 ```typescript
-// ✅ GOOD: Explicit null check
+// [OK] GOOD: Explicit null check
 const user = await getUser(id);
 if (!user) {
   throw new NotFoundError('User not found');
@@ -97,7 +97,7 @@ const name = user.name;  // Safe access
 ### Solution: Early Return
 
 ```typescript
-// ✅ GOOD: Early return pattern
+// [OK] GOOD: Early return pattern
 async function getUserName(id: string): Promise<string> {
   const user = await getUser(id);
   if (!user) {
@@ -178,13 +178,13 @@ if (!user) {
 
 ```typescript
 // Trust external data
-const data = externalInput as User;  // ❌
+const data = externalInput as User;  // [X]
 
 // Use non-null assertion
-const name = user!.name;  // ❌
+const name = user!.name;  // [X]
 
 // Ignore parse errors
-const data = userSchema.parse(input);  // ❌ Throws on invalid
+const data = userSchema.parse(input);  // [X] Throws on invalid
 ```
 
 ---

package/dist/templates/markdown/structure/flows/code-reuse-thinking-guide.md.txt

@@ -159,15 +159,15 @@ function Card({ title, content, badge }: CardProps) {
 - [ ] Is this display value defined in multiple components?
 - [ ] Should there be a shared config for this domain concept?
 
-**The Problem**: Same domain concept displayed in multiple components, each with its own config. Changing one, forgetting others → inconsistency.
+**The Problem**: Same domain concept displayed in multiple components, each with its own config. Changing one, forgetting others -> inconsistency.
 
 **Example - Before (bug)**:
 ```tsx
 // TodoColumn.tsx
-const stateConfig = { open: { label: "Open", ... } };  // ✅ Updated
+const stateConfig = { open: { label: "Open", ... } };  // [OK] Updated
 
 // TodoDetailPanel.tsx (FORGOT!)
-const stateConfig = { open: { label: "Todo", ... } };  // ❌ Still old
+const stateConfig = { open: { label: "Todo", ... } };  // [X] Still old
 
 // Result: Column shows "Open", Detail panel shows "Todo"
 ```
@@ -198,7 +198,7 @@ rg "stateConfig|StateConfig|state.*label" --type tsx
 - [ ] Is there already a visual distinction for this concept?
 - [ ] Does the logic use the **same criteria** as the visual representation?
 
-**The Problem**: Visual representation and logic use different criteria → inconsistent behavior.
+**The Problem**: Visual representation and logic use different criteria -> inconsistent behavior.
 
 **Example - Before (bug)**:
 ```typescript
@@ -265,7 +265,7 @@ import { SYNC_CONSTANTS } from "@shared/constants";
 - Abstraction would be confusing
 
 **Rule of thumb**: 
-> "Duplication is cheaper than the wrong abstraction" — Sandi Metz
+> "Duplication is cheaper than the wrong abstraction" -- Sandi Metz
 
 But once you see 3+ occurrences, it's time to abstract.
 
@@ -297,18 +297,18 @@ rg "open.*label|label.*open" --type tsx
 
 ```
 You're about to write some code
-    │
-    ├─ Does similar code exist?
-    │   ├─ Yes → Can you reuse/extend it?
-    │   │   ├─ Yes → Reuse it
-    │   │   └─ No → Why not? (might need abstraction)
-    │   └─ No → Continue
-    │
-    ├─ Is this the 3rd time writing this pattern?
-    │   ├─ Yes → Time to abstract
-    │   └─ No → OK to duplicate for now
-    │
-    └─ Done
+    |
+    |- Does similar code exist?
+    |   |- Yes -> Can you reuse/extend it?
+    |   |   |- Yes -> Reuse it
+    |   |   \- No -> Why not? (might need abstraction)
+    |   \- No -> Continue
+    |
+    |- Is this the 3rd time writing this pattern?
+    |   |- Yes -> Time to abstract
+    |   \- No -> OK to duplicate for now
+    |
+    \- Done
 ```
 
 ---

package/dist/templates/markdown/structure/flows/cross-layer-thinking-guide.md.txt

@@ -37,8 +37,8 @@ Before writing code, answer these questions:
 **Q: How does data flow?**
 
 ```
-[ ] Read flow:  Database → Service → API → Hook → Component
-[ ] Write flow: Component → Hook → API → Service → Database
+[ ] Read flow:  Database -> Service -> API -> Hook -> Component
+[ ] Write flow: Component -> Hook -> API -> Service -> Database
 [ ] Both ways (bidirectional)
 ```
 
@@ -82,92 +82,92 @@ Before writing code, answer these questions:
 ### Pattern A: CRUD Feature
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│                    THINK THROUGH                             │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. CREATE                                                   │
-│     └─ UI: What triggers creation? (button, form)           │
-│     └─ API: What's the input schema?                        │
-│     └─ DB: What tables are affected?                        │
-│     └─ Response: What does UI need back?                    │
-│                                                              │
-│  2. READ                                                     │
-│     └─ List view: What fields needed? (avoid over-fetch)    │
-│     └─ Detail view: Lazy load heavy content?                │
-│     └─ Loading: Show skeleton? Empty state?                 │
-│                                                              │
-│  3. UPDATE                                                   │
-│     └─ Optimistic UI? (update local before API responds)    │
-│     └─ Validation: Same rules as create?                    │
-│     └─ Partial update? (PATCH vs PUT)                       │
-│                                                              │
-│  4. DELETE                                                   │
-│     └─ Soft delete? (isDeleted flag)                        │
-│     └─ Cascade? (related entities)                          │
-│     └─ Confirmation required?                               │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
++-------------------------------------------------------------+
+|                    THINK THROUGH                             |
+|-------------------------------------------------------------|
+|                                                              |
+|  1. CREATE                                                   |
+|     \- UI: What triggers creation? (button, form)           |
+|     \- API: What's the input schema?                        |
+|     \- DB: What tables are affected?                        |
+|     \- Response: What does UI need back?                    |
+|                                                              |
+|  2. READ                                                     |
+|     \- List view: What fields needed? (avoid over-fetch)    |
+|     \- Detail view: Lazy load heavy content?                |
+|     \- Loading: Show skeleton? Empty state?                 |
+|                                                              |
+|  3. UPDATE                                                   |
+|     \- Optimistic UI? (update local before API responds)    |
+|     \- Validation: Same rules as create?                    |
+|     \- Partial update? (PATCH vs PUT)                       |
+|                                                              |
+|  4. DELETE                                                   |
+|     \- Soft delete? (isDeleted flag)                        |
+|     \- Cascade? (related entities)                          |
+|     \- Confirmation required?                               |
+|                                                              |
+\-------------------------------------------------------------+
 ```
 
 ### Pattern B: Form Submission
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│                    THINK THROUGH                             │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. INPUT                                                    │
-│     └─ What fields are required vs optional?                │
-│     └─ What validations on each field?                      │
-│     └─ Real-time validation or on submit?                   │
-│                                                              │
-│  2. SUBMISSION                                               │
-│     └─ Disable button while submitting?                     │
-│     └─ Show loading indicator?                              │
-│     └─ Prevent double submission?                           │
-│                                                              │
-│  3. SUCCESS                                                  │
-│     └─ Redirect to where?                                   │
-│     └─ Show success message?                                │
-│     └─ Invalidate which queries?                            │
-│                                                              │
-│  4. ERROR                                                    │
-│     └─ Show inline errors or toast?                         │
-│     └─ Which fields keep values?                            │
-│     └─ How to retry?                                        │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
++-------------------------------------------------------------+
+|                    THINK THROUGH                             |
+|-------------------------------------------------------------|
+|                                                              |
+|  1. INPUT                                                    |
+|     \- What fields are required vs optional?                |
+|     \- What validations on each field?                      |
+|     \- Real-time validation or on submit?                   |
+|                                                              |
+|  2. SUBMISSION                                               |
+|     \- Disable button while submitting?                     |
+|     \- Show loading indicator?                              |
+|     \- Prevent double submission?                           |
+|                                                              |
+|  3. SUCCESS                                                  |
+|     \- Redirect to where?                                   |
+|     \- Show success message?                                |
+|     \- Invalidate which queries?                            |
+|                                                              |
+|  4. ERROR                                                    |
+|     \- Show inline errors or toast?                         |
+|     \- Which fields keep values?                            |
+|     \- How to retry?                                        |
+|                                                              |
+\-------------------------------------------------------------+
 ```
 
 ### Pattern C: Data List with Filters
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│                    THINK THROUGH                             │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. FILTERS                                                  │
-│     └─ Which filters are available?                         │
-│     └─ Filters in URL for shareability?                     │
-│     └─ Server-side or client-side filtering?                │
-│                                                              │
-│  2. PAGINATION                                               │
-│     └─ Page-based or cursor-based?                          │
-│     └─ Total count needed?                                  │
-│     └─ Infinite scroll or explicit pages?                   │
-│                                                              │
-│  3. SORTING                                                  │
-│     └─ Default sort order?                                  │
-│     └─ Multi-column sort?                                   │
-│     └─ Server-side or client-side?                          │
-│                                                              │
-│  4. LOADING                                                  │
-│     └─ Skeleton for initial load?                           │
-│     └─ Overlay for filter change?                           │
-│     └─ Keep previous data while loading?                    │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
++-------------------------------------------------------------+
+|                    THINK THROUGH                             |
+|-------------------------------------------------------------|
+|                                                              |
+|  1. FILTERS                                                  |
+|     \- Which filters are available?                         |
+|     \- Filters in URL for shareability?                     |
+|     \- Server-side or client-side filtering?                |
+|                                                              |
+|  2. PAGINATION                                               |
+|     \- Page-based or cursor-based?                          |
+|     \- Total count needed?                                  |
+|     \- Infinite scroll or explicit pages?                   |
+|                                                              |
+|  3. SORTING                                                  |
+|     \- Default sort order?                                  |
+|     \- Multi-column sort?                                   |
+|     \- Server-side or client-side?                          |
+|                                                              |
+|  4. LOADING                                                  |
+|     \- Skeleton for initial load?                           |
+|     \- Overlay for filter change?                           |
+|     \- Keep previous data while loading?                    |
+|                                                              |
+\-------------------------------------------------------------+
 ```
 
 ---
@@ -212,24 +212,24 @@ Before writing code, answer these questions:
 
 ```
 Start: New Feature
-    │
-    ├─ Touches 3+ layers?
-    │   ├─ Yes → Use this thinking guide
-    │   └─ No → Standard implementation
-    │
-    ├─ Has form submission?
-    │   ├─ Yes → Think through Pattern B
-    │   └─ No → Skip
-    │
-    ├─ Has data list?
-    │   ├─ Yes → Think through Pattern C
-    │   └─ No → Skip
-    │
-    ├─ Has CRUD operations?
-    │   ├─ Yes → Think through Pattern A
-    │   └─ No → Skip
-    │
-    └─ Done: Implementation checklist ready
+    |
+    |- Touches 3+ layers?
+    |   |- Yes -> Use this thinking guide
+    |   \- No -> Standard implementation
+    |
+    |- Has form submission?
+    |   |- Yes -> Think through Pattern B
+    |   \- No -> Skip
+    |
+    |- Has data list?
+    |   |- Yes -> Think through Pattern C
+    |   \- No -> Skip
+    |
+    |- Has CRUD operations?
+    |   |- Yes -> Think through Pattern A
+    |   \- No -> Skip
+    |
+    \- Done: Implementation checklist ready
 ```
 
 ---

package/dist/templates/markdown/structure/flows/index.md.txt

@@ -18,18 +18,18 @@ Most bugs happen at **layer boundaries**, not within layers. This directory prov
 
 ```
 Before writing ANY code
-    │
-    ├─ Read: Pre-Implementation Checklist
-    │   └─ "Will this constant be used elsewhere?"
-    │   └─ "Does this pattern already exist?"
-    │
-    ├─ If feature spans 3+ layers
-    │   └─ Read: Cross-Layer Thinking Guide
-    │   └─ Consider creating a Flow Spec
-    │
-    └─ During/After implementation
-        └─ Reference: Code Reuse Thinking Guide
-        └─ Run: /check-cross-layer command
+    |
+    |- Read: Pre-Implementation Checklist
+    |   \- "Will this constant be used elsewhere?"
+    |   \- "Does this pattern already exist?"
+    |
+    |- If feature spans 3+ layers
+    |   \- Read: Cross-Layer Thinking Guide
+    |   \- Consider creating a Flow Spec
+    |
+    \- During/After implementation
+        \- Reference: Code Reuse Thinking Guide
+        \- Run: /check-cross-layer command
 ```
 
 ---
@@ -56,7 +56,7 @@ Before writing ANY code
 
 Create a flow spec when a feature:
 
-- [ ] Spans 3+ layers (e.g., API → Service → Component → Hook)
+- [ ] Spans 3+ layers (e.g., API -> Service -> Component -> Hook)
 - [ ] Has transformation points where data format changes
 - [ ] Has multiple consumers with different requirements
 - [ ] Involves state that passes through multiple components
@@ -66,41 +66,41 @@ Create a flow spec when a feature:
 
 ## Quick Reference: Common Cross-Layer Patterns
 
-### Pattern 1: API → Service → Component
+### Pattern 1: API -> Service -> Component
 
 ```
 API Route              # Validate input, call service
-    │
-    ▼
+    |
+    v
 Service Layer          # Business logic, database
-    │
-    ▼
+    |
+    v
 Response               # Format for client
-    │
-    ▼
+    |
+    v
 React Query Hook       # Cache, loading states
-    │
-    ▼
+    |
+    v
 Component              # Render UI
 ```
 
 **Common Mistake**: Service returns different format than hook expects.
 
-### Pattern 2: User Action → State → API → Refetch
+### Pattern 2: User Action -> State -> API -> Refetch
 
 ```
 User clicks button        # UI Layer
-    │
-    ▼
+    |
+    v
 Call mutation hook        # React Query mutation
-    │
-    ▼
+    |
+    v
 API Request               # POST/PATCH/DELETE
-    │
-    ▼
+    |
+    v
 Invalidate queries        # Trigger refetch
-    │
-    ▼
+    |
+    v
 UI updates                # New data rendered
 ```
 

package/dist/templates/markdown/structure/flows/pre-implementation-checklist.md.txt

@@ -6,7 +6,7 @@
 
 ## Why This Checklist?
 
-Most code quality issues aren't caught during implementation—they're **designed in** from the start:
+Most code quality issues aren't caught during implementation--they're **designed in** from the start:
 
 | Problem | Root Cause | Cost |
 |---------|------------|------|
@@ -25,15 +25,15 @@ Most code quality issues aren't caught during implementation—they're **designe
 Before adding any constant or config value:
 
 - [ ] **Cross-layer usage?** Will this value be used in both frontend and backend?
-  - If yes → Put in shared constants file
+  - If yes -> Put in shared constants file
   - Example: Batch size used by backend sync AND frontend threshold check
 
 - [ ] **Multiple consumers?** Will this value be used in 2+ files within the same layer?
-  - If yes → Put in a shared constants file for that layer
+  - If yes -> Put in a shared constants file for that layer
   - Example: Don't define `DEBOUNCE_MS = 2000` in each hook file
 
 - [ ] **Magic number?** Is this a hardcoded value that could change?
-  - If yes → Extract to named constant with comment explaining why
+  - If yes -> Extract to named constant with comment explaining why
   - Example: `BATCH_SIZE: 15  // API limit constraint`
 
 ### 2. Logic & Patterns
@@ -48,18 +48,18 @@ Before implementing any logic:
   ```
 
 - [ ] **Will repeat?** Will this exact logic be needed in 2+ places?
-  - If yes → Create a shared hook/utility **first**, then use it
+  - If yes -> Create a shared hook/utility **first**, then use it
   - Don't copy-paste and plan to refactor later
 
 - [ ] **Callback pattern?** Does the logic need optional callbacks (onStart, onComplete, onError)?
-  - If yes → Design the abstraction with callback support from the start
+  - If yes -> Design the abstraction with callback support from the start
 
 ### 3. Types & Interfaces
 
 Before defining types:
 
 - [ ] **Cross-layer type?** Is this type used across API boundary?
-  - If yes → Define in shared types location
+  - If yes -> Define in shared types location
   - Never duplicate type definitions between frontend and backend
 
 - [ ] **Existing type?** Does a similar type already exist?
@@ -73,7 +73,7 @@ Before creating UI components:
   - Example: If items show priority icons in a specific order, sorting logic should use the same order
 
 - [ ] **State lifecycle?** Will this component unmount during normal user flow?
-  - If yes → Consider where state should persist (parent, context, store)
+  - If yes -> Consider where state should persist (parent, context, store)
 
 ---
 
@@ -81,21 +81,21 @@ Before creating UI components:
 
 ```
 Adding a value/constant?
-├── Used in frontend AND backend? → Shared constants
-├── Used in 2+ files in same layer? → Layer-specific shared constants
-└── Single file only? → Local constant is fine
+|-- Used in frontend AND backend? -> Shared constants
+|-- Used in 2+ files in same layer? -> Layer-specific shared constants
+\-- Single file only? -> Local constant is fine
 
 Adding logic/behavior?
-├── Similar pattern exists? → Extend or reuse existing
-├── Will be used in 2+ places? → Create shared hook/utility first
-└── Single use only? → Implement directly (but document pattern)
+|-- Similar pattern exists? -> Extend or reuse existing
+|-- Will be used in 2+ places? -> Create shared hook/utility first
+\-- Single use only? -> Implement directly (but document pattern)
 ```
 
 ---
 
 ## Anti-Patterns to Avoid
 
-### ❌ Copy-Paste-Modify
+### [X] Copy-Paste-Modify
 
 ```typescript
 // DON'T: Same logic in multiple files
@@ -107,7 +107,7 @@ const triggerSync = useCallback(() => {
 }, []);
 ```
 
-### ✅ Shared Abstraction
+### [OK] Shared Abstraction
 
 ```typescript
 // DO: Single source of truth
@@ -119,7 +119,7 @@ export function useSyncTrigger(options) { /* logic once */ }
 const triggerSync = useSyncTrigger({ workspaceId });
 ```
 
-### ❌ Local Constant Aliases
+### [X] Local Constant Aliases
 
 ```typescript
 // DON'T: Create local aliases for imported constants
@@ -127,7 +127,7 @@ import { CONSTANTS } from "@shared/constants";
 const DEBOUNCE_MS = CONSTANTS.DEBOUNCE_MS;  // Unnecessary!
 ```
 
-### ✅ Direct Usage
+### [OK] Direct Usage
 
 ```typescript
 // DO: Use imported constants directly
@@ -171,7 +171,7 @@ setTimeout(fn, CONSTANTS.DEBOUNCE_MS);
 |-------|--------|
 | Same constant duplicated in 5+ hooks | Always ask "will this constant be used elsewhere?" before defining |
 | Same logic copied multiple times | If logic will repeat, create abstraction **before** first use |
-| Created local aliases for imported constants | Never create local aliases—use imported constants directly |
+| Created local aliases for imported constants | Never create local aliases--use imported constants directly |
 
 ---