@jakkrichm/create-nexus-devflow 2.17.5 → 2.17.7

package/template/.claude/skills/check/reference/verify.md

@@ -0,0 +1,129 @@
+# Check verification
+
+**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.
+
+Verification activity was started by the dispatcher before loading this reference.
+
+Where this sits in the workflow:
+
+    /implement  ->  [check]  ->  /complete
+    (built a       (run the app,    (only once the
+     step or        prove each       done-whens are
+     the feature)   done-when)       proven)
+
+`/implement` builds and does a quick build-plus-screenshot check inline. `/check`
+is the deeper, repeatable gate for when a "done when" needs the *real running app*,
+not just a green build: a click that triggers a download, a route that returns a
+file, a flow across screens. Run it on a single step whose done-when is
+behavioral, or on the whole feature as the acceptance check before `/complete`.
+
+The point is evidence. A passing build proves the code compiles; `/check` proves
+the thing the spec promised actually happens. It changes no source and commits
+nothing - it runs the app and reports what it saw.
+
+## Input
+
+Optional: a specific thing to check (a step, a flow, a URL). With no argument,
+verify the whole current feature against every "done when" in
+`devflow/context/{xxx-slug}/spec.md`.
+
+## Step 1 - build the checklist
+
+Read `devflow/config.json` first. A missing file means the built-in defaults
+apply. If the file exists but is invalid, stop and point the user to `/doctor`.
+Configuration never grants permission to start a server or take any other action
+that the project instructions or user have not authorized.
+The quality-gate config controls automatic invocation only. An explicit `/check`
+or `$check` request always runs.
+
+Read `devflow/context/{xxx-slug}/spec.md`. Pull the observable "done when"
+criteria from the build steps (and any acceptance notes in the Testing section).
+Turn them into a concrete checklist of claims to prove - each one a specific,
+observable behavior, not "it works". If the user named one thing, scope to that.
+
+If there's no active feature spec, ask what to verify rather than guessing.
+
+## Step 2 - get the app running
+
+Use the project's real commands (see Commands in `AGENTS.md`). Match the project
+type:
+
+- **Web app** - start (or reuse) the dev/preview server, then drive a real browser
+  to the relevant routes. Prefer reusing an already-running server over starting a
+  duplicate. If `AGENTS.md` declares `Browser tests: <command>`, run that exact
+  command as repeatable evidence and use its harness for covered interactions.
+  Reuse runner-owned server lifecycle instead of starting a duplicate. A green
+  suite is one evidence source, not proof of claims it does not observe. If no
+  command is declared but Playwright is already installed, prefer it for browser
+  driving, screenshots, console errors, and failed request checks. Never install
+  it from `/check`; use another real-browser evidence path and report what you
+  used, or point to `/browser-tests` for later optional setup.
+- **CLI** - run the actual command(s) with representative inputs.
+- **Server/API** - start it and hit the endpoints.
+- **Library** - exercise the public API through an example or the test command.
+
+If a `test` command is declared in `AGENTS.md`, you may run it as *one* input, but
+`/check` is broader than unit tests: it checks real behavior, which is exactly the
+evidence UI and integration steps ride on instead of unit tests.
+
+## Step 3 - exercise each claim
+
+Drive the app to each checklist item and capture evidence as you go:
+
+- Navigate and interact for real (click, type, submit, download) - don't assert
+  from the code what the running app would do.
+- Capture **screenshots** for visual/UI claims, **output** for CLI/API claims.
+- Watch for **console errors and failed network requests**; a clean-looking screen
+  with errors in the console is not a pass.
+
+With `verification.uiEvidence: "required"`, every UI claim needs direct browser
+evidence, including a screenshot and the relevant console and network check. If
+that evidence path is unavailable, mark the claim unverifiable instead of
+passing it from build output. With `when-available`, use the strongest available
+evidence and report any gap plainly.
+
+### AC-to-Test Traceability Verification:
+Cross-reference each Acceptance Criterion (`- [ ] **AC-N**`) in `spec.md` against the test suite's executed assertions and observable evidence:
+- Match tagged test cases (e.g. `it('AC-1: ...')`) to their respective criteria.
+- Ensure 100% of defined acceptance criteria have empirical proof before issuing a `verified` status.
+
+
+## Step 4 - report
+
+Give a short, honest verdict, one line per checklist item:
+
+    [pass] Download PDF saves certificate-<slug>.pdf - file downloaded, opened to the cert
+    [pass] Both buttons show a loading state - screenshot: loading-state.png
+    [fail] PDF border missing - printBackground not set; screenshot: pdf-no-border.png
+    [skip] Vercel render - can't verify locally (feature 9)
+
+Then state the bottom line: are all the feature's done-whens proven, or not yet.
+
+- All proven -> update only the `**Status:**` line in
+  `devflow/context/{xxx-slug}/spec.md` to `verified`, then say it is ready for
+  `/complete`.
+- Anything failed -> update only that status line to `verification failed`, then
+  hand back to `/implement`; name what to fix. Do not fix it here.
+- Anything unverifiable -> update only that status line to `verification
+  incomplete`, then say why; never report it as a pass.
+
+The status-line update is generated workflow state, not a product-source edit.
+Do not change the spec, checkboxes, findings, or product files from `/check`.
+
+## Rules
+
+- **Observe product behavior, don't repair it.** `/check` changes only the
+  current spec's status line as described above. It never edits product source,
+  commits, or merges. Fixing is `/implement`'s job.
+- **Evidence or it didn't happen.** Every `pass` is backed by something observed -
+  a screenshot, output, a response. No assumed passes from reading the code.
+- **Honest over green.** "Couldn't verify" and "failed" are valid, useful results.
+  Faking a pass defeats the entire gate.
+- **Check the spec, not vibes.** Verify against the done-whens in
+  `spec.md`, so "works" means what the spec said it would do.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -1,10 +1,13 @@
 ---
 name: ci
-description: "[devflow] Set up or normalize one project Verify command and matching GitHub Actions checks while preserving existing CI. Use for /ci, GitHub Actions setup, pull-request checks, automatic checks, or aligning verification."
+description: "[devflow] Set up or normalize one project Verify command and matching GitHub Actions checks while preserving existing CI, with an optional local pre-push hook. Use for /ci, GitHub Actions setup, pull-request checks, automatic checks, pre-push hooks, or aligning verification."
+argument-hint: "[--hook | --no-hook]"
 ---
 
 # ci - set up automatic GitHub checks
 
+**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`.
@@ -15,7 +18,7 @@ Where this sits in the workflow:
     (project commands)     (setup)    (same recipe)      (pull requests)
 
 This skill gives local work and GitHub one shared automated command. It is an
-optional setup task, not a requirement for using the Blueprint.
+optional setup task, not a requirement for using DevFlow.
 
 Keep the beginner explanation simple:
 
@@ -23,9 +26,12 @@ Keep the beginner explanation simple:
 - **GitHub Actions is the worker.** It runs the same recipe automatically.
 - **A GitHub ruleset is the lock.** That optional remote setting can require the
   worker to report green before merge.
+- **A pre-push hook is the early warning.** That optional local setting runs the
+  recipe before a push leaves the machine. It is a convenience, not the lock:
+  `git push --no-verify` skips it.
 
-This skill configures the recipe and worker. It never changes the remote ruleset,
-pushes, publishes, deploys, or adds local git hooks.
+This skill configures the recipe and worker, and adds the hook only when the
+user opts in. It never changes the remote ruleset, pushes, publishes, or deploys.
 
 ## Input
 
@@ -47,7 +53,7 @@ Read enough to identify the real project setup:
 - `.github/workflows/` and any documented external CI
 - git's current branch, configured default branch, and remotes when available
 
-Do not assume npm, Node.js, `main`, or GitHub from the Blueprint template. Do not
+Do not assume npm, Node.js, `main`, or GitHub from the DevFlow template. Do not
 run installs or edit files during inspection.
 
 If an existing workflow already provides equivalent pull-request checks, explain
@@ -107,6 +113,33 @@ before writing the push trigger instead of guessing. Preserve all other workflow
 files. When another workflow overlaps, report the overlap and ask whether to
 reuse, align, or leave it alone.
 
+## Step 3b - offer a local pre-push hook (opt-in)
+
+After the workflow exists, ask one question and default to no:
+
+    Also add a local pre-push hook that runs Verify before every push? [y/N]
+
+Skip the question when the request already answered it (for example "/ci with
+hook" or "no hook"). When the answer is no, write nothing and move on. When it
+is yes:
+
+1. Write `.githooks/pre-push` (mode 755) that announces itself and then runs
+   the exact `Verify` command from `AGENTS.md` with `exec`, so the command's
+   exit code is the hook's exit code.
+2. Point git at the folder: `git config core.hooksPath .githooks`.
+3. For JavaScript and TypeScript projects, add a `prepare` script,
+   `git config core.hooksPath .githooks 2>/dev/null || true`, so a fresh
+   install wires the hook without a manual step. The `|| true` keeps installs
+   working where no git checkout exists, such as a deploy build. For other
+   stacks, document the `git config` line in the README instead.
+4. Run the hook once (`.githooks/pre-push`). If it fails, remove what this
+   step added and report the failing subcommand. Never leave a hook the
+   project cannot pass.
+
+The hook and the workflow run the same `Verify` command; if one changes, the
+other changes with it. Say in the report that `--no-verify` bypasses the hook,
+so the GitHub ruleset remains the lock.
+
 ## Step 4 - prove the setup locally
 
 Run the exact documented `Verify` command locally. The individual build, test,
@@ -134,6 +167,7 @@ Finish with a concise setup report:
 - checks included and checks omitted
 - test gate status
 - workflow path and triggers
+- whether a pre-push hook was added, and that `--no-verify` bypasses it
 - local Verify result and whether CI is only prepared locally or confirmed by a
   successful GitHub run
 - files changed
@@ -145,7 +179,7 @@ part of this skill.
 
 ## Interaction with other skills
 
-- `/tests` adds the real test command to an existing Verify command, but never
+- `/setup-tests` or `/test` adds the real test command to an existing Verify command, but never
   creates CI by itself.
 - `/implement`, `/complete`, and `/autopilot` run Verify when it is documented,
   with their existing fallback behavior when it is absent.
@@ -156,8 +190,8 @@ part of this skill.
 
 - Preserve existing CI and custom checks.
 - Never invent tests or install a runner as part of CI setup.
-- Never add git hooks, coverage, browser tests, security scans, or matrices by
-  default.
+- Never add coverage, browser tests, security scans, or matrices by default.
+- Add a git hook only through the Step 3b opt-in, never silently.
 - Never push or change a remote ruleset without separate explicit approval.
 - Keep one exact Verify command shared by local work and GitHub.
 

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

@@ -106,6 +106,8 @@ Before logging or committing, run a short safety pass and report blockers only:
 - no P0 or P1 finding in `devflow/context/{xxx-slug}/findings.md` is `open` or `fixed`.
   `fixed` still blocks on purpose: the repair exists but no review has looked at
   it - run `/audit` to close it. The only waivers are `accepted` or `invalid`.
+- any `Status: Assumed` ADR in `devflow/decisions/` has been surfaced with its ratification plan noted.
+
 
 Do not claim "passed", "verified", or "working" without naming the command,
 route, screenshot, or output that proves it. Stop before Step 1 if required

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

@@ -77,10 +77,18 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
    - Codebase-grounded interactive inquiry to clarify entity boundaries, data flows, and edge cases.
    - Record agreed terminology in `devflow/context/glossary.md` and major architecture decisions in `devflow/decisions/ADR-xxx-{slug}.md`.
 6. **🎨 Visual Architecture & Diagram Design Lens (`archify` / `diagram-design`)**:
-   - When exploring system topologies, legacy IT modernizations, sequence flows, data platform pipelines, state machines, or user journeys, check for `archify` or `diagram-design` in `.agents/skills/`.
-   - **For interactive system architecture, dataflows, state transitions, and sequence traces**: Use `archify` (`.agents/skills/archify/SKILL.md`) to compile validated interactive HTML artifacts with dark/light themes, motion, and route probes.
-   - **For editorial, business, quadrant, or broad diagram types**: Use `diagram-design` (`.agents/skills/diagram-design/SKILL.md`).
+   - When exploring system topologies, legacy IT modernizations, sequence flows, data platform pipelines, state machines, or user journeys, check for `archify` or `diagram-design` in `.claude/skills/`.
+   - **For interactive system architecture, dataflows, state transitions, and sequence traces**: Use `archify` (`.claude/skills/archify/SKILL.md`) to compile validated interactive HTML artifacts with dark/light themes, motion, and route probes.
+   - **For editorial, business, quadrant, or broad diagram types**: Use `diagram-design` (`.claude/skills/diagram-design/SKILL.md`).
    - Save diagram artifacts to `devflow/discoveries/{DISCOVERY_ID}-{slug}/diagrams/{name}.html` and reference them directly in `discovery.md`.
+7. **🧩 Slicing & Decomposition Lens (4 Slicing Archetypes)**:
+   - When breaking down a large initiative into sub-features or milestones, evaluate against [`devflow/reference/slicing-archetypes.md`](file:///d:/Projects/devtools/nexus-devflow/devflow/reference/slicing-archetypes.md):
+     - **Skateboard**: Minimal functional loop (prove core logic end-to-end with minimal UI).
+     - **Facade**: Rich UI/DX with mock backend (validate user flow & interaction first).
+     - **Tracer Bullet**: Deep vertical slice across all layers (DB -> API -> UI) for 1 happy path.
+     - **Journey**: Slice along natural user workflow milestones.
+   - Recommend the primary Archetype for each proposed sub-feature in `discovery.md`.
+
 
 ### Decision & Approval Gate:
 Set one visible decision:

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

@@ -100,6 +100,10 @@ Gather these, then summarize. Do not dump file contents.
      report it as an obsolete installer artifact. Its absence is healthy. An
      unchanged managed copy can be removed by the updater; a modified copy needs
      user review.
+   - Check whether `AGENTS.md` contains substantive proportional-engineering
+     guidance (`## Proportional engineering` or equivalent rules). Warn if
+     missing, explaining that updates preserve this file and provide manual repair
+     guidance.
    - Check whether `AGENTS.md` has a `## Commands` section with dev and build
      commands.
    - Report missing lint or test commands as informational unless the project has
@@ -160,6 +164,8 @@ Gather these, then summarize. Do not dump file contents.
      last commit subject, and whether the branch is ahead of upstream.
    - If the directory is not a git repo, report that as a setup issue and keep
      going.
+9. **Token Economics & Session Cost Audit**
+   - When session transcript is available, report token efficiency, cache hit rate, and estimated model costs using `npm run analyze:tokens` or `scripts/analyze-token-usage.ts`.
 
 ## Output
 

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

@@ -0,0 +1,78 @@
+---
+name: explore
+description: "[devflow] Explore an idea against the actual codebase without changing files. Investigate whether a change would help, compare alternatives and tradeoffs, and discuss uncertainty before deciding whether to plan anything. Use for /explore, considering an idea, or weighing options without writing a spec."
+argument-hint: "[<idea or question>]"
+---
+
+# explore - investigate an idea before deciding to build
+
+**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.
+
+Explore is a read-only conversation grounded in the actual project. It can help
+with questions such as whether caching would help a dashboard, whether teams
+belong in the product, or which upload approach fits existing code.
+
+No plans or active feature are required. Do not require `/overview`, invent a
+plan, or treat missing DevFlow context as a blocker to discussing the idea.
+This command never writes activity state, including `devflow/.state/run.json`.
+
+## Start from the question
+
+Use the supplied topic or relevant conversation context. With neither, ask what
+the user wants to investigate. For a vague idea, state a tentative interpretation
+and ask a focused question only when its answer changes the investigation.
+
+Reuse context already loaded in the session. Read relevant project instructions,
+code, tests as text, manifests, and existing plans when they help answer the
+question. Follow the actual implementation far enough to support your claims;
+point to concrete files or symbols. Avoid scanning unrelated parts of the repo.
+Read-only Git inspection can establish what exists or is already in progress.
+
+Authoritative documentation lookup is appropriate when technical uncertainty
+needs it. Distinguish documented facts from what this project actually uses.
+Missing code or evidence is an uncertainty to explain, not permission to execute
+an experiment or to invent current behavior.
+
+## Discuss the options
+
+Keep the conversation proportional to the question. Compare plausible options
+against the user's needs and existing project constraints. Include doing nothing
+when the current behavior may already be sufficient. Do not invent scale,
+security requirements, or new abstractions to justify a change.
+
+Explain the strongest case against your recommendation and how confident you
+are. Separate observed facts, assumptions, and unanswered questions. Say what
+evidence could change the recommendation without gathering it through execution.
+An unresolved question or a recommendation to leave the project alone is a valid
+outcome.
+
+Use a small diagram in the response when it makes a relationship or tradeoff
+clearer. Do not create diagram files. There is no mandatory output template,
+report, question count, or next-step checklist. Follow the user's responses and
+let the discussion continue as long as useful.
+
+## Keep the boundaries clear
+
+- Never create, edit, or delete files, including specs, plans, notes, generated
+  output, and activity state. Do not save the conversation into the project.
+- Never install dependencies, execute product code, run tests or builds, start
+  servers, perform browser interactions, or call state-changing tools. Read
+  source and existing evidence instead of testing a hypothesis by execution.
+- Never create or switch branches, commit, merge, push, publish, or deploy.
+- Never turn a request to discuss an idea into approval to plan or implement it.
+  If the user asks for changes, explain the appropriate handoff and keep this
+  Explore invocation read-only. Do not invoke another command automatically.
+
+## Neighbors and handoff
+
+- `/brief` explains an existing build-plan item, its scope, dependencies, and
+  size. Explore can discuss an unplanned idea or question a planned approach.
+- `/discovery` develops broader product direction and reviewed planning drafts.
+  Explore does not draft either planning file.
+- `/debug` reproduces and isolates an actual failure. Explore discusses options
+  without executing code to diagnose or verify them.
+- `/feature` writes a buildable spec; `/fix` specifies a confirmed small change.
+  Suggest the appropriate command only when the user is ready to proceed.
+
+Do not force a handoff at the end of every response. Keep discussing the idea
+when that is what the user wants, and leave the project unchanged.

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

@@ -102,6 +102,8 @@ the data model, stack, and conventions. Decide how big the feature is:
   those sub-items back under the parent in `build-plan.md` as an indented
   checklist (`4a`, `4b`, `4c` ...). Spec only the **first** sub-feature now; the
   rest get picked up on later `/feature` runs.
+  *Use the **4 Slicing Archetypes** ([`devflow/reference/slicing-archetypes.md`](file:///d:/Projects/devtools/nexus-devflow/devflow/reference/slicing-archetypes.md)) to guide the split: 🛹 Skateboard (core logic first), 🎭 Facade (UI/DX mock first), 🎯 Tracer Bullet (end-to-end slice), or 🧭 Journey (workflow steps).*
+
 
 Two levels of breakdown - don't confuse them:
 
@@ -198,7 +200,7 @@ Before the user reads it, turn on the spec yourself and try to break it. The
 cheapest place to catch a scope problem or an oversized step is here, before any
 code exists. Run the draft against these questions:
 
-- **Coverage.** What does this feature need that no step delivers? Push on the
+- **Coverage & Input Mapping.** What does this feature need that no step delivers? Run a mechanical **Input Coverage Test**: does every value this build produces, displays, or computes have a named source (input, DB column, formula, or settled decision) in the spec? Push on the
   unhappy paths the happy-path spec skipped: empty / missing / malformed input,
   the error / loading / empty states, the first-run case, failure of anything
   external it calls.
@@ -218,6 +220,7 @@ code exists. Run the draft against these questions:
   anything pushed to "out of scope" that this feature actually can't ship without?
 - **Done-whens.** Is each one observable and checkable by `/check`, or is it a
   vague "it works"? Make it concrete.
+- **Proportionality.** Does any proposed abstraction, dependency, service, config surface, or security mechanism lack a current requirement, or duplicate existing code/platform features? If so, remove it.
 - **Testing.** Does the predicted coverage match the gate - in-scope logic gets a
   test when a `test` command is declared in `AGENTS.md`, UI/integration rides on
   screenshot + build?

package/template/.claude/skills/feature/reference/feature-spec-template.md

@@ -14,18 +14,18 @@
 ## 1. Specification & Scope
 
 ### 1.1 Problem Statement
-{คำอธิบายปัญหาและที่มาของความจำเป็นในการพัฒนาฟีเจอร์นี้}
+{Description of the problem, background, and rationale for developing this feature}
 
 ### 1.2 In-Scope
-1. {ขอบเขตการทำงานข้อที่ 1}
-2. {ขอบเขตการทำงานข้อที่ 2}
+1. {In-scope item 1}
+2. {In-scope item 2}
 
 ### 1.3 Out-of-Scope
-- {สิ่งที่อยู่นอกเหนือขอบเขตหรือไม่ทำในรอบนี้}
+- {Items deliberately excluded or deferred to future features}
 
-### 1.4 Acceptance Criteria (เกณฑ์การยอมรับ)
-- [ ] **AC-1**: {เกณฑ์การตรวจรับข้อที่ 1}
-- [ ] **AC-2**: {เกณฑ์การตรวจรับข้อที่ 2}
+### 1.4 Acceptance Criteria
+- [ ] **AC-1**: {Acceptance criterion 1}
+- [ ] **AC-2**: {Acceptance criterion 2}
 
 ---
 
@@ -40,18 +40,18 @@
 - **Review Strategy**: One feature-level review packet at completion
 
 ### 2.3 Test Decision: Required (TDD) | Optional
-- **Rationale**: {เหตุผลความจำเป็นในการเขียน Unit Tests / TDD}
+- **Rationale**: {Reason for requiring Unit Tests / TDD}
 
 ---
 
 ## 3. Implementation Checklist (Strict TDD)
 
-- [ ] **Task 1: {หัวข้องานที่ 1}**
-  - [ ] 1.1 `[TDD-Red]`: {เขียน Test เคสล้มเหลว}
-  - [ ] 1.2 `[TDD-Green]`: {เขียนโค้ดขั้นต่ำเพื่อให้ Test ผ่าน}
-  - [ ] 1.3 `[TDD-Refactor]`: {Refactor และตรวจให้ 100% Tests Green}
+- [ ] **Task 1: {Task 1 title}**
+  - [ ] 1.1 `[TDD-Red]`: {Write failing unit or behavioral test}
+  - [ ] 1.2 `[TDD-Green]`: {Write minimal implementation to pass test}
+  - [ ] 1.3 `[TDD-Refactor]`: {Refactor and ensure 100% tests green}
 
-- [ ] **Task 2: {หัวข้องานที่ 2}**
+- [ ] **Task 2: {Task 2 title}**
   - [ ] 2.1 `[TDD-Red]`: ...
   - [ ] 2.2 `[TDD-Green]`: ...
   - [ ] 2.3 `[TDD-Refactor]`: ...
@@ -65,11 +65,11 @@
 - **Automated Test Matrix**: TBD
 - **Static Contract Verification**: TBD
 - **Package Smoke Test**: TBD
-- **Findings Ledger**: ตรวจสอบ `findings.md` สะอาด 100%
+- **Findings Ledger**: Verify `findings.md` is 100% clean
 
 ### 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
-- [ ] **AC-1**: {หลักฐานการผ่านเกณฑ์ข้อที่ 1}
-- [ ] **AC-2**: {หลักฐานการผ่านเกณฑ์ข้อที่ 2}
+- [ ] **AC-1**: {Empirical proof for AC-1}
+- [ ] **AC-2**: {Empirical proof for AC-2}
 
 ---
 

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

@@ -70,10 +70,14 @@ Allocate the next sequential ID (`ADR-001`, `ADR-002`, ...) and create `devflow/
 ```markdown
 # ADR-xxx: {Title}
 
-- **Status**: Accepted
+- **Status**: Accepted | Assumed (Fast-tracked Assumption)
 - **Date**: {YYYY-MM-DD}
 - **Context**: {Why was this decision needed? What problem does it solve?}
 - **Decision**: {What did we decide to do?}
+- **Assumption Metadata** *(Required when Status is Assumed)*:
+  - **Assumption**: {What was assumed to unblock progress}
+  - **Risk Level & Blast Radius**: {Risk if assumption fails}
+  - **Ratification Plan**: {Trigger, date, or test to ratify as Accepted or Rejected}
 - **Alternatives Considered**:
   - *Option 1*: {Pros / Cons}
   - *Option 2*: {Pros / Cons}
@@ -82,6 +86,7 @@ Allocate the next sequential ID (`ADR-001`, `ADR-002`, ...) and create `devflow/
   - *Trade-offs / Risks*: {Costs, constraints, or follow-ups}
 ```
 
+
 ---
 
 ## 4. Closing & Handoff

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

@@ -26,7 +26,7 @@ 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 entry in Thai (`th` per user communication rules):
+Evaluate the user's raw idea and generate an enriched entry:
 - **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
@@ -37,17 +37,17 @@ Insert the new idea block directly under `## 📌 Pending Ideas` in `devflow/ide
 
 ```markdown
 ### [IDEA-001] {Brief idea title}
-- **บันทึกเมื่อ**: {YYYY-MM-DD}
-- **ไอเดียตั้งต้น**: {User's raw idea text}
+- **Recorded Date**: {YYYY-MM-DD}
+- **Original Idea**: {User's raw idea text}
 - **AI Feasibility & Tech**: {Feasibility and tooling analysis}
 - **Value & Potential**: {Value and impact analysis}
-- **Quick Seed (กันลืม)**:
+- **Quick Seed**:
   1. {Key point 1}
   2. {Key point 2}
-- **สถานะ**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
+- **Status**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
 ```
 
-*(If placeholder `*(ยังไม่มีไอเดียค้างอยู่...)*` exists, remove it upon recording the first idea)*
+*(If placeholder `*(No pending ideas...)*` exists, remove it upon recording the first idea)*
 
 ### 4. Output Summary
 Report to the user:

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

@@ -93,7 +93,12 @@ feature was started earlier and interrupted (often a cleared context). The spec
 its ticked steps are files, so pick up where it left off: read which steps are done,
 check the git branch and `git status`/log to see what is committed and what is still
 in the working tree, then continue from the **first unchecked step** instead of
-starting over.
+### Step 0 - Mechanical Input Coverage Pre-flight Gate
+
+Before touching code or executing build tasks, perform a positive **Input Coverage Test** against the active Living Spec:
+- Enumerate every value, state, or data field this implementation must produce, compute, or display (from the acceptance criteria and spec design).
+- For each required value, verify that the spec explicitly names where it comes from (e.g. database schema/column, API request parameter, calculated derivation from a named source, or explicit prior architectural decision).
+- **Anti-Hallucination Guard**: Any required value with no named source is an **Owed Decision**. Do NOT rationalize it as "just wiring" and do NOT silently invent an ad-hoc provider, schema field, or business rule. Stop and route to `/grill` or request user clarification before proceeding.
 
 ## Step 1 - branch
 
@@ -111,10 +116,13 @@ When implementing a rollback task, follow the exact safety procedure in `referen
 Work in small reviewable diffs, keeping progress in the selected spec.
 
 1. For logic or behavior changes with the test gate on, use Red-Green-Refactor: write a focused failing test, confirm the assertion fails for the missing behavior, implement the smallest change, then refactor with affected tests green. Preserve the user's existing work. Consult [TDD anti-patterns](tdd-anti-patterns.md) when test design needs it.
+   - **Proportional Engineering**: Add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only when the approved spec or an established repository requirement needs it now. Prefer existing code, standard library, and native platform features.
 2. Match the step's done-when and run focused checks. Documentation or formatting-only edits use structural checks and review; they do not require artificial unit tests. Capture relevant runtime or browser proof for behavioral criteria, following the selected Check policy.
 3. Fix failures caused by the change and rerun affected checks without requesting authorization again. Broaden verification when dependencies, failures, or risk justify it.
 4. Record the diff summary and evidence. Mark a step complete once its done-when passes and any configured per-step review has been approved. A repaired finding becomes `fixed` with resolution evidence; only a subsequent audit can close it. Apply the review cadence above before proceeding.
 
+Run a proportionality check before final verification: every new abstraction, dependency, service, configuration surface, compatibility layer, and security mechanism must trace to the approved spec or an established repository requirement. Remove speculative machinery this work added without weakening real trust-boundary validation, data-loss prevention, accessibility, or configured verification.
+
 At the final handoff, run the exact documented Verify command and all required gates. If there is no Verify command, use the project's declared build and test commands. Reuse a passing result for unchanged inputs within this pass; rerun affected gates after subsequent edits. Do not add tests or tools just to inflate the verification matrix.
 
 ### Ticket execution

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

@@ -87,6 +87,32 @@ When generating or logging test runs during `/implement` or `/check`:
 
 ---
 
+## 7. 5-Tier Test File Classification Strategy
+
+Do not write identical test patterns for all file types. Classify files into 5 distinct tiers:
+
+| Tier | Category / File Paths | Recommended Test Strategy | What NOT to do |
+| :--- | :--- | :--- | :--- |
+| 🧠 **Tier 1** | **Pure Logic & Algorithms**<br>`src/utils/`, `src/services/`, `lib/` | Fast in-memory Unit Tests with 100% boundary & edge cases coverage. Use TDD (Red-Green-Refactor). | Do not over-mock pure mathematical or transformation functions. |
+| 🎨 **Tier 2** | **UI Components**<br>`src/components/`, `src/pages/` | Component rendering, event dispatching, visual verification via Playwright / BrowserOS Neo. | **Prohibited**: Do not write trivial unit tests that merely assert static HTML tags exist. |
+| 🔌 **Tier 3** | **API & Data Integration**<br>`src/api/`, route handlers, DB models | Contract tests, schema validation (Zod), HTTP status codes, error payload shapes. | Do not test external third-party network APIs without isolated fakes. |
+| ⚙️ **Tier 4** | **Config & Build Tooling**<br>`*.json`, `*.yaml`, `scripts/` | Static contract validation (`npm run check:static`), budget linters (`npm run check:budgets`), smoke tests. | Do not skip static validation on build tool modifications. |
+| 📝 **Tier 5** | **Documentation & Prose**<br>`*.md`, `devflow/docs/` | Structural checks, markdown contract scans, and link integrity verification. | Do not write artificial unit test suites for documentation files. |
+
+---
+
+## 8. Acceptance Criteria (`AC-N`) Traceability Protocol
+
+To guarantee 100% spec fidelity, every automated test suite must trace back to the active Living Spec:
+- **Test Title Tagging**: Prefix test titles or describe blocks with the target Acceptance Criterion:
+  ```typescript
+  it('AC-1: enforces 32KB byte budget on SKILL.md files', async () => { ... });
+  it('AC-2: returns exit code 1 when budget violation occurs', async () => { ... });
+  ```
+- **Traceability Verification**: During `/check`, cross-reference every `- [ ] AC-N` against the passing test assertion name to ensure zero untracked requirements.
+
+---
+
 ## Relationship To DevFlow 2.6.x
 
 - **Classification**: Companion command & Engineering standard

package/template/AGENTS.md

@@ -28,6 +28,17 @@ Explicit user scope takes precedence over skill guidance, within runtime permiss
 
 Use focused checks during edits, and run the documented required gates before handoff. Repeat passing checks only after relevant changes, failures, or unresolved concerns. Apply TDD to logic and behavior changes; documentation-only edits need appropriate structural or review evidence.
 
+## Proportional engineering
+
+Build for established requirements, not hypothetical scale, threats, or future flexibility. Reuse existing code, the standard library, native platform features, and installed dependencies before adding machinery.
+
+- Unknown scale or extensibility defaults to the smaller reversible design. Do not infer enterprise, multi-tenant, hostile-user, or compliance requirements.
+- Derive trust and data-integrity boundaries from actual reachability: untrusted input, auth/session/ownership, shared persisted data, destructive operations, payments, secrets, and sensitive data.
+- Ask only when an unknown materially changes behavior, architecture, persisted data, interoperability, a real security boundary, or cost. Otherwise choose the simplest repository-native implementation.
+- Add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only for a current requirement.
+- Simplicity never removes real trust-boundary validation, data-loss prevention, accessibility, explicit security requirements, configured tests, or project rules.
+- Stack-specific template standards apply only when the project uses that stack.
+
 ## Project configuration
 
 `devflow/config.json` is the user-owned, machine-readable workflow policy for this project. Workflow skills read the relevant settings before acting. A missing file means built-in defaults. An invalid file falls back to defaults for read-only status reporting, but mutating workflow commands stop and point to `/doctor` instead of guessing.
@@ -50,7 +61,7 @@ Unused adapter families can be removed. Codex, Antigravity, GitHub Copilot, and
 
 ### Universal Invocation & Agent Directives:
 
-1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `continuous`, `analyze`, `discovery`, `idea`, `grill`, `brainstorm`, `bughunter`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `ci`, `test`, `setup-tests`, `browser-tests`, `autopilot`, `prototype`, `report-html`, `brief`, `audit`, `release`, `convert-any-to-md`, `publish-devflow`, `vendor`). The way you invoke commands depends on your AI Provider / Tool:
+1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `continuous`, `analyze`, `discovery`, `explore`, `idea`, `grill`, `brainstorm`, `bughunter`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `ci`, `test`, `setup-tests`, `browser-tests`, `autopilot`, `prototype`, `report-html`, `brief`, `audit`, `release`, `convert-any-to-md`, `publish-devflow`, `vendor`). The way you invoke commands depends on your AI Provider / Tool:
    - **Canonical Name (Plain text)**: Directly invoke or prompt the command by its standard name (e.g., `feature`, `implement`, `continuous`, `devflow`, `discovery`, `analyze`).
    - **Slash Prefix (`/`)**: For tools supporting slash commands (Claude Code, Google Antigravity, Gemini CLI), e.g., `/feature`, `/fix`, `/implement`, `/continuous`, `/devflow`, `/discovery`, `/analyze`.
    - **Dollar Prefix (`$`)**: For OpenAI Codex CLI or skill-invocation tools, e.g., `$feature`, `$fix`, `$continuous`, `$devflow`, `$discovery`, `$analyze`.