@jakkrichm/create-nexus-devflow 2.0.20 → 2.0.22

package/template/.agents/skills/00-discover/SKILL.md

@@ -30,31 +30,11 @@ Use this when:
 Write the primary discovery artifact to:
 
 ```text
-devflow/discoveries/{DISCOVERY_ID}-{slug}00-discover.md
+devflow/discoveries/{DISCOVERY_ID}-{slug}/00-discover.md
 ```
 
-using:
-
-```text
-.agent/resources/schemas/discover.template.md
-```
-
-Before writing `00-discover.md`, read `artifact_language` from `discover.template.md` and produce the artifact in that language.
-
 A Discovery ID uses a separate namespace such as `DISC-YYYYMMDD-NNN`. It is not a Running ID and must not reserve a numeric delivery run.
 
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
 ## Process
 
 ### Loop Contract
@@ -62,111 +42,43 @@ Before completing any generated artifact:
 Run discovery as a decision-and-routing loop, not as task initialization.
 
 - **Intent**: understand the request, select proportionate supporting inquiry, and decide whether the idea should enter delivery definition.
-- **Context**: read the request, the discovery artifact when resuming, companion outputs, project context, constraints, and available evidence.
+- **Context**: read the request, discovery artifact when resuming, project context, constraints, and available evidence.
 - **Action**: restate the problem, identify the decision-blocking uncertainty, select `Brainstorm`, `PRD`, `Research`, `Debug`, or direct decision, then synthesize returned findings.
 - **Observation**: use concrete evidence such as option tradeoffs, product framing, research results, root cause, stakeholder constraints, open questions, and visible risk.
-- **Adjustment**: invoke only the companion route needed to resolve the current uncertainty; every companion invoked by Discover must return to this Discovery ID for synthesis.
 - **Stop Condition**: stop when the selected route and evidence are recorded, open questions are visible, and the decision is `Proceed`, `Defer`, or `Reject`.
-- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`. `Defer` and `Reject` end without allocating a Running ID.
-
-### 1. Create Or Resume The Discovery
-
-- inspect `devflow/discoveries/`
-- create a collision-free Discovery ID or resume the one supplied
-- generate a stable slug
-- do not inspect or increment numeric Running IDs during this stage
-
-### 2. Ground The Request
-
-- restate the request in plain language
-- identify the affected users, stakeholders, or systems
-- capture known constraints and decision-blocking unknowns
-- distinguish an idea worth exploring from delivery work already approved elsewhere
-
-### 3. Select The Supporting Route
-
-Choose proportionally:
-
-- `Brainstorm` when several viable directions need comparison
-- `PRD` when user value, product outcomes, MVP boundaries, or success measures need framing
-- `Research` when facts, codebase evidence, feasibility, or external constraints are missing
-- `Debug` when the request begins with a failure and root cause is unknown
-- direct decision when the request and evidence are already clear
-
-Routes are not mutually exclusive, but do not stack them by default. Record why each selected route is necessary. Pass the Discovery ID to the companion and require its output to link back to the discovery.
-
-### 4. Synthesize Returned Findings
-
-After each companion route:
-
-- update `00-discover.md` with the durable findings and source path
-- reassess whether another route is materially necessary
-- return to the Discover decision rather than jumping directly to `10-define`
-
-### 5. Decide
+- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`.
+
+### 1. Supporting Routes & Built-in Lenses
+
+1. **Brainstorming Lens (Divergent & Convergent)**:
+   - Formulate 2-3 viable options.
+   - Construct a **Trade-off Comparison Table**:
+     | Option | Pros | Cons | Recommendation |
+     | :--- | :--- | :--- | :--- |
+2. **Research & Empirical Proof Lens**:
+   - Inspect existing codebase patterns with search tools (`grep_search`, `rg`).
+   - Conduct external web search if library feasibility or API contracts are uncertain.
+   - Record verifiable empirical facts.
+3. **PRD & Scoping Lens**:
+   - Problem Statement & Target User Persona.
+   - Core User Stories (`As a... I want to... So that...`).
+   - In-Scope vs. Out-of-Scope boundaries.
+4. **Issue & Bug Triage Lens**:
+   - Classify severity (`Critical/Blocker`, `Major`, `Minor`).
+   - Determine whether root-cause analysis (`debug`) is required before spec.
+
+### 2. Decision & Approval Gate
 
 Set one decision:
-
 - `Proceed`: enough value and evidence exist to define delivery work
 - `Defer`: the idea remains relevant but timing, evidence, or ownership is not ready
 - `Reject`: the idea should not proceed under the current framing
 
-Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `10-define`.
-
-### 6. Write `00-discover.md`
-
-- preserve the template headings
-- follow the configured `artifact_language`
-- replace placeholders with concrete context
-- record selected routes, returned findings, open questions, decision, and rationale
-- keep `related_runs` empty until `10-define` materializes approved slices
-
-### 7. Manual Review Gate
-
-Before `10-define`:
-
-- confirm the selected route and evidence are sufficient
-- confirm the decision is `Proceed`
-- set `Approval Status` to `Approved`
-
-Do not allocate Running IDs when the decision or approval is pending.
+### 3. Write `00-discover.md`
 
-## Output
-
-Report:
-
-- Discovery ID and artifact path
-- request and problem summary
-- selected support route and why
-- important findings and open questions
-- `Proceed`, `Defer`, or `Reject` decision
-- recommended next step, including `10-define {discovery_id}` only when Proceed is approved
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline discovery stage
-- Previous state: request intake
-- Next state: `10-define {discovery_id}` only after approved Proceed
-- Common companion routes: `Brainstorm`, `PRD`, `Research`, `Debug`
-- Running ID lifecycle: begins in `10-define`, not in Discover
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/discover.template.md`
+Record selected routes, returned findings, open questions, decision, and rationale.
 
 ## Next Workflow Recommendation
 
-- **Primary**: the selected companion route, or `10-define {discovery_id}` after approved Proceed
-- **Alternatives**:
-  - `Brainstorm {discovery_id}` for unresolved options
-  - `PRD {discovery_id}` for product framing
-  - `Research {discovery_id}` for missing evidence
-  - `Debug {discovery_id}` for unknown root cause
-  - no next command when the decision is Defer or Reject
-
-## Nexus Event
-
-- Use `grill-with-docs` when focused clarification could change the decision or selected route.
-- Use `prototype` when runnable evidence is the fastest way to settle feasibility.
+- **Primary**: `10-define {discovery_id}` only after approved Proceed
+- **Defer/Reject**: No next command needed

package/template/.agents/skills/40-execute/SKILL.md

@@ -76,7 +76,7 @@ Use the original coder discipline, adapted to 2.0:
 
 If tests are `Required`:
 
-1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางของ [test-driven-development](file:///.agents/skills/test-driven-development/SKILL.md)
+1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางใน [coding-standards.md](file:///devflow/context/coding-standards.md)
 2. **GREEN**: เขียนโค้ดระบบจริงให้สอดคล้องเพื่อให้เทสต์ผ่าน
 3. **REFACTOR**: ปรับปรุงโครงสร้างโค้ดโดยยังคงรันเทสต์ผ่านอย่างต่อเนื่อง
 

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

@@ -2,9 +2,10 @@
 name: 50-verify
 description: "[Devflow] Verify stage in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement."
 ---
+
 # Phase 50: Verify Quality
 
-Review implementation quality, run validation, produce a verification report, and route the task forward or back to implementation.
+Review implementation quality, run multi-lane validation, produce a verification report, and route the task forward or back to implementation.
 
 ## Usage
 
@@ -16,173 +17,39 @@ Review implementation quality, run validation, produce a verification report, an
 
 Use `50-verify.md` as the primary verification artifact.
 Use `50-verify-impact.md` as an optional companion artifact when the run changes behavior, touches core logic, crosses integration boundaries, or needs explicit rollback and client impact analysis.
-Before writing either verification artifact, read `artifact_language` from the matching template and produce the markdown output in that language.
-
-Use these commands only to keep workflow status aligned with the task engine:
-
-Record verification start, results, open issues, and approval direction directly in `50-verify.md`. Use the stage markdown itself to indicate whether the work is ready for human review or needs to return to implementation.
-If an impact report is needed, create it in the same task directory and summarize its conclusions from `50-verify.md`.
-Keep the verification checklist aligned with the same soft-gate state so downstream report and release stages can see the current approval direction without re-reading the full verify narrative.
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
-## Process
-
-### Loop Contract
-
-Run verification as an evidence review loop, not as a single pass/fail guess.
-
-- **Intent**: decide whether the implementation satisfies the spec and plan without introducing unacceptable regression risk.
-- **Context**: read `20-spec.md`, `30-plan.md`, `40-execute.md`, checklist state, changed files, test decisions, and available command/manual evidence.
-- **Action**: run or inspect validation, compare implementation evidence against the contract, review risk areas, and record findings by severity.
-- **Observation**: use concrete evidence from test output, validation output, diff review, manual checks, skipped checks, and impact notes.
-- **Adjustment**: if evidence is missing or failing, request targeted implementation follow-up, route to `Debug`, or return to `40-execute` with the exact evidence gap.
-- **Stop Condition**: stop only with a clear verdict: pass, fail, or blocked; include the evidence, residual risks, and next route.
-- **Handoff**: `50-verify.md` must tell `60-report` why the work is ready, or tell `40-execute` exactly what must change before verification resumes.
-
-### 1. Context Gathering
-
-Read:
 
-- `20-spec.md`
-- `30-plan.md`
-- `40-execute.md`
-- `checklists/verification-checklist.md` when present
-- changed files
-- test output, command output, screenshots, or manual-check evidence
+## Process & Quality Gates
 
-### 2. Artifact Gate
+### 1. Senior QA Review & Multi-Lane Verification
 
-Run the necessary validation for the current state before doing the full review.
-
-### 3. QA Review & Findings Ledger Verification
-
-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, and performance
-- test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
-- test decision alignment and scope discipline
-
-Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
-
-For test-decision alignment, verify that planned verification was actually executed and that the evidence matches the claimed result.
-Use `review` for a two-axis standards/spec review, `diagnosing-bugs` when a failure needs root cause analysis, and `silent-failure-audit` when the risk is false-positive success.
-
-### 4. Verification Report
-
-Create or update `50-verify.md` in the task directory.
-Create or update `50-verify-impact.md` when the run includes behavior changes, client-facing flow changes, integration risk, or rollback considerations worth reviewing separately.
-
-Base the structure on:
-
-```text
-.agent/resources/schemas/verify.template.md
-.agent/resources/schemas/verify-impact.template.md
-```
+Execute verification across all essential quality dimensions:
 
-Before reporting completion, validate the markdown and replace all placeholders with concrete command output, manual checks, failures, screenshots, and residual risks.
-Follow the `artifact_language` configured in the selected template for both `50-verify.md` and `50-verify-impact.md`.
+1. **Lane 1: Typecheck & Static Code Quality**:
+   - Run typecheck and static analysis (`tsc --noEmit`, `npm run lint`).
+2. **Lane 2: Automated Test Suites (TDD Gate)**:
+   - Run automated unit and integration tests (`npm test`).
+   - Confirm 100% test pass rate with zero disabled or skipped tests.
+3. **Lane 3: Scrutinize QA & Edge Cases Review**:
+   - **Boundary Conditions**: Check empty inputs, 0/1 counts, off-by-one errors.
+   - **Null / Undefined Safety**: Verify nullish handling and strict type invariants.
+   - **Error Handling & Propagation**: Verify errors provide actionable diagnostics without swallowing.
+4. **Lane 4: Security & Hygiene Audit**:
+   - **Secrets Check**: Ensure no hardcoded credentials or API keys exist.
+   - **Input Sanitization**: Ensure parameterized queries and validated inputs.
+5. **Lane 5: Findings Ledger State Machine (`findings.md`)**:
+   - Inspect `devflow/context/findings.md`.
+   - **P0/P1 HARD GATE**: Any Finding of severity `P0` or `P1` in `open` or `fixed` status unconditionally blocks pass.
+6. **Lane 6: Manual Scenario Proof**:
+   - Provide clear manual verification instructions: "Where to go", "What to run/click", "What to expect".
 
-Include:
+### 2. Decision & Route
 
-- verdict: pass or fail
-- evidence: commands and results
-- loop observation, adjustment, stop condition, and handoff notes
-- test-decision alignment
-- checklist alignment and any stale status corrections
-- approval gate summary copied into the verification checklist when relevant
-- findings grouped by severity
-- manual checks required
-- recommended next action
-- impact report summary or explicit note that no impact report was needed
-
-### 5. Decision
-
-**STRICT GATING (CRITICAL FAIL)**: หากพบว่าไม่มีการสร้าง/แก้ไข Unit Test ตามกฎ Unit Test Mandate หรือรันเทสต์แล้วไม่ผ่านทั้งหมด **บังคับให้ตัดสินเป็น FAIL ทันที**
-
-If pass:
-
-- route to `60-report`
-
-If fail:
-
-- route back to `40-execute` with exact failed evidence, missing checks, or required changes
-
-Use `Debug` when investigation is needed before implementation can resume.
-
-### 6. Manual Review Soft Gate
-
-Verification is the main human review checkpoint for implemented work.
-If the evidence is incomplete or `Approval Status` remains pending:
-
-- warn that release is not yet ready for confident handoff
-- recommend additional review or a return to `40-execute`
-- keep `60-report` as a soft recommendation only
+- **Pass**: Route to `60-report {ID}`.
+- **Fail**: Route back to `40-execute {ID}` with exact failure evidence and remediation steps.
 
 ## Output
 
 Report:
-
-- QA verdict
-- key findings
-- commands run
-- validation status
-- impact and rollback analysis when `50-verify-impact.md` is present
-- next command: `60-report {ID}` if pass, or `40-execute {ID}` if fail
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `40-execute`
-- Next state: `60-report` when evidence is sufficient
-- Common companion commands: `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `Wiki`
-- Support skills: `review`, `diagnosing-bugs`, `tdd`, and `silent-failure-audit` for focused verification lanes
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/verify.template.md`
-- `.agent/resources/schemas/verify-impact.template.md`
-- Related commands: `40-execute`, `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `60-report`
-
-## Next Workflow Recommendation
-
-- **Primary**: `60-report {ID}` when verification passes, or `40-execute {ID}` when verification fails.
-- **Why**: Verification decides whether work moves forward to the final report stage or loops back for fixes.
-- **Alternatives**:
-  - `Debug` - choose this when the failure needs root cause analysis before more implementation.
-  - `review` - choose this when changed work needs standards and spec review as separate axes.
-  - `Wiki project ingest devflow/runs/{ID}-*50-verify.md` - choose this when verification reveals reusable project knowledge.
-
-## Nexus Event
-
-- Use `Debug` when failures need deeper investigation before rework.
-- Use `PR-Review`, `QA-Orchestrate`, or `Agent code-reviewer` when a narrower review lane would change the verification decision quality.
-- Use `Wiki` when verified findings should become reusable project knowledge before the run continues.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when QA confirms a reusable lesson, regression pattern, manual check, or validation command.
-- **Scope**: `project` unless QA reveals a DevFlow framework rule.
-- **Reason**: Verified QA evidence is one of the safest sources for project wiki updates.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*50-verify.md`
-
+- QA verdict across all verification lanes
+- Evidence commands and outputs
+- Next command: `60-report {ID}` (if pass) or `40-execute {ID}` (if fail)

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

@@ -1,6 +1,6 @@
 ---
 name: 60-report
-description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown and HTML summary report for the completed run."
+description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) so the outcome is easy to communicate every time.
+Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) with retrospective lessons learned, findings summary, and release digest.
 
 ## Usage
 
@@ -21,110 +21,37 @@ Produce the final human-friendly summary of the full running flow in Markdown (`
 Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}/60-report.md
+devflow/context/current-run/60-report.md
 ```
 
-using:
-
-```text
-.agent/resources/schemas/report.template.md
-```
-
-Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
-
 > [!IMPORTANT]
-> **No Auto-Generated HTML**: ยกเลิกการสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากผู้ใช้หรือทีมต้องการสร้าง HTML Report สวยงาม ให้เรียกคำสั่งแยกต่างหาก: `/report:html` หรือ `npm run report:html`
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
+> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากต้องการดู HTML Report ให้เรียกคำสั่งแยก: `/report:html`
 
 ## Process
 
-### Loop Contract
-
-Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
-
-- **Intent**: produce a final markdown summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
-- **Context**: read all relevant stage artifacts, checklist files, verify impact notes, release notes, validation output, and supporting artifacts that materially explain the result.
-- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions.
-- **Observation**: use concrete evidence such as checklist completion, blocked or skipped items, validation results, release state, impact notes, and unresolved follow-ups.
-- **Adjustment**: if evidence is missing, return to the owning stage; if the report must support continuation, use `handoff`; if the run produced reusable lessons, use `insight-capture` or `Wiki`.
-- **Stop Condition**: stop when `60-report.md` exists, summarizes the outcome accurately, includes checklist and evidence snapshots, and names any remaining follow-up work.
-- **Handoff**: `60-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
-
-### 1. Gather Full Run Context
-
+### 1. Gather Full Run Context & Verification Evidence
 Read all relevant stage artifacts:
-
-- the shared `00-discover.md` referenced by `source_discovery` when it materially explains the delivery decision
 - `10-define.md`
 - `20-spec.md`
 - `30-plan.md`
 - `40-execute.md`
 - `50-verify.md`
-- `checklists/implementation-checklist.md` when present
-- `checklists/verification-checklist.md` when present
-
-Include supporting artifacts only when they add real context.
-
-### 2. Summarize The Run
-
-Explain:
-
-- what problem was addressed
-- what direction was chosen
-- what was implemented
-- 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
-
-### 3. Produce Standardized Outputs
-
-Write:
-
-- a readable Markdown report (`60-report.md`) for contributors
-
-Keep checklist summaries and follow-up status inside `60-report.md`.
-
-Both outputs should summarize checklist state when checklist artifacts exist, including:
-
-- completion progress
-- blocked or skipped items
-- notable evidence snapshots
-- approval status, review blockers, and next allowed command when they still matter
-- remaining follow-up work
-
-## Output
-
-Report:
-
-- what the run accomplished
-- checklist completion status and remaining items
-- important remaining follow-ups
-- where `60-report.md` was written
-- standalone HTML command tip: `/report:html` (if HTML view is desired)
 
-## Relationship To DevFlow 2.0
+### 2. Retrospective Lessons Learned & Gotchas (Insight Extraction)
+Extract durable insights from the completed run:
+- **Reusable Patterns**: Design choices or implementations that future runs should mirror.
+- **Gotchas & Pitfalls**: Unforeseen issues or quirks encountered during execution.
+- **Unresolved Follow-ups**: Route any residual out-of-scope ideas to `devflow/ideas.md`.
 
-- Classification: Mainline workflow
-- Previous state: `50-verify`
-- Next state: `70-release` when the summary is aligned and release can proceed
-- Common companion commands: `/report:html` for standalone HTML dashboard, `Wiki` for durable knowledge capture, `Help` for routing or explanation
+### 3. Produce Standardized Report (`60-report.md`)
+Structure the report in **Thai (`th`)**:
+1. **Executive Summary**: ปัญหาและแนวทางแก้ไข
+2. **Delivery Scope**: รายการฟีเจอร์และคอมโพเนนต์ที่ส่งมอบ
+3. **Verification Evidence Snapshot**: ผลการทดสอบทุก Lane
+4. **Retrospective & Lessons Learned**: บทเรียนและข้อควรระวัง
+5. **Manual Try Guide**: ขั้นตอนสำหรับมนุษย์ทดสอบระบบ
 
 ## Next Workflow Recommendation
 
-- **Primary**: `70-release {ID}` after `60-report.md` reflects the verified state clearly.
-- **Optional Standalone HTML**: `/report:html` (or `npm run report:html -- {ID}`) if an interactive HTML report is desired for stakeholder presentation.
-- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues.
+- **Primary**: `70-release {ID}`
+- **Optional Standalone HTML**: `/report:html`

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

@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Package approved work for delivery after the report stage has captured the final verified story. Archives the active run from `devflow/context/current-run/` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}/`, updates `HISTORY.md`, performs git merge, and closes the run.
+Package approved work for delivery after the report stage has captured the final verified story. Archives the active run from `devflow/context/current-run/` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}/`, updates `HISTORY.md` and `CHANGELOG.md`, executes pre-flight smoke checks, performs conventional git commit & merge, and closes the run.
 
 ## Usage
 
@@ -40,14 +40,39 @@ Before packaging, merging, or releasing:
    - Inspect `devflow/context/findings.md`.
    - No Finding of severity `P0` or `P1` in `open` or `fixed` status is permitted.
    - `fixed` still blocks release until reviewed and closed in `50-verify`.
-2. **2-Stage Approval Separation**:
+2. **Pre-flight & Deployment Smoke Validation**:
+   - Verify environment variables and configuration parameters.
+   - Run production build or package smoke check (`npm run build` or `npm run test:package`).
+   - Validate that clean state exists with no untracked experimental files.
+3. **2-Stage Approval Separation**:
    - Consent to merge into `main` is strictly separate from consent to `git push` to remote or deploy.
-3. **Archive Resolved Findings**:
-   - Move resolved findings (`closed`, `accepted`, `invalid`) into release archive notes and clean `findings.md`.
-4. **Archive Run Folder to Categorized History**:
-   - Determine Category (`features`, `fixes`, `rollbacks`).
-   - Move directory `devflow/context/current-run/` (or `devflow/runs/{xxx-slug}/`) ➔ `devflow/history/{category}/{xxx-slug}/`.
-5. **Append to Master History Ledger**:
-   - Append entry to `devflow/history/HISTORY.md` linking to `history/{category}/{xxx-slug}/60-report.md`.
-6. **Update Workspace State**:
-   - Set `devflow/context/current-stage.md` to `Idle`.
+
+### 1. Changelog & SemVer Version Bump
+
+1. Calculate next version according to **Semantic Versioning (SemVer)**:
+   - `Major`: Breaking architectural changes, removed public APIs
+   - `Minor`: New backward-compatible features added
+   - `Patch`: Bug fixes, optimizations, documentation
+2. Append new release entry to `CHANGELOG.md` in [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format (`Added`, `Changed`, `Fixed`, `Removed`, `Security`).
+
+### 2. Conventional Commit & Git Merge
+
+1. Stage all release and tracking files.
+2. Commit with conventional format: `chore(release): release {version}` or `feat({scope}): {summary}`.
+3. Squash-merge to base branch (`main`) with explicit user approval.
+
+### 3. Archive Run Folder to Categorized History
+
+1. Determine Category (`features`, `fixes`, `rollbacks`).
+2. Move directory `devflow/context/current-run/` ➔ `devflow/history/{category}/{xxx-slug}/`.
+3. Clean resolved findings (`closed`, `accepted`, `invalid`) from `devflow/context/findings.md` and append to the release notes.
+4. Append entry to `devflow/history/HISTORY.md` linking to `history/{category}/{xxx-slug}/60-report.md`.
+
+### 4. Update Workspace State
+
+Set `devflow/context/current-stage.md` to:
+- `Active Discovery ID`: `None`
+- `Active Running ID`: `None (Idle)`
+- `Current Stage`: `Idle (Ready for new run)`
+- `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
+- `Last Updated`: `{YYYY-MM-DD}`

package/template/.agents/skills/check/SKILL.md

@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Quality assurance and multi-lane verification stage in Fast-Track. Validates the implementation against Acceptance Criteria, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`devflow/context/current-feature.md`).
+Quality assurance and multi-lane verification stage in Fast-Track. Validates implementation against Acceptance Criteria, executes Scrutinize QA & Security checks, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`devflow/context/current-feature.md`).
 
 ## Invocations & Aliases
 
@@ -31,15 +31,26 @@ When invoked:
 2. Read `devflow/context/current-feature.md`.
 3. Locate `## 1. Specification & Scope` (Acceptance Criteria) and `## 3. Implementation Checklist`.
 
-### 2. Multi-lane Verification Execution
-Execute the verification gates across all lanes:
-1. **Lane 1 (Type & Syntax Safety)**:
+### 2. Multi-lane Verification & Scrutinize QA
+
+Execute verification gates across all lanes:
+
+1. **Lane 1: Typecheck & Static Code Quality**:
    - Run typecheck and linting (e.g. `npm run typecheck`, `npm run lint`).
-2. **Lane 2 (Test Suites & Coverage)**:
+   - Confirm 0 type errors, 0 lint warnings.
+2. **Lane 2: Automated Test Suites (TDD Gate)**:
    - Run automated unit and integration tests (e.g. `npm test`).
-3. **Lane 3 (Manual / Scenario Proof)**:
+   - Confirm 100% tests pass with no disabled/skipped tests.
+3. **Lane 3: Scrutinize & Edge Cases Review**:
+   - **Boundary Conditions**: Check empty collections, 0/1 limits, off-by-one errors.
+   - **Null / Undefined Safety**: Verify optional chaining and nullish coalescing.
+   - **Error Handling & Propagation**: Verify errors are logged and handled without swallow.
+4. **Lane 4: Security & Hygiene Audit**:
+   - **Secrets Check**: No hardcoded API keys, passwords, or tokens in source code.
+   - **Injection & Sanitization**: Ensure inputs are validated and parameterized.
+5. **Lane 5: Manual Scenario Proof**:
    - Verify specific scenarios against Acceptance Criteria (`AC-1`, `AC-2`).
-   - Summarize "Where to go", "What to click/call", and "What to expect".
+   - Provide concrete walkthrough: "Where to go", "What to run/click", "What to expect".
 
 ### 3. Update Living Spec (`current-feature.md`)
 Append or update `## 5. Verification Evidence` in `devflow/context/current-feature.md` in **Thai (`th`)**:
@@ -48,6 +59,7 @@ Append or update `## 5. Verification Evidence` in `devflow/context/current-featu
 ## 5. Verification Evidence
 - **Typecheck & Linter**: Passed (0 errors, 0 warnings)
 - **Automated Test Suites**: All tests passed (e.g. 12/12 passed, 0 failed)
+- **Scrutinize & Security Audit**: Clean (No boundary issues, 0 secrets, safe inputs)
 - **Acceptance Criteria Verification**:
   - [x] AC-1: {ผลการตรวจสอบเงื่อนไขที่ 1 ผ่าน 100%}
   - [x] AC-2: {ผลการตรวจสอบเงื่อนไขที่ 2 ผ่าน 100%}