@jakkrichm/create-nexus-devflow 2.2.2 → 2.6.0

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

@@ -1,72 +0,0 @@
----
-name: 70-deliver
-description: "[devflow][D] Deliver stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 70: Deliver
-
-$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` and `CHANGELOG.md`, executes pre-flight smoke checks, performs conventional git commit & merge, and closes the run.
-
-## Usage
-
-```text
-70-deliver {id or workspace path}
-```
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/context/current-run/70-deliver.md
-```
-
-## Process & Quality Gates
-
-### 0. Step 0 Safety Pass & Findings Ledger Gate
-
-Before packaging, merging, or delivering:
-
-1. **Findings Ledger Blockers**:
-   - 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. **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.
-
-### 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/.claude/skills/10-define/SKILL.md

@@ -1,54 +0,0 @@
----
-name: 10-define
-description: "[devflow][D] Define stage in DevFlow 2.0 - turn an approved discovery into a bounded delivery run in context/current-run with stable scope."
-argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
----
-
-# Phase 10: Define
-
-$ARGUMENTS
-
-Convert an approved `Proceed` discovery into a bounded delivery run. Checks the Single Active Run Guardrail, allocates a sequential ID without prefix (`xxx-slug`), and writes `devflow/context/current-run/10-define.md`.
-
-## Usage
-
-```text
-10-define {discovery-id or discovery path}
-10-define {id or run path}
-```
-
-## Markdown-First Contract
-
-For the active delivery run, write:
-
-```text
-devflow/context/current-run/10-define.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/define.template.md
-```
-
-## Process & Quality Gates
-
-### 1. Single Active Run Guardrail (One Thing at a Time)
-1. Inspect `devflow/context/current-stage.md`, `devflow/context/current-feature.md`, and `devflow/context/current-run/`.
-2. If an active uncompleted run exists:
-   - **HALT and reject opening a new define stage**.
-   - Warn the user to complete or close the active run with `/complete` or `70-deliver` first.
-
-### 2. Validate The Discovery Gate
-Require:
-- `Decision: Proceed`
-- `Approval Status: Approved`
-- A resolvable Discovery ID and `discovery.md` (or legacy `00-explore.md`)
-
-### 3. Allocate Sequential ID
-- Inspect `devflow/history/HISTORY.md` and allocate sequential ID without prefix (e.g. `022-{slug}`).
-- Create directory `devflow/context/current-run/` if it does not exist.
-- Write `devflow/context/current-run/10-define.md`.
-- Update `devflow/context/current-stage.md`:
-  - `Active Running ID`: `{ID}`
-  - `Current Stage`: `10-define (Completed -> Ready for 20-spec)`

package/template/.claude/skills/20-spec/SKILL.md

@@ -1,155 +0,0 @@
----
-name: 20-spec
-description: "[devflow][D] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 20: Spec
-
-$ARGUMENTS
-
-Turn the defined work into a specification that is concrete enough for planning and explicit enough to serve as the delivery contract.
-
-## Usage
-
-```text
-20-spec {running-id or workspace path}
-```
-
-Use this when:
-
-- the goal and scope are stable
-- the team needs testable or reviewable requirements
-- planning should not start until the contract is explicit
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/runs/{ID}-{slug}20-spec.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/spec.template.md
-```
-
-Before writing `20-spec.md`, read `artifact_language` from `spec.template.md` and produce the artifact in that language.
-
-## 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 specification as a contract-hardening loop, not as a prose expansion of the definition.
-
-- **Intent**: produce requirements and acceptance criteria that are concrete enough for planning and review.
-- **Context**: read the run's `10-define.md`, follow its `source_discovery` link when original framing matters, and read relevant research, hard constraints, and domain or codebase decisions that shape this run's delivery contract.
-- **Action**: write requirements, acceptance criteria, constraints, and out-of-scope items, then inspect whether each requirement is testable and unambiguous.
-- **Observation**: use concrete evidence such as ambiguous wording, unchecked assumptions, edge cases, missing acceptance criteria, conflicting constraints, and implementation details that are not true constraints.
-- **Adjustment**: if facts are missing, route to `Research`; if requirements need stress-testing, use `grill-with-docs`; if module or interface boundaries affect the contract, use `codebase-design`; if scope is unstable or still contains multiple independently deliverable contracts, return to `10-define` and split the run before continuing.
-- **Stop Condition**: stop when every requirement has checkable acceptance criteria, hard constraints are explicit, out-of-scope items are visible, and `30-plan` can break the work down without inventing intent.
-- **Handoff**: `20-spec.md` must tell `30-plan` what must be delivered, how success will be checked, what constraints cannot move, and what is intentionally excluded.
-
-### 1. Read Definition Artifacts
-
-Read:
-
-- `10-define.md`
-- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
-- research notes if they impose real constraints
-
-### 2. Write The Specification
-
-Define:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- explicit out-of-scope items
-
-The spec should be strong enough that planning can break it into executable units without guessing intent.
-
-### 3. Handle Missing Certainty
-
-If the spec cannot be written confidently:
-
-- call `Research` when facts are missing
-- use `grill-with-docs` when requirements, acceptance criteria, constraints, or out-of-scope items need to be stress-tested against scenarios and domain language
-- use `codebase-design` when requirements imply module boundaries, interface contracts, seams, or testability constraints
-- record assumptions explicitly when they are unavoidable
-
-Do not hide uncertainty inside vague requirement text.
-
-Do not combine sibling Running IDs into one spec. If this run still contains multiple independent acceptance, release, ownership, or context boundaries, stop and return to `10-define {running_id}` for an explicit split.
-
-### 4. Finalize `20-spec.md`
-
-- preserve the template headings
-- follow the `artifact_language` configured in `spec.template.md`
-- replace all placeholders
-- keep implementation details out unless they are true constraints
-- make sure the acceptance criteria can actually be checked
-
-### 5. Manual Review Soft Gate
-
-Before recommending `30-plan`, check whether the delivery contract has been human-reviewed.
-If `Approval Status` is not approved yet:
-
-- warn that planning may drift if the spec is still under review
-- recommend review of requirements, exclusions, and acceptance criteria first
-- keep `30-plan` as a soft recommendation only
-
-## Output
-
-Report:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- out-of-scope items
-- manual review warnings when the contract is still pending
-- recommended next step
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `10-define`
-- Next state: `30-plan` when the contract is implementation-ready
-- Common companion commands: `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate` when product or integration context is still incomplete; support skills: `grill-with-docs`, `domain-modeling`, and `codebase-design` when the spec depends on precise domain language, durable decisions, or module/interface constraints
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/spec.template.md`
-- Related commands: `10-define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `30-plan`
-
-## Next Workflow Recommendation
-
-- **Primary**: `30-plan`
-- **Why**: The specification is now concrete enough to break into executable work.
-- **Alternatives**:
-  - `Research` - choose this when the spec still depends on missing facts.
-  - `grill-with-docs` - choose this when the spec is readable but not yet tough enough to plan from.
-  - `codebase-design` - choose this when interface shape or testability constraints must be settled before planning.
-  - `10-define` - choose this when the scope itself is still unstable.
-
-## Nexus Event
-
-- Use `Research` when a requirement, rule, or integration constraint still lacks evidence.
-- Use `Spec-Research`, `Competitor`, or `PRD` when the contract needs stronger external, product, or market framing before planning.
-- Use `grill-with-docs` when available if clarification could materially change acceptance criteria, edge cases, exclusions, or rules.

package/template/.claude/skills/30-plan/SKILL.md

@@ -1,226 +0,0 @@
----
-name: 30-plan
-description: "[devflow][D] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
----
-# Phase 30: Plan Implementation
-
-**Strict mode: planning only. Do not edit source code in this phase.**
-
-Create a codebase-informed implementation plan using `30-plan.md` as the primary artifact in DevFlow 2.0.
-
-## Usage
-
-```text
-30-plan {ID}
-```
-
-## Markdown-First Contract
-
-Use `30-plan.md` as the main planning artifact.
-
-Use controlled task-engine commands when plan status or subtask tracking must be synchronized:
-
-Record complexity, context, phases, subtasks, and validation notes directly in the stage markdown files for this running ID. Treat `30-plan.md` as the source of truth.
-
-**MANDATORY RULE:** If you create temporary script files (e.g. `.ps1`, `.sh`) to execute multiple compatibility commands in batch, save them inside the task workspace, never in the central `scripts/` directory.
-
-## 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 planning as an evidence loop, not as a one-shot outline.
-
-- **Intent**: produce a plan that lets implementation proceed without guessing scope, files, risks, or verification.
-- **Context**: read the spec, prior stage artifacts, relevant code/docs, existing commands, and any research that constrains execution.
-- **Action**: draft the smallest useful plan, then inspect whether every phase has files, dependencies, risks, verification, and a test decision.
-- **Observation**: use concrete evidence such as file paths, existing patterns, package scripts, validation commands, and unresolved assumptions.
-- **Adjustment**: if evidence is missing, search/read more, recommend `Research` or `Agent codebase-explorer`, split the work, or route back to `20-spec` when the contract is not plan-ready.
-- **Stop Condition**: stop only when phases are ordered, subtasks are scoped, verification is explicit, test decisions are recorded, and any blockers are visible.
-- **Handoff**: `30-plan.md` must give `40-execute` enough context to select one scoped unit and execute it without inventing intent.
-
-### 1. Read Task Artifacts
-
-Read:
-
-- `devflow/runs/{ID}-*20-spec.md`
-- `10-define.md` and the shared `00-explore.md` referenced by `source_discovery` when they help clarify intent
-
-### 2. Assess Complexity
-
-Use the old planning discipline:
-
-- `simple`: 1 phase, 1-3 subtasks
-- `standard`: multiple ordered phases with clear verification
-- `complex`: deeper codebase exploration, possibly specialist help
-
-If architecture or data flow is still unclear, recommend `Research` or `Agent codebase-explorer` before pretending the plan is stable.
-If domain terms, boundaries, or hard-to-reverse design choices are still questionable, use `grill-with-docs` before locking the plan.
-Use `codebase-design` when phases depend on seam placement or module interfaces. Use `tdd` when behavior-change subtasks need red-green-refactor test cases.
-
-### 3. Explore Codebase Patterns
-
-Use fast searches (`rg`, file reads) to find:
-
-- similar implementations
-- entry points
-- config and test commands
-- files likely to change
-- patterns that implementation should mirror
-
-Record important findings in `30-plan.md`. Use legacy context updates only when compatibility tooling still needs them.
-
-### 4. Build The Plan
-
-Use strict planning discipline, keeping `30-plan.md` as the main contract:
-
-- **Atomic Micro-Task Sizing (2–5 Minutes)**: Every subtask must be a small, verifiable unit that can be implemented and reviewed cleanly without context sprawl.
-- record the planning loop evidence: context read, observations, adjustments made, stop condition, and handoff notes
-- add phases in dependency order
-- include explicit files to modify or create (exact file paths)
-- include patterns to follow
-- include verification command or manual check
-- include a test decision for every subtask
-- record assumptions, scope boundaries, and risks explicitly
-
-Each subtask should answer:
-
-- what to change
-- where to change it (exact path)
-- which pattern to follow
-- how to verify it
-- whether automated tests are required, manual, or not required
-
-### 4.1 Strict TDD Task Breakdown & Test Decision Gate
-
-**STRICT MANDATE (กฎเหล็ก Unit Test & TDD)**: สำหรับทุก subtask ที่มีการเพิ่ม แก้ไข หรือเปลี่ยนแปลงการทำงานของโค้ด (Behavior Change) **ต้องระบุเป็น `Required` เสมอ** และต้องย่อยงานเป็น **TDD Triplet Sub-tasks** ดังนี้:
-
-```markdown
-- [ ] Task 1.1 [TDD-Red]: Write failing test for {feature/behavior} in {test_file} and verify failure
-- [ ] Task 1.2 [TDD-Green]: Implement minimal code in {src_file} to satisfy Task 1.1 test
-- [ ] Task 1.3 [TDD-Refactor]: Refactor logic, eliminate duplication, and verify zero regression
-```
-
-For every subtask, decide one of:
-
-- `Required`: automated tests must be created or updated (Mandatory for all behavior changes, formatted as TDD Triplet)
-- `Manual/Command Only`: verification is non-test but still explicit (Only for configuration/infrastructure tasks)
-- `Not Required`: no new automated test is needed because there is no meaningful behavior surface (Only for documentation/comments)
-
-Record:
-
-- reason
-- planned cases when tests are required (using AAA pattern: Arrange-Act-Assert)
-- verification command or manual check
-- expected result
-
-Do not use "too simple" as the only reason for skipping tests.
-
-### 5. Create Human-Readable Plan
-
-Create `30-plan.md` in the task workspace and base its structure on:
-
-```text
-.agent/resources/schemas/plan.template.md
-```
-
-Before writing `30-plan.md`, read `artifact_language` from `plan.template.md` and produce the artifact in that language.
-
-Before reporting completion:
-
-Review `{plan_md_path}` against `plan.template.md`, keep the required headings, and remove placeholder text before completion.
-
-Replace every placeholder with concrete phases, files, commands, dependencies, and verification evidence.
-Follow the `artifact_language` configured in `plan.template.md` for all plan narrative text.
-
-Create the checklist directory when detailed execution tracking is needed:
-
-```text
-devflow/runs/{ID}-*/checklists/
-```
-
-Seed at least:
-
-- `implementation-checklist.md`
-- `verification-checklist.md`
-
-Use the schema templates under `.agent/resources/schemas/` and turn approved phases/subtasks into live markdown checklist items using task markers such as `- [ ]`, `- [/]`, `- [!]`, and `- [-]` so humans can follow the run without reading the full planning narrative.
-
-### 6. Validate And Close Planning
-
-Run:
-
-Run `npm run validate` after changing the framework, templates, or shared references. For task work, manually verify that `30-plan.md` still matches the required template contract.
-
-If validation fails, repair only what is necessary and keep `30-plan.md` aligned with the corrected state.
-
-### 7. Manual Review Soft Gate
-
-Before recommending `40-execute`, check whether the plan still shows pending review.
-If `Approval Status` is still pending or major dependencies remain unresolved:
-
-- warn that implementation should wait for review
-- recommend human confirmation of sequencing, scope, and verification strategy
-- keep `40-execute` as a soft recommendation only
-
-## Output Checklist
-
-- complexity is clear
-- loop evidence is recorded: intent, context, observation, adjustment, stop condition, and handoff
-- phases are ordered by dependency
-- every subtask is scoped and verifiable
-- every subtask has a test decision
-- `30-plan.md` is written and reviewable
-- validation passes
-- manual review warning is explicit when approval is still pending
-- next command is ready
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `20-spec`
-- Next state: `40-execute` when execution steps and verification are clear
-- Common companion commands: `Research` or `Agent` when architecture, data flow, or external constraints still need investigation; support skills: `grill-with-docs`, `domain-modeling`, `codebase-design`, `tdd`, and `to-issues` for final design stress-testing, durable terminology capture, test planning, and issue packaging
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/plan.template.md`
-- Related commands: `20-spec`, `Research`, `Agent`, `40-execute`
-
-## Next Workflow Recommendation
-
-- **Primary**: `40-execute {ID}`
-- **Why**: Approved planning is the gate before implementation in DevFlow 2.0.
-- **Alternatives**:
-  - `Research` - choose this when the plan still depends on missing evidence.
-  - `Agent codebase-explorer devflow/runs/{ID}-*/` - choose this when architecture or data flow is unclear.
-  - `grill-with-docs` - choose this when plan assumptions or design boundaries need one last adversarial pass.
-  - `codebase-design` - choose this when a plan needs clearer seams, interfaces, or test surfaces.
-  - `20-spec {ID}` - choose this when the spec itself is not strong enough for planning.
-
-## Nexus Event
-
-- Use `Research` when architecture, sequencing, or rollout decisions still depend on missing evidence.
-- Use `Agent codebase-explorer` or another specialist lane when the codebase shape or integration boundary is still unclear.
-- Use `grill-with-docs` when available if a short clarification pass could materially change sequencing, dependency order, rollout risk, or verification strategy.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when planning records a reusable architecture decision, project pattern, or context-loading lesson.
-- **Scope**: `project` unless the planning lesson changes DevFlow framework behavior.
-- **Reason**: Plans often discover stable patterns that future sessions should reuse.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*30-plan.md`
-

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

@@ -1,158 +0,0 @@
----
-name: 40-execute
-description: "[devflow][D] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
----
-# Phase 40: Execute Code
-
-Implement and execute the approved plan incrementally. Source code edits are allowed in this phase.
-
-## Usage
-
-```text
-40-execute {ID}
-```
-
-## Markdown-First Contract
-
-Use `40-execute.md` as the primary execution artifact.
-Before writing `40-execute.md`, produce the artifact in Thai (`th`).
-
-Before execution, confirm the plan is approved in the stage artifacts. Track subtask progress, execution notes, and completion evidence directly in `40-execute.md` and related stage markdown files.
-
-## 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 execution as scoped execution loops, one unit at a time.
-
-- **Intent**: complete the selected planned unit while preserving the spec, plan, and repository conventions.
-- **Context**: read `30-plan.md`, `20-spec.md`, relevant checklist items, target files, pattern files, and test decisions before editing.
-- **Action**: make the smallest useful change for the current unit, update or create tests when required, run the planned verification, and record the result.
-- **Observation**: inspect concrete evidence from diffs, command output, tests, manual checks, and checklist status before claiming progress.
-- **Adjustment**: if evidence does not match intent, fix within the current unit, capture the blocker, use `Debug`, or return to `30-plan` or `20-spec` when the work no longer matches the contract.
-- **Stop Condition**: stop the unit when the planned change is complete, verification evidence is recorded, deviations are explained, and the next unit or handoff is clear.
-- **Handoff**: `40-execute.md` must tell `50-verify` what changed, why it changed, which checks ran, what failed or was skipped, and what residual risk remains.
-
-### 1. Get Bearings
-
-Read:
-
-- `30-plan.md`
-- `20-spec.md`
-- `checklists/implementation-checklist.md` when present
-- referenced pattern files
-- `10-define.md` when the intent needs a quick reminder
-
-Confirm the current Git branch with `git branch --show-current` and use that branch as the user's chosen working branch. Do not create, switch, or checkout branches automatically.
-
-Select one scoped unit of work at a time. Do not implement the whole plan as one blob.
-
-### 2. Execute One Scoped Unit (Strict TDD Red-Green-Refactor)
-
-Use the strict coder discipline:
-
-- **STRICT MANDATE (กฎเหล็ก Unit Test & TDD)**: สำหรับทุกงานที่มีการแก้ไข logic การทำงาน ต้องสร้างหรือแก้ไข Unit Test ควบคู่กับการแก้ไขโค้ดเสมอ โดยห้ามเขียนเฉพาะ Production Code โดยไม่มีเทสต์
-- **🔴 RED (Test First)**: ออกแบบและเขียน Test Case ในไฟล์เทสต์ก่อนเสมอ แล้วรันคำสั่งเทสต์เพื่อพิสูจน์ว่า **Test ล้มเหลว (FAIL)** ตามที่คาดหวัง
-- **🟢 GREEN (Minimal Implementation)**: เขียน Production Code เท่าที่จำเป็นเพื่อให้เทสต์ผ่าน แล้วรันคำสั่งเทสต์เพื่อพิสูจน์ว่า **Test ผ่าน 100% (PASS)**
-- **🔵 REFACTOR (Clean Code)**: ปรับปรุงโครงสร้างโค้ดให้อ่านง่าย กำจัดความซ้ำซ้อน (DRY) โดยที่เทสต์ยังคงเขียว 100%
-- **Code Deletion / Reversion Rule**: หากเผลอเขียน Production Code ก่อนมีเทสต์ ให้ Revert หรือลบโค้ดส่วนนั้น แล้วเริ่มวงจร RED ก่อนเสมอ
-- start each scoped unit by naming its intent, context, expected observation, adjustment route, and stop condition
-- read referenced pattern files before editing
-- read the test decision from `30-plan.md`
-- confirm assumptions, target files, and success criteria before editing
-- preserve project style
-- run the planned verification and capture concrete terminal outputs
-- record observation, adjustment, stop condition status, and the result in `40-execute.md`
-- update checklist item status, timestamps, and evidence links as work progresses
-
-### 3. Recovery
-
-Use the old recovery discipline when blocked:
-
-- capture the blocker with evidence
-- mark failure only when the current unit truly cannot continue
-- recommend `Debug` when root cause analysis is needed
-- return to Plan when the work no longer matches the plan
-
-Use `tdd` for behavior-change implementation loops, `diagnosing-bugs` when a tight repro is needed before a fix, and `codebase-design` when implementation exposes an awkward seam or shallow module.
-
-### 4. Finalize Execution
-
-When the scoped work is complete:
-
-- summarize the completed units
-- list changed files
-- record verification performed
-- record loop evidence for each completed unit: intent, observation, adjustment, and stop condition
-- record deviations, blockers, and manual checks
-- make sure checklist statuses match the actual state of the code and tests
-- make sure `40-execute.md` is ready for Verify
-
-### 5. Manual Review Soft Gate
-
-If the plan was not clearly approved, warn that execution proceeded under review risk.
-When finishing `40-execute.md`:
-
-- record any deviation from the approved plan explicitly
-- set reviewer expectations before `50-verify`
-- keep `50-verify` as the next soft recommendation rather than an unconditional jump
-
-## Output
-
-Report:
-
-- scoped units completed
-- files changed
-- verification commands run
-- test decisions followed or changed, with reasons
-- loop evidence and handoff notes for Verify
-- blocked items or manual checks
-- next command: `50-verify {ID}`
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `30-plan`
-- Next state: `50-verify` when scoped execution is complete
-- Common companion commands: `Debug` for blockers, `Preview` for local checks; support skills: `tdd`, `diagnosing-bugs`, and `codebase-design` for behavior changes, root-cause loops, and implementation-time design pressure
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- Related commands: `30-plan`, `Debug`, `Preview`, `50-verify`
-
-## Next Workflow Recommendation
-
-- **Primary**: `50-verify {ID}` when the planned work is complete.
-- **Why**: Implementation needs independent verification before release or human acceptance.
-- **Alternatives**:
-  - `Debug "{blocker}"` - choose this when execution is blocked by an unexplained failure.
-  - `30-plan {ID}` - choose this when the plan is incomplete or no longer matches the work.
-  - `Preview` - choose this when a local runtime or visual check is useful before formal verification.
-  - `codebase-design` - choose this when the implementation cannot be tested cleanly because the module shape is wrong.
-
-## Nexus Event
-
-- Use `Debug` when the conversation reveals an unexplained blocker, flaky behavior, or root-cause gap.
-- Use `Preview` when a runtime, UI, or local interaction check would reduce verification risk.
-- Return to `30-plan` when execution drift shows the plan no longer matches reality.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when coding discovers a reusable implementation pattern, gotcha, or context optimization.
-- **Scope**: `project` unless the discovery is about DevFlow itself.
-- **Reason**: Coding findings are useful only when they are stable enough to help future tasks.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-execute.md`