@jakkrichm/create-nexus-devflow 2.16.4 → 2.17.1

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

@@ -6,6 +6,8 @@ argument-hint: "[{resume, max-features, or start-feature}]"
 
 # continuous - Complete the Build Plan One Local Feature at a Time
 
+**Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
+
 **First action:** Before project inspection, preflight, or any other tool call,
 publish `running` to `devflow/.state/run.json` using the dashboard activity
 contract in `AGENTS.md`.
@@ -19,120 +21,192 @@ Where this sits in the workflow:
                Gates ➔ Merge)
 ```
 
-`/continuous` (หรือ `$continuous`) คือโหมดการทำงานแบบ Autonomous Multi-Feature Delivery Loop สำหรับจัดส่งฟีเจอร์ที่อยู่ใน `devflow/build-plan.md` ต่อเนื่องทีละฟีเจอร์ในเครื่อง Local โดยไม่ต้องหยุดรอ Manual Review Prompts ในแต่ละขั้นตอนย่อย แต่ยังคงรักษาความเข้มงวดของ **The 3-Pillars Model & Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)**, การทำ TDD, การตรวจ Quality Gates, การบันทึก Findings Ledger, และการ Squash-merge ลง Local Main Commit ทีละฟีเจอร์อย่างปลอดภัย 100%
-
-### ขอบเขตสิทธิ์ที่ได้รับอนุญาตเฉพาะในเครื่อง Local:
-- สร้างและสลับ Feature Branch ในเครื่อง Local
-- บันทึก Checkpoint Commits ย่อยบน Branch
-- สร้าง required immutable independent-review checkpoints
-- บันทึก Feature Commit สุดท้าย
-- Squash-merge ฟีเจอร์ที่เสร็จสมบูรณ์ลง Default Branch ของ Local
-- ลบ Feature Branch เฉพาะใน Local หลังรวมโค้ดสำเร็จ
-- วนลูปเริ่มทำฟีเจอร์ที่ยังไม่ได้เช็ค (`- [ ]`) รายการถัดไปใน `build-plan.md`
-
-### ข้อจำกัดความปลอดภัยเด็ดขาด (Strict Safety Boundaries):
-- **ห้าม** Push ขึ้น Remote Repository
-- **ห้าม** Deploy หรือเผยแพร่ (Publish) สู่ภายนอก
-- **ห้าม** ลบข้อมูลจริง, ทำลาย Database, หรือรัน Destructive Migration
-- **ห้าม** กด Accept Finding หรือเพิกเฉยต่อ Failing Quality Gate แทนมนุษย์
+Continuous Mode (`/continuous` or `$continuous`) is an explicit opt-in loop for
+completing planned features serially from `devflow/build-plan.md` in local isolation
+without pausing at normal human review prompts. It preserves the same strict
+**The 3-Pillars Model & Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)**,
+disciplined TDD verification, quality gates, findings ledger, branch isolation, and
+one clean local main commit per feature that a careful human workflow would produce.
+
+### Authorized Local Actions for this Run:
+- Create and switch local feature branches (`feature/{xxx-slug}`)
+- Create configured checkpoint commits on those branches
+- Create required immutable independent-review checkpoints
+- Create the final local feature commit
+- Squash-merge a completed feature into the local default branch (`main`)
+- Delete the merged local feature branch
+- Repeat with the next unchecked build-plan item
+
+### Strict Safety Boundaries:
+- **NEVER** push to remote repositories
+- **NEVER** deploy or publish externally
+- **NEVER** delete production data, destroy databases, or run irreversible migrations
+- **NEVER** accept findings or waive failing quality gates on behalf of the user
+- Always stop before those actions and hand off to the user
 
 ---
 
 ## Input & Target Selection
 
-- **ไม่ระบุ Argument (`/continuous`)**:
-  1. หากมีฟีเจอร์ค้างอยู่ใน `devflow/context/{xxx-slug}/` ให้ทำต่อจากขั้นตอนย่อยแรกที่ยังไม่ได้เช็ค (`- [ ]`)
-  2. หากไม่มี ให้เลือกฟีเจอร์แรกที่ยังไม่ได้เช็ค (`- [ ]`) ใน `devflow/build-plan.md`
-  3. วนลูปทำต่อเนื่องตามลำดับใน `build-plan.md` จนกว่าจะหมด หรือครบตามจำนวน `continuous.maxFeatures` ใน `devflow/config.json`
-- **ระบุ `resume` (`/continuous resume`)**: ทำงานต่อจากฟีเจอร์และขั้นตอนย่อยที่ค้างอยู่ทันที
-- **ระบุชื่อหรือหมายเลขฟีเจอร์ (`/continuous 13`)**: เริ่มต้นจากฟีเจอร์ที่ระบุ แล้ววนลูปต่อไปยังฟีเจอร์ถัดไป
+Before selecting a new feature or requiring an active live spec, always inspect
+pending completion using the installed Complete skill and
+`../complete/reference/completion-recovery.md`. Use its read-only candidate screen
+first: settled clean default-branch history needs no historical transient objects
+for a new run. An actual completion candidate or an explicit request to resume
+interrupted completion requires full recovery proof, using this run's scoped Git
+authority and `qualityGates.continuous`. Do not repeat archival or a work commit/merge.
+Missing, conflicting, or unprovable recovery evidence stops before next-feature work.
+An active feature with no completion candidate resumes implementation normally; its
+ordinary `resume` does not require an archive or completion proof.
+
+With no argument after pending completion has been reconciled:
+
+1. Resume an active feature in `devflow/context/{xxx-slug}/spec.md`.
+2. Otherwise select the next unchecked leaf item (`- [ ]`) in `devflow/build-plan.md`.
+3. Continue in build-plan order until no unchecked leaf remains or
+   `continuous.maxFeatures` completed features have been counted.
+
+`resume` explicitly resumes the active feature or its pending completion.
+A feature number or name may set the starting item only when no different work item
+is active. After that item, continue with the next unchecked leaf items in normal
+build-plan order.
+
+Continuous Mode handles planned features only. If the active work is a fix or rollback,
+stop and point to its normal reviewed workflow. Never overwrite active work to make
+the requested target fit.
 
 ---
 
-## Step 1: Preflight Safety Check (ตรวจสอบความพร้อมก่อนเริ่ม)
+## Step 1: Preflight Safety Check
 
-อ่านบริบทตั้งต้น:
+Read initial context:
 - `AGENTS.md`
-- `devflow/config.json` (หากไม่มี ให้ใช้ค่า Defaults อย่างปลอดภัย; หาก Invalid ให้หยุดและชี้ไปที่ `/doctor`)
-- `devflow/project-plan.md` และ `devflow/build-plan.md`
+- `devflow/config.json` (if missing, use safe defaults; if invalid, stop and point to `/doctor`)
+- `devflow/project-plan.md` and `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/{xxx-slug}/` (ถ้ามีงานค้างอยู่)
-- `devflow/context/coding-standards.md` และ `devflow/context/ai-interaction.md`
-- สถานะ Git (`git status`, `git branch`, recent log)
-
-### กฎการเริ่มงาน (Start Conditions):
-1. สถานะ Git Working Tree สะอาด (Clean) บน Default Branch หรือมีเฉพาะ Diff ของฟีเจอร์ปัจจุบัน
-2. `devflow/build-plan.md` มีฟีเจอร์ที่ยังไม่ได้ทำเหลืออยู่
-3. ไม่มี Finding ระดับ P0 หรือ P1 ค้างในสถานะ `open` หรือ `fixed`
-4. บันทึก Commit SHA ตั้งต้นของ Default Branch ไว้สำหรับสรุปผลในรายงานสุดท้าย
+- `devflow/context/{xxx-slug}/` (if work is already active)
+- `devflow/context/coding-standards.md` and `devflow/context/ai-interaction.md`
+- Git status (`git status`, `git branch`, default branch, and recent log)
+
+### Start Conditions:
+1. The project is a Git repository.
+2. The working tree is clean on the default branch, or all dirty work belongs to the
+   active feature on its matching configured feature branch, including proven pending
+   completion handled through the recovery contract.
+3. `devflow/build-plan.md` is a valid ordered checkbox plan with at least one remaining leaf.
+4. Overview is fresh. If stale but both plans are clear and consistent, refresh it
+   using `/overview` behavior and include that change with the first feature.
+5. Existing P0 or P1 findings are not `open` or `fixed`.
+6. Project commands and the exact `Verify` command, when declared, are usable.
+7. Record the starting default-branch commit SHA for the final integration summary.
+
+The initial `devflow/.state/run.json` record required by `AGENTS.md` must already show
+command `continuous` and status `running` before preflight begins. After preflight passes,
+enrich it with boundary `local-only`, the current feature, and completed-feature progress
+against the smaller of the remaining queue or configured limit. Update it when a feature
+starts, after every passing build step, after each quality gate, and after each local main
+commit. On a stop, set status `blocked` with `/continuous resume` when resuming is safe.
+At the end of the queue or limit, set status `completed`.
 
 ---
 
-## Step 2: Serial Feature Lifecycle (วงจรการส่งมอบทีละฟีเจอร์)
+## Step 2: Serial Feature Lifecycle
 
-ดำเนินงานวนลูปทีละ 1 ฟีเจอร์ตามลำดับ:
+Execute the loop one feature at a time in strict order:
 
-### 2.1 Select & Spec (เลือกและร่างสเปก)
-- หาก Resuming: ใช้ Spec เดิมใน `devflow/context/{xxx-slug}/spec.md`
-- หากเป็นฟีเจอร์ใหม่: ถอดความต้องการจาก `build-plan.md` และสร้าง Task Workspace ที่ `devflow/context/{xxx-slug}/` พร้อมเขียน `spec.md`, `stage.md`, `findings.md` และวิเคราะห์ Red-team ก่อนเริ่มโค้ด
+### 2.1 Select & Spec
+- If resuming: Reuse the existing spec in `devflow/context/{xxx-slug}/spec.md`.
+- If new feature: Extract requirements from `devflow/build-plan.md` and initialize the
+  task workspace at `devflow/context/{xxx-slug}/` with `spec.md`, `stage.md`, and `findings.md`.
+  Check `../feature/reference/build-history.md` for `--build-N` naming conventions if
+  rebuilding a previously rolled-back feature, ensuring existing archives in
+  `devflow/history/features/` are never overwritten. Self-review the spec before coding.
 
 ### 2.2 Create / Resume Feature Branch
-- สร้าง Branch ตาม Prefix ใน Config (เช่น `feature/061-slug`) จาก Default Branch
+- Use the configured branch prefix (e.g., `feature/{xxx-slug}`) from the current local default branch.
+- When resuming, require the existing branch and active spec to agree.
+- If switching would strand unrelated work or the default branch changed unsafely, stop.
+  Never stash, reset, or discard work automatically.
 
 ### 2.3 Implement Small Steps with Strict TDD
-- ดำเนินการสร้างฟังก์ชันทีละ Task ตาม Checklist ใน Spec:
-  1. `[TDD-Red]`: เขียน Unit Test ก่อน
-  2. `[TDD-Green]`: เขียนโค้ดขั้นต่ำให้ Test ผ่าน
-  3. `[TDD-Refactor]`: ปรับแต่งโค้ดให้สะอาดและรัน Verification ผ่าน
-  4. ทำเครื่องหมาย `- [x]` ใน Spec และบันทึก Checkpoint Commit บน Branch (หาก `workflow.checkpointCommits: "enabled"`)
+Execute the spec in order, one small diff at a time:
+1. `[TDD-Red]`: Write the failing unit test first.
+2. `[TDD-Green]`: Implement the minimal code to pass the test.
+3. `[TDD-Refactor]`: Clean up and ensure all verifications pass cleanly.
+4. Check off the step (`- [x]`) in `spec.md`.
+5. When `workflow.checkpointCommits` is `enabled`, create a conventional local
+   checkpoint commit containing that passing step and its checked spec state.
+   When `disabled`, keep the work uncommitted until feature completion.
 
 ### 2.4 Apply Continuous Quality Gates
-ตรวจสอบตามการตั้งค่า `qualityGates.continuous` ใน `devflow/config.json`:
-- **Audit**: `manual` (ข้ามอัตโนมัติ), `when-sensitive` (รันเมื่อแตะ Auth/Security/Database/Secrets), `always` (รันทุกฟีเจอร์)
-- **Independent Review**: อ่าน `qualityGates.continuous.independentReview`; `manual` คือ opt-in, `always` บังคับทุกฟีเจอร์, และ `when-sensitive` บังคับเมื่อฟีเจอร์แตะ authentication, authorization, secrets, payments, personal data, destructive operations, dependencies, deployment หรือ security boundary อื่น บันทึกคำตัดสินและหลักฐานต่อฟีเจอร์ใน spec
-- **Check**: `manual` (ข้ามอัตโนมัติ), `when-behavioral` (รันเมื่อมี Runtime Behavior เช่น UI/CLI/API), `always` (รันทุกฟีเจอร์)
-- **Try Guide**: `manual` (ข้ามอัตโนมัติ), `when-user-facing` (สร้าง Try Guide เมื่อเป็น UI/CLI), `always` (สร้างทุกฟีเจอร์)
-
-ทุก product/spec edit ทำให้ receipt เดิมหมดอายุ เมื่อ Independent Review gate
-ทำงาน ให้รัน Verify และสร้าง immutable checkpoint (ได้รับอนุญาตภายใต้ Continuous Mode authority แม้ checkpointCommits จะ disabled) จากนั้นปฏิบัติตาม `/audit independent current`
-หาก `review.independentExecution` เป็น `automatic` ให้ spawn และรอ isolated reviewer child พร้อมตรวจสอบ receipt ให้ผ่านก่อนดำเนินการต่อ
-หากเป็น `manual` หรือ runtime ไม่สามารถพิสูจน์ isolation, identity, model ได้ ให้ตั้งสถานะเป็น `ready` และหยุดด้วย manual handoff
-Continuous Mode จะไม่ทำการ audit งานของตัวเองโดยเด็ดขาด
-
-คำขอจะบันทึก `Requested execution` และ receipt จะบันทึก `Actual execution`
-การจับคู่ของ execution และ reviewer context จะต้องถูกต้องตามสัญญา review
-หากเป็น legacy request ที่ไม่มี `Requested execution` ให้ถือว่าเป็น legacy manual-only ห้ามเติมฟิลด์หรือรัน subagent กับมัน
-
-สำหรับฟีเจอร์ browser-facing ให้รัน `npm run test:browser` เมื่อมี
-`test:browser` script และเก็บ interactive evidence ผ่าน `browseros-neo` เมื่อ
-พร้อมใช้งาน หาก script หรือ MCP ไม่มี ให้บันทึก limitation และหยุดเมื่อ evidence
-นั้นเป็น gate ที่จำเป็น ห้ามติดตั้งหรืออ้างผลโดยปริยาย
+Evaluate `qualityGates.continuous` in `devflow/config.json`:
+- **Audit**: `manual` skips automatic audit; `when-sensitive` runs `/audit current`
+  for authentication, authorization, payments, secrets, personal or user data, migrations,
+  destructive operations, external side effects, security boundaries, or unusually broad changes;
+  `always` audits every feature.
+- **Independent Review**: Read `qualityGates.continuous.independentReview`; `manual` skips
+  automatic review; `when-sensitive` requires an isolated reviewer for the same sensitive
+  categories as Audit; `always` requires an isolated reviewer for every feature. A passing
+  independent receipt satisfies the Audit gate for that feature.
+- **Check**: `manual` skips automatic `/check`; `when-behavioral` runs it when a done-when
+  needs observed runtime behavior (UI, CLI, API, background job); `always` checks every feature.
+- **Try Guide**: `manual` skips automatic generation; `when-user-facing` generates a guide
+  for UI, CLI, or user-facing workflows; `always` generates one for every feature.
+
+Run required gates in order: check, review, then try guide. When independent review is
+selected, ensure application code is in a clean immutable checkpoint. First rerun final
+verification and selected Check gate and set spec status to `verified`. This review
+checkpoint is covered by Continuous Mode authority even when step checkpoint commits are
+disabled. Follow `/audit independent current`.
+
+With `review.independentExecution: "automatic"`, spawn and wait for the isolated reviewer
+subagent and validate its receipt before continuing. With `manual`, or when runtime cannot
+prove isolation, identity, model, or completion, set activity to `ready` and stop with the
+manual handoff. Continuous Mode never audits its own work.
+
+The request records `Requested execution`; the receipt records `Actual execution`. Require
+the execution and reviewer-context pairing defined by the review contract. A pending request
+without `Requested execution` is legacy manual-only.
+
+For browser-facing features, run `npm run test:browser` when `test:browser` script exists
+and collect interactive evidence via `browseros-neo` when available.
 
 ### 2.5 Repair Findings
-- ซ่อมแซม Finding ระดับ P0/P1 ที่เกิดขึ้นจากฟีเจอร์นี้โดยอัตโนมัติ (ไม่เกิน `continuous.maxRepairAttempts` ครั้ง)
-- หากไม่สามารถซ่อมแซมได้ หรือมี P0/P1 ค้างอยู่ ให้หยุดการทำงานทันที
+- Automatically repair confirmed P0 and P1 findings directly caused by the feature, up to
+  `continuous.maxRepairAttempts` times.
+- After repair, rerun affected verification and re-audit the repaired area.
+- Any unresolved P0 or P1 finding left `open` or `fixed` stops the loop before completion.
 
 ### 2.6 Complete Locally Like a Human
-- รัน Verification ขั้นสุดท้าย
-- ย้ายและ Archive เอกสารไปที่ `devflow/history/features/{xxx-slug}.md`
-- อัปเดตเช็คบ็อกซ์ใน `devflow/build-plan.md`
-- ลบโฟลเดอร์รัน `devflow/context/{xxx-slug}/`
-- Squash-merge Feature Branch เข้าสู่ Local Main และลบ Feature Branch ใน Local
-- นับจำนวนฟีเจอร์ที่สำเร็จเพิ่มขึ้น 1
+Apply the `/complete` safety, logging, and archive behavior without asking commit and merge prompts:
+1. Run final documented verification.
+2. Confirm the current spec status is `verified`.
+3. Capture source tree / annotation proof per `../complete/reference/completion-recovery.md`
+   and embed `<!-- devflow:completion {...} -->` in the archive.
+4. Place the archive at `devflow/history/features/{xxx-slug}.md`.
+5. Update checkboxes in `devflow/build-plan.md` and append entry to `devflow/history/HISTORY.md`.
+6. Remove the active run directory `devflow/context/{xxx-slug}/`.
+7. Switch to the local default branch, squash-merge the feature branch, and create one
+   conventional commit containing product work, tests, and DevFlow history.
+8. Delete the merged local feature branch.
+9. Confirm the default branch is clean before selecting the next feature.
 
 ---
 
 ## Step 3: Optional Final Integration Audit
 
-เมื่อครบกำหนดจำนวนฟีเจอร์หรือหมด `build-plan.md` หาก `continuous.finalIntegrationAudit: true` ให้รันการตรวจสอบความเข้ากันได้แบบบูรณาการ (Cross-Feature Contracts & Seams) จากจุดเริ่มต้นถึง HEAD ปัจจุบัน
+When the feature queue completes or `continuous.maxFeatures` is reached, if
+`continuous.finalIntegrationAudit: true`, execute an integration compatibility check
+(Cross-Feature Contracts & Seams) covering the span from the starting commit to current HEAD.
 
 ---
 
-## Step 4: Stop & Report (สรุปรายงานผลลัพธ์)
+## Step 4: Stop & Report
 
-เมื่อการทำงานสิ้นสุด (ไม่ว่าจะสำเร็จครบถ้วน หรือหยุดเนื่องจากติดเงื่อนไขความปลอดภัย) ให้รายงานสรุปเป็นภาษาไทย:
-- Commit เริ่มต้น และ Commit สุดท้ายของ Default Branch
-- รายชื่อฟีเจอร์ที่จัดส่งสำเร็จในรอบนี้ พร้อม Commit Hash
-- ผลการรัน Quality Gates และการซ่อมแซม Findings (ถ้ามี)
-- ความคืบหน้าภาพรวมของ `build-plan.md` และฟีเจอร์ถัดไป
-- ย้ำเตือนชัดเจนว่า **ไม่มีการ Push ใดๆ ขึ้น Remote Repository**
+When Continuous Mode finishes (either fully completed or stopped at a safety boundary),
+present a concise summary report in Thai (per user communication rules):
+- Starting and ending commit SHAs of the local default branch.
+- List of features delivered in this run with their commit hashes.
+- Summary of quality gates executed and findings resolved.
+- Overall progress of `devflow/build-plan.md` and next upcoming feature.
+- Clear reminder that **no remote push or deployment has occurred**.

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

@@ -126,6 +126,10 @@ build plan starts high-level.
 
 ## Step 3 - write the spec
 
+Before review, allocate the selected feature ID's build attempt using
+`reference/build-history.md`: first build 1, otherwise one greater than
+the maximum proven prior attempt after all prior builds were reversed. For attempt N > 1, append `--build-N` to the slug and archive path (e.g. `086-export--build-2.md`).
+
 For the one (sub-)feature being built now, allocate sequential ID (`xxx-slug`) and create a dedicated workspace at `devflow/context/{xxx-slug}/`. Write the full living spec to
 `devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. The first heading and build-plan identity must use this canonical form:
 
@@ -133,8 +137,10 @@ For the one (sub-)feature being built now, allocate sequential ID (`xxx-slug`) a
 # Feature: <title>
 
 **From build-plan:** feature <id>
+**Build attempt:** <positive integer>
 ```
 
+
 Fill every section:
 - Goal, Problem Statement, and In/Out of scope
 - Acceptance Criteria (AC-1, AC-2, ...)

package/template/.agents/skills/feature/reference/build-history.md

@@ -0,0 +1,79 @@
+# Build history identity
+
+Read metadata from the archived original spec, not appended findings or review.
+Read the feature ID from its `**From build-plan:**` or supported legacy
+feature field, not its title or filename. Normalize the numeric part by removing
+leading zeros and the optional letter to lowercase (`012A` becomes `12a`). Match
+that complete ID, never a substring. Use the archived spec's positive integer
+`**Build attempt:**`; duplicate or malformed fields stop selection. A legacy
+first-build archive without it counts as attempt 1 only when its spec identity
+and unsuffixed `NN-name.md` path agree unambiguously. Derive the expected name
+from its own spec, not today's renamed plan title. Text such as `Build 2` in a
+title proves no attempt.
+For new paths, pad the numeric part to at least two digits, keep its letter, and
+use the spec title's lowercase kebab-case slug. Append `--build-N` only for N > 1.
+An archive declaring an attempt must agree with that computed path.
+The double hyphen is reserved: slug normalization collapses punctuation runs to
+one hyphen, so a first build titled `Export Build 2` uses `04-export-build-2.md`,
+while a later attempt 2 titled `Export` uses `04-export--build-2.md`.
+
+Before freezing a new spec, check its exact planned archive path in `devflow/history/features/` and branch.
+Require `lstat` to return `ENOENT` for the archive leaf; any existing entry,
+including a dangling symlink, blocks it. Present parents must be ordinary
+directories. Require a valid branch name and no existing or namespace-conflicting
+local branch ref (inspect `git for-each-ref refs/heads/`, including packed refs).
+Also require no prior use of the archive path in available Git history:
+
+```bash
+git log --all --reflog --full-history --format=%H -- <planned-archive-path>
+```
+
+Any result or inspection failure stops before spec review with the exact collision.
+Do not auto-bump the attempt or rename reviewed work to avoid it. These checks
+apply to new specs; existing completion must run its recovery routing first so
+its own archive is reconciled rather than rejected. Preserve already-reviewed
+legacy spec bytes, branch, and any proven recovery destination.
+
+A legacy rebuild can preserve a reviewed spec without this field. Its completion
+annotation must freeze the original `baseCommit`: resolve only prior builds and
+their completed reversals present at that base, derive `max(attempts) + 1`, and
+require the exact resulting archive path. For an integrated archive, its unique
+introducing commit's sole parent must equal that base. For unfinished completion,
+use Complete's phase proof. The path checks this derived attempt; it never supplies
+the number. Missing or ambiguous proof stops without rewriting the archived spec.
+Settled history numbering and rollback selection do not require the annotation's
+historical `head` or `sourceTree`; actual completion recovery still requires them.
+
+Before using prior builds or reversals, prove each selected record on the local
+default branch. Resolve the unique introducing commit with:
+
+```bash
+git log --full-history --diff-filter=A --format=%H <local-default> -- <archive-path>
+git log --full-history --format=%H <introducing-commit>..<local-default> -- <archive-path>
+```
+
+The first result must contain exactly one commit which actually adds the path;
+the second must be empty. Confirm the current blob and mode equal that addition
+(use Git's normal EOL normalization for a working-file comparison). Inspect the
+record at that commit, not an uncommitted replacement. Reject orphan, overwritten,
+deleted/re-added, renamed, multiply-added, or conflicting records. Never choose
+the newest commit, file count, or timestamp to resolve ambiguity.
+
+A build is reversed only by a completed `**Type:** Rollback` record in `devflow/history/rollbacks/` with its exact
+`**Target archive:**` and full `**Target commit:**`, matching feature ID, verified
+or complete status and finished steps. Its `Target parent` must match the target's
+sole parent. Prove that rollback record's unique unchanged addition
+by the same procedure, reachable on the local default after the target build.
+Require a non-merge rollback commit containing that record and its completed
+plan bookkeeping. Uncommitted, malformed, changed, or merely rollback-looking
+files are not completed reversals. Conflicting or duplicate reversals stop.
+
+Include exact rollback references retained on the selected plan line; missing
+referenced records are a blocker, not an empty history. For a new unchecked feature,
+use 1 when there are no prior records; otherwise
+require every prior build to have one proven completed reversal and allocate
+`max(attempts) + 1`. Duplicate attempts or inconsistent/missing history stop with
+the exact paths and missing proof. Search only this feature's records and their
+exact reversal references. Ignored local-only history without introducing-commit
+proof cannot establish a rebuild or rollback target; stop without force-adding or
+migrating it. Ordinary first builds do not require prior history.

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

@@ -26,32 +26,32 @@ When invoked:
 3. Allocate the next sequential ID (e.g. `IDEA-001`, `IDEA-002`).
 
 ### 2. AI Feasibility & Value Analysis
-Evaluate the user's raw idea and generate an enriched summary in **Thai (`th`)**:
-- **ไอเดียตั้งต้น (Raw Idea)**: ข้อความที่ผู้ใช้ระบุ
-- **AI Feasibility & Tech**: ประเมินความเป็นไปได้ (ง่าย / ปานกลาง / ซับซ้อน) พร้อมแนะนำ Library, API, หรือแนวทางเทคนิคเบื้องต้น
-- **Value & Potential**: คุณค่า ประโยชน์ และความน่าสนใจของฟีเจอร์นี้
-- **Quick Seed (สรุปประเด็นกันลืม)**: 2-3 ประเด็นทางเทคนิคหรือแนวทางการต่อยอด เพื่อให้กลับมาอ่านทีหลังแล้วจำบริบทได้ทันที
+Evaluate the user's raw idea and generate an enriched entry in Thai (`th` per user communication rules):
+- **Raw Idea**: The user's input description
+- **AI Feasibility & Tech**: Feasibility rating (Easy / Medium / Complex) along with recommended libraries, APIs, or architectural approaches
+- **Value & Potential**: Business value, user benefits, and strategic impact
+- **Quick Seed**: 2-3 key technical nuances or seed points to preserve context for later pickup
 
 ### 3. Append to `devflow/ideas.md`
 Insert the new idea block directly under `## 📌 Pending Ideas` in `devflow/ideas.md`:
 
 ```markdown
-### [IDEA-001] {หัวข้อไอเดียสั้นๆ}
+### [IDEA-001] {Brief idea title}
 - **บันทึกเมื่อ**: {YYYY-MM-DD}
-- **ไอเดียตั้งต้น**: {ข้อความที่ผู้ใช้ป้อน}
-- **AI Feasibility & Tech**: {บทวิเคราะห์ความเป็นไปได้และเครื่องมือ}
-- **Value & Potential**: {บทวิเคราะห์คุณค่าและความน่าสนใจ}
+- **ไอเดียตั้งต้น**: {User's raw idea text}
+- **AI Feasibility & Tech**: {Feasibility and tooling analysis}
+- **Value & Potential**: {Value and impact analysis}
 - **Quick Seed (กันลืม)**:
-  1. {ประเด็นสำคัญที่ 1}
-  2. {ประเด็นสำคัญที่ 2}
-- **สถานะ**: `Pending` (หยิบไปทำได้ด้วย `/feature IDEA-001` หรือ `/discovery IDEA-001`)
+  1. {Key point 1}
+  2. {Key point 2}
+- **สถานะ**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
 ```
 
-*(หากมีข้อความ `*(ยังไม่มีไอเดียค้างอยู่...)*` ให้ลบออกเมื่อมีไอเดียแรก)*
+*(If placeholder `*(ยังไม่มีไอเดียค้างอยู่...)*` exists, remove it upon recording the first idea)*
 
 ### 4. Output Summary
 Report to the user:
 - Allocated Idea ID: `[IDEA-xxx]`
 - Summary of Feasibility & Value analysis
 - Seed points saved
-- Instructions for promotion: "เมื่อพร้อมลงมือทำ สามารถพิมพ์ `/feature IDEA-xxx` หรือ `/discovery IDEA-xxx` ได้ทันที"
+- Instructions for promotion: "Ready to implement? Run `/feature IDEA-xxx` or `/discovery IDEA-xxx` anytime."

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

@@ -53,16 +53,23 @@ skill.
 
 ## Step 1 - resolve the exact feature
 
-Match the requested number or name against both the checked build-plan items and
-`devflow/history/features/*.md`. Exclude the directory README.
-
-Use the archive path to locate the commit that added it:
-
-    git log --diff-filter=A --format="%H %s" HEAD -- <archive-path>
-
-Use the newest matching commit reachable from the current branch. Confirm the
-archive was added by that commit and its subject and diff are consistent with the
-requested feature. If the target is a merge commit, stop before Step 2 and before
+Resolve the requested number or name to one checked build-plan ID; for an archive
+path, read its exact spec identity first and match that checked item. Then gather
+all exact-ID feature archive candidates using `../feature/reference/build-history.md`.
+Normalize the stable ID, retaining its letter, and read attempts from verified
+spec metadata/history proof, never arbitrary title or filename suffixes.
+
+For each candidate, require its unique introducing commit on the local default
+and prove the archive blob and mode have not changed since that addition. Exclude
+builds with a proven completed reachable rollback naming that exact archive and
+introducing commit. The checked item must have exactly one unreversed build.
+An explicit archive request stays bound to that exact path: reject it if already
+reversed, rather than silently choosing another build. Ambiguous, orphan,
+overwritten, multiply-added, or missing records stop with their exact paths and
+missing proof. Do not select by newest commit, filename order, or rollback date.
+
+Confirm the selected commit's diff is consistent with the requested feature.
+If the target is a merge commit, stop before Step 2 and before
 writing or changing `devflow/context/{xxx-slug}/spec.md`. Do not record a
 target parent or choose a mainline. Publish `blocked` to
 `devflow/.state/run.json`, explain that DevFlow cannot safely infer which
@@ -129,6 +136,12 @@ Allocate sequential ID (`xxx-slug`) and create `devflow/context/{xxx-slug}/`. Wr
 - compatibility work that is allowed, if any
 - exact verification commands and observable removal criteria
 
+Before freezing a new rollback spec, apply the archive-path and branch-availability
+checks in `../feature/reference/build-history.md` to its planned branch and
+`YYYY-MM-DD-<exact-target-archive-stem>.md` destination. Retain `--build-N` in the
+target stem when present. A collision stops for an explicit decision; never
+renumber the target or silently rename reviewed work. Existing completion recovery runs first.
+
 The first build step must apply the target commit's product diff in reverse using
 the guarded Type: Rollback behavior in `/implement`. Later steps may repair only
 the specific downstream compatibility issues named in the spec. Do not use a

package/template/.claude/skills/analyze/SKILL.md

@@ -21,10 +21,10 @@ contract in `AGENTS.md`.
 ```text
 # 1. Ingest specific file from any path (PDF, DOCX, XLSX, Image, CSV, Text)
 /analyze C:\Users\...\Downloads\customer-spec.pdf
-/analyze ./mockup.png ./schema.xlsx "ระบบสะสมแต้มสมาชิก"
+/analyze ./mockup.png ./schema.xlsx "Loyalty point system"
 
 # 2. Ingest raw text or requirement from chat
-/analyze "ลูกค้าต้องการระบบผ่อนชำระ 0% เชื่อมกับ KBank Payment Gateway..."
+/analyze "Customer requested 0% installment plan connected to KBank Payment Gateway..."
 
 # 3. Scan pending unassigned files in devflow/inbox/
 /analyze
@@ -46,50 +46,50 @@ contract in `AGENTS.md`.
 
 ---
 
-### Step 1: Auto-Allocate Workspace & Ingestion (Frictionless Ingest)
+## Step 1: Auto-Allocate Workspace & Ingestion (Frictionless Ingest)
 1. **Allocate REQ-ID**: Generate sequential ID format `REQ-YYYYMMDD-NNN` (e.g. `REQ-20260903-001-point-system`).
 2. **Create Request Workspace**:
    ```text
    devflow/inbox/{REQ-ID}/
-   ├── raw/                # เก็บไฟล์ต้นฉบับ (PDF, Word, Excel, Images, Email)
-   ├── parsed.md           # ข้อความ/ตารางที่สกัดออกมาแล้ว (Clean Markdown)
-   └── clarifications.md   # รายการคำถามที่ต้องไปถาม Stakeholder เพิ่ม
+   ├── raw/                # Original source files (PDF, Word, Excel, Images, Email)
+   ├── parsed.md           # Extracted structured text/tables (Clean Markdown)
+   └── clarifications.md   # Questions and clarifications checklist for stakeholders
    ```
 3. Copy or save incoming files into `devflow/inbox/{REQ-ID}/raw/`.
 
 ---
 
-### Step 2: Parse & Normalize Requirement (`parsed.md`)
+## Step 2: Parse & Normalize Requirement (`parsed.md`)
 1. Extract text and tables from all raw files:
    - For Office/PDF docs: Invoke `convert-any-to-md` or document extractor.
    - For Web URLs / Confluence / Notion: Invoke `defuddle`.
    - For Images / Wireframes / Screenshots: Conduct Multimodal Vision OCR and describe layout and fields.
 2. Structure into `devflow/inbox/{REQ-ID}/parsed.md`:
-   - **Executive Summary**: วัตถุประสงค์หลักของ Requirement
-   - **Target Persona & User Stories**: ใครทำอะไร เพื่ออะไร
-   - **Functional Requirements (FR)**: รายการฟังก์ชันและ Business Rules
-   - **Non-Functional Requirements (NFR)**: Performance, Security, PDPA, Retention
-   - **Data Entities & Fields**: ฟิลด์ข้อมูลและชนิดข้อมูลเบื้องต้น
+   - **Executive Summary**: Core purpose and business objective of the requirement
+   - **Target Persona & User Stories**: Who performs what action and why
+   - **Functional Requirements (FR)**: List of functions and business rules
+   - **Non-Functional Requirements (NFR)**: Performance, Security, PDPA/Privacy, Data Retention
+   - **Data Entities & Fields**: Data fields, schemas, and initial types
 
 ---
 
-### Step 3: Codebase Impact & Blast Radius Analysis (`codebase-impact.md`)
-*(ดำเนินการเมื่อเป็นระบบเดิม / Brownfield Codebase)*
+## Step 3: Codebase Impact & Blast Radius Analysis (`codebase-impact.md`)
+*(Execute when operating on an existing system / brownfield codebase)*
 
 1. Search codebase patterns using `grep_search`, `rg`, and AST analysis for affected models, controllers, APIs, and routes.
 2. Calculate **Blast Radius & Complexity Score**:
-   - **Affected Files & Modules**: รายการไฟล์ที่ต้องแก้ไขหรือสร้างใหม่
-   - **API & Contract Breaking Risk**: ตรวจสอบว่ากระทบกับ API เดิมหรือ Third-Party หรือไม่
-   - **Complexity Rating**: `Low` | `Medium` | `High` | `Extreme` พร้อมเหตุผล
+   - **Affected Files & Modules**: List of files to be modified or newly created
+   - **API & Contract Breaking Risk**: Check if existing APIs or third-party contracts are impacted
+   - **Complexity Rating**: `Low` | `Medium` | `High` | `Extreme` with rationale
 3. Save analysis report to `devflow/analysis/{REQ-ID}/codebase-impact.md`.
 
 ---
 
-### Step 4: Socratic Gap Detection & Clarification Checklist (`clarifications.md`)
+## Step 4: Socratic Gap Detection & Clarification Checklist (`clarifications.md`)
 1. Apply `grilling` and `domain-modeling` lenses to detect gaps:
-   - **Missing Edge Cases**: เงื่อนไขขอบ, กรณีข้อมูลผิดพลาด, เน็ตหลุด, Concurrent Requests
-   - **Ambiguous Business Rules**: กฎที่ยังคลุมเครือ ไม่ระบุ SLA หรือขั้นตอนที่ชัดเจน
-   - **Security & Authorization**: การกำหนด Role, สิทธิ์การเข้าถึงข้อมูล, ข้อมูลส่วนบุคคล (PII)
+   - **Missing Edge Cases**: Boundary conditions, error states, network drops, concurrent requests
+   - **Ambiguous Business Rules**: Unclear policies, unspecified SLAs, or undefined workflows
+   - **Security & Authorization**: Role definitions, access permissions, personal identifiable data (PII)
 2. Generate an actionable checklist in `devflow/inbox/{REQ-ID}/clarifications.md` for the SA to take directly into stakeholder meetings.
 
 ---