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

package/package.json

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

package/templates/claude/settings.json

@@ -13,16 +13,6 @@
       }
     ],
     "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "{{platform_hook_session_start_command}}",
-            "timeout": 15000
-          }
-        ]
-      },
       {
         "matcher": "",
         "hooks": [

package/templates/codex/hooks.json

@@ -1,6 +1,6 @@
 {
   "hooks": {
-    "UserPromptSubmit": [
+    "SessionStart": [
       {
         "hooks": [
           {
@@ -9,7 +9,9 @@
             "timeout": 10
           }
         ]
-      },
+      }
+    ],
+    "UserPromptSubmit": [
       {
         "hooks": [
           {

package/templates/common/bundled-skills/ec-init/SKILL.md

@@ -44,10 +44,30 @@ Field whitelist: `mode`, `language`, `test.*`, `build.*`, `lint.*`. Do not inven
 top-level keys. Do not copy any CLI-owned field (`harness_version`, `agents`, …) into this
 file.
 
-## Entry guard (idempotency — run first)
+## Project-init preflight (run first — read-only)
 
 1. Read `.easy-coding/tasks/project-init/task.json`.
    - File missing → the CLI never ran. Tell the user to run `easy-coding init` first. Stop.
+   - File present → record its `status` for the entry dispatch below, but do not start the
+     compliance scan or initialization yet.
+2. Do not call the state API or write any project asset until this file-existence check passes.
+
+## Session path resolution (run after preflight — before any project write)
+
+Resolve one stable session path `<P>` and reuse it for the entire skill run:
+
+1. If hook context contains `[easy-coding:session-file:P]`, use that exact path.
+2. Otherwise run
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py snapshot --agent <agent-id>`
+   and use the returned `session_file` as `<P>`. This is the compatibility path for an explicit
+   ec-init invocation before the platform has surfaced hook context.
+3. If snapshot fails or does not return a safe session path, stop before writing any project
+   asset and tell the user to enable or approve the platform hooks. Never execute a command with
+   the literal placeholder `<P>`.
+
+## Entry dispatch (idempotency — run after session resolution)
+
+1. Use the `status` read during the project-init preflight.
    - `status == "COMPLETE"` → already initialized. Run the **compliance scan** (see below),
      then exit.
    - `status == "PENDING"` → proceed with full initialization.
@@ -89,7 +109,7 @@ On decline: exit with the gap list as a reference for the user to address manual
 
 **Clear upgrade marker:** After the compliance scan completes (whether all checks passed or
 gaps were fixed), run
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py project-init-complete --agent <agent-id>`.
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py project-init-complete --session-file <P> --agent <agent-id>`.
 This removes `pending_init_since` and clears the "Waiting init · Upgrade" status line so the
 user is no longer prompted on every session. Use the returned `status_context` as the current
 status source.
@@ -147,7 +167,7 @@ agent must be able to see what was generated and on what evidence.
    Also ensure `SHORT_MEMORY_TEMPLATE.md` exists in `memory/` as format reference. Never write
    fake entries.
 7. **Mark complete** — write the final `init_log` entry, then run
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py project-init-complete --agent <agent-id>`.
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py project-init-complete --session-file <P> --agent <agent-id>`.
    Use the returned `status_context`, then tell the user initialization is done and daily work
    goes through `{{skill_trigger}}ec-workflow`.
 

package/templates/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -52,7 +52,8 @@ confirms two critical gates, lite uses the same gates but forces IMPLEMENT -> VE
 and auto advances legal edges automatically. Lite never enters REVIEW. VERIFICATION remains
 the code-task fresh-evidence hard gate, and MEMORY keeps the conditional long-memory threshold
 gate. The active task
-pointer lives in `sessions/{ppid}.json`;
+pointer lives in `sessions/{agent}-{session-id}.json` (with an agent-prefixed PPID fallback only
+when a hook payload has no logical session ID);
 when the task reaches `COMPLETE` or `CLOSED`, the state API clears `current_task` so the
 session returns to Ready. Each task's stage persists in its `task.json`. Hooks inject the
 session and task state as breadcrumbs so every reply can render the status line.

package/templates/common/bundled-skills/ec-meta/references/platform-files/README.md

@@ -37,23 +37,27 @@ Python runtime files are shared verbatim across platforms (only the JSON wrapper
   transitions, and task state reads.
 - `easy_coding_status.py` — renders the Markdown status line and machine breadcrumbs from
   state API snapshots.
-- `session-start.py` — ensures the per-session file exists; performs legacy `state.json`
-  migration; injects resume / init-required / handoff breadcrumbs. Idempotent.
-- `inject-workflow-state.py` — injects the `workflow-state` and `current-task` breadcrumbs so
-  the status line can render.
+- `session-start.py` — initializes the per-session file on native session-start events and emits
+  resume / init-required / handoff breadcrumbs.
+- `inject-workflow-state.py` — idempotently ensures the session and injects the `workflow-state`
+  and `current-task` breadcrumbs so the status line can render.
 - `inject-subagent-context.py` — injects the sub-agent guard before an Agent tool call.
 
 Wrapper differences:
 
 - **Claude Code**: full event set — `SessionStart`, `UserPromptSubmit`, `PreToolUse(Agent)`.
-  `session-start.py` also runs on `UserPromptSubmit` before `inject-workflow-state.py`, so
-  every prompt receives a fresh status context even if the native session event is not surfaced
-  to the model turn.
-- **Codex**: no `SessionStart` and no Agent tool. `session-start.py` and
-  `inject-workflow-state.py` both hang off `UserPromptSubmit`; `inject-subagent-context.py`
-  is skipped. Codex hooks also require user-level enablement (`[features] hooks = true`).
-- **Qoder**: like Claude Code (has Agent tool + Stop) but uses `UserPromptSubmit` for state
-  injection. The `.qoder/settings.json` wrapper nests an extra `hooks` array.
-
-`session-start.py` is designed to be idempotent precisely because Claude/Codex/Qoder can fire it
-on `UserPromptSubmit` rather than only a real session-start event — repeated calls are safe.
+  `session-start.py` owns native session initialization, while `inject-workflow-state.py` is the
+  single session writer on each prompt.
+- **Codex**: `session-start.py` runs on `SessionStart`, while
+  `inject-workflow-state.py` runs on `UserPromptSubmit`; `inject-subagent-context.py` is
+  skipped because Codex has no Agent tool hook. Codex hooks also require user-level enablement
+  (`[features] hooks = true`).
+- **Qoder**: has no separate session-start registration, so `inject-workflow-state.py` performs
+  idempotent initialization and state injection as the single `UserPromptSubmit` writer. Qoder
+  also has Agent tool + Stop hooks, and `.qoder/settings.json` nests an extra `hooks` array.
+
+Every session-writing hook resolves the same agent-prefixed logical session key from the hook
+payload, for example `codex-<session-id>.json`. On first use it adopts a legacy `<ppid>.json`
+file when present. A global atomic migration lock ensures only one concurrently starting session
+can claim legacy `state.json`; the winner commits its canonical session before removing the old
+state and releasing the lock.

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-memory/SKILL.md

@@ -18,13 +18,17 @@ recorded comment/doc language.
 
 Create one file under `.easy-coding/memory/short/` following the format in
 `.easy-coding/memory/SHORT_MEMORY_TEMPLATE.md`. File naming convention:
-`{NNN}_{YYYYMMDD}_{smart_name}.md`. The entry is immutable after creation.
+`{memory_id}_{YYYYMMDD}_{smart_name}.md`. Generate the id first with
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-new-id --session-file <P> --agent <agent-id>`.
+Use the returned `memory_id` unchanged as both the filename prefix and the frontmatter `id`.
+It uses UUIDv7, so agents never scan the directory or calculate a shared numeric sequence.
+Keep the readable `smart_name` suffix. The entry is immutable after creation.
 Frontmatter (all fields required):
 
 ```yaml
 ---
 memory_schema: 2
-id: SM-{YYYYMMDD}-{NN}
+id: {memory_id returned by memory-new-id, exact}
 source_task: {current task id, exact}
 date: {YYYY-MM-DD}
 task_type: {feature | bugfix | refactor | perf | doc | workflow}
@@ -53,7 +57,8 @@ After the file is successfully written, record the checkpoint immediately:
 Use the returned `status_context` as authoritative. On resume, if `memory_progress` already
 shows `short_memory_written:true`, do not create a duplicate entry; continue from Step 2.
 The state API validates `memory_schema: 2`, requires `source_task` to equal the current task id,
-and fingerprints the file. Do not reuse an older task's memory file as this checkpoint.
+requires a UUIDv7 id that exactly matches the filename prefix, and fingerprints the file. Do not
+reuse an older task's memory file as this checkpoint.
 
 ## Supermodule memory routing
 

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.

package/templates/qoder/settings.json

@@ -1,21 +1,12 @@
 {
   "hooks": {
     "UserPromptSubmit": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "{{platform_hook_session_start_command}}",
-            "timeout": 10
-          }
-        ]
-      },
       {
         "hooks": [
           {
             "type": "command",
             "command": "{{platform_hook_inject_workflow_state_command}}",
-            "timeout": 5
+            "timeout": 10
           }
         ]
       }

package/templates/runtime/memory/SHORT_MEMORY_TEMPLATE.md

@@ -1,6 +1,6 @@
 ---
 memory_schema: 2
-id: SM-YYYYMMDD-001
+id: {memory_id}
 source_task: MM-DD-task-slug
 date: YYYY-MM-DD
 task_type: feature | bugfix | refactor | perf | doc | workflow
@@ -20,14 +20,17 @@ target_long: BUSINESS | TECHNICAL | BOTH | NONE
 # Short Memory Template
 
 > This template defines the format for files under `.easy-coding/memory/short/`.
-> File naming convention: `{NNN}_{YYYYMMDD}_{smart_name}.md`
+> File naming convention: `{memory_id}_{YYYYMMDD}_{smart_name}.md`
+> Generate `memory_id` through the state API `memory-new-id` command and use it unchanged as
+> both the filename prefix and this frontmatter `id`. The UUIDv7 id is safe for concurrent agents.
+> Keep `smart_name` as the readable summary suffix.
 > `source_task` must exactly match the current workflow task id from `task.json`.
 > Short memories are immutable after creation — they serve as a sliding window of recent
 > details and a buffer for long-term distillation candidates.
 > When short memories reach the threshold (default 10), the newest 5 are kept as recent
 > context; older entries are distillation candidates for long-term memory.
-> Sorting: by frontmatter `date` ascending; if date is missing or tied, by filename prefix
-> number ascending; then by filename ascending.
+> Sorting: by frontmatter `date` ascending, then by frontmatter `id`, then by filename. Legacy
+> `SM-YYYYMMDD-NNN` ids sort before UUIDv7 ids on the same date for upgrade compatibility.
 
 ## Task Summary
 

package/templates/runtime/templates/dev-spec-skeleton.md

@@ -29,7 +29,7 @@
 - **核心类 / 页面 / 接口**：[[EC_TODO:核心类 / 页面 / 接口]]
 - **数据库变更**：[[EC_TODO:有/无]]
 - **接口变更**：[[EC_TODO:有/无]]
-- **关联历史任务**：[[EC_TODO:相关短期记忆序号；无则“无”]]
+- **关联历史任务**：[[EC_TODO:相关短期记忆 ID；无则“无”]]
 
 ### 改动范围
 > 只列真实项目源码/配置文件的改动。禁止把 `.easy-coding/` 下的 harness 产物（dev-spec / execution.jsonl / test-strategy / 记忆 / 报告等）当作改动对象。本表为空仅允许用于"用户明确要求的无代码交付形态"；代码类任务（重构/修复/功能）若此表为空，即为自我降级。