@jakkrichm/create-nexus-devflow 2.0.10 → 2.0.12

package/bin/create-nexus-devflow.js

@@ -256,17 +256,29 @@ async function confirmUpdateConflicts(prepared, options) {
   return answer.trim().toLowerCase() === "y";
 }
 
+function printNextSteps() {
+  console.log("\nNext steps in your AI IDE (Antigravity, Claude Code, Codex, etc.):");
+  console.log("  1. Project Setup & Baseline:");
+  console.log("     - Existing project : Run `/adopt` (or `$adopt`) to scan codebase and bootstrap context.");
+  console.log("     - Fresh project    : Run `/onboard` (or `$onboard`) to configure project baseline.");
+  console.log("  2. System Health & CI:");
+  console.log("     - Health check     : Run `/doctor` (or `$doctor`) to verify adapters and setup.");
+  console.log("     - CI configuration : Run `/ci` (or `$ci`) to setup GitHub Actions workflow.");
+  console.log("  3. Delivery Flow:");
+  console.log("     - Interactive guide: Run `/devflow` (or `$devflow`) for state & routing assistance.");
+  console.log("     - Start new work   : Run `/00-discover` (or `$00-discover`) to begin delivery lifecycle.");
+}
+
 function printInstallSuccess(targetDir, result, options) {
   console.log("\nNexus-DevFlow overlay successfully installed!");
   console.log(`Applied ${result.appliedCount} file(s).`);
-  console.log("\nNext steps:");
-  console.log("  1. Open your project in your AI IDE (Antigravity, Codex, Claude Code, etc.)");
-  console.log("  2. Run `/00-Discover` or `/help` to start your DevFlow workspace workflow.");
+  printNextSteps();
 }
 
 function printUpdateSuccess(prepared, result) {
   console.log("\nNexus-DevFlow update successfully applied!");
   console.log(`Applied ${result.appliedCount} file(s), removed ${result.removedCount} orphaned file(s).`);
+  printNextSteps();
 }
 
 main().catch((err) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jakkrichm/create-nexus-devflow",
-  "version": "2.0.10",
+  "version": "2.0.12",
   "description": "Installer package for Nexus-DevFlow agentic workflow layer.",
   "license": "MIT",
   "author": "Jakkrich",

package/template/.agents/skills/50-verify/SKILL.md

@@ -65,21 +65,21 @@ Read:
 
 Run the necessary validation for the current state before doing the full review.
 
-### 3. QA Review
+### 3. QA Review & Findings Ledger Verification
 
-Use the old QA reviewer discipline, adapted to 2.0:
+Use the senior QA reviewer discipline, adapted to DevFlow 2.0 and Blueprint quality gates:
 
 - **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
+- **EMPIRICAL PROOF CONTRACT (หลักฐานเชิงประจักษ์)**: ห้ามเคลมว่า "ผ่าน" หรือ "ทำงานได้" โดยไม่มีหลักฐานรูปธรรม — ต้องระบุ Command, Test Output, Route, Screenshot, หรือ Log จริงที่พิสูจน์ผลลัพธ์
+- **FINDINGS LEDGER STATE MACHINE (`findings.md`)**:
+  - ตรวจสอบ `devflow/context/findings.md`
+  - ตรวจสอบสถานะ: `open` ➔ `fixed` ➔ `closed` (เฉพาะการตรวจซ้ำใน `50-verify` เท่านั้นที่สามารถเลื่อนสถานะ `fixed` เป็น `closed` ได้)
+  - **P0/P1 HARD GATE**: หากพบ Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ที่ยังไม่ได้ถูกแก้ไข/ตรวจซ้ำ ให้ตัดสินเป็น FAIL ทันที
+- **MANUAL TRY GUIDE**: สรุปขั้นตอนการทดสอบด้วยมือสำหรับมนุษย์ (Where to go, What to click, What to expect) ไว้อย่างชัดเจน
 - compare claimed implementation evidence against the spec, plan, diff, and test decisions before forming a verdict
-- correctness
-- readability
-- architecture (DIP, SRP, Loose Coupling)
-- security
-- performance
+- correctness, readability, architecture (DIP, SRP, Loose Coupling), security, and performance
 - test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
-- test decision alignment
-- manual verification gaps
-- assumptions and scope discipline
+- test decision alignment and scope discipline
 
 Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
 

package/template/.agents/skills/60-report/SKILL.md

@@ -87,8 +87,9 @@ Explain:
 - what problem was addressed
 - what direction was chosen
 - what was implemented
-- how it was verified
+- how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
 - how checklist progress moved across the run
+- **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
 - what approval or review state remained at each important gate
 - what the release recommendation is
 - what follow-up items still exist

package/template/.agents/skills/70-release/SKILL.md

@@ -64,6 +64,20 @@ Run release as a readiness-packaging loop, not as a celebratory summary.
 - **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.
 - **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.
 
+### 0. Step 0 Safety Pass & Findings Ledger Gate
+
+Before packaging, merging, or releasing:
+
+1. **Findings Ledger Blockers**:
+   - ตรวจสอบ `devflow/context/findings.md`
+   - ต้องไม่มี Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ค้างอยู่
+   - สถานะ `fixed` ยังคงบล็อก release เสมอจนกว่าจะผ่านการ Review ใน `50-verify` เพื่อเลื่อนเป็น `closed`
+2. **2-Stage Approval Separation**:
+   - การขออนุมัติ Merge เข้า `main` หรือ `master` เป็นการอนุมัติขั้นแรก
+   - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
+3. **Archive Resolved Findings**:
+   - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
+
 ### 1. Load Verified Context
 
 Read:
@@ -72,6 +86,7 @@ Read:
 - `50-verify.md`
 - `40-implement.md`
 - `20-spec.md`
+- `devflow/context/findings.md`
 - any PR, deploy, merge, or handoff notes already captured
 
 ### 2. Package The Release Outcome
@@ -81,6 +96,7 @@ Summarize:
 - what is being delivered
 - what changed in user or system terms
 - what state the work is in for PR, deploy, merge, or handoff
+- resolved and archived findings
 - what follow-up items remain
 
 ### 3. Write `70-release.md`
@@ -94,15 +110,18 @@ Prefer clear release-note style wording:
 - what changed
 - what was fixed
 - what is intentionally deferred
+- archived findings summary
 
-### 4. Confirm Readiness
+### 4. Confirm Readiness & 2-Stage Execution
 
 If release readiness changes because unresolved issues are found:
 
 - route back to `50-verify` or `40-implement`
 
 Do not package unfinished work as release-ready through wording tricks.
-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.
+When executing git operations:
+1. Obtain explicit user confirmation before merging.
+2. Obtain separate explicit user confirmation before running `git push` or deployment.
 
 ### 5. Manual Review Soft Gate
 

package/template/.claude/skills/50-verify/SKILL.md

@@ -65,21 +65,21 @@ Read:
 
 Run the necessary validation for the current state before doing the full review.
 
-### 3. QA Review
+### 3. QA Review & Findings Ledger Verification
 
-Use the old QA reviewer discipline, adapted to 2.0:
+Use the senior QA reviewer discipline, adapted to DevFlow 2.0 and Blueprint quality gates:
 
 - **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
+- **EMPIRICAL PROOF CONTRACT (หลักฐานเชิงประจักษ์)**: ห้ามเคลมว่า "ผ่าน" หรือ "ทำงานได้" โดยไม่มีหลักฐานรูปธรรม — ต้องระบุ Command, Test Output, Route, Screenshot, หรือ Log จริงที่พิสูจน์ผลลัพธ์
+- **FINDINGS LEDGER STATE MACHINE (`findings.md`)**:
+  - ตรวจสอบ `devflow/context/findings.md`
+  - ตรวจสอบสถานะ: `open` ➔ `fixed` ➔ `closed` (เฉพาะการตรวจซ้ำใน `50-verify` เท่านั้นที่สามารถเลื่อนสถานะ `fixed` เป็น `closed` ได้)
+  - **P0/P1 HARD GATE**: หากพบ Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ที่ยังไม่ได้ถูกแก้ไข/ตรวจซ้ำ ให้ตัดสินเป็น FAIL ทันที
+- **MANUAL TRY GUIDE**: สรุปขั้นตอนการทดสอบด้วยมือสำหรับมนุษย์ (Where to go, What to click, What to expect) ไว้อย่างชัดเจน
 - compare claimed implementation evidence against the spec, plan, diff, and test decisions before forming a verdict
-- correctness
-- readability
-- architecture (DIP, SRP, Loose Coupling)
-- security
-- performance
+- correctness, readability, architecture (DIP, SRP, Loose Coupling), security, and performance
 - test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
-- test decision alignment
-- manual verification gaps
-- assumptions and scope discipline
+- test decision alignment and scope discipline
 
 Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
 

package/template/.claude/skills/60-report/SKILL.md

@@ -87,8 +87,9 @@ Explain:
 - what problem was addressed
 - what direction was chosen
 - what was implemented
-- how it was verified
+- how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
 - how checklist progress moved across the run
+- **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
 - what approval or review state remained at each important gate
 - what the release recommendation is
 - what follow-up items still exist

package/template/.claude/skills/70-release/SKILL.md

@@ -64,6 +64,20 @@ Run release as a readiness-packaging loop, not as a celebratory summary.
 - **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.
 - **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.
 
+### 0. Step 0 Safety Pass & Findings Ledger Gate
+
+Before packaging, merging, or releasing:
+
+1. **Findings Ledger Blockers**:
+   - ตรวจสอบ `devflow/context/findings.md`
+   - ต้องไม่มี Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ค้างอยู่
+   - สถานะ `fixed` ยังคงบล็อก release เสมอจนกว่าจะผ่านการ Review ใน `50-verify` เพื่อเลื่อนเป็น `closed`
+2. **2-Stage Approval Separation**:
+   - การขออนุมัติ Merge เข้า `main` หรือ `master` เป็นการอนุมัติขั้นแรก
+   - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
+3. **Archive Resolved Findings**:
+   - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
+
 ### 1. Load Verified Context
 
 Read:
@@ -72,6 +86,7 @@ Read:
 - `50-verify.md`
 - `40-implement.md`
 - `20-spec.md`
+- `devflow/context/findings.md`
 - any PR, deploy, merge, or handoff notes already captured
 
 ### 2. Package The Release Outcome
@@ -81,6 +96,7 @@ Summarize:
 - what is being delivered
 - what changed in user or system terms
 - what state the work is in for PR, deploy, merge, or handoff
+- resolved and archived findings
 - what follow-up items remain
 
 ### 3. Write `70-release.md`
@@ -94,15 +110,18 @@ Prefer clear release-note style wording:
 - what changed
 - what was fixed
 - what is intentionally deferred
+- archived findings summary
 
-### 4. Confirm Readiness
+### 4. Confirm Readiness & 2-Stage Execution
 
 If release readiness changes because unresolved issues are found:
 
 - route back to `50-verify` or `40-implement`
 
 Do not package unfinished work as release-ready through wording tricks.
-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.
+When executing git operations:
+1. Obtain explicit user confirmation before merging.
+2. Obtain separate explicit user confirmation before running `git push` or deployment.
 
 ### 5. Manual Review Soft Gate