easy-coding-harness 0.8.0 → 0.8.1-beta.0

package/CHANGELOG.md

@@ -6,6 +6,12 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 0.8.1-beta.0
+
+- 修复分析阶段结束后的确认门可能退化为单一“回复确认执行”提示的问题：存在 `pending_transition` 时必须实际调用平台原生选择能力，完整提供确认目标阶段、交接给其他智能体和 free-form Other。
+- 普通确认门与 Approve 模式代码 IMPLEMENT 特殊门分别保留各自完整分支，文本回退不会遗漏“跳过 REVIEW 进入 VERIFICATION”；原生选择返回空值、取消、超时或无法解析时继续保留待确认边，同一 assistant 轮最多重试一次，避免无限重复调用。
+- workflow、analysis、Claude/Codex/Qoder 主约束、设计与使用文档及三平台安装回归测试同步固化上述展示契约。
+
 ## 0.8.0
 
 - 正式发布 `lite` 确认模式：沿用 Guard 的关键确认门，代码任务完成 IMPLEMENT 后跳过 REVIEW，直接进入 VERIFICATION。

package/package.json

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

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

@@ -263,11 +263,29 @@ Re-output the COMPLETE revised dev-spec.md:
 3. Overwrite the `plan` record in execution.jsonl with the new strategy.
 4. For code tasks, update test-strategy.md if test scope changed. For read-only tasks, keep the
    file absent.
-5. Request ANALYSIS -> IMPLEMENT again and present the standard confirmation/handoff/Other gate.
+5. Request ANALYSIS -> IMPLEMENT again and present the complete confirmation/handoff/Other gate
+   defined below.
+
+## ANALYSIS -> IMPLEMENT choice gate (hard)
+
+The same turn that `request-transition` succeeds must invoke the platform's native user-choice
+tool when one is available. The visible branches are:
+
+1. Confirm entering IMPLEMENT (recommended)
+2. Hand off to another agent
+3. Other — use the native free-form Other input for revisions or another instruction.
+
+If no native choice tool exists, render all three branches as a numbered text fallback. An empty,
+dismissed, timed-out, or unparseable result keeps the task in ANALYSIS with its pending edge and
+may retry the native choice at most once per assistant turn. If that retry also fails, stop the
+current turn and re-present the complete gate on the next user interaction. Never replace the gate
+with only "reply confirm", "confirm execution", or a statement that no valid choice was received,
+and never invoke native choice repeatedly in the same turn. Choosing handoff delegates to
+ec-workflow's existing target-less `handoff-task` flow; do not ask the user to name the next agent.
 
 ## End state
 
 Read dev-spec.md back from disk and output the COMPLETE content as your reply to the user —
-not a summary, not a different format, not a table you invented. Then ask ec-workflow to
-record `pending_transition: ANALYSIS -> IMPLEMENT`, present the standard boundary choices,
+not a summary, not a different format, not a table you invented. Then ask ec-workflow to record
+`pending_transition: ANALYSIS -> IMPLEMENT`, immediately present the complete choice gate above,
 and stop. Never start implementing from this skill.

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

@@ -144,11 +144,12 @@ it, routing matches, and switching happens again.
 - **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:
+- **Native choice rendering is mandatory (hard requirement).** When the effective mode requires
+  confirmation, call `request-transition`. After it succeeds, the boundary is not fully presented
+  until the user can actually choose every required business branch. When the agent/platform
+  exposes a native user-choice tool, you MUST actually invoke it in the same turn; mentioning the
+  tool, recommending a reply, or printing only a confirmation sentence is not a substitute. Offer
+  exactly these business branches through that native UI:
   1. Confirm entering/returning to `<target-stage>` (recommended)
   2. Hand off to another agent
   3. Other — use the native tool's built-in free-form Other input.
@@ -158,9 +159,22 @@ it, routing matches, and switching happens again.
   VERIFICATION, cancel that edge, request IMPLEMENT -> VERIFICATION, and immediately confirm it
   because that selection is explicit confirmation of the alternate target.
   Plain-text numbered choices are fallback only: use them only when no native user-choice tool
-  exists. The runtime hook never mutates workflow state from user-prompt text. Native choice
-  results, numbered fallback replies, and every natural-language reply must be interpreted by
-  you against the current task and stored target before calling `confirm-transition` explicitly.
+  exists. An ordinary gate must list all three branches rather than collapsing to "reply confirm":
+  `1. Confirm entering/returning to <target-stage> (recommended)`,
+  `2. Hand off to another agent`, `3. Other (describe revisions or another instruction)`.
+  The code-task IMPLEMENT completion fallback must preserve its special branch set:
+  `1. Enter REVIEW (recommended)`, `2. Skip REVIEW and enter VERIFICATION`,
+  `3. Hand off to another agent`, `4. Other (describe revisions or another instruction)`.
+  An empty, dismissed, timed-out, or unparseable choice result is not confirmation. Preserve the
+  pending edge and re-present the complete native choice UI at most once per assistant turn. If
+  that retry is also empty, dismissed, timed out, or unparseable, stop the current turn with the
+  pending edge intact and re-present the gate on the next user interaction; never call the native
+  choice tool repeatedly in the same turn. If native choice is no longer available, render the
+  appropriate complete numbered fallback. Never report "no valid choice" and then show only a
+  confirmation instruction. The runtime hook never mutates workflow state from user-prompt text.
+  Native choice results, numbered fallback replies, and every natural-language reply must be
+  interpreted by 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 confirmation-required stage advance is a two-step protocol: first

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

@@ -47,6 +47,16 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 - 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.
+- A confirmation-required boundary is not fully presented until the user can choose its complete
+  business branches. When a native user-choice tool is available, invoke it in the same turn with
+  the complete gate. An ordinary gate offers "confirm entering/returning to the target stage"
+  (recommended) and "hand off to another agent", with free-form Other for revisions. The special
+  approve-mode code IMPLEMENT gate must instead preserve enter REVIEW, skip to VERIFICATION, and
+  handoff, with free-form Other. Only when no native choice tool exists may you show the matching
+  complete numbered fallback. Empty, dismissed, timed-out, or unparseable results preserve the
+  pending edge and may retry native choice at most once per assistant turn; after a failed retry,
+  stop the turn and re-present the gate on the next user interaction. Never degrade to only
+  "reply confirm" or repeatedly invoke native choice in the same turn.
 - 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.

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

@@ -45,6 +45,16 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 - 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.
+- A confirmation-required boundary is not fully presented until the user can choose its complete
+  business branches. When a native user-choice tool is available, invoke it in the same turn with
+  the complete gate. An ordinary gate offers "confirm entering/returning to the target stage"
+  (recommended) and "hand off to another agent", with free-form Other for revisions. The special
+  approve-mode code IMPLEMENT gate must instead preserve enter REVIEW, skip to VERIFICATION, and
+  handoff, with free-form Other. Only when no native choice tool exists may you show the matching
+  complete numbered fallback. Empty, dismissed, timed-out, or unparseable results preserve the
+  pending edge and may retry native choice at most once per assistant turn; after a failed retry,
+  stop the turn and re-present the gate on the next user interaction. Never degrade to only
+  "reply confirm" or repeatedly invoke native choice in the same turn.
 - 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.