@sandrinio/vdoc 3.7.0 → 3.7.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sandrinio/vdoc",
3
- "version": "3.7.0",
3
+ "version": "3.7.1",
4
4
  "description": "Documentation skills for AI coding agents",
5
5
  "type": "module",
6
6
  "bin": {
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -10,6 +10,7 @@ Use the user's description to find the relevant source files:
10
10
  2. Otherwise, search the codebase with Glob and Grep to find files matching the user's description
11
11
  3. Read ALL relevant source files — not just the main file, but helpers, types, middleware, tests, API routes, components
12
12
  4. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
13
+ 5. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
13
14
 
14
15
  Do not skim. Understand how the feature actually works before writing.
15
16
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95
 
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
85
85
 
86
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
87
87
  2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
88
- 3. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
89
- 4. Confirm the file was written before moving to the next doc
88
+ 3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
89
+ 4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
90
+ 5. Confirm the file was written before moving to the next doc
90
91
 
91
- Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
92
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
92
93
 
93
94
  **Writing rules:**
94
95