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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.8.1-beta.0",
+  "version": "0.8.1-beta.2",
   "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-git/SKILL.md

@@ -28,21 +28,28 @@ with `.easy-coding/sessions/` always excluded. The CLI already added it to `.git
 
 ## Rules
 
-1. **In-progress warning.** If the commit touches a task folder whose status is not COMPLETE,
-   warn: "Task «X» is not finished — commit the intermediate state?" and wait.
-2. **Conflict handling for `.easy-coding/`** (mostly `memory/`): first explain the conflict
+1. **Non-terminal warning.** If the commit touches a task folder whose status is neither
+   `COMPLETE` nor `CLOSED`, warn: "Task «X» is not finished — commit the intermediate state?"
+   and wait. `COMPLETE` and `CLOSED` are terminal states; include their task artifacts without
+   asking for intermediate-state confirmation.
+2. **CLI-managed upgrade changes.** Inspect the complete workspace change list before choosing
+   the commit set. Changes written by `easy-coding upgrade` to managed harness files are in
+   scope by default. Do not exclude them because the current agent did not write them or
+   because they were produced outside the current assistant turn. Preserve the explicit path
+   exclusions above, and report unrelated pre-existing work separately.
+3. **Conflict handling for `.easy-coding/`** (mostly `memory/`): first explain the conflict
    details to the user, get confirmation, then do an inductive semantic merge — never blindly
    pick ours/theirs. This requirement applies only to conflicts inside `.easy-coding/`.
-3. **Cross-repo commit sets.** When a task spans repos (per the dev-spec / current task
+4. **Cross-repo commit sets.** When a task spans repos (per the dev-spec / current task
    `repo_paths`), the commit/push covers every involved repo. Read `repo_paths` from the
    current task state to locate each checkout, check changes, and commit/push them as one
    coherent change set — do not leave a sub-repo behind.
-4. **Supermodule two-step commits.** If the current repo has `.gitmodules`, or the current
+5. **Supermodule two-step commits.** If the current repo has `.gitmodules`, or the current
    task touches a git submodule path, treat each submodule as an independent git boundary:
    commit and push child repos first, then commit and push the parent gitlink update. If a
    child repo is on a detached HEAD, stop and ask the user to choose or create a branch before
    committing there.
-5. **No false success.** Never claim a commit or push succeeded without reading the command
+6. **No false success.** Never claim a commit or push succeeded without reading the command
    output. A failed push reported as success is a serious error.
 
 ## Boundaries
@@ -50,6 +57,8 @@ with `.easy-coding/sessions/` always excluded. The CLI already added it to `.git
 - Do not touch session files, task status fields, or run stage transitions — git only.
 - Do not commit `.easy-coding/sessions/`.
 - Do not commit `spec/dev/` unless the user explicitly asks.
+- Do not omit managed `easy-coding upgrade` changes merely because they were created outside
+  the current agent turn.
 - In a supermodule task launched from the parent root, parent `.easy-coding/` belongs to the
   parent git. Child `.easy-coding/memory/` changes created by memory archive belong to the
   owning child git and must be committed before the parent gitlink update.

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/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 / 记忆 / 报告等）当作改动对象。本表为空仅允许用于"用户明确要求的无代码交付形态"；代码类任务（重构/修复/功能）若此表为空，即为自我降级。