Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245
  1. # Document Project Workflow - Validation Checklist
  2. ## Scan Level and Resumability
  3. - [ ] Scan level selection offered (quick/deep/exhaustive) for initial_scan and full_rescan modes
  4. - [ ] Deep-dive mode automatically uses exhaustive scan (no choice given)
  5. - [ ] Quick scan does NOT read source files (only patterns, configs, manifests)
  6. - [ ] Deep scan reads files in critical directories per project type
  7. - [ ] Exhaustive scan reads ALL source files (excluding node_modules, dist, build)
  8. - [ ] State file (project-scan-report.json) created at workflow start
  9. - [ ] State file updated after each step completion
  10. - [ ] State file contains all required fields per schema
  11. - [ ] Resumability prompt shown if state file exists and is <24 hours old
  12. - [ ] Old state files (>24 hours) automatically archived
  13. - [ ] Resume functionality loads previous state correctly
  14. - [ ] Workflow can jump to correct step when resuming
  15. ## Write-as-you-go Architecture
  16. - [ ] Each document written to disk IMMEDIATELY after generation
  17. - [ ] Document validation performed right after writing (section-level)
  18. - [ ] State file updated after each document is written
  19. - [ ] Detailed findings purged from context after writing (only summaries kept)
  20. - [ ] Context contains only high-level summaries (1-2 sentences per section)
  21. - [ ] No accumulation of full project analysis in memory
  22. ## Batching Strategy (Deep/Exhaustive Scans)
  23. - [ ] Batching applied for deep and exhaustive scan levels
  24. - [ ] Batches organized by SUBFOLDER (not arbitrary file count)
  25. - [ ] Large files (>5000 LOC) handled with appropriate judgment
  26. - [ ] Each batch: read files, extract info, write output, validate, purge context
  27. - [ ] Batch completion tracked in state file (batches_completed array)
  28. - [ ] Batch summaries kept in context (1-2 sentences max)
  29. ## Project Detection and Classification
  30. - [ ] Project type correctly identified and matches actual technology stack
  31. - [ ] Multi-part vs single-part structure accurately detected
  32. - [ ] All project parts identified if multi-part (no missing client/server/etc.)
  33. - [ ] Documentation requirements loaded for each part type
  34. - [ ] Architecture registry match is appropriate for detected stack
  35. ## Technology Stack Analysis
  36. - [ ] All major technologies identified (framework, language, database, etc.)
  37. - [ ] Versions captured where available
  38. - [ ] Technology decision table is complete and accurate
  39. - [ ] Dependencies and libraries documented
  40. - [ ] Build tools and package managers identified
  41. ## Codebase Scanning Completeness
  42. - [ ] All critical directories scanned based on project type
  43. - [ ] API endpoints documented (if requires_api_scan = true)
  44. - [ ] Data models captured (if requires_data_models = true)
  45. - [ ] State management patterns identified (if requires_state_management = true)
  46. - [ ] UI components inventoried (if requires_ui_components = true)
  47. - [ ] Configuration files located and documented
  48. - [ ] Authentication/security patterns identified
  49. - [ ] Entry points correctly identified
  50. - [ ] Integration points mapped (for multi-part projects)
  51. - [ ] Test files and patterns documented
  52. ## Source Tree Analysis
  53. - [ ] Complete directory tree generated with no major omissions
  54. - [ ] Critical folders highlighted and described
  55. - [ ] Entry points clearly marked
  56. - [ ] Integration paths noted (for multi-part)
  57. - [ ] Asset locations identified (if applicable)
  58. - [ ] File organization patterns explained
  59. ## Architecture Documentation Quality
  60. - [ ] Architecture document uses appropriate template from registry
  61. - [ ] All template sections filled with relevant information (no placeholders)
  62. - [ ] Technology stack section is comprehensive
  63. - [ ] Architecture pattern clearly explained
  64. - [ ] Data architecture documented (if applicable)
  65. - [ ] API design documented (if applicable)
  66. - [ ] Component structure explained (if applicable)
  67. - [ ] Source tree included and annotated
  68. - [ ] Testing strategy documented
  69. - [ ] Deployment architecture captured (if config found)
  70. ## Development and Operations Documentation
  71. - [ ] Prerequisites clearly listed
  72. - [ ] Installation steps documented
  73. - [ ] Environment setup instructions provided
  74. - [ ] Local run commands specified
  75. - [ ] Build process documented
  76. - [ ] Test commands and approach explained
  77. - [ ] Deployment process documented (if applicable)
  78. - [ ] CI/CD pipeline details captured (if found)
  79. - [ ] Contribution guidelines extracted (if found)
  80. ## Multi-Part Project Specific (if applicable)
  81. - [ ] Each part documented separately
  82. - [ ] Part-specific architecture files created (architecture-{part_id}.md)
  83. - [ ] Part-specific component inventories created (if applicable)
  84. - [ ] Part-specific development guides created
  85. - [ ] Integration architecture document created
  86. - [ ] Integration points clearly defined with type and details
  87. - [ ] Data flow between parts explained
  88. - [ ] project-parts.json metadata file created
  89. ## Index and Navigation
  90. - [ ] index.md created as master entry point
  91. - [ ] Project structure clearly summarized in index
  92. - [ ] Quick reference section complete and accurate
  93. - [ ] All generated docs linked from index
  94. - [ ] All existing docs linked from index (if found)
  95. - [ ] Getting started section provides clear next steps
  96. - [ ] AI-assisted development guidance included
  97. - [ ] Navigation structure matches project complexity (simple for single-part, detailed for multi-part)
  98. ## File Completeness
  99. - [ ] index.md generated
  100. - [ ] project-overview.md generated
  101. - [ ] source-tree-analysis.md generated
  102. - [ ] architecture.md (or per-part) generated
  103. - [ ] component-inventory.md (or per-part) generated if UI components exist
  104. - [ ] development-guide.md (or per-part) generated
  105. - [ ] api-contracts.md (or per-part) generated if APIs documented
  106. - [ ] data-models.md (or per-part) generated if data models found
  107. - [ ] deployment-guide.md generated if deployment config found
  108. - [ ] contribution-guide.md generated if guidelines found
  109. - [ ] integration-architecture.md generated if multi-part
  110. - [ ] project-parts.json generated if multi-part
  111. ## Content Quality
  112. - [ ] Technical information is accurate and specific
  113. - [ ] No generic placeholders or "TODO" items remain
  114. - [ ] Examples and code snippets are relevant to actual project
  115. - [ ] File paths and directory references are correct
  116. - [ ] Technology names and versions are accurate
  117. - [ ] Terminology is consistent across all documents
  118. - [ ] Descriptions are clear and actionable
  119. ## Brownfield PRD Readiness
  120. - [ ] Documentation provides enough context for AI to understand existing system
  121. - [ ] Integration points are clear for planning new features
  122. - [ ] Reusable components are identified for leveraging in new work
  123. - [ ] Data models are documented for schema extension planning
  124. - [ ] API contracts are documented for endpoint expansion
  125. - [ ] Code conventions and patterns are captured for consistency
  126. - [ ] Architecture constraints are clear for informed decision-making
  127. ## Output Validation
  128. - [ ] All files saved to correct output folder
  129. - [ ] File naming follows convention (no part suffix for single-part, with suffix for multi-part)
  130. - [ ] No broken internal links between documents
  131. - [ ] Markdown formatting is correct and renders properly
  132. - [ ] JSON files are valid (project-parts.json if applicable)
  133. ## Final Validation
  134. - [ ] User confirmed project classification is accurate
  135. - [ ] User provided any additional context needed
  136. - [ ] All requested areas of focus addressed
  137. - [ ] Documentation is immediately usable for brownfield PRD workflow
  138. - [ ] No critical information gaps identified
  139. ## Issues Found
  140. ### Critical Issues (must fix before completion)
  141. -
  142. ### Minor Issues (can be addressed later)
  143. -
  144. ### Missing Information (to note for user)
  145. -
  146. ## Deep-Dive Mode Validation (if deep-dive was performed)
  147. - [ ] Deep-dive target area correctly identified and scoped
  148. - [ ] All files in target area read completely (no skipped files)
  149. - [ ] File inventory includes all exports with complete signatures
  150. - [ ] Dependencies mapped for all files
  151. - [ ] Dependents identified (who imports each file)
  152. - [ ] Code snippets included for key implementation details
  153. - [ ] Patterns and design approaches documented
  154. - [ ] State management strategy explained
  155. - [ ] Side effects documented (API calls, DB queries, etc.)
  156. - [ ] Error handling approaches captured
  157. - [ ] Testing files and coverage documented
  158. - [ ] TODOs and comments extracted
  159. - [ ] Dependency graph created showing relationships
  160. - [ ] Data flow traced through the scanned area
  161. - [ ] Integration points with rest of codebase identified
  162. - [ ] Related code and similar patterns found outside scanned area
  163. - [ ] Reuse opportunities documented
  164. - [ ] Implementation guidance provided
  165. - [ ] Modification instructions clear
  166. - [ ] Index.md updated with deep-dive link
  167. - [ ] Deep-dive documentation is immediately useful for implementation
  168. ---
  169. ## State File Quality
  170. - [ ] State file is valid JSON (no syntax errors)
  171. - [ ] State file is optimized (no pretty-printing, minimal whitespace)
  172. - [ ] State file contains all completed steps with timestamps
  173. - [ ] State file outputs_generated list is accurate and complete
  174. - [ ] State file resume_instructions are clear and actionable
  175. - [ ] State file findings contain only high-level summaries (not detailed data)
  176. - [ ] State file can be successfully loaded for resumption
  177. ## Completion Criteria
  178. All items in the following sections must be checked:
  179. - ✓ Scan Level and Resumability
  180. - ✓ Write-as-you-go Architecture
  181. - ✓ Batching Strategy (if deep/exhaustive scan)
  182. - ✓ Project Detection and Classification
  183. - ✓ Technology Stack Analysis
  184. - ✓ Architecture Documentation Quality
  185. - ✓ Index and Navigation
  186. - ✓ File Completeness
  187. - ✓ Brownfield PRD Readiness
  188. - ✓ State File Quality
  189. - ✓ Deep-Dive Mode Validation (if applicable)
  190. The workflow is complete when:
  191. 1. All critical checklist items are satisfied
  192. 2. No critical issues remain
  193. 3. User has reviewed and approved the documentation
  194. 4. Generated docs are ready for use in brownfield PRD workflow
  195. 5. Deep-dive docs (if any) are comprehensive and implementation-ready
  196. 6. State file is valid and can enable resumption if interrupted