@jakkrichm/create-nexus-devflow 2.0.0

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

@@ -0,0 +1,221 @@
+---name: 30-plan
+
+description: Plan implementation in DevFlow 2.0 - transform `20-spec.md` into a markdown-first executable plan.
+---
+# 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-Implement` 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-discover.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 the old planner discipline, but keep `30-plan.md` as the main contract:
+
+- record the planning loop evidence: context read, observations, adjustments made, stop condition, and handoff notes
+- add phases in dependency order
+- add subtasks that are small, verifiable units
+- include explicit files to modify or create
+- 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
+- which pattern to follow
+- how to verify it
+- whether automated tests are required, manual, or not required
+
+### 4.1 Test Decision Gate
+
+**STRICT MANDATE (กฎเหล็ก Unit Test)**: สำหรับทุก subtask ที่มีการเพิ่ม แก้ไข หรือเปลี่ยนแปลงการทำงานของโค้ด (Behavior Change) **ต้องระบุเป็น `Required` เสมอ** ห้ามละเว้นเด็ดขาด ยกเว้นงานประเภทเอกสารหรือแก้ไข Configuration เท่านั้น
+
+For every subtask, decide one of:
+
+- `Required`: automated tests must be created or updated (Mandatory for all behavior changes)
+- `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-Implement`, 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-Implement` 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-Implement` 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-Implement`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/40-Implement {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-implement/SKILL.md

@@ -0,0 +1,166 @@
+---name: 40-implement
+
+description: Implement code in DevFlow 2.0 - execute one planned unit at a time with markdown-first implementation evidence.
+---
+# Phase 40: Implement Code
+
+Implement the approved plan incrementally. Source code edits are allowed in this phase.
+
+## Usage
+
+```text
+/40-Implement {ID}
+```
+
+## Markdown-First Contract
+
+Use `40-implement.md` as the primary implementation artifact.
+Before writing `40-implement.md`, read `artifact_language` from `.agent/resources/schemas/implement.template.md` and produce the artifact in that language.
+
+Use controlled task-engine commands when progress state must be synchronized:
+
+Before implementation, confirm the plan is approved in the stage artifacts. Track subtask progress, implementation notes, and completion evidence directly in `40-implement.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 implementation 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-implement.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. Implement One Scoped Unit
+
+Use the original coder discipline, adapted to 2.0:
+
+- **STRICT MANDATE (กฎเหล็ก Unit Test)**: ต้องสร้าง/แก้ไข Unit Test ควบคู่กับการแก้ไขโค้ดเสมอ โดยห้ามแก้ไขเฉพาะไฟล์โค้ดหลัก (Production Code) โดยไม่แก้ไขหรือสร้างไฟล์เทสต์ควบคู่กัน
+- 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
+- make the smallest useful code change
+- preserve project style
+- run the planned verification
+- record observation, adjustment, stop condition status, and the result in `40-implement.md`
+- update checklist item status, timestamps, and evidence links as work progresses
+
+If tests are `Required`:
+
+1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางของ [test-driven-development](file:///.agents/skills/test-driven-development/SKILL.md)
+2. **GREEN**: เขียนโค้ดระบบจริงให้สอดคล้องเพื่อให้เทสต์ผ่าน
+3. **REFACTOR**: ปรับปรุงโครงสร้างโค้ดโดยยังคงรันเทสต์ผ่านอย่างต่อเนื่อง
+
+### 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 Implementation
+
+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
+- follow the `artifact_language` configured in `implement.template.md`
+- make sure checklist statuses match the actual state of the code and tests
+- make sure `40-implement.md` is ready for Verify
+
+### 5. Manual Review Soft Gate
+
+If the plan was not clearly approved, warn that implementation proceeded under review risk.
+When finishing `40-implement.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 implementation 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`
+- `.agent/resources/schemas/implement.template.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 implementation 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 implementation 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-implement.md`
+

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

@@ -0,0 +1,188 @@
+---name: 50-verify
+
+description: Verify quality 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.
+
+## Usage
+
+```text
+/50-Verify {ID}
+```
+
+## Markdown-First Contract
+
+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-implement.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-Implement` 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-Implement` exactly what must change before verification resumes.
+
+### 1. Context Gathering
+
+Read:
+
+- `20-spec.md`
+- `30-plan.md`
+- `40-implement.md`
+- `checklists/verification-checklist.md` when present
+- changed files
+- test output, command output, screenshots, or manual-check evidence
+
+### 2. Artifact Gate
+
+Run the necessary validation for the current state before doing the full review.
+
+### 3. QA Review
+
+Use the old QA reviewer discipline, adapted to 2.0:
+
+- **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
+- 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
+- test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
+- test decision alignment
+- manual verification gaps
+- assumptions 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
+```
+
+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`.
+
+Include:
+
+- 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-Implement` 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-Implement`
+- keep `/60-Report` as a soft recommendation only
+
+## 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-Implement {ID}` if fail
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/40-Implement`
+- 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-Implement`, `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `/60-Report`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/60-Report {ID}` when verification passes, or `/40-Implement {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`
+