@jakkrichm/create-nexus-devflow 2.0.10 → 2.0.11

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": "@jakkrichm/create-nexus-devflow",
3
- "version": "2.0.10",
3
+ "version": "2.0.11",
4
4
  "description": "Installer package for Nexus-DevFlow agentic workflow layer.",
5
5
  "license": "MIT",
6
6
  "author": "Jakkrich",
@@ -65,21 +65,21 @@ Read:
65
65
 
66
66
  Run the necessary validation for the current state before doing the full review.
67
67
 
68
- ### 3. QA Review
68
+ ### 3. QA Review & Findings Ledger Verification
69
69
 
70
- Use the old QA reviewer discipline, adapted to 2.0:
70
+ Use the senior QA reviewer discipline, adapted to DevFlow 2.0 and Blueprint quality gates:
71
71
 
72
72
  - **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
73
+ - **EMPIRICAL PROOF CONTRACT (หลักฐานเชิงประจักษ์)**: ห้ามเคลมว่า "ผ่าน" หรือ "ทำงานได้" โดยไม่มีหลักฐานรูปธรรม — ต้องระบุ Command, Test Output, Route, Screenshot, หรือ Log จริงที่พิสูจน์ผลลัพธ์
74
+ - **FINDINGS LEDGER STATE MACHINE (`findings.md`)**:
75
+ - ตรวจสอบ `devflow/context/findings.md`
76
+ - ตรวจสอบสถานะ: `open` ➔ `fixed` ➔ `closed` (เฉพาะการตรวจซ้ำใน `50-verify` เท่านั้นที่สามารถเลื่อนสถานะ `fixed` เป็น `closed` ได้)
77
+ - **P0/P1 HARD GATE**: หากพบ Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ที่ยังไม่ได้ถูกแก้ไข/ตรวจซ้ำ ให้ตัดสินเป็น FAIL ทันที
78
+ - **MANUAL TRY GUIDE**: สรุปขั้นตอนการทดสอบด้วยมือสำหรับมนุษย์ (Where to go, What to click, What to expect) ไว้อย่างชัดเจน
73
79
  - compare claimed implementation evidence against the spec, plan, diff, and test decisions before forming a verdict
74
- - correctness
75
- - readability
76
- - architecture (DIP, SRP, Loose Coupling)
77
- - security
78
- - performance
80
+ - correctness, readability, architecture (DIP, SRP, Loose Coupling), security, and performance
79
81
  - test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
80
- - test decision alignment
81
- - manual verification gaps
82
- - assumptions and scope discipline
82
+ - test decision alignment and scope discipline
83
83
 
84
84
  Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
85
85
 
@@ -87,8 +87,9 @@ Explain:
87
87
  - what problem was addressed
88
88
  - what direction was chosen
89
89
  - what was implemented
90
- - how it was verified
90
+ - how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
91
91
  - how checklist progress moved across the run
92
+ - **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
92
93
  - what approval or review state remained at each important gate
93
94
  - what the release recommendation is
94
95
  - what follow-up items still exist
@@ -64,6 +64,20 @@ Run release as a readiness-packaging loop, not as a celebratory summary.
64
64
  - **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
65
65
  - **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
66
66
 
67
+ ### 0. Step 0 Safety Pass & Findings Ledger Gate
68
+
69
+ Before packaging, merging, or releasing:
70
+
71
+ 1. **Findings Ledger Blockers**:
72
+ - ตรวจสอบ `devflow/context/findings.md`
73
+ - ต้องไม่มี Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ค้างอยู่
74
+ - สถานะ `fixed` ยังคงบล็อก release เสมอจนกว่าจะผ่านการ Review ใน `50-verify` เพื่อเลื่อนเป็น `closed`
75
+ 2. **2-Stage Approval Separation**:
76
+ - การขออนุมัติ Merge เข้า `main` หรือ `master` เป็นการอนุมัติขั้นแรก
77
+ - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
78
+ 3. **Archive Resolved Findings**:
79
+ - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
80
+
67
81
  ### 1. Load Verified Context
68
82
 
69
83
  Read:
@@ -72,6 +86,7 @@ Read:
72
86
  - `50-verify.md`
73
87
  - `40-implement.md`
74
88
  - `20-spec.md`
89
+ - `devflow/context/findings.md`
75
90
  - any PR, deploy, merge, or handoff notes already captured
76
91
 
77
92
  ### 2. Package The Release Outcome
@@ -81,6 +96,7 @@ Summarize:
81
96
  - what is being delivered
82
97
  - what changed in user or system terms
83
98
  - what state the work is in for PR, deploy, merge, or handoff
99
+ - resolved and archived findings
84
100
  - what follow-up items remain
85
101
 
86
102
  ### 3. Write `70-release.md`
@@ -94,15 +110,18 @@ Prefer clear release-note style wording:
94
110
  - what changed
95
111
  - what was fixed
96
112
  - what is intentionally deferred
113
+ - archived findings summary
97
114
 
98
- ### 4. Confirm Readiness
115
+ ### 4. Confirm Readiness & 2-Stage Execution
99
116
 
100
117
  If release readiness changes because unresolved issues are found:
101
118
 
102
119
  - route back to `50-verify` or `40-implement`
103
120
 
104
121
  Do not package unfinished work as release-ready through wording tricks.
105
- Use `resolving-merge-conflicts` when merge or rebase conflicts block packaging. Use `handoff` when release output must transfer to another agent or session without duplicating artifacts.
122
+ When executing git operations:
123
+ 1. Obtain explicit user confirmation before merging.
124
+ 2. Obtain separate explicit user confirmation before running `git push` or deployment.
106
125
 
107
126
  ### 5. Manual Review Soft Gate
108
127
 
@@ -65,21 +65,21 @@ Read:
65
65
 
66
66
  Run the necessary validation for the current state before doing the full review.
67
67
 
68
- ### 3. QA Review
68
+ ### 3. QA Review & Findings Ledger Verification
69
69
 
70
- Use the old QA reviewer discipline, adapted to 2.0:
70
+ Use the senior QA reviewer discipline, adapted to DevFlow 2.0 and Blueprint quality gates:
71
71
 
72
72
  - **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
73
+ - **EMPIRICAL PROOF CONTRACT (หลักฐานเชิงประจักษ์)**: ห้ามเคลมว่า "ผ่าน" หรือ "ทำงานได้" โดยไม่มีหลักฐานรูปธรรม — ต้องระบุ Command, Test Output, Route, Screenshot, หรือ Log จริงที่พิสูจน์ผลลัพธ์
74
+ - **FINDINGS LEDGER STATE MACHINE (`findings.md`)**:
75
+ - ตรวจสอบ `devflow/context/findings.md`
76
+ - ตรวจสอบสถานะ: `open` ➔ `fixed` ➔ `closed` (เฉพาะการตรวจซ้ำใน `50-verify` เท่านั้นที่สามารถเลื่อนสถานะ `fixed` เป็น `closed` ได้)
77
+ - **P0/P1 HARD GATE**: หากพบ Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ที่ยังไม่ได้ถูกแก้ไข/ตรวจซ้ำ ให้ตัดสินเป็น FAIL ทันที
78
+ - **MANUAL TRY GUIDE**: สรุปขั้นตอนการทดสอบด้วยมือสำหรับมนุษย์ (Where to go, What to click, What to expect) ไว้อย่างชัดเจน
73
79
  - compare claimed implementation evidence against the spec, plan, diff, and test decisions before forming a verdict
74
- - correctness
75
- - readability
76
- - architecture (DIP, SRP, Loose Coupling)
77
- - security
78
- - performance
80
+ - correctness, readability, architecture (DIP, SRP, Loose Coupling), security, and performance
79
81
  - test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
80
- - test decision alignment
81
- - manual verification gaps
82
- - assumptions and scope discipline
82
+ - test decision alignment and scope discipline
83
83
 
84
84
  Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
85
85
 
@@ -87,8 +87,9 @@ Explain:
87
87
  - what problem was addressed
88
88
  - what direction was chosen
89
89
  - what was implemented
90
- - how it was verified
90
+ - how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
91
91
  - how checklist progress moved across the run
92
+ - **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
92
93
  - what approval or review state remained at each important gate
93
94
  - what the release recommendation is
94
95
  - what follow-up items still exist
@@ -64,6 +64,20 @@ Run release as a readiness-packaging loop, not as a celebratory summary.
64
64
  - **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
65
65
  - **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
66
66
 
67
+ ### 0. Step 0 Safety Pass & Findings Ledger Gate
68
+
69
+ Before packaging, merging, or releasing:
70
+
71
+ 1. **Findings Ledger Blockers**:
72
+ - ตรวจสอบ `devflow/context/findings.md`
73
+ - ต้องไม่มี Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ค้างอยู่
74
+ - สถานะ `fixed` ยังคงบล็อก release เสมอจนกว่าจะผ่านการ Review ใน `50-verify` เพื่อเลื่อนเป็น `closed`
75
+ 2. **2-Stage Approval Separation**:
76
+ - การขออนุมัติ Merge เข้า `main` หรือ `master` เป็นการอนุมัติขั้นแรก
77
+ - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
78
+ 3. **Archive Resolved Findings**:
79
+ - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
80
+
67
81
  ### 1. Load Verified Context
68
82
 
69
83
  Read:
@@ -72,6 +86,7 @@ Read:
72
86
  - `50-verify.md`
73
87
  - `40-implement.md`
74
88
  - `20-spec.md`
89
+ - `devflow/context/findings.md`
75
90
  - any PR, deploy, merge, or handoff notes already captured
76
91
 
77
92
  ### 2. Package The Release Outcome
@@ -81,6 +96,7 @@ Summarize:
81
96
  - what is being delivered
82
97
  - what changed in user or system terms
83
98
  - what state the work is in for PR, deploy, merge, or handoff
99
+ - resolved and archived findings
84
100
  - what follow-up items remain
85
101
 
86
102
  ### 3. Write `70-release.md`
@@ -94,15 +110,18 @@ Prefer clear release-note style wording:
94
110
  - what changed
95
111
  - what was fixed
96
112
  - what is intentionally deferred
113
+ - archived findings summary
97
114
 
98
- ### 4. Confirm Readiness
115
+ ### 4. Confirm Readiness & 2-Stage Execution
99
116
 
100
117
  If release readiness changes because unresolved issues are found:
101
118
 
102
119
  - route back to `50-verify` or `40-implement`
103
120
 
104
121
  Do not package unfinished work as release-ready through wording tricks.
105
- Use `resolving-merge-conflicts` when merge or rebase conflicts block packaging. Use `handoff` when release output must transfer to another agent or session without duplicating artifacts.
122
+ When executing git operations:
123
+ 1. Obtain explicit user confirmation before merging.
124
+ 2. Obtain separate explicit user confirmation before running `git push` or deployment.
106
125
 
107
126
  ### 5. Manual Review Soft Gate
108
127