easy-coding-harness 0.6.1 → 0.7.1-beta0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.6.1",
+  "version": "0.7.1-beta0",
   "description": "CLI scaffold for installing Easy Coding harness files into agent-native directories.",
   "repository": {
     "type": "git",

package/templates/common/skills/ec-analysis/SKILL.md

@@ -50,9 +50,9 @@ Communicate with the user in the user's language.
    downgrade: during the pre-fill decision gate, ask "split into batches? / which subset this
    round?" and wait for the user to decide. Never make a scope-narrowing decision yourself and
    present it as settled. Never fabricate a
-   premise such as "the user already fixed scope X in INIT" or "auto_mode already selected Y"
-   to justify narrowing — `auto_mode` only waives stage-boundary prompts under an explicit
-   autonomous user request and carries NO scope or delivery-form decision whatsoever.
+   premise such as "the user already fixed scope X in INIT" or "confirm_mode already selected Y"
+   to justify narrowing — confirmation mode controls stage-boundary prompts only and carries
+   NO scope or delivery-form decision whatsoever.
 6. **改动范围 lists ONLY real project code.** The 改动范围 table carries only changes to real
    project source/config files. Any harness artifact under `.easy-coding/` (dev-spec.md,
    execution.jsonl, test-strategy.md, memory files, generated reports, etc.) is FORBIDDEN in

package/templates/common/skills/ec-implementing/SKILL.md

@@ -53,7 +53,7 @@ EVERY STRATEGY = MANDATORY SUB-AGENT DISPATCH. NO EXCEPTIONS.
 You MUST dispatch sub-agents using {{sub_agent_dispatch}} for every unit, whatever the
 strategy. You are FORBIDDEN from implementing any unit yourself in the main agent. Doing the
 work inline instead of dispatching is a protocol violation equivalent to bypassing the
-ANALYSIS -> IMPLEMENT confirmation gate.
+ANALYSIS -> IMPLEMENT gate selected by the effective confirm mode.
 
 Self-check before writing ANY implementation code:
 - Am I about to write implementation code in the main agent? → STOP. Dispatch a sub-agent.
@@ -121,19 +121,19 @@ let sub-agents re-dispatch each other.
 
 ## End state
 
-- **Code task:** after all units are done and self-audited, hand back to ec-workflow. It records
-  IMPLEMENT -> REVIEW as the recommended pending edge, then presents: (1) enter REVIEW,
-  (2) skip REVIEW and enter VERIFICATION, (3) hand off, plus native free-form Other.
+- **Code task:** after all units are done and self-audited, hand back to ec-workflow. In approve
+  mode it records IMPLEMENT -> REVIEW as the recommended pending edge and presents REVIEW /
+  skip to VERIFICATION / handoff. In guard/auto it automatically enters REVIEW.
 - **No-code read-only task:** after recording the successful result and showing the complete
-  deliverable, call `auto-transition --stage COMPLETE` through ec-workflow. Do not request or
+  deliverable, request COMPLETE in approve mode or auto-transition in guard/auto. Do not
   enter REVIEW, VERIFICATION, or MEMORY; do not write short or long memory. The state API only
   accepts this terminal edge when the latest plan is `single` with `files:[]` and the latest
   result has `changed_files:[]`, a non-empty `deliverable`, and no issues/needs_attention.
   A matching `dispatch` record must immediately precede the accepted result among that unit's
   execution records; an inline report without dispatch cannot complete.
 
-If something invalidates the plan before completion, request IMPLEMENT -> ANALYSIS and wait at
-the standard gate instead of improvising.
+If something invalidates the plan before completion, select IMPLEMENT -> ANALYSIS and follow
+the effective confirm mode instead of improvising.
 
 ## Self-check gates (before handing back)
 
@@ -143,6 +143,6 @@ the standard gate instead of improvising.
 - [ ] Each returned unit has a `result` record?
 - [ ] No files modified outside the change-scope table?
 - [ ] For a no-code unit: changed_files is empty, deliverable is non-empty, and the full
-      deliverable was output verbatim to the user before automatic completion?
-- [ ] For a no-code task: IMPLEMENT -> COMPLETE was automatic, with no REVIEW, VERIFICATION,
-      MEMORY, or memory write?
+      deliverable was output verbatim to the user before completion?
+- [ ] For a no-code task: IMPLEMENT -> COMPLETE followed the effective confirm mode, with no
+      REVIEW, VERIFICATION, MEMORY, or memory write?

package/templates/common/skills/ec-memory/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: ec-memory
-description: MEMORY-stage skill — part of the archive flow, triggered only after user acceptance and a confirmed stage edge. Writes one schema-v2 short memory, runs the authoritative conditional long-memory gate, performs optional distillation, and automatically completes the task.
+description: MEMORY-stage skill — archive flow entered after a green VERIFICATION gate according to the effective confirm mode. Writes one schema-v2 short memory, runs the authoritative conditional long-memory gate, performs optional distillation, and automatically completes the task.
 ---
 
 # ec-memory — archive what was learned
 
-ec-workflow dispatches you during MEMORY, which runs only after the user accepts the task and
-confirms entry. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
+ec-workflow dispatches you during MEMORY after approve/guard acceptance or an auto-mode green
+VERIFICATION gate. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
 `verify` records are precise source material), the changed-files list, existing memory files.
 Read-only `doc` / `analysis` / `report` tasks auto-complete from IMPLEMENT and never enter
 MEMORY or write task memory.

package/templates/common/skills/ec-no-harness/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: ec-no-harness
+description: Disable Easy Coding Harness orchestration for the current agent session and use native agent behavior. Use only when the user explicitly invokes {{skill_trigger}}ec-no-harness or explicitly asks to restore Easy Coding after this bypass.
+---
+
+# ec-no-harness — current-session Easy Coding bypass
+
+This skill bypasses only Easy Coding Harness for the current session. It does not disable the
+platform's hook system, alter `EC_HOOKS`, or suppress non-Easy-Coding skills and instructions.
+
+Communicate with the user in the user's language.
+
+## Disable for this session
+
+Read `[easy-coding:session-file:P]` from the injected context, then call:
+
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py disable-harness --session-file <P> --agent <agent-id>`
+
+After the command succeeds:
+- Do not enter or resume ec-workflow in this session.
+- Do not emit an Easy Coding status line or apply Easy Coding stages, confirmation gates,
+  task artifacts, verification orchestration, or memory workflow.
+- Process the user's request with the platform's native agent behavior.
+- Continue honoring project/user/global instructions, explicitly requested non-Easy-Coding
+  skills, and every other hook.
+- Do not clear `current_task`, delete a pending transition, or modify task state. The task is
+  suspended intact and can resume after restoring Easy Coding or in a new session.
+
+If the invocation contains no request beyond enabling the bypass, briefly confirm that native
+mode is active for the current session.
+
+## Restore Easy Coding in the same session
+
+Only when the user explicitly asks to restore/resume Easy Coding, call:
+
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py enable-harness --session-file <P> --agent <agent-id>`
+
+Use the returned `status_context` as authoritative. Do not advance the task automatically;
+hand control back to ec-workflow routing semantics.

package/templates/common/skills/ec-reviewing/SKILL.md

@@ -89,6 +89,6 @@ Platform spawn rule: {{platform_spawn_instruction}}
 Append `review` records to execution.jsonl, one per dimension:
 `{"type":"review","dimension":"correctness","findings":[{"file":"...","line":42,"issue":"...","severity":"warn"}]}`.
 Then state the verdict and hand back to ec-workflow.
-For `accept` or `replan`, ec-workflow records the corresponding pending transition and presents
-the standard confirmation/handoff/Other gate. A `fix` round stays inside REVIEW and therefore
+For `accept` or `replan`, ec-workflow follows the effective confirm mode for the corresponding
+transition. A `fix` round stays inside REVIEW and therefore
 does not create a status transition unless the outcome changes.

package/templates/common/skills/ec-task-management/SKILL.md

@@ -1,16 +1,34 @@
 ---
 name: ec-task-management
-description: Task panel for Easy Coding tasks. Use when the user runs {{skill_trigger}}ec-task-management, asks to see tasks, create a task, continue a task, or take over a task handed off by another agent.
+description: Task and session panel for Easy Coding. Use when the user runs {{skill_trigger}}ec-task-management, asks to see/create/continue/take over tasks, or asks to view or change the current session confirm mode.
 ---
 
-# ec-task-management — the task panel
+# ec-task-management — the task and session panel
 
-A focused task panel: list unfinished tasks, create tasks, and let the user choose one task
-to continue or take over. Stage progression still belongs to ec-workflow; closure belongs
-to ec-task-close.
+A combined task and session panel: list unfinished tasks, create tasks, let the user choose one
+task to continue or take over, and manage the current session's confirm mode. Stage progression
+still belongs to ec-workflow; closure belongs to ec-task-close.
 
 Communicate with the user in the user's language.
 
+## Default panel contract
+
+A bare `{{skill_trigger}}ec-task-management` invocation means "show the full task and session
+panel", not just the unfinished task list. On every invocation:
+
+1. Call `list-tasks --agent <agent-id>`.
+2. Call `snapshot --session-file <P>`.
+3. Show the unfinished tasks and a separate "Session confirm mode" section containing:
+   - `project_confirm_mode`
+   - `session_confirm_mode` (`project default` when null)
+   - `effective_confirm_mode`
+4. Show the supported conversational changes in the user's language: set this session to
+   `approve`, `guard`, or `auto`, and restore the project default.
+
+Never omit the confirm-mode section, even when the unfinished task list is empty. A bare panel
+invocation is read-only: do not set or clear the session override until the user explicitly asks
+for a change.
+
 ## Capabilities
 
 ### List unfinished tasks
@@ -62,6 +80,28 @@ The command returns `status_line` and `status_context`. If the command sets or c
 `current_task`, use the returned context as the authoritative status source for the rest of
 the current turn instead of older hook-injected status text.
 
+### View or change this session's confirm mode
+
+Use the snapshot already required by the default panel and show:
+- `project_confirm_mode`
+- `session_confirm_mode` (`project default` when null)
+- `effective_confirm_mode`
+
+When the user asks to change the current session, use native choice UI when available and offer
+exactly `approve`, `guard` (recommended default), and `auto`. The native free-form Other input
+may receive `restore project default`; do not invent a fourth button when the UI is limited to
+three choices.
+
+Set an override through the state API, never by editing the session JSON:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-confirm-mode --session-file <P> --mode <approve|guard|auto> --agent <agent-id>`.
+
+Restore project configuration through:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-confirm-mode --session-file <P> --agent <agent-id>`.
+
+Use the returned snapshot as authoritative and report the effective mode. Preserve any existing
+`pending_transition`; when it becomes automatic, ec-workflow consumes its original target via
+`auto-transition` instead of losing the completed stage outcome.
+
 ## Boundaries
 
 - Do not close or cancel tasks — that is ec-task-close.

package/templates/common/skills/ec-verification/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ec-verification
-description: VERIFICATION-stage skill — the hard gate between implementation/review and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
+description: VERIFICATION-stage skill — the hard evidence gate between implementation/review and archive. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, then follows the effective confirm mode for archive or repair.
 ---
 
 # ec-verification — the hard gate
@@ -19,10 +19,10 @@ NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
 - A previous round's result does not count.
 - "should pass" / "looks correct" is not evidence.
 
-NO AUTO-ARCHIVE WITHOUT USER ACCEPTANCE
-- Verification passing does not complete the task.
-- The memory flow is part of archive; it runs only after the user accepts.
-- An unaccepted task's memory is dirty data.
+NO ARCHIVE WITHOUT A GREEN GATE
+- Verification passing evidence is mandatory in every confirm mode.
+- approve/guard require user acceptance before MEMORY; auto advances after the green gate.
+- Confirmation mode never turns failed or missing evidence into acceptance.
 ```
 
 ## 1. Run the gate (parallel, always sub-agents)
@@ -53,10 +53,10 @@ Append one `verify` record per check:
 
 ## 3. Gate decision
 
-- All three pass AND coverage satisfied → present the verification result; wait for user
-  acceptance. Do NOT archive yet.
-- Any failure → append the failing `verify` record, summarize failures, request
-  VERIFICATION -> IMPLEMENT, and wait at the standard confirmation/handoff/Other gate.
+- All three pass AND coverage satisfied → present the verification result; approve/guard wait
+  for user acceptance, while auto hands the green result to ec-workflow for automatic MEMORY.
+- Any failure → append the failing `verify` record, summarize failures, select
+  VERIFICATION -> IMPLEMENT, and follow the effective confirm mode.
 
 ## 4. User acceptance and repair loop
 
@@ -64,11 +64,10 @@ After a green gate, present an acceptance summary: what changed (files + summari
 verification results (lint/type/test), and the coverage status. Then the user takes time to
 test manually. Their response routes:
 
-- **"accepted"** → request VERIFICATION -> MEMORY and present the standard boundary gate.
+- **"accepted"** (approve/guard) → request VERIFICATION -> MEMORY and present the standard boundary gate.
 - **"problem here"** → scope judgment against the dev-spec:
-  - in scope → request VERIFICATION -> IMPLEMENT and wait for the user to confirm the return;
-    after repair, the IMPLEMENT completion choice decides whether REVIEW runs again or
-    VERIFICATION resumes directly.
+  - in scope → select VERIFICATION -> IMPLEMENT and follow the effective confirm mode; after
+    repair, approve presents the IMPLEMENT choice while guard/auto default to REVIEW.
   - out of scope → propose a new task (`spawned_from` = current task id); the current task
     may archive now (if already satisfactory) or stay suspended.
 - **"cancel"** → ec-task-close.
@@ -77,15 +76,16 @@ Repair sizing: a trivial tweak is fixed and re-verified inside VERIFICATION; a l
 change formally returns to IMPLEMENT. After repair, present the standard IMPLEMENT completion
 choice again so the user may enter REVIEW or skip directly to VERIFICATION.
 
-## 5. Archive entry (only after acceptance)
+## 5. Archive entry
 
-Acceptance does not mutate the stage directly. Hand control to ec-workflow to call
-`request-transition --stage MEMORY`, then present:
+In approve/guard, acceptance does not mutate the stage directly. Hand control to ec-workflow
+to call `request-transition --stage MEMORY`, then present:
 1. Confirm entering MEMORY
 2. Hand off to another agent
 3. Other (native free-form Other, or the third text option)
 
 Only after confirmation may ec-workflow consume the pending edge and dispatch ec-memory.
+In auto, hand the green gate directly to ec-workflow for `auto-transition --stage MEMORY`.
 ec-memory owns both short-memory creation and the conditional long-memory gate inside the
 single MEMORY stage. After memory processing completes, MEMORY -> COMPLETE advances
 automatically without another confirmation or handoff gate.

package/templates/common/skills/ec-workflow/SKILL.md

@@ -14,6 +14,10 @@ replies are English.
 
 ## Startup sequence (run on every activation, in order)
 
+If `[easy-coding:no-harness]` is present, do not start or resume this workflow. The current
+session is intentionally using native agent behavior; only `ec-no-harness` may restore Easy
+Coding for that session.
+
 1. **Init guard.** Read `.easy-coding/tasks/project-init/task.json`.
    - Missing → tell the user to run the `easy-coding init` CLI first. Stop.
    - `status != "COMPLETE"` → tell the user to run `{{skill_trigger}}ec-init` first. Stop.
@@ -65,24 +69,24 @@ replies are English.
 ## State machine
 
 ```
-INIT --[auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[auto]--> COMPLETE
+INIT --[always auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[always auto]--> COMPLETE
                                     \----------------> VERIFICATION
-                                    \--[read-only auto]------------------------------> COMPLETE
+                                    \--[read-only, mode-aware]-----------------------> COMPLETE
                  ^            ^          |             |
                  +-- replan ---+          +--- fix -----+
                               ^                         |
                               +------- repair ----------+
-user-decision edge --[explicit confirmation / handoff / Other]--> target stage
+edge behavior --[effective confirm mode: approve / guard / auto]--> target stage
 any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
 | Stage | Owner skill | What happens | Exit condition |
 |---|---|---|---|
 | INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | work complete; auto-transition to ANALYSIS |
-| ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | analysis presented; request IMPLEMENT |
-| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | code: choose REVIEW or VERIFICATION; read-only: auto-complete after delivery |
-| REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal target; request it |
-| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | result selects MEMORY or IMPLEMENT; request it |
+| ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | mode-aware transition to IMPLEMENT |
+| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | code defaults to REVIEW when automatic; approve may choose VERIFICATION |
+| REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal mode-aware target |
+| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | mode-aware transition to MEMORY or IMPLEMENT |
 | MEMORY | ec-memory | write short memory, then run the conditional long-memory gate | memory work complete; auto-transition to COMPLETE |
 | COMPLETE | ec-workflow | clear current_task, set task status, summary | automatic terminal after MEMORY or validated read-only IMPLEMENT |
 | CLOSED | ec-task-close | user abort; no memory flow | terminal |
@@ -93,9 +97,9 @@ any stage --[user abort via ec-task-close]--> CLOSED
 > code task into a documentation-only task — that is a downgrade (see ec-analysis HARD RULE 5).
 > Use `doc`, `analysis`, or `report` only when the user's original request explicitly asks for
 > a no-code deliverable. Those task types may carry execution units with an empty file scope;
-> code task types may not. A successful empty-scope task ends automatically from IMPLEMENT to
-> COMPLETE after its full deliverable is shown; it never creates test-strategy.md or enters
-> REVIEW, VERIFICATION, or MEMORY.
+> code task types may not. After its full deliverable is shown, a successful empty-scope task
+> follows the effective confirm mode from IMPLEMENT to COMPLETE; it never creates
+> test-strategy.md or enters REVIEW, VERIFICATION, or MEMORY.
 
 ## Task switching
 
@@ -114,22 +118,28 @@ it, routing matches, and switching happens again.
 
 ## Transition rules (hard)
 
-- **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot
-  start before the ANALYSIS -> IMPLEMENT confirmation gate passes. After code implementation,
-  the user may enter REVIEW or skip it and enter VERIFICATION; code tasks never skip
-  VERIFICATION. Explicit read-only tasks are the separate terminal exception below.
-- **User-decision edges are confirmation gates.** Stage completion on those edges does NOT
-  change `task.json.status`. It records a `pending_transition` through the state API, presents
-  the choices below, and stops. This applies to forward edges, repair/replan edges, and the
-  IMPLEMENT review choice. Task creation entering INIT and the separately confirmed
-  ec-task-close flow do not add a redundant second prompt.
-- **Mechanical edges are automatic.** After INIT work completes, call `auto-transition`
-  for ANALYSIS and dispatch ec-analysis in the same flow. After `memory-complete`, call
-  `auto-transition` for COMPLETE and emit the closeout summary. A successful explicit read-only
-  task also calls `auto-transition` from IMPLEMENT to COMPLETE immediately after displaying the
-  full deliverable. These edges do not create `pending_transition`, do not offer handoff, and
-  never wait for user confirmation.
-- **Native choice first (hard requirement).** After `request-transition` succeeds, you MUST
+- **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION and code tasks never
+  skip VERIFICATION. In `guard` and `auto`, an automatic code path chooses REVIEW as the default
+  successor to IMPLEMENT. In `approve`, the user may explicitly choose REVIEW or skip it and
+  enter VERIFICATION.
+- **Resolve the effective confirm mode first.** Read `[easy-coding:confirm-mode:X]` or the state
+  API snapshot. Session mode overrides project `behavior.confirm_mode`; missing project
+  configuration defaults to `guard`.
+  - `approve`: every legal edge requires `request-transition` and explicit confirmation except
+    INIT -> ANALYSIS and MEMORY -> COMPLETE.
+  - `guard` (default): only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY require explicit
+    confirmation. Every other legal edge uses `auto-transition` after its owner selects the
+    evidence-backed target.
+  - `auto`: every legal edge uses `auto-transition`.
+  `ec-task-close` remains an explicit user abort and is not triggered by confirm mode.
+- **Confirmation policy changes prompts, not evidence.** No mode chooses product scope,
+  delivery form, API contracts, or risk decisions for the user. No mode bypasses dev-spec,
+  execution, review, verification, or memory checkpoints.
+- **Always-automatic mechanical edges.** After INIT work completes, call `auto-transition` for
+  ANALYSIS. After `memory-complete`, call `auto-transition` for COMPLETE. These two edges never
+  create `pending_transition` in any mode.
+- **Native choice first (hard requirement).** When the effective mode requires confirmation,
+  call `request-transition`. After it succeeds, you MUST
   prefer the agent/platform's native user-choice tool whenever one is available. Do not render
   a plain-text numbered list on a platform that can present selectable options and a free-form
   Other input. Offer exactly these business branches through that native UI:
@@ -147,7 +157,7 @@ it, routing matches, and switching happens again.
   you against the current task and stored target before calling `confirm-transition` explicitly.
   On Other feedback, cancel the pending edge before revising work or requesting a different
   legal target. Never interpret silence, enthusiasm, or topic changes as confirmation.
-- **State before action.** Every user-confirmed stage advance is a two-step protocol: first
+- **State before action.** Every confirmation-required stage advance is a two-step protocol: first
   consume the pending edge through `confirm-transition`, then run that stage's real work. The
   automatic edges use `auto-transition` instead. Do not start
   analysis, implementation, review, verification, memory writing, or closeout while
@@ -165,23 +175,20 @@ it, routing matches, and switching happens again.
   Additionally, ANALYSIS must stay faithful to the user's delivery form — it may NOT downgrade
   a code task to a report-only task — and the 改动范围 table must list only real project code,
   never `.easy-coding/` harness artifacts (ec-analysis HARD RULES 5 and 6).
-- **Autonomous exception.** `behavior.auto_mode: true` in `.easy-coding/config.yaml` only
-  waives stage-boundary prompts when the user explicitly requested autonomous execution.
-  It carries NO scope or delivery-form decision. Never cite `auto_mode` to narrow scope,
-  downgrade a code task, or bypass a blocker that needs a real user decision.
-- **At user-decision stage completion** request the legal target immediately (not at turn end):
+- **At confirmation-required stage completion** request the legal target immediately:
   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py request-transition --session-file <P> --stage <STAGE> --agent <agent-id> --reason "<why this edge is ready>"`.
   This writes only `pending_transition`; it does not change the stage.
 - **No-code IMPLEMENT delivery:** before completing the task, ec-implementing must
   have output the successful unit's complete non-empty `deliverable` verbatim to the user.
   A summary or execution.jsonl record is not a substitute; missing user-visible delivery keeps
   the task in IMPLEMENT. The execution log must contain a matching `dispatch` immediately before
-  the accepted result for that unit. After delivery, call `auto-transition --stage COMPLETE`;
-  do not enter REVIEW, VERIFICATION, or MEMORY and do not write memory.
-- **On automatic completion** call:
-  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <ANALYSIS|COMPLETE> --agent <agent-id>`.
-  The state API accepts INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and a validated
-  read-only IMPLEMENT -> COMPLETE through this command.
+  the accepted result for that unit. After delivery, use `request-transition` in approve mode
+  or `auto-transition` in guard/auto mode for COMPLETE; do not enter REVIEW, VERIFICATION, or
+  MEMORY and do not write memory.
+- **On an automatic edge** call:
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <TARGET> --agent <agent-id>`.
+  The state API validates both the legal edge and the effective confirm mode before changing
+  the stage.
 - **On user confirmation** read the current task's pending edge and call:
   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py confirm-transition --session-file <P> --stage <STAGE> --agent <agent-id>`.
   Only after the read-after-write status names the target stage may its action start.
@@ -197,18 +204,17 @@ it, routing matches, and switching happens again.
   you MUST revert the task's status to the previous valid stage and explain why the
   transition was rejected. Do not proceed with an illegal stage.
 - **Repair loop sizing** (after VERIFICATION): a trivial tweak may be fixed inside
-  VERIFICATION and re-verified without a status change; a logic or structure change requests
-  VERIFICATION -> IMPLEMENT and waits at the standard confirmation gate. After repair, present
-  the IMPLEMENT completion choice again so the user may enter REVIEW or skip directly to
-  VERIFICATION.
+  VERIFICATION and re-verified without a status change; a logic or structure change selects
+  VERIFICATION -> IMPLEMENT and follows the effective mode. After repair, approve mode presents
+  the IMPLEMENT choice again; guard/auto follow the default REVIEW path.
 - **Scope guard** (repair loop): if the user's fix request falls outside the dev-spec scope
   (features or files absent from the change-scope table), say so explicitly and propose a
   new task with `spawned_from` set to the current task id. Never silently absorb scope creep.
 - **Task switching is allowed at any stage.** The suspended task retains its stage in
   task.json. Do not run memory flows for suspended tasks — only completed tasks get archived.
-- **Archive only after user acceptance.** VERIFICATION passing does not complete the task.
-  A green gate requests VERIFICATION -> MEMORY and presents the standard choices. After the
-  user confirms, MEMORY writes one short entry first, records it through `memory-short-complete`,
+- **Archive only after the configured acceptance gate.** VERIFICATION passing does not complete
+  the task. A green gate requests VERIFICATION -> MEMORY in approve/guard, or advances
+  automatically in auto. After entry, MEMORY writes one short entry first, records it through `memory-short-complete`,
   then asks the state API for the authoritative `memory` instruction. `action == "no-op"`
   skips long-memory reads/writes; `action == "distill"` processes exactly `trim_count` older
   entries. After `memory-complete`, ec-memory automatically advances MEMORY -> COMPLETE.
@@ -220,7 +226,8 @@ it, routing matches, and switching happens again.
 ## Resume and handoff
 
 Hook breadcrumbs you may receive: `[workflow-state:X]`, `[current-task:Y]`,
-`[easy-coding:session-file:P]`, `[easy-coding:handoff-from:Z]`,
+`[easy-coding:session-file:P]`, `[easy-coding:confirm-mode:M]`,
+`[easy-coding:handoff-from:Z]`,
 `[easy-coding:init-required]`.
 
 Resuming an active task (whether from session restart, claim, handoff, or task switch):
@@ -229,21 +236,20 @@ Resuming an active task (whether from session restart, claim, handoff, or task s
    records tell you exactly where work stopped.
 3. If the task was claimed from another agent, read the latest `handoff` record first for the
    fast summary and tell the user which previous agent handed it off.
-4. If `pending_transition` exists, do not rerun the completed stage action. If its stored edge
-   is INIT -> ANALYSIS or MEMORY -> COMPLETE, treat it as an upgrade-era automatic edge: call
-   `auto-transition` for the stored target immediately, without confirmation or handoff. For
-   a read-only task in IMPLEMENT, cancel any stale pending REVIEW/VERIFICATION edge before the
-   terminal check below. For any other stored edge, re-present the standard
-   confirmation/handoff/Other choices. At an IMPLEMENT boundary for a code task, re-present the
-   special REVIEW / skip to VERIFICATION / handoff choices.
+4. If `pending_transition` exists, do not rerun the completed stage action. Compare the stored
+   edge with `effective_confirm_mode`. If the edge is now automatic, call `auto-transition` for
+   its stored target; otherwise re-present the confirmation/handoff/Other choices. For a
+   read-only task in IMPLEMENT, cancel any stale REVIEW/VERIFICATION edge before the terminal
+   check below. At an approve-mode IMPLEMENT boundary for a code task, re-present the special
+   REVIEW / skip to VERIFICATION / handoff choices.
 5. If a read-only task resumes in IMPLEMENT with a valid successful result, output its complete
-   deliverable again and immediately auto-transition to COMPLETE. Otherwise tell the user what
-   is being resumed and from which stage, then continue.
+   deliverable again and follow the effective mode to COMPLETE. Otherwise tell the user what is
+   being resumed and from which stage, then continue.
 
 After a task switch, the same resume flow applies — the only difference is that `current_task`
 was just changed by the switching procedure rather than being loaded from a prior session.
 
-Offering handoff — every user-decision pending edge includes the handoff option. On that
+Offering handoff — every confirmation-required pending edge includes the handoff option. On that
 option, call:
 `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py handoff-task --session-file <P> --agent <agent-id> --summary "<dense context: plan shape, key decisions, user emphases>"`.
 

package/templates/main-constraint/AGENTS.md.tpl

@@ -11,7 +11,7 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-- Ready: > **Easy Coding** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to view tasks
+- Ready: > **Easy Coding** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
 - Waiting init: > **Easy Coding** · Waiting init · Use `ec-init` to initialize
 - Active task: > **Easy Coding** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
@@ -28,22 +28,25 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-brainstorming` — design exploration before building (hard design gate)
 - `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — list/create tasks · `ec-task-close` — interrupt a task
+- `ec-task-management` — task/session panel: list/create tasks and view/change the session confirm mode · `ec-task-close` — interrupt a task
+- `ec-no-harness` — bypass only Easy Coding for the current session
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
 
 First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
-  User-decision edges use `pending_transition`; offer the target and handoff, and offer
-  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
-  to VERIFICATION.
-  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
-  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
-  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
-  writes no task memory.
-  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
+- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
+  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
+  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
+  delivery form, evidence gates, or the legal transition graph.
+- Confirmation-required edges use `pending_transition`; automatic edges use the restricted
+  `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
+  VERIFICATION, or MEMORY, and writes no task memory.
+- When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
+  only Easy Coding workflow/stage orchestration for this session. Continue honoring every
+  non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
   write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
   without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
@@ -51,8 +54,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
 - For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
   evidence, and coverage must match the test strategy, before completion.
-- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
-  only after explicit user acceptance; once memory processing completes, COMPLETE is automatic.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
+  effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly

package/templates/main-constraint/CLAUDE.md.tpl

@@ -11,7 +11,7 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-- Ready: > **Easy Coding** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to view tasks
+- Ready: > **Easy Coding** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
 - Waiting init: > **Easy Coding** · Waiting init · Use `ec-init` to initialize
 - Active task: > **Easy Coding** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
@@ -26,22 +26,25 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-brainstorming` — design exploration before building (hard design gate)
 - `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — list/create tasks · `/ec-task-close` — interrupt a task
+- `/ec-task-management` — task/session panel: list/create tasks and view/change the session confirm mode · `/ec-task-close` — interrupt a task
+- `/ec-no-harness` — bypass only Easy Coding for the current session
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
 
 First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
-  User-decision edges use `pending_transition`; offer the target and handoff, and offer
-  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
-  to VERIFICATION.
-  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
-  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
-  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
-  writes no task memory.
-  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
+- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
+  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
+  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
+  delivery form, evidence gates, or the legal transition graph.
+- Confirmation-required edges use `pending_transition`; automatic edges use the restricted
+  `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
+  VERIFICATION, or MEMORY, and writes no task memory.
+- When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
+  only Easy Coding workflow/stage orchestration for this session. Continue honoring every
+  non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
   write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
   without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
@@ -49,8 +52,8 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
 - For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
   evidence, and coverage must match the test strategy, before completion.
-- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
-  only after explicit user acceptance; once memory processing completes, COMPLETE is automatic.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
+  effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly