duaer-spec 0.9.0 → 0.11.0

package/.claude/rules/agents-workflow.md

@@ -40,7 +40,8 @@ cd .worktree/feat-login
 
 - Spec-sync for behavior changes; ADR when architecture/security/contracts change
 - One logical change per commit; leave the worktree clean
-- User/protocol-visible changes update E2E scenario docs
+- Risk-based verification per `.duaer/memory/testing.md` before accept / merge
+- User/protocol-visible changes update E2E scenario docs **and** run required L3 subsets
 - Merge into **`develop`** when done (hotfix: **`main`**, then back-merge **`develop`**)
 - **Handoff (mandatory):** stop worktree-bound processes → remove `.worktree/<id>` →
   restart from primary checkout on `develop` (`duaer handoff [--run]`, `.duaer/handoff.json`)

package/.claude/rules/duaer-spec.md

@@ -20,13 +20,17 @@ For new behavior, fixes, refactors that change product behavior, or architecture
    `.duaer/specs/<nnn-slug>/`). Work only in the worktree. Never commit
    `.worktree/`. Never develop on `main` or `develop`.
 1. **Silently follow** the procedure in `.claude/skills/duaer-do/SKILL.md`
-   (assign Brief → light tasks → implement → converge → handoff line).
-2. Do **not** wait for `/duaer-do` or any other skill invocation.
-3. Do **not** say “please run `/duaer-specify`” — you do it.
-4. Do **not** dump a methodology tutorial unless they ask how Duaer works.
-5. Merge to **`develop`** when done (hotfix: **`main`**, then back-merge
+   (assign Brief → **understand / confirm** → light tasks → implement →
+   converge → handoff line).
+2. If the ask is vague: restate precise goal / scope / acceptance and wait for
+   confirm (or ≤3 blocking questions) before coding. Do not invent product
+   decisions silently.
+3. Do **not** wait for `/duaer-do` or any other skill invocation.
+4. Do **not** say “please run `/duaer-specify`” — you do it.
+5. Do **not** dump a methodology tutorial unless they ask how Duaer works.
+6. Merge to **`develop`** when done (hotfix: **`main`**, then back-merge
    **`develop`**). Promote to **`main`** only if the user asks to go online.
-6. **Handoff (mandatory):** stop processes bound to `.worktree/<id>/`, remove
+7. **Handoff (mandatory):** stop processes bound to `.worktree/<id>/`, remove
    the worktree, then restart services from the primary checkout on `develop`
    using `.duaer/handoff.json` / `duaer handoff [--run]`. Never leave the user
    on a dead worktree server.
@@ -43,6 +47,8 @@ For new behavior, fixes, refactors that change product behavior, or architecture
 ## Forbidden
 
 - Jump from chat to code with no Brief under `.duaer/specs/`.
+- Jump from a vague ask to implementation without restating and confirming
+  intent (see Understand in `duaer-do`).
 - Making the human operate the workflow.
 
 ## Optional finer tools (agent-only)

package/.cursor/rules/agents-workflow.mdc

@@ -43,7 +43,8 @@ cd .worktree/feat-login
 
 - Spec-sync for behavior changes; ADR when architecture/security/contracts change
 - One logical change per commit; leave the worktree clean
-- User/protocol-visible changes update E2E scenario docs
+- Risk-based verification per `.duaer/memory/testing.md` before accept / merge
+- User/protocol-visible changes update E2E scenario docs **and** run required L3 subsets
 - Merge into **`develop`** when done (hotfix: **`main`**, then back-merge **`develop`**)
 - **Handoff (mandatory):** stop worktree-bound processes → remove `.worktree/<id>` →
   restart from primary checkout on `develop` (`duaer handoff [--run]`, `.duaer/handoff.json`)

package/.cursor/rules/duaer-spec.mdc

@@ -24,13 +24,17 @@ For new behavior, fixes, refactors that change product behavior, or architecture
    `.worktree/`. Never develop on `main` or `develop`.
 1. **Silently follow** the procedure in the `duaer-do` skill
    (`.cursor/skills/duaer-do/SKILL.md` or `.claude/skills/duaer-do/SKILL.md`)
-   (assign Brief → light tasks → implement → converge → handoff line).
-2. Do **not** wait for `/duaer-do` or any other skill invocation.
-3. Do **not** say “please run `/duaer-specify`” — you do it.
-4. Do **not** dump a methodology tutorial unless they ask how Duaer works.
-5. Merge to **`develop`** when done (hotfix: **`main`**, then back-merge
+   (assign Brief → **understand / confirm** → light tasks → implement →
+   converge → handoff line).
+2. If the ask is vague: restate precise goal / scope / acceptance and wait for
+   confirm (or ≤3 blocking questions) before coding. Do not invent product
+   decisions silently.
+3. Do **not** wait for `/duaer-do` or any other skill invocation.
+4. Do **not** say “please run `/duaer-specify`” — you do it.
+5. Do **not** dump a methodology tutorial unless they ask how Duaer works.
+6. Merge to **`develop`** when done (hotfix: **`main`**, then back-merge
    **`develop`**). Promote to **`main`** only if the user asks to go online.
-6. **Handoff (mandatory):** stop processes bound to `.worktree/<id>/`, remove
+7. **Handoff (mandatory):** stop processes bound to `.worktree/<id>/`, remove
    the worktree, then restart services from the primary checkout on `develop`
    using `.duaer/handoff.json` / `duaer handoff [--run]`. Never leave the user
    on a dead worktree server.
@@ -47,6 +51,8 @@ For new behavior, fixes, refactors that change product behavior, or architecture
 ## Forbidden
 
 - Jump from chat to code with no Brief under `.duaer/specs/`.
+- Jump from a vague ask to implementation without restating and confirming
+  intent (see Understand in `duaer-do`).
 - Making the human operate the workflow.
 
 ## Optional finer tools (agent-only)

package/.cursor/skills/duaer-clarify/SKILL.md

@@ -56,6 +56,11 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
 
+Note: The lightweight **Understand** step in `duaer-do` is the front door for
+casual asks (restate + confirm before coding). Use this skill when a Spec
+already exists and still has high-impact gaps (up to 5 questions). Prefer
+Understand first; escalate here when the Brief is large or architecture-heavy.
+
 Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/duaer-plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
 
 Execution steps:

package/.cursor/skills/duaer-converge/SKILL.md

@@ -98,6 +98,11 @@ When the codebase already satisfies everything, the command MUST leave `tasks.md
 produces a corresponding remediation task. If the constitution is an unfilled template,
 skip constitution checks gracefully rather than failing.
 
+**Verification Authority**: `.duaer/memory/testing.md` is part of accept criteria.
+Do **not** stamp `status: "accepted"` if required risk-table levels were not run and
+no written waiver exists in the feature docs. Treat missing verification as a
+`missing` gap (append a Convergence task) rather than accepting on Spec match alone.
+
 ## Execution Steps
 
 ### 1. Initialize Convergence Context
@@ -256,15 +261,23 @@ Append to the **end** of `tasks.md`, per the append contract:
     "checkedAt": "<ISO-8601 UTC>",
     "openTasks": 0,
     "findings": 0,
-    "source": "duaer-converge"
+    "source": "duaer-converge",
+    "verification": {
+      "levels": ["L0", "L1"],
+      "commands": ["<commands run>"],
+      "result": "pass",
+      "notes": "<optional waiver or subset note>"
+    }
   }
   ```
 
+  Include `verification` whenever checks were run or waived (`result`: `pass` |
+  `waived`). Omit only for pure-docs jobs with no levels required.
   Set `openTasks` to the count of unchecked `- [ ]` lines currently in `tasks.md`
   (must be `0` for `status: "accepted"`; if any remain, treat as `tasks_appended`
   path instead — do not stamp accepted).
 - Report: **"✅ Converged — the implementation satisfies the spec, plan, and tasks."**
-- Include the summary counts of what was checked.
+- Include the summary counts of what was checked **and** verification levels/commands.
 - Tell the user they can run `duaer job .` to see handoff status (policy default: coach).
 - Reminder: this is **job acceptance**, not a repository merge lock.
 ### 8. Provide Next Actions (Handoff)

package/.cursor/skills/duaer-do/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "duaer-do"
-description: "Autonomous job loop for digital employees: Brief → work → accept. Agents must follow this whenever the user asks for product work — without waiting for the user to invoke this skill or any CLI."
+description: "Autonomous job loop for digital employees: Brief → understand → work → accept. Agents must follow this whenever the user asks for product work — without waiting for the user to invoke this skill or any CLI."
 compatibility: "Requires duaer-spec project structure with .duaer/ directory"
 metadata:
   author: "duaer-spec"
@@ -37,25 +37,48 @@ Do **not** lecture about methodology. Do **not** ask them to run commands.
      `.duaer/specs/<nnn-slug>/` inside that checkout. Never set both names to
      the same `<nnn-slug>`.
 
-2. **Break down** — If `tasks.md` missing, write a short checklist from the Spec.
+2. **Understand** — Turn a casual ask into a precise job **before** coding:
+   - Restate in plain language: **goal**, **in scope**, **out of scope**,
+     **acceptance** (how we know it is done).
+   - If the ask is vague, multi-way, or missing acceptance: present that
+     restatement, optionally ask **at most 3** blocking questions (or offer
+     recommended defaults), and **wait for the human to confirm or correct**
+     before Break down / Work.
+   - Write the confirmed intent into the Brief (`spec.md`). Do not invent
+     product decisions silently.
+   - **May proceed without a blocking wait** when any of these hold:
+     - The human already gave clear acceptance criteria, OR
+     - Hotfix with a clear repro / root cause, OR
+     - The human explicitly said to skip confirm ("just do it", "按你说的做"),
+       in which case record assumptions in the Brief.
+   - Deep ambiguity after a full Spec still uses `duaer-clarify` (up to 5
+     questions). Understand is the **lightweight front door** on every ask.
+
+3. **Break down** — If `tasks.md` missing, write a short checklist from the Spec.
    Skip a heavy plan unless architecture or contracts change.
 
-3. **Work** — Implement open tasks; mark `[x]` as you go. No scope beyond Spec.
+4. **Work** — Implement open tasks; mark `[x]` as you go. No scope beyond Spec.
 
-4. **Accept** — Converge against Spec: stamp `delivery.json` `accepted`, or append
-   gap tasks and implement them when small enough; otherwise one clear remaining note.
+5. **Accept** — Converge against Spec **and** `.duaer/memory/testing.md`:
+   run required verification (or record a written waiver), stamp `delivery.json`
+   `accepted` with optional `verification` evidence, or append gap tasks and
+   implement them when small enough; otherwise one clear remaining note.
+   Never accept on Spec match alone when required levels were not run.
 
-5. **Handoff** — One line to the human:
+6. **Handoff** — One line to the human:
    - `✅ Job accepted — ready for your review.`
    - `⏳ Job not accepted yet — <one sentence>.`
+   - During Understand wait: `⏳ Confirming intent — <one sentence restatement>.`
    Never claim done unless accepted + tasks clear. Git is not locked by this.
 
 ## Hotfix
 
-Still a short Spec (symptom / cause / acceptance), then work + accept. Same handoff.
+Still a short Spec (symptom / cause / acceptance). Restate once; if repro is
+clear, proceed. Same handoff.
 
 ## Never
 
+- Jump from a vague chat line to implementation without restating intent.
 - Ask the human to run `/duaer-*`, `duaer status`, or `duaer policy`.
 - Discuss policy modes unless they ask.
 - Block on slash-command invocation.

package/.cursor/skills/duaer-implement/SKILL.md

@@ -174,7 +174,8 @@ You **MUST** consider the user input before proceeding (if not empty).
 9. Completion validation:
    - Verify all required tasks are completed
    - Check that implemented features match the original specification
-   - Validate that tests pass and coverage meets requirements
+   - Run `.duaer/memory/testing.md` levels required for the change (or record waivers)
+   - Validate that required tests pass; leave failures as open work
    - Confirm the implementation follows the technical plan
 
 Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/duaer-tasks` first to regenerate the task list.

package/.cursor/skills/duaer-tasks/SKILL.md

@@ -78,7 +78,7 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Phase 1: Setup tasks (project initialization)
    - Phase 2: Foundational tasks (blocking prerequisites for all user stories)
    - Phase 3+: One phase per user story (in priority order from spec.md)
-   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks
+   - Each phase includes: story goal, independent test criteria, **verification tasks** (from `testing.md`), implementation tasks
    - Final Phase: Polish & cross-cutting concerns
    - All tasks must follow the strict checklist format (see Task Generation Rules below)
    - Clear file paths for each task
@@ -139,7 +139,11 @@ The tasks.md should be immediately executable - each task must be specific enoug
 
 **CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
 
-**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
+**Verification is DEFAULT**: For each user story, generate verification tasks
+from `.duaer/memory/testing.md` (L0–L3 as the risk table requires). Do **not**
+omit tests just because the Spec did not say “TDD”. Only skip a level when the
+Spec or tasks record an explicit waiver. Extra TDD-style tests before
+implementation remain allowed when requested.
 
 ### Checklist Format (REQUIRED)
 
@@ -181,12 +185,12 @@ Every task MUST strictly follow this format:
      - Models needed for that story
      - Services needed for that story
      - Interfaces/UI needed for that story
-     - If tests requested: Tests specific to that story
+     - Verification tasks for that story (per `.duaer/memory/testing.md` risk table)
    - Mark story dependencies (most stories should be independent)
 
 2. **From Contracts**:
    - Map each interface contract → to the user story it serves
-   - If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase
+   - Each interface contract → contract/verification task [P] before or with implementation when the risk table requires L1/L2
 
 3. **From Data Model**:
    - Map each entity to the user story(ies) that need it

package/.duaer/active-job.json

@@ -0,0 +1,5 @@
+{
+  "specDir": ".duaer/specs/009-live-repo-pick",
+  "branch": "feat/live-repo-pick",
+  "startedAt": "2026-09-16T00:40:00.000Z"
+}

package/.duaer/memory/constitution.md

@@ -11,8 +11,9 @@ Duaer for what to build.
 ### I. Spec before code (NON-NEGOTIABLE)
 
 The **agent** starts a Brief before coding — the human does not operate phases.
-Autonomous default: follow `duaer-do` (Brief → tasks → implement → converge).
-Never skip Spec or converge. Never ask the human to run `/duaer-*` for normal work.
+Autonomous default: follow `duaer-do` (Brief → **understand** → tasks →
+implement → converge). Never skip Spec, intent confirm when vague, or converge.
+Never ask the human to run `/duaer-*` for normal work.
 
 ### II. Read as-is before changing
 
@@ -29,8 +30,13 @@ Do not expand scope without updating the spec and tasks.
 
 ### IV. Verify before done
 
-Mark tasks complete only when the stated verification (tests, manual checks,
-or converge) has been performed or explicitly waived in the feature docs.
+Mark tasks complete only when the verification required by
+`.duaer/memory/testing.md` (and any Spec/task checks) has been **executed**,
+or explicitly waived in the feature docs.
+
+Do not stamp `delivery.json` `accepted` without verification evidence (or a
+written waiver). Prefer automated subsets; use manual L4 only when automation
+cannot cover the path.
 
 **Job handoff (not a git lock):** the agent reports accept/open itself.
 Default policy `coach` — do not claim "done" while the active job is unfinished.

package/.duaer/memory/project-context.md

@@ -7,7 +7,7 @@ Fill this in for each project. Agents treat it as implementation truth.
 - Language / runtime:
 - Package manager:
 - App entrypoints:
-- Test commands:
+- Test commands: (fill from `.duaer/memory/testing.md` — L0/L1/L2/L3 scripts)
 
 ## Layout
 

package/.duaer/memory/testing.md

@@ -1,14 +1,75 @@
-# Testing expectations (template)
+# Testing expectations (project contract)
+
+Agents **must** read this file before marking work verified or accepting a job.
+Replace command examples with the adopting project's real scripts. Keep the
+level model and risk rules unless an ADR documents a change.
 
 ## Levels
 
-- L0: lint / typecheck
-- L1: unit tests for changed modules
-- L2: integration tests for changed boundaries
-- L3: e2e / browser for user-visible paths
-- L4: manual account verification when UI or auth is involved
+| Level | What | Typical commands (replace) | Default owner |
+|---|---|---|---|
+| **L0** | Lint / typecheck / static | `npm run lint`, `tsc --noEmit` | After every implementation pass |
+| **L1** | Unit tests for changed modules | `npm test` (or package subset) | Default for code changes |
+| **L2** | Integration / product acceptance at changed boundaries | project acceptance or integration suite | When boundaries or core paths change |
+| **L3** | Automated E2E / browser for user-visible paths | `npm run test:e2e` or equivalent **subset** | When UI / protocol UX changes |
+| **L4** | Manual account / device path when automation cannot cover auth or real data | documented steps in the Brief | When UI/auth and no automated substitute |
+
+IDE Browser / MCP exploration is **optional discovery**. It does **not** replace
+L3 automation when the project has an E2E suite.
+
+## Risk table (what to run)
+
+| Change touch | Minimum before accept / merge to `develop` |
+|---|---|
+| Docs / comments only | None (note in Brief) |
+| Internal code, same behavior | L0 + L1 for affected packages |
+| API / data / core path | L0 + L1 + L2 (or documented equivalent) |
+| User-visible or protocol-visible UI/UX | L0 + L1 + **L3 subset for touched flows** + update E2E catalog |
+| Auth / payments / irreversible ops | Above + L4 if L3 cannot cover |
+
+Prefer **targeted subsets** over full monorepo suites. Do not skip a required
+level without an explicit waiver in the feature docs (`tasks.md` or Spec).
+
+## Opt-in (still need an explicit ask or Spec note)
+
+Mark these in the project table when they are expensive:
+
+- Full-repo E2E (vs subset)
+- Remote CI-only jobs the agent would trigger manually
+- Live paid LLM / third-party smoke
+- Production / staging account checks beyond local
+
+Absence from this opt-in list means the agent **runs** the level when the risk
+table requires it — the human does **not** have to re-request ordinary
+verification.
+
+## Definition of Done (agent-owned work)
+
+Before `delivery.json` `accepted` and before merging the request branch into
+local **`develop`**:
+
+1. [ ] Required levels from the risk table have been **executed** (or waived in writing)
+2. [ ] Failures fixed or the job left `open` with a clear remaining note
+3. [ ] User/protocol-visible changes: E2E catalog scenario added/updated
+4. [ ] Handoff mentions what was run (commands + result)
+
+## Phase hooks (Duaer)
+
+| Phase | Verification action |
+|---|---|
+| `specify` | Independent Test + acceptance scenarios; name expected levels |
+| `plan` | Fill **Testing** with concrete commands / levels |
+| `tasks` | **Default:** verification tasks per story (not optional) |
+| `implement` | Run relevant checks as tasks complete |
+| `converge` | Refuse `accepted` without verification evidence or waiver |
+
+## Waivers
+
+A waiver must state: which level, why it cannot run now, and the follow-up.
+“Too slow” alone is not enough if a subset command exists.
 
-## Default for features
+## Adopter profiles
 
-Specs and `tasks.md` must include verification tasks. Prefer automated checks;
-document any manual step that cannot be automated.
+Thick product examples (e.g. `examples/dianwu-flow/testing.md`) may add L5+
+layers (Playwright CI, live LLM, expert review). Those extend this contract;
+they do not replace it.

package/.duaer/specs/001-verification-gate/delivery.json

@@ -0,0 +1,19 @@
+{
+  "schemaVersion": 1,
+  "status": "accepted",
+  "outcome": "converged",
+  "checkedAt": "2026-09-15T06:50:00.000Z",
+  "openTasks": 0,
+  "findings": 0,
+  "source": "duaer-converge",
+  "verification": {
+    "levels": ["L0", "L1"],
+    "commands": [
+      "rg 'Do not run local E2E' AGENTS.md docs/agent (expect none)",
+      "rg 'Verification is DEFAULT' .cursor/skills/duaer-tasks/SKILL.md",
+      "test -f .duaer/memory/testing.md docs/adr/001-verification-gate.md"
+    ],
+    "result": "pass",
+    "notes": "Docs/policy change in duaer-spec; no app runtime suite. Manual catalog E2E-017–020."
+  }
+}

package/.duaer/specs/001-verification-gate/spec.md

@@ -0,0 +1,60 @@
+# Feature Specification: Verification gate for development
+
+**Feature Branch**: `feat/verification-gate`
+
+**Created**: 2026-09-15
+
+**Status**: Active
+
+**Input**: Evolve duaer-spec so adopting projects require risk-based verification during development (not docs-only E2E; not default “skip E2E”).
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Agent must verify before accept (Priority: P1)
+
+As a human using a digital employee on an adopting project, I want the agent to run the project's required checks for the change before marking the job accepted, so “done” means verified, not only Spec-matched.
+
+**Why this priority**: Closes the gap between Spec converge and real quality.
+
+**Independent Test**: Read AGENTS + `duaer-do` + converge; confirm accept path requires verification per `.duaer/memory/testing.md`.
+
+**Acceptance Scenarios**:
+
+1. **Given** a user-visible change, **When** the agent converges, **Then** it must run (or record a justified waiver for) the levels required by `testing.md`, and stamp `delivery.json` only when that gate is satisfied.
+2. **Given** an internal-only change, **When** the agent works, **Then** it still runs L0/L1 (or project equivalent) when those commands exist, and may skip browser E2E.
+
+### User Story 2 - Project testing contract is actionable (Priority: P1)
+
+As an adopting project, I get a concrete `.duaer/memory/testing.md` that defines levels, when to run what, and the merge-to-develop minimum — not a five-line stub.
+
+**Independent Test**: Open installed `testing.md`; it names levels, risk table, DoD, and phase hooks.
+
+### User Story 3 - Policy no longer forbids needed E2E (Priority: P1)
+
+As an agent, I am instructed to run risk-appropriate automated E2E / browser suites from the project contract, instead of a blanket “do not run E2E unless the user asks”.
+
+**Independent Test**: AGENTS / workflow R3 / change-checklist no longer contain the blanket ban; they point at `testing.md`.
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+- **FR-001**: System MUST publish an actionable `.duaer/memory/testing.md` template (levels L0–L4+, risk table, DoD, phase hooks, waiver rules).
+- **FR-002**: AGENTS and workflow MUST require risk-based verification for agent-owned development; MUST NOT blanket-forbid local E2E.
+- **FR-003**: `duaer-do`, `duaer-tasks`, and `duaer-converge` MUST treat verification as default (tasks include it; accept requires evidence or explicit waiver).
+- **FR-004**: E2E scenario catalog docs remain required for user/protocol-visible changes (R3 docs) **and** execution follows `testing.md`.
+- **FR-005**: ADR MUST record the policy change (verification gate).
+- **FR-006**: Host always-on rules (`agents-workflow`) MUST mention verification, not only E2E docs.
+- **FR-007**: Expensive / remote / full-suite or live-LLM runs MAY still require explicit user ask when `testing.md` marks them as opt-in; subset E2E for touched UI paths MUST run when the project defines those commands.
+
+### Non-goals
+
+- Scaffolding Playwright into every adopter by default.
+- Requiring IDE Browser MCP.
+- Changing R6 PR principle (third-party completeness may still be follow-up).
+
+## Success Criteria
+
+- **SC-001**: A new agent reading only AGENTS + testing.md + duaer-do knows it must verify before accept.
+- **SC-002**: Blanket “do not run E2E unless asked” is gone from ops docs.
+- **SC-003**: dianwu-flow example remains a thick adopter profile pointing at the shared contract.

package/.duaer/specs/001-verification-gate/tasks.md

@@ -0,0 +1,21 @@
+# Tasks: Verification gate
+
+## Phase 1 — Contract
+
+- [x] T001 Expand `.duaer/memory/testing.md` into actionable project contract
+- [x] T002 Rewrite AGENTS §3 + workflow R3 + change-checklist for risk-based verification
+- [x] T003 Update constitution IV + agents-workflow (Cursor/Claude) + DUADER light mention
+- [x] T004 ADR-001 verification gate; update ADR index
+
+## Phase 2 — Job loop skills
+
+- [x] T005 Update `duaer-do` Accept step for verification evidence
+- [x] T006 Flip `duaer-tasks` from “tests optional” to default verification tasks
+- [x] T007 Update `duaer-converge` / `duaer-implement` accept + validation gates
+- [x] T008 Optional `verification` field on `delivery.json` when accepted
+
+## Phase 3 — Catalog & examples
+
+- [x] T009 Update e2e-test-plan scenarios; CHANGELOG; examples/dianwu-flow pointer
+- [x] T010 `checkWorkplace` includes `.duaer/memory/testing.md`
+- [x] T011 Converge + stamp delivery.json

package/.duaer/specs/002-understand-gate/delivery.json

@@ -0,0 +1,14 @@
+{
+  "status": "accepted",
+  "acceptedAt": "2026-09-15T10:05:00.000Z",
+  "summary": "Added Understand gate to duaer-do and host-facing docs so vague asks are restated and confirmed before implementation.",
+  "verification": {
+    "levels": ["L0"],
+    "commands": [
+      "rg 'Understand' .cursor/skills/duaer-do/SKILL.md DUADER.md AGENTS.md",
+      "rg 'understand / confirm' .cursor/rules/duaer-spec.mdc .claude/rules/duaer-spec.md"
+    ],
+    "result": "pass",
+    "notes": "Methodology/docs only; no runtime suite."
+  }
+}

package/.duaer/specs/002-understand-gate/spec.md

@@ -0,0 +1,42 @@
+# Feature Specification: Understand gate before implement
+
+**Feature Branch**: `feat/understand-gate`
+
+**Created**: 2026-09-15
+
+**Status**: Active
+
+**Input**: User wants casual asks restated and confirmed as precise requirements before coding.
+
+## User Scenarios & Testing
+
+### User Story 1 - Casual ask gets a restatement first (Priority: P1)
+
+A human says something vague (e.g. "消息没回复修好一下"). The digital employee restates a precise Brief (goal / scope / acceptance / out of scope), asks only what blocks precision (or offers recommended defaults), and does **not** start implementation until the human confirms or corrects.
+
+**Independent Test**: Read `duaer-do` + DUADER + AGENTS; confirm Understand is required before Work for underspecified asks.
+
+**Acceptance Scenarios**:
+
+1. **Given** a vague product ask, **When** the agent runs `duaer-do`, **Then** it presents an intent restatement and waits for confirm before implement.
+2. **Given** a clear ask with explicit acceptance (or hot-fix with clear repro), **When** the agent runs `duaer-do`, **Then** it may proceed after a short restatement without a blocking Q&A.
+3. **Given** the human says skip / just do it, **When** noted in the Brief, **Then** implement may proceed with recorded assumption risk.
+
+## Requirements
+
+- **FR-001**: `duaer-do` MUST include an **Understand** step after Assign (or as part of Assign) and before Break down / Work.
+- **FR-002**: Understand MUST restate: what / why / in-scope / out-of-scope / how we will know it is done.
+- **FR-003**: If the ask is underspecified, the agent MUST wait for human confirmation (or answers to ≤3 blocking questions) before Work.
+- **FR-004**: Confirmed intent MUST be written into the Brief (`spec.md`) before tasks/implement.
+- **FR-005**: Host-facing docs (DUADER, AGENTS autonomous loop, Cursor duaer-spec rule) MUST mention the Understand gate so agents do not skip it.
+- **FR-006**: Deep `/duaer-clarify` remains for post-spec ambiguity; Understand is the lightweight front door for every casual ask.
+
+## Success Criteria
+
+- **SC-001**: A new agent reading only duaer-do knows not to jump from chat to code without restating and confirming when the ask is vague.
+- **SC-002**: Humans experience "整理需求 → 确认 → 开发" without typing phase names.
+
+## Verification
+
+- L0: Doc/skill review (this change is methodology text).
+- E2E catalog: update scenario for `duaer-do` Understand gate.

package/.duaer/specs/002-understand-gate/tasks.md

@@ -0,0 +1,9 @@
+# Tasks: Understand gate
+
+- [x] T001 Add Understand step to `.cursor/skills/duaer-do/SKILL.md`
+- [x] T002 Update `DUADER.md` agent procedure
+- [x] T003 Update `AGENTS.md` autonomous job loop
+- [x] T004 Update `.cursor/rules/duaer-spec.mdc`
+- [x] T005 Point `duaer-clarify` at Understand as front door
+- [x] T006 Update `docs/agent/e2e-test-plan.md` + `CHANGELOG.md`
+- [x] T007 Stamp delivery.json (L0 doc review)

package/.duaer/specs/003-live-dev-web/delivery.json

@@ -0,0 +1,13 @@
+{
+  "status": "accepted",
+  "acceptedAt": "2026-09-15T10:30:00.000Z",
+  "summary": "现场开发 web: dialogue + four-block confirm + duaer live writes Brief under .duaer/specs.",
+  "verification": {
+    "levels": ["L0", "L3-smoke"],
+    "commands": [
+      "curl /api/health",
+      "POST /api/confirm → .duaer/specs/00N-*"
+    ],
+    "result": "pass"
+  }
+}

package/.duaer/specs/003-live-dev-web/spec.md

@@ -0,0 +1,33 @@
+# Feature Specification: 现场开发 Web（对话确认台）
+
+**Feature Branch**: `feat/live-dev`
+
+**Created**: 2026-09-15
+
+**Status**: Active
+
+**Input**: Confirmed — web UI on duaer-spec: multi-round dialogue → four-block confirm → digital employee Brief.
+
+## Goal
+
+Ship a **网页端「现场开发」** so a human can clarify requirements in chat, confirm a fixed four-block card, then hand off a Duaer Brief for the digital employee to work.
+
+## In scope (v1)
+
+- Local web page: dialogue + four blocks (要做什么 / 不做什么 / 验收标准 / 假设)
+- Multi-round questions (priority order, one at a time, max 5)
+- Confirm button locks intent and writes `.duaer/specs/<nnn-slug>/` Brief + light tasks + `active-job.json`
+- CLI: `duaer live` (or `npm run live`) serves UI + write API against the **current project**
+- Copyable handoff prompt for the coding agent
+
+## Out of scope (v1)
+
+- Cloud multi-tenant hosting, billing
+- Full IDE / auto-merge to main
+- Mandatory paid LLM (v1 uses structured questioning; optional later)
+
+## Acceptance
+
+1. User can open the page, answer rounds, edit the four blocks, and confirm.
+2. Confirm creates Brief files under `.duaer/specs/` without prior implement.
+3. Docs explain how to run `duaer live` from an adopting repo.

package/.duaer/specs/003-live-dev-web/tasks.md

@@ -0,0 +1,8 @@
+# Tasks: 003-live-dev-web
+
+- [x] T001 Spec + active-job
+- [x] T002 Static UI: chat + four-block card + confirm
+- [x] T003 Node server: serve + POST confirm → Brief
+- [x] T004 `duaer live` CLI + package.json script
+- [x] T005 README note + CHANGELOG
+- [x] T006 Smoke test server + delivery stamp

package/.duaer/specs/004-live-deepseek-preset/delivery.json

@@ -0,0 +1,12 @@
+{
+  "status": "accepted",
+  "acceptedAt": "2026-09-15T11:15:00.000Z",
+  "verification": {
+    "levels": ["L0"],
+    "commands": [
+      "duaer live config --provider deepseek --api-key sk-test (DUAER_HOME temp)",
+      "GET /api/config returns providers including deepseek"
+    ],
+    "result": "pass"
+  }
+}