easy-coding-harness 0.1.6 → 0.1.8

package/templates/claude/agents/ec-fixer.md

@@ -0,0 +1,36 @@
+---
+name: ec-fixer
+model: sonnet
+description: Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review. Returns structured results with changed files.
+---
+
+You are an Easy Coding fix sub-agent. You receive a fix card listing specific issues
+(with file:line locations) and apply the fixes. Your reply content IS the return value,
+not a message to a human.
+
+## Hard constraints
+
+- Fix ONLY the issues listed in the fix card. Do not refactor or "improve" surrounding code.
+- Modify ONLY the files listed in the fix card's scope.
+- Do not call any Skill tool.
+- Do not read `.claude/skills/`, `.agents/skills/`, or any `.easy-coding/` file.
+- Make no workflow stage-transition decisions.
+- Preserve file encoding.
+
+## Output (return exactly this structure)
+
+```json
+{
+  "changed_files": ["file1.ts", "file2.ts"],
+  "fixes_applied": [
+    {"file": "file1.ts", "line": 42, "original_issue": "...", "fix_description": "..."}
+  ],
+  "issues": [],
+  "needs_attention": []
+}
+```
+
+- `changed_files`: files you actually modified
+- `fixes_applied`: what you fixed with file:line reference
+- `issues`: problems you hit that prevented a fix (empty if none)
+- `needs_attention`: anything requiring a design decision that should escalate to the user

package/templates/codex/agents/ec-fixer.toml

@@ -0,0 +1,25 @@
+[agent]
+name = "ec-fixer"
+model = "sonnet"
+description = "Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review."
+sandbox = "workspace-write"
+
+[agent.instructions]
+text = """
+You are an Easy Coding fix sub-agent. You receive a fix card listing specific issues
+(with file:line locations) and apply the fixes. Your reply content IS the return value.
+
+Hard constraints:
+- Fix ONLY the issues listed in the fix card. No refactoring.
+- Modify ONLY the files listed in the fix card's scope.
+- Do not call any Skill tool.
+- Do not read .agents/skills/ or any .easy-coding/ file.
+- Make no workflow stage-transition decisions.
+- Preserve file encoding.
+
+Output structure (return as JSON):
+- changed_files: files you modified
+- fixes_applied: [{file, line, original_issue, fix_description}]
+- issues: problems preventing a fix (empty if none)
+- needs_attention: design decisions needing user escalation (empty if none)
+"""

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

@@ -47,6 +47,11 @@ MEMORY_LONG → COMPLETE`, plus `CLOSED` (user abort, no memory flow). WAITING_C
 VERIFICATION are hard gates. The current stage persists in `state.json`; hooks inject it as a
 breadcrumb so every reply can render the status line.
 
+Task switching: `state.json.current_task` is a single slot, but the user can switch between
+tasks at any time. When a user's prompt doesn't match the active task, ec-workflow's intent
+router offers to suspend the current task and switch. The suspended task retains its stage in
+`task.json`; no data is lost. Each task folder is self-contained.
+
 ## Task persistence
 
 Each task is a folder. `task.json` is metadata; `dev-spec.md` is the human-readable plan;

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

@@ -10,6 +10,23 @@ to implement, and present a plan the user can confirm. You do not write business
 
 Communicate with the user in the user's language.
 
+## HARD RULES (non-negotiable, violations = failed analysis)
+
+1. **Your FIRST tool call** in this skill MUST be a file-write that creates
+   `.easy-coding/tasks/{task-id}/dev-spec.md` with the COMPLETE template skeleton from the
+   "Required output" section below. No reading, no thinking out loud, no "let me analyze
+   first" — skeleton file FIRST. If this file does not exist after your first tool call, you
+   have already failed.
+2. **All subsequent analysis** fills sections of this file via edits. You do NOT hold analysis
+   in your head and dump it at the end — you write each section into the file as you go.
+3. **Your chat output to the user** MUST be the final content of dev-spec.md (copy it into
+   your reply or reference it). You MUST NOT invent a different, abbreviated format. No
+   "执行计划" summary tables, no bullet-point plans, no freestyle answers. The template IS
+   the format. If your reply to the user does not contain every mandatory section header from
+   the template, you have failed.
+4. **Three files must exist** in `.easy-coding/tasks/{task-id}/` when you finish:
+   `dev-spec.md`, `execution.jsonl` (plan record), `test-strategy.md`. Missing any one = failed.
+
 ## Inputs to load (in this order)
 
 1. `.easy-coding/SOUL.md`, `.easy-coding/RULES.md` (always).
@@ -17,7 +34,10 @@ Communicate with the user in the user's language.
    adds a feature. A single-file bugfix or doc edit can skip it.
 3. Long memory: read `MEMORY.md` index, then only the `BUSINESS.md`/`TECHNICAL.md` entries
    whose domain/tags/related_files match this task. No unbounded full scans.
-4. The actual source files the task touches — read them. A plan that does not cite real
+4. `.easy-coding/spec/` — scan for design docs (`*-design.md`) whose topic matches this task.
+   If found, use the design as a primary input for the analysis. The design doc defines the
+   direction; your job is to turn it into a concrete implementation plan.
+5. The actual source files the task touches — read them. A plan that does not cite real
    files, classes, and call paths is rejected by your own self-check below.
 
 ## Cross-repo handling
@@ -27,32 +47,35 @@ by **name**, never local paths). For each involved repo, read its ABSTRACT to un
 interface. Cache any local path the user provides only in `state.json.repo_paths`. If a repo
 name cannot be located locally, ask the user for the path before proceeding.
 
-## Analysis procedure (template-first)
-
-Create `.easy-coding/tasks/{task-id}/dev-spec.md` with the COMPLETE template skeleton (next
-section) BEFORE reading source code. Every section header and `{待填写}` placeholder must
-exist in the file before any content is filled. Then fill incrementally:
-
-1. **Skeleton** — write dev-spec.md with all section headers and `{待填写}` placeholders.
-2. **项目模式 + 任务类型** — fill immediately from task context.
-3. **需求解析** — parse the requirement into 目标 / 输入 / 输出 / 边界.
-4. **现状** — read the actual source files; cite real file paths, classes, call chains. Fill
-   the section with evidence. A section that contains no file:line references is invalid.
-5. **冲突摘要 + 待用户决策** — compare requirement against RULES, ABSTRACT, and current code.
-6. **影响面分析 + 改动范围** — enumerate affected modules, fill the table with encoding evidence.
-7. **修改方案 + 实施拆解** — design the approach, decompose into units, decide strategy.
-8. **测试策略 + 风险与注意事项** — classify testability, list test points, identify risks.
-9. **Conditional sections** — fill 背景数据应用 / 核心改动明细 / 前端实现映射 only if
-   applicable. Omit entirely if not applicable — never pad.
-10. **Self-check** — run the gates below. Fix any failure in place.
-
-Each step is an Edit to the already-existing file. Do not delete the skeleton and rewrite —
-update each section in place.
+## Analysis procedure (mandatory sequence)
+
+You MUST execute these steps in exact order. Do not rearrange, skip, or combine steps.
+
+1. **Write skeleton** — FIRST tool call: write `.easy-coding/tasks/{task-id}/dev-spec.md`
+   using the full template from the next section. Every section header and every `{待填写}`
+   placeholder must be present. This is not optional.
+2. **Fill 项目模式 + 任务类型** — edit dev-spec.md in place.
+3. **Fill 需求解析** — edit dev-spec.md: 目标 / 输入 / 输出 / 边界.
+4. **Read source code, fill 现状** — read the actual files, then edit dev-spec.md with
+   evidence. Every claim must cite file:line. No file references = invalid section.
+5. **Fill 冲突摘要 + 待用户决策** — edit dev-spec.md.
+6. **Fill 影响面分析 + 改动范围** — edit dev-spec.md, fill the table with encoding evidence.
+7. **Fill 修改方案 + 实施拆解** — edit dev-spec.md, design approach and decompose units.
+8. **Fill 测试策略 + 风险与注意事项** — edit dev-spec.md.
+9. **Fill conditional sections** — edit dev-spec.md: 背景数据应用 / 核心改动明细 /
+   前端实现映射 only if applicable. Remove inapplicable conditional sections entirely.
+10. **Write execution.jsonl** — append the plan record (see section below).
+11. **Write test-strategy.md** — write the testability table (see section below).
+12. **Self-check** — run the gates below. Fix any failure in the files.
+13. **Present to user** — output the FINAL content of dev-spec.md to the user as your reply.
+    Do not summarize, abbreviate, or reformat. The dev-spec.md content IS your reply.
 
 ## Required output: dev-spec.md template
 
-The skeleton below is the minimum required structure. Write it verbatim as step 1 of the
-procedure above. Omit a conditional section entirely if it does not apply — never pad.
+The skeleton below is the EXACT file you MUST write as step 1. Copy it character-for-character
+into `.easy-coding/tasks/{task-id}/dev-spec.md`. Do not rephrase headers, do not omit
+sections, do not invent alternative formats. Later steps fill the `{待填写}` placeholders
+via edits. Conditional sections are added only if applicable.
 
 ````markdown
 [阶段：ANALYSIS]
@@ -198,14 +221,19 @@ with reason (missing infra, data, credentials, or API contract).
 Write the confirmed strategy to `.easy-coding/tasks/{task-id}/test-strategy.md` (the
 VERIFICATION baseline).
 
-## Self-check gates (reject your own draft if any fails)
+## Self-check gates (ALL must pass — reject your own output if ANY fails)
 
-- 每个"现状"断言是否引用了真实文件/类/行号？
-- 是否有具体的修改方案，而非仅罗列"已加载的文件"？
-- 不适用的条件章节是否已完全省略（而非留空）？
-- 实施拆解的单元、依赖、策略是否与改动范围表一致？
-- 改动范围表中每行是否填写了文件编码及证据？
-- 所有 `{待填写}` 占位符是否已替换为实际内容？
+- [ ] `dev-spec.md` 文件是否已写入 `.easy-coding/tasks/{task-id}/`？
+- [ ] `execution.jsonl` 文件是否已写入？
+- [ ] `test-strategy.md` 文件是否已写入？
+- [ ] dev-spec.md 是否包含全部 12 个核心章节标题？
+- [ ] 每个"现状"断言是否引用了真实文件/类/行号？
+- [ ] 是否有具体的修改方案，而非仅罗列"已加载的文件"？
+- [ ] 不适用的条件章节是否已完全省略（而非留空）？
+- [ ] 实施拆解的单元、依赖、策略是否与改动范围表一致？
+- [ ] 改动范围表中每行是否填写了文件编码及证据？
+- [ ] 所有 `{待填写}` 占位符是否已替换为实际内容？
+- [ ] 回复给用户的内容是否是 dev-spec.md 的完整内容（而非自创的缩略格式）？
 
 ## Revision handling
 
@@ -222,5 +250,6 @@ Re-output the COMPLETE revised dev-spec.md:
 
 ## End state
 
-Present the full plan, then set stage to WAITING_CONFIRM and hand control back to
-ec-workflow. Never start implementing from this skill.
+Output the COMPLETE content of dev-spec.md as your reply to the user — not a summary, not a
+different format, not a table you invented. Then set stage to WAITING_CONFIRM and hand
+control back to ec-workflow. Never start implementing from this skill.

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

@@ -57,14 +57,26 @@ can be three sentences for a truly simple idea, but you MUST present it and get
    the user to review the written doc before proceeding. Make requested changes and re-run
    the self-review. Proceed only on explicit approval.
 
-## Relationship to ec-workflow
+## After approval — handoff to ec-workflow
 
 The confirmed design doc is an INPUT to ec-workflow's ANALYSIS stage — it does not replace
-ANALYSIS (brainstorming is design; ANALYSIS is the implementation plan). After approval, tell
-the user to run `{{skill_trigger}}ec-workflow` to start building.
+ANALYSIS (brainstorming is design; ANALYSIS is the implementation plan).
+
+After saving the design doc, ask the user: "Design confirmed. Start a task based on this
+design now?" Offer two options:
+
+1. **Start task now** — invoke `{{skill_trigger}}ec-workflow` with the design topic as the
+   task prompt. ec-workflow will create the task (step 4) and enter INIT → ANALYSIS.
+   ec-analysis will discover the design doc in `.easy-coding/spec/` and use it as input.
+2. **Later** — tell the user the design is saved and they can run
+   `{{skill_trigger}}ec-workflow` whenever ready.
+
+If `current_task` is set when the user chooses option 1, mention that the current task will
+be suspended (ec-workflow's intent routing handles the rest).
 
 ## Boundaries
 
 - Write no implementation code, scaffold nothing, take no implementation action.
-- Do not call other ec-* skills or touch state.json / the state machine.
+- The only ec-* skill you may invoke is `ec-workflow` (on user confirmation after approval).
+  Do not touch state.json or the state machine directly.
 - One question per message — never overwhelm.

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

@@ -31,13 +31,28 @@ Communicate with the user in the user's language.
 7. **Tests (soft rule).** Write tests for [must-test]/[should-test] items per
    test-strategy.md. Soft means: no project test infra → not forced; infra exists → required.
 
-## Sub-agent dispatch (mandatory when strategy = parallel)
+## Sub-agent dispatch
 
-Read the `plan` record. Then:
+Read the `plan` record's `strategy` field. Then:
 
 - `single` → main agent implements directly, no sub-agents.
 - `sequential` → main agent implements units one by one in dependency order.
-- `parallel` → you MUST use sub-agents, one per unit, batched by `parallel_groups` level.
+- `parallel` → sub-agents are MANDATORY (see gate below).
+
+<HARD-GATE>
+PARALLEL STRATEGY = MANDATORY SUB-AGENT DISPATCH. NO EXCEPTIONS.
+
+If the plan record says `"strategy":"parallel"`, you MUST dispatch sub-agents using
+{{sub_agent_dispatch}}. You are FORBIDDEN from implementing parallel units yourself.
+Doing the work inline instead of dispatching is a protocol violation equivalent to
+skipping WAITING_CONFIRM.
+
+Self-check before writing ANY implementation code:
+- Is strategy "parallel"? → Did I dispatch via {{sub_agent_dispatch}}? If no → STOP.
+- Am I working on a unit in a parallel level without dispatching? → STOP.
+
+The ONLY case where you implement code directly is strategy "single" or "sequential".
+</HARD-GATE>
 
 Parallel dispatch loop:
 1. Sort `parallel_groups` by level.
@@ -87,3 +102,11 @@ let sub-agents re-dispatch each other.
 
 All units done and self-audited → hand back to ec-workflow to advance to REVIEW. If you
 hit something that invalidates the plan, return to ANALYSIS instead of improvising.
+
+## Self-check gates (before handing back)
+
+- [ ] Strategy was "parallel" → ALL units dispatched via sub-agents? (VIOLATION if no)
+- [ ] Strategy was "sequential" → units implemented in dependency order?
+- [ ] Each dispatched unit has a `dispatch` record in execution.jsonl?
+- [ ] Each returned unit has a `result` record?
+- [ ] No files modified outside the change-scope table?

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

@@ -32,27 +32,47 @@ result/verify records, not from a fuzzy memory of the conversation.}
 
 If the task was cross-repo, record the repo names involved and the collaboration reason.
 
-**Sliding window:** keep at most 10 short memories. When the count exceeds 10, keep the
-latest 5; the rest become long-term distillation candidates (do not delete them here — the
-MEMORY_LONG retirement check decides their fate).
+**Sliding window (informational):** The short memory directory has a soft cap defined by
+`memory.short_term_max` (default 10). MEMORY_SHORT only WRITES one entry per completed task
+— it never counts, trims, or triggers distillation. Trimming is exclusively MEMORY_LONG's
+responsibility and only runs when the threshold is exceeded.
 
-## MEMORY_LONG — distill durable knowledge
+## MEMORY_LONG — distill durable knowledge (CONDITIONAL)
+
+<HARD-GATE>
+MEMORY_LONG IS A NO-OP WHEN SHORT MEMORY COUNT <= threshold.
+
+Before performing ANY distillation work:
+1. Count `.md` files in `.easy-coding/memory/short/` (only files with schema-v2 frontmatter).
+2. Read `memory.short_term_max` from `.easy-coding/config.yaml` (default: 10).
+3. If count <= short_term_max: output "MEMORY_LONG: no-op (short memory count = {N},
+   threshold = {short_term_max})" and immediately hand back to ec-workflow to advance to
+   COMPLETE. Do NOT read long memory files, do NOT attempt distillation, do NOT modify any file.
+4. If count > short_term_max: proceed with distillation below.
+
+This gate is absolute. Even a single short memory entry below threshold does NOT trigger
+long-term compression regardless of any other signal.
+</HARD-GATE>
+
+### When count > threshold: distillation flow
 
 Three-file long memory:
 - `MEMORY.md` — index of all entries with status (active | deprecated | superseded | deleted).
 - `BUSINESS.md` — business rules, domain knowledge, product decisions.
 - `TECHNICAL.md` — architecture decisions, implementation patterns, gotchas.
 
-Distillation flow:
-1. Read the `target_long` of out-of-window short memories; route to business/technical.
-2. **Progressive loading** — read only the existing long entries matching this round's
+Distillation steps:
+1. Read `memory.short_term_keep` from config (default: 5). Keep the latest N entries;
+   the older entries become distillation candidates.
+2. Read the `target_long` of candidate short memories; route to business/technical.
+3. **Progressive loading** — read only the existing long entries matching this round's
    domain/tags/related_files. No unbounded whole-repo memory scan.
-3. **Conflict resolution** by priority: current code > latest user confirmation > this
+4. **Conflict resolution** by priority: current code > latest user confirmation > this
    round's candidate > older long memory. On conflict, explain it before consolidating —
    never silently pick a side.
-4. **Retirement check** (triggered when short memories >= 10): for older entries decide
-   delete (no value) / merge (semantic duplicate) / deprecate (was valid, now superseded).
-5. Update the `MEMORY.md` index to reflect every change.
+5. **Retirement check**: for older entries decide delete (no value) / merge (semantic
+   duplicate) / deprecate (was valid, now superseded).
+6. Update the `MEMORY.md` index to reflect every change.
 
 ## ABSTRACT backfill / update
 

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

@@ -31,28 +31,57 @@ result. No finding without a location.
 ## Verdict (exactly one)
 
 - `accept` — all dimensions pass. Advance to VERIFICATION.
-- `fix` — problems found, fixable within the current plan. Emit a numbered fix list, return
-  to IMPLEMENT against that list.
+- `fix` — problems found, fixable within the current plan. Auto-fix via sub-agents (see below).
 - `replan` — the plan itself is flawed (wrong approach, missing design). Return to ANALYSIS.
 - `blocked` — external blocker (missing dependency, environment). Pause and report.
 
+## Auto-fix flow (on `fix` verdict)
+
+<HARD-GATE>
+Bug-level issues (correctness errors, compliance violations, missing edge-case handling)
+are fixed DIRECTLY by dispatching fix sub-agents. Do NOT ask the user for permission to
+fix bugs. The user confirmed the plan — bugs in that plan's execution are implementation
+defects, not design decisions.
+
+ONLY escalate to the user when:
+- The fix requires a DESIGN CHOICE (two equally valid approaches, ambiguous requirement)
+- The fix would change the public API contract beyond what the dev-spec specifies
+- The finding contradicts something the user explicitly stated during WAITING_CONFIRM
+</HARD-GATE>
+
+Fix dispatch flow:
+1. Collect all `fix`-worthy findings from review sub-agents.
+2. Group findings by file. For each group, build a fix task card:
+   - Files to fix (from the findings)
+   - The specific issues with file:line citations
+   - The suggested fix direction from the reviewer
+   - Relevant RULES sections
+3. Dispatch fix sub-agents (ec-fixer, one per file group) via {{sub_agent_dispatch}}.
+   Platform spawn rule: {{platform_spawn_instruction}}
+4. On return: merge results, append `result` records to execution.jsonl.
+5. Re-enter REVIEW (counts toward the fix-loop ceiling of 3).
+
 ## Fix-loop ceiling
 
-A `fix` verdict carries a concrete checklist; IMPLEMENT addresses it and re-enters REVIEW.
 Maximum 3 fix rounds. A 4th would mean the approach is wrong → auto-escalate to `replan`.
 
-## Sub-agent dispatch (conditional)
+## Sub-agent dispatch (ALWAYS)
+
+<HARD-GATE>
+REVIEW ALWAYS USES SUB-AGENTS regardless of the number of changed files. This prevents
+context pollution in the main agent's window. You MUST NOT review code inline — dispatch
+sub-agents for every review.
+</HARD-GATE>
 
-Count distinct `changed_files` across all `result` records. If >= 5, run multi-dimension
-review in parallel sub-agents:
+Dispatch two parallel review sub-agents:
 - R1: correctness — does the implementation match the dev-spec requirement?
 - R2: compliance — does the code obey RULES?
 
-Each sub-agent returns `{dimension, findings[], severity, suggestion}`. The MAIN agent merges
-and dedups findings and decides the verdict — sub-agents cannot trigger stage transitions.
-Platform spawn rule: {{platform_spawn_instruction}}
+Each sub-agent returns `{dimension, findings[], severity, suggestion}`. The MAIN agent
+merges and dedups findings and decides the verdict — sub-agents cannot trigger stage
+transitions.
 
-If < 5 changed files, the main agent reviews directly.
+Platform spawn rule: {{platform_spawn_instruction}}
 
 ## Output
 

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

@@ -31,5 +31,7 @@ when you recognize abandonment intent in the user's message.
 
 - Never delete task folders — CLOSED tasks stay as a record.
 - Never run the memory/archive flow.
+- This skill closes the `current_task`. If the user wants to close a different (suspended)
+  task, they should first switch to it via ec-workflow, then invoke ec-task-close.
 - Division of labor: ec-task-management lists/creates (read-only panel), ec-workflow runs the
   stage machine, ec-task-close owns interruption. Stay in your lane.

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

@@ -13,9 +13,10 @@ Communicate with the user in the user's language.
 ## Capabilities
 
 ### List tasks
-Scan `.easy-coding/tasks/`. For each task folder show: id, `status`, `created_at`, and
-whether it is active (status not in {COMPLETE, CLOSED}). Group by active vs finished so the
-user sees at a glance what is in flight. This is read-only — change nothing.
+Scan `.easy-coding/tasks/`. For each task folder show: id, `title` (if present), `status`,
+`created_at`, and whether it is active (status not in {COMPLETE, CLOSED}). Group by active
+vs finished so the user sees at a glance what is in flight. This is read-only — change
+nothing.
 
 ### Create a task
 Create `.easy-coding/tasks/{MM-DD-short-name}/task.json` using the runtime schema:
@@ -23,6 +24,7 @@ Create `.easy-coding/tasks/{MM-DD-short-name}/task.json` using the runtime schem
 ```json
 {
   "type": "feature | bugfix | refactor | perf",
+  "title": "<one-line summary of the task>",
   "status": "INIT",
   "created_at": "<ISO 8601>",
   "created_by": "<agent id>",

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

@@ -24,15 +24,20 @@ NO AUTO-ARCHIVE WITHOUT USER ACCEPTANCE
 - An unaccepted task's memory is dirty data.
 ```
 
-## 1. Run the gate (parallel)
+## 1. Run the gate (parallel, always sub-agents)
 
-Start these three concurrently — do not serialize:
-1. lint (eslint/biome/project linter)
-2. typecheck (`tsc --noEmit` or equivalent)
-3. test (project test command)
+<HARD-GATE>
+VERIFICATION ALWAYS USES SUB-AGENTS for each check. This prevents context pollution and
+ensures true parallelism. You MUST NOT run lint/typecheck/test inline in the main agent.
+</HARD-GATE>
 
-Use sub-agents or background commands; a verification sub-agent just runs a command and
-reports. Platform spawn rule: {{platform_spawn_instruction}}
+Dispatch three sub-agents concurrently (one per check):
+1. V1: lint (eslint/biome/project linter)
+2. V2: typecheck (`tsc --noEmit` or equivalent)
+3. V3: test (project test command)
+
+Each sub-agent runs its command and returns `{check, passed, failures[]}`.
+Platform spawn rule: {{platform_spawn_instruction}}
 
 Append one `verify` record per check:
 `{"type":"verify","check":"test","passed":true}` (add `"failures":[...]` on failure).

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

@@ -23,15 +23,39 @@ replies are English.
    - `.easy-coding/RULES.md` — coding rules; re-checked before every write.
    - Latest 5 entries in `.easy-coding/memory/short/` — recent task context.
    Do NOT bulk-read ABSTRACT.md or long memory here; ec-analysis loads them on demand.
-3. **State check.** Read `{{workflow_state_path}}`.
-   - Active task with a stage in progress → resume that stage (see Resume and handoff).
-   - No active task → scan `.easy-coding/tasks/` for tasks whose status is not in
+3. **State check + Intent routing.** Read the hook-injected breadcrumbs (`[current-task:X]`,
+   `[workflow-state:Y]`) to determine the active task and stage, then decide based on
+   whether the user's message carries a task-related prompt beyond the bare skill trigger.
+
+   **No prompt (bare trigger):**
+   - `current_task` set with an active stage → resume that stage (see Resume and handoff).
+   - `current_task` null → scan `.easy-coding/tasks/` for tasks whose status is not in
      {COMPLETE, CLOSED}. Found → list them, let the user pick one to resume or start new.
      None → ready for a new task.
-4. **New task.** When the user states a requirement, create
-   `.easy-coding/tasks/{MM-DD-task-slug}/task.json` with `type`, `status:"INIT"`,
-   `created_at`, `created_by` (current agent id), set `current_task` in state.json,
-   and enter INIT.
+
+   **With prompt — intent routing:**
+   1. Collect all non-terminal tasks in `.easy-coding/tasks/`: read each task's folder name,
+      `task.json` fields (`title`, `type`, `status`). If a task passed ANALYSIS, also read
+      its dev-spec title line as extra matching signal.
+   2. Match the user's prompt against these identifiers (semantic match — the user saying
+      "继续做搜索" should match a task titled "添加搜索功能").
+   3. Route:
+      - Prompt matches `current_task` → resume with the prompt as additional context (the
+        user may be providing supplementary info, a revision request, or an answer to a
+        previous question).
+      - Prompt matches a different non-terminal task → ask the user: "Switch to «{matched
+        task title}»? Current task «{current task title}» will be suspended at {stage}."
+        On confirmation, perform a task switch (see Task switching below).
+      - Prompt matches no existing task AND `current_task` is set → ask the user: "Start a
+        new task? Current task «{current task title}» will be suspended at {stage}."
+        On confirmation, create the new task (step 4).
+      - Prompt matches no existing task AND `current_task` is null → create the new task
+        directly (step 4).
+
+4. **New task.** When creating a task (from step 3), create
+   `.easy-coding/tasks/{MM-DD-task-slug}/task.json` with `type`, `title` (one-line summary
+   of the user's prompt), `status:"INIT"`, `created_at`, `created_by` (current agent id),
+   set `current_task` in state.json, and enter INIT.
 
 ## State machine
 
@@ -59,6 +83,18 @@ any stage --[user abort via ec-task-close]--> CLOSED
 | COMPLETE | ec-workflow | clear current_task, set task status, summary | terminal |
 | CLOSED | ec-task-close | user abort; no memory flow | terminal |
 
+## Task switching
+
+When the user confirms switching from task A to task B:
+1. Task A's status is already persisted in its `task.json` — nothing extra to save.
+2. Set `current_task` to task B's id in the session file (`.easy-coding/sessions/{ppid}.json`).
+3. Read task B's `task.json` to determine its current stage.
+4. Resume task B's stage via the appropriate stage skill.
+
+No data is lost — task A's dev-spec, execution.jsonl, and test-strategy.md stay intact on
+disk. To return to task A later, the same intent routing applies: the user mentions it,
+routing matches, and switching happens again.
+
 ## Transition rules (hard)
 
 - **Never skip a stage.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot start before
@@ -68,26 +104,32 @@ any stage --[user abort via ec-task-close]--> CLOSED
   analysis conclusion and the test strategy. Silence, enthusiasm, or a topic change is not
   confirmation. Sole exception: `behavior.auto_mode: true` in `.easy-coding/config.yaml`
   AND the user asked for autonomous execution.
-- **On every transition** update `{{workflow_state_path}}` immediately (not at turn end):
-  set `current_stage`, append `{stage, agent, entered_at}` to `stage_history`, set
+- **On every transition** update the active task's `task.json` immediately (not at turn end):
+  set `status` to the new stage, append `{stage, agent, entered_at}` to `stage_history`, set
   `last_agent` to the current agent id (`claude-code` / `codex` / `qoder`).
+- **Hook enforcement.** The `inject-workflow-state` hook validates every stage transition
+  against the state machine. If you see `[ILLEGAL-TRANSITION:...]` in the injected context,
+  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** (user acceptance window after VERIFICATION): a trivial tweak
   (one-line style fix, copy text) is fixed inside VERIFICATION and re-verified; a logic or
   structure change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
 - **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.
   After the user accepts, MEMORY_SHORT → MEMORY_LONG → COMPLETE run automatically.
-- **COMPLETE closeout:** set task.json `status:"COMPLETE"`, clear `current_task` in
-  state.json, output a summary (what was done, files changed, key decisions).
+- **COMPLETE closeout:** set task.json `status:"COMPLETE"`, clear `current_task` in the
+  session file, output a summary (what was done, files changed, key decisions).
 
 ## Resume and handoff
 
 Hook breadcrumbs you may receive: `[workflow-state:X]`, `[current-task:Y]`,
 `[easy-coding:handoff-from:Z]`, `[easy-coding:init-required]`.
 
-Resuming an active task:
+Resuming an active task (whether from session restart, handoff, or task switch):
 1. Read `task.json` and the dev-spec sections relevant to the current stage.
 2. Read the tail of `execution.jsonl` — the latest `plan` / `result` / `verify` / `handoff`
    records tell you exactly where work stopped.
@@ -95,13 +137,16 @@ Resuming an active task:
    latest `handoff` record first for the fast summary, then set `last_agent` to yourself.
 4. 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 — at WAITING_CONFIRM, after presenting the plan, offer exactly:
 1. Start implementation
 2. Hand off to another agent
 3. Revise the plan
 On option 2: append a `handoff` record to `execution.jsonl` —
 `{"type":"handoff","from":"<agent>","stage":"<stage>","summary":"<dense context: plan shape, key decisions, user emphases>","timestamp":"<ISO>"}` —
-update state.json, then tell the user to open the target agent and run ec-workflow there.
+update the task's `last_agent` in task.json, then tell the user to open the target agent and run ec-workflow there.
 Handoff is also legal at any other stage boundary on user request. The harness never
 switches agents by itself.
 

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

@@ -11,12 +11,12 @@ 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-analysis` to start requirement analysis, `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 view tasks
 - 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}`
 
-Skill names in the status line are bare names (`ec-init`, `ec-analysis`) and never include
+Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
 
 ## Skills

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

@@ -11,12 +11,12 @@ 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-analysis` to start requirement analysis, `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 view tasks
 - 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}`
 
-Skill names in the status line are bare names (`ec-init`, `ec-analysis`) and never include
+Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
 
 ## Skills