easy-coding-harness 1.1.0-beta.1 → 1.1.0-beta.3

package/package.json

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

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

@@ -6,7 +6,8 @@ description: ANALYSIS-stage skill. Produces the confirmed dev-spec, execution pl
 # ec-analysis — progressive analysis and mode selection
 
 This stage is read-only for project source. Its outputs are task artifacts only:
-`dev-spec.md`, `execution.jsonl` plan, and `test-strategy.md` for code tasks.
+`dev-spec.md`, `execution.jsonl` plan, and `test-strategy.md` when required by the concrete mode.
+Compact Fast keeps checks in the existing plan.
 
 Communicate with the user in the user's language.
 
@@ -14,9 +15,11 @@ Communicate with the user in the user's language.
 
 1. Read task.json, SOUL, RULES index/headings, ABSTRACT index/headings, and the dev-spec
    skeleton.
-2. Search short-memory frontmatter and summaries first. Open only memories whose domains,
+2. Search short-memory frontmatter and knowledge summaries first. Open only memories whose domains,
    tags, related files, or predecessor links match this task. Do not load the newest five
-   memories unconditionally.
+   memories unconditionally. Skip `memory_value: none` during knowledge retrieval. For legacy
+   reports, read the matching reusable decisions or pitfalls; consult acceptance/process records
+   only when the current task needs that history, not as default development context.
 3. Read full RULES/ABSTRACT sections only for affected modules.
 4. Inspect concrete code paths and tests. Expand context only when evidence reveals another
    dependency or risk.
@@ -24,7 +27,8 @@ Communicate with the user in the user's language.
 Load context only for the current change and its direct dependencies. Reuse existing findings;
 without new evidence, do not repeat discovery or expand into unrelated modules.
 
-For a task with `task.json.spec_source`, use `resume-spec-context` against the stored source, exact
+For a task with `task.json.spec_source`, reuse the returned/current-session consumption closure.
+Only if missing or changed, use `resume-spec-context` against the stored source, exact
 `selected_spec_tasks`, and only their stored `task.repo_paths` bindings. Schema, Spec ID, design
 revision, and `design_sha256` must still match. A changed `document_sha256` with the same design is
 normal shared progress; refresh `execution_revision` without invalidating plan/QUALITY

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

@@ -1,6 +1,6 @@
 ---
 name: ec-config
-description: Inspect and configure Easy Coding project/session Approval, Workflow, and Java unit test strategies.
+description: Inspect and configure Easy Coding project/session Approval, cooperation, and Java unit test strategies across session, local and project scopes.
 ---
 
 # ec-config — mode configuration
@@ -10,15 +10,17 @@ and available actions. Never mutate project or session settings without an expli
 
 ## Configuration panel
 
-Call `snapshot` and show project, session, effective, and frozen task values for `approval_mode`,
+Call `snapshot` and show project, session, effective, and frozen task values for `approval_mode`, `cooperate_mode`,
 the mechanically calculated workflow mode (read-only), `unit_test_mode`, and `ut_coverage_threshold`.
+Show `behavior_sources`, `local_behavior`, and `effective_cooperate_mode` alongside the current
+task cooperation/continuation so a receiving Agent can distinguish its defaults from accepted work.
 Use `project_unit_test_mode`, `session_unit_test_mode`, `effective_unit_test_mode`, their threshold
 counterparts, `task_unit_test_mode`, `task_tdd_baselines`, and `unit_test_readiness_status` directly.
 When readiness is `not_checked`, report it as not checked; do not scan infrastructure merely to
 populate the panel. Inspect readiness when the user requests it or selects UT/TDD.
 
-Precedence is `session override > project config > defaults`. Defaults are Approval `guard`,
-Workflow `adaptive`, unit test strategy `none`, and shared changed-line coverage threshold 90%.
+Precedence is `session override > ~/.easy-coding/config.yaml > project config > defaults`, per field. Defaults are Approval `guard`,
+Workflow `adaptive`, cooperation `default`, unit test strategy `none`, and shared changed-line coverage threshold 90%.
 The strategies are:
 
 - `none`: ordinary task-required verification, with no additional coverage gate.
@@ -36,6 +38,32 @@ non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and QUALITY -> MEMOR
 waits only for the plan, and `auto` advances legal green edges immediately. A new code diff after
 the QUALITY checkpoint requires acceptance of that exact diff without changing the approval mode.
 
+## Cooperation and configuration scopes
+
+`cooperate_mode: default | dispatch` selects stage-boundary handoff or manual implementation/repair
+handoff. In dispatch, the coordinator analyzes, verifies and writes memory; the user may choose
+current-Agent execution for any bounded change. Never launch or schedule another Agent.
+One decision approves the displayed scope and its executor. Dispatch requires this human decision
+even under Auto; Approve consumes it as the same approval, not a second dialog. Existing accepted
+handoffs and frozen UT/TDD contracts survive changes to defaults.
+
+The local file is optional. Read-only inspection and init/upgrade never create it. Save only explicit
+keys under `behavior`; resetting a key removes that override. Local settings are preferences across
+projects and platforms, so saving local UT/TDD does not scan or initialize the current project.
+Readiness is checked when a task actually enables that strategy.
+
+After the user chooses scope and values, use these commands (the explicit choice authorizes `--yes`):
+
+```bash
+easy-coding config --scope local --cooperate-mode dispatch --yes
+easy-coding config --scope project --cooperate-mode default --yes
+easy-coding config --scope local --reset cooperate_mode --yes
+```
+
+The same scopes support `--approval-mode`, `--unit-test-mode`, and `--ut-coverage-threshold`.
+For a session, call `set-cooperate-mode --mode default|dispatch` or `clear-cooperate-mode`
+with the current state API, agent and session file. Bare `ec-config` remains read-only.
+
 ## Project configuration
 
 Use `easy-coding config`. The CLI confirms an atomic update of Approval, unit test strategy, and
@@ -49,7 +77,7 @@ After explicit user selection, use the current logical session file:
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-approval-mode --mode approve|guard|confirm|auto --agent <agent-id> --session-file <P>
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-approval-mode --agent <agent-id> --session-file <P>
 
-# Omitting threshold preserves the session threshold or inherits project/default 90.
+# Omitting threshold preserves the session threshold or inherits local/project/default 90.
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-unit-test-mode --mode none|ut|tdd [--threshold 1..100] --agent <agent-id> --session-file <P>
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-unit-test-mode --agent <agent-id> --session-file <P>
 ```

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

@@ -7,10 +7,10 @@ description: IMPLEMENT-stage skill. Executes the confirmed plan with workflow-mo
 
 Use only after ANALYSIS has frozen `task.json.workflow_mode` to `fast`, `standard`, or
 `strict`. Read `dev-spec.md`, the latest `plan` record in `execution.jsonl`, relevant RULES
-and ABSTRACT sections, and `test-strategy.md` for code tasks.
+and ABSTRACT sections. Read `test-strategy.md` when required; compact Fast uses plan checks.
 
 For a Canonical-backed task, consume the ready `spec_context.consumption` returned on creation
-or claim. On session resume or after design sync, call `resume-spec-context --agent <agent-id>
+or claim. Reuse unchanged context on the same session; only if context is missing or design changed, call `resume-spec-context --agent <agent-id>
 --session-file <P>`. The bound source and selected changes/steps/tests govern the implementation;
 handoff summaries and derived plans cannot substitute for this context. A blocked context or
 pending `spec_change` stops implementation until the original source is repaired/synchronized.
@@ -221,3 +221,11 @@ conversation overhead while keeping work observable.
       an existing core Java class, has Javadoc unless it qualifies for the documented-interface
       implementation exception.
 - [ ] The task enters QUALITY, regardless of workflow mode.
+
+## Manual implementation handoff
+
+When `continuation.next_action=implement`, execute only its approved Units. Reuse the original plan,
+commands and results. Honor `stop_after:IMPLEMENT`: record completion and hand back with
+`next_action:quality`, then stop. The receiving coordinator handles the existing stage boundary
+once under the approval policy; the executor never starts quality work by inertia. Users may
+instead choose current-Agent execution. No platform is permanently assigned either role.

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

@@ -1,27 +1,55 @@
 ---
 name: ec-memory
-description: MEMORY-stage skill. Creates a workflow-mode-aware schema-v2 checkpoint from existing task evidence and performs conditional long-memory distillation.
+description: MEMORY-stage skill. Extracts reusable development knowledge from existing task evidence and performs conditional long-memory distillation.
 ---
 
-# ec-memory — evidence-derived checkpoint and knowledge governance
+# ec-memory — reusable knowledge for future development
 
 MEMORY remains mandatory for code tasks. Daily task processing and architecture maintenance are
 separate responsibilities: every completed code task produces one immutable short-memory fact;
 only a long-memory distillation, or the explicit missing-ABSTRACT startup exception, may open an
 architecture assessment. Never update architecture merely because MEMORY was entered.
 
-The short-memory checkpoint must not re-analyze the repository or repeat the entire conversation.
-Generate it only from the verified evidence already stored in `task.json`, `dev-spec.md`, and
-`execution.jsonl`. The bounded repository reads described below belong only to a required
-`backfill` or `update` architecture assessment.
+MEMORY must not re-analyze the repository or repeat the entire conversation. Reuse confirmed
+decisions and verified findings already available in `dev-spec.md`, implementation results and
+Review evidence in `execution.jsonl`; `task.json` supplies identity and frozen mode. The bounded
+repository reads below belong only to a required `backfill` or `update` architecture assessment.
+
+## Knowledge value
+
+A short memory is directly usable knowledge, not an acceptance report. Keep a fact when it helps
+a later task understand behavior, choose the right change, diagnose a failure, or verify correctly.
+
+- Lead with a knowledge topic and a retrieval summary, not a version release or task-completion
+  headline. Prefer business semantics, design reasons, relevant code entrypoints, compatibility
+  boundaries, and observed failure causes with their fixes.
+- State the applicable situation and useful conclusion. Include reasons, limitations and exact
+  symbols or source references where they help the next developer; do not fill a fixed checklist
+  for every fact. Preserve only confirmed conclusions, and keep task-specific scope constraints
+  scoped to that task rather than turning them into permanent project rules.
+- Leave acceptance records in `execution.jsonl`; cite the relevant source instead of copying it.
+  Omit approval JSON, fingerprints, execution timelines, test counts, per-run coverage numbers,
+  temporary log paths, file inventories and handoff history. Do not add a list of excluded noise.
+  A reusable verification command or environment constraint belongs here only when it guides
+  future work; a single run's pass/fail and UT/TDD lifecycle evidence stay in the task record.
+- When no new reusable knowledge exists, set `memory_value: none` and `target_long: NONE`, write
+  a brief reason and retain the source reference. Do not manufacture lessons or duplicate existing
+  knowledge merely to populate sections. This still completes the mandatory short-memory step.
+
+For example, preserve that a cache write may return a failure code without throwing, why proceeding
+with an unpersisted local value breaks shared counting, and where to bypass that behavior. A count
+of passing tests and the user's acceptance timestamp do not teach a future task how to handle it.
+
+Both `default` and `dispatch` use this contract. The coordinator reuses the analysis, implementation
+results and Review findings already available. Reuse any executor-only discovery from its existing
+result; do not require another report, another handoff, or repeated checks for MEMORY.
 
 ## Depth by workflow mode
 
-- `fast`: mechanically produce a compact checkpoint: goal, scope, result, frozen mode,
-  commands/results, and only clearly reusable decisions.
-- `standard`: add reusable contract, compatibility, and troubleshooting facts when present.
-- `strict`: preserve architecture, migration, risk, verification, and cross-module decisions
-  needed for future high-risk work.
+- `fast`: keep the directly reusable conclusions concise.
+- `standard`: include relevant contract, compatibility, and troubleshooting reasons when present.
+- `strict`: retain non-obvious architecture, migration and cross-module boundaries needed by
+  future changes. Greater depth never requires process logs, more checks, or invented knowledge.
 
 Every memory uses schema 2 and includes `workflow_mode` in frontmatter. Generate its UUIDv7 ID
 through:
@@ -33,22 +61,18 @@ through:
 Name it `{memory_id}_{YYYYMMDD}_{smart_name}.md` and set
 `source_task: {current task id, exact}`. Write one immutable short memory under
 `.easy-coding/memory/short/`, then register it with
-`memory-short-complete`. Never invent test results or commit hashes.
+`memory-short-complete`. Task ownership and content integrity remain runtime checks; acceptance
+and Canonical evidence remain in their existing records, not duplicated in the memory body.
 
-Copy the final `acceptance` record from `execution.jsonl` into the checkpoint as a concise
-decision fact: authorization source, decision summary, `diff_sha256`, review policy, verification
-policy, changed files, and any Canonical source tasks that required targeted verification.
-`memory-short-complete` rejects a checkpoint that omits any of those decision fields. This records
-the user's accepted exception without re-reviewing or re-analyzing the code. Canonical writeback
-already carries the same digest and authorization as shared `acceptance` evidence.
-
-For frozen UT/TDD, record the strategy, shared threshold, passed local unit-test result, and
-changed-line coverage result with its frozen baseline. Only TDD includes lifecycle evidence.
-Remote CI is not acceptance evidence. With `none`, omit coverage-specific fields.
+Upgrades preserve existing project templates. These instructions take precedence over legacy
+process sections in `SHORT_MEMORY_TEMPLATE.md`; omit those sections when writing a new memory.
+Do not rewrite old memories or user templates to adopt this contract.
 
 Ask the state API for `memory-instruction`. Distill only when it returns `action:distill`;
-otherwise record `no-op`. Long memory receives reusable facts only, not file dumps, transient
-logs, routine command output, or speculation.
+otherwise record `no-op`. Long memory merges reusable facts, deduplicates matching knowledge and
+retires superseded conclusions. Extract useful knowledge from legacy acceptance reports without
+carrying over process noise; `memory_value: none` contributes no long-memory topic. Work only
+within the frozen candidates and matching topics, without a global history cleanup.
 
 ## Architecture assessment
 

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

@@ -6,15 +6,17 @@ description: QUALITY-stage skill. Freezes one candidate, runs independent Review
 # ec-quality — one candidate, two read-only gates
 
 Use only while the current task is in `QUALITY`. Communicate in the user's language. QUALITY
-does not modify source, tests, configuration, plans, or task scope.
+keeps Review and Verification read-only while permitting approved bounded repairs between checks.
+Ordinary fixes stay in QUALITY; changed requirements/contracts or a replaced implementation plan
+return to ANALYSIS/IMPLEMENT. Bug severity or line count alone does not decide the route.
 
 ## Candidate freeze
 
 For Canonical-backed tasks, load the current session's bound selection through `resume-spec-context`
-when resuming. Pass that original consumption closure to both gates and compare selected contracts,
+only when the current session lacks that context or the design changed. Pass that original consumption closure to both gates and compare selected contracts,
 changes, Steps and Tests against the candidate. Pending `spec_change` blocks QUALITY acceptance
 until the source revision is synchronized. Bounded corrections refresh only their affected Unit
-mappings and continue IMPLEMENT; substantive expansion returns to ANALYSIS.
+mappings and retain the current stage; substantive expansion returns to ANALYSIS.
 
 Call `evidence-fingerprints` once to obtain the runtime-owned attempt and candidate. The runtime
 owns signatures and prior-evidence references. Never calculate historical fingerprints, import
@@ -59,7 +61,8 @@ meaningless remaining check when a concrete blocker is found. Aggregate the repa
 
 ### Standard
 
-- Dispatch one independent reviewer.
+- Use one independent reviewer. A coordinator who did not author the candidate can provide this
+  review after another Agent implemented it; do not launch a duplicate reviewer merely for form.
 - Run affected lint/typecheck/test plus every must-test command from `test-strategy.md`.
 - Run Review and Verification in parallel when their inputs are already frozen.
 
@@ -108,7 +111,7 @@ blocking record also carries a `failure_classes` array; do not defer classificat
 
 ## Verification Gate
 
-Run only the commands selected by the mode and `test-strategy.md`. Record real exit status and
+Run only commands selected by the mode and the existing plan/test strategy. Record real exit status and
 current implementation/config fingerprints plus the active `quality_attempt` using the existing
 `type:"verify"` contract. Do not run a command inside Review Gate, and do not fix a failure inside
 Verification Gate. A failed applicable check also carries its structured `failure_classes` array.
@@ -129,7 +132,7 @@ Wait for both gates, then aggregate all blocking results once. Classify each ite
 
 If code or tests need edits, create one concise Repair Bundle containing every in-scope blocking
 item, affected files, required verification, and evidence that may be reused. After both Gates are
-terminal, finalize the decision before transitioning once to IMPLEMENT:
+terminal, finalize the decision, then prepare the bounded repair while remaining in QUALITY:
 
 ```bash
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py finalize-quality \
@@ -152,10 +155,39 @@ review/verify record first, then write each affected source task `blocked` throu
 use the exact idempotency key `<H>:<S>:<F>:quality-<A>:blocked`. Add one failed evidence object for
 each affected Gate kind with ref
 `execution.jsonl#quality-attempt=<A>;implementation=<F>;source-task=<S>;kind=review|verify`.
-Only after every blocked writeback is acknowledged may the task return to IMPLEMENT; the state API
-rejects a writeback from another run, attempt, fingerprint, or evidence window. Entering IMPLEMENT
-reopens only those blocked source tasks as a new `in_progress` attempt, while unaffected implemented
-tasks keep their shared conclusion.
+After blocked writeback is acknowledged, start the approved repair. The runtime reopens only those
+source tasks with a repair-specific idempotency key, keeping local status QUALITY and unaffected
+source progress. Record affected Step/result completion and source `implemented` before completing
+the repair. Reuse the existing writer and ledger, never copy a second implementation plan.
+
+Use `begin-correction --file <existing-unit-file> --summary <bundle>` to prepare one `quality_repair`.
+In dispatch mode, present this complete bundle once with choices: current Agent, another Agent,
+or defer/revise. This human dispatch decision remains under every approval mode; Approve shares
+the same decision. The user may explicitly authorize current-Agent execution. Default mode uses
+its existing approval policy for local repair, with no handoff inside the stage.
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py start-quality-repair \
+  --repair-id <id> --executor current|other [--confirmed] --agent <agent-id> --session-file <P>
+```
+
+Pass `--confirmed` only for a real user decision on this bundle. For other-Agent execution the call
+also writes the handoff. The recipient claims the task and directly repairs the approved files;
+it must not ask again or return to IMPLEMENT. Bounded code and necessary tests follow the existing
+unit test strategy, including TDD lifecycle checks only when TDD is frozen. The recipient finishes:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py complete-quality-repair \
+  --repair-id <id> --agent <agent-id> --session-file <P>
+```
+
+This returns other-Agent repairs to the coordinator for delta review/verification. No quality gate
+may pass while the repair is pending. Scope/contract changes must be resolved rather than silently
+included in the accepted bundle. Repeated starts/completions reuse the existing repair ID.
+
+`prepare-check --record` also accepts an array. `record-check --result` accepts an array of
+`{prepared_id,result}` to register the results of those prepared checks. Each check keeps its own
+inputs and real result; batching shares runtime reads, not unrelated evidence.
 
 After repair, choose the minimum honest evidence refresh:
 

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

@@ -22,7 +22,7 @@ Call the state API snapshot and show:
   pending confirmed Spec change.
 
 Mode inspection and configuration belongs to `ec-config`. If the user asks to change Approval,
-Workflow, unit test strategy, or the shared coverage threshold, route there and do not mutate those fields here.
+Workflow, cooperation, unit test strategy, or the shared coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 
@@ -38,8 +38,8 @@ When creating from a Canonical Spec, call `inspect-dev-spec --manifest-only`, di
 task and dependency selection, then call `create-task-from-spec` only after explicit user
 selection. Multiple selected Spec tasks still create one Harness task. Do not call
 `select-dev-spec-scope` during discovery. Creation and claim return the selected consumption
-closure; consume it before stage work. On a resumed session, use `resume-spec-context` with
-the current agent/session. A blocked context allows repair/rebind/sync, but blocks advancement.
+closure; consume it before stage work. On the same session, reuse unchanged context; call `resume-spec-context` only if context is missing
+or invalidated. A new session must consume its selected closure. A blocked context allows repair/rebind/sync, but blocks advancement.
 Initialize missing shared execution before creation. Support `rebind-spec-source` only when the
 new file matches schema + spec_id + design revision + design_sha256 and does not roll execution
 revision backward. A pending writeback is repaired with `reconcile-spec-execution`, never by
@@ -49,3 +49,10 @@ action is cleared with `status:error`; correct its input instead of replaying it
 Confirmed requirement changes use `begin-spec-change` before editing the original source.
 Its summary and affected tasks survive handoff. Finish revision + READY + `sync-spec-design`,
 then reload context and refresh the plan in ANALYSIS. Do not clear a pending change manually.
+
+## Scoped continuation
+
+Display the task coordinator, continuation action/stop point and current repair bundle. A claim
+returns the existing approved work; do not request a second scope approval. The main Agent is not
+replaced by the coding executor. Handoff summaries reference existing plan Units and execution
+indices; never copy a new Spec or reconstruct old verification results.

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

@@ -12,8 +12,9 @@ user's language.
 
 ```text
 INIT --auto--> ANALYSIS -> IMPLEMENT -> QUALITY -> MEMORY --auto--> COMPLETE
-                    ^           ^          |
-                    +--replan---+          +---repair-----+
+                    ^                      |
+                    +---- scope/contract replan -----+
+                                  QUALITY -- bounded repair --> QUALITY
 
 any active stage --explicit user abort--> CLOSED
 ```
@@ -27,18 +28,19 @@ Pure conversation, explanation, analysis, and read-only review stay Ready and cr
 - `approval_mode = approve|guard|confirm|auto` controls whether a legal transition waits for a
   user. `confirm` waits only at ANALYSIS -> IMPLEMENT; after that, green QUALITY, MEMORY, and
   COMPLETE transitions advance automatically. `auto` advances every legal green
-  edge. The only additional pause is an exceptional code diff detected after the frozen
+  edge. Dispatch keeps its explicit scope/executor decision; another pause is an exceptional code diff detected after the frozen
   QUALITY acceptance checkpoint; accepting that exact diff does not change the mode.
 - `workflow_mode = adaptive|fast|standard|strict` controls execution cost and assurance depth.
 - `unit_test_mode` independently selects `none`, `ut`, or `tdd`. It defaults to `none`;
   `ut_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
 
-Approval and unit test strategy retain session-over-project precedence. Execution depth is always the
+Approval, cooperation and unit test settings use session > local > project > defaults, per field.
+Local preferences live in optional `~/.easy-coding/config.yaml`; reads never create it. Execution depth is always the
 mechanically calculated minimum for the current change. Do not recommend, select a higher mode,
 or inherit an old task mode. Persist it once with `propose-workflow-mode --agent <agent-id>
 --session-file <P>`; the runtime calculates and freezes the value.
 
-Unit test strategy uses the same session-over-project precedence and freezes its mode and
+Unit test strategy uses the same three-scope precedence and freezes its mode and
 `ut_coverage_threshold` on ANALYSIS -> IMPLEMENT. UT and TDD share passed local unit tests and
 changed-line coverage, and reuse `ec-tdd-init` readiness. Only TDD requires test-first lifecycle
 and its review dimension. UT keeps ordinary review and compact Fast planning. The `tdd-init`
@@ -126,7 +128,7 @@ or `qoder`. Never use a display or source-author attribution such as `Codex with
    `type=tdd-init` code task only after scope confirmation. Do not reinterpret it as an ordinary
    TDD-enabled feature task and do not require readiness before creating it.
 5. Match the user's intent against `current_task` and the active task list before resuming.
-   If the user names or clearly matches another task, confirm the switch and call
+   If the user explicitly selects another task, that selection authorizes the switch; call
    `claim-task --task-id <id> --agent <agent-id> --session-file <P>`. Do not execute task A
    under task B's request.
    - With no explicit repository-mutation request, stay Ready and answer normally. Ambiguous
@@ -139,7 +141,23 @@ or `qoder`. Never use a display or source-author attribution such as `Codex with
 6. Resume the matched/current task, then load only state-relevant assets. Do not read five full
    memories at every startup; ANALYSIS searches memory metadata and opens relevant entries on
    demand.
-7. If another Agent last owned the task, summarize the stored handoff before continuing.
+7. Honor the returned `continuation` before generic stage dispatch. Summarize the existing handoff,
+   consume its approved scope and references, and stop at `stop_after`. Never create a new task,
+   replan, or ask again to approve already accepted work merely because the Agent changed.
+   `cooperation.coordinator` stays the main Agent/session while `last_agent` tracks the executor.
+   A repeated claim of the same active task does not require another claim record.
+
+## Manual dispatch
+
+`cooperate_mode=default` preserves handoff at stage boundaries. `dispatch` also supports handing
+a QUALITY repair to another Agent without changing stage. The user manually switches Agents.
+At an implementation decision, offer current-Agent execution, handoff, or defer/change once.
+"Confirm and hand off" consumes the existing pending stage approval before writing a handoff;
+"handoff for analysis" alone does not approve implementation. Do not ask again on claim.
+Use `handoff-task --continuation` with `next_action`, existing `unit_ids`, optional `evidence_refs`,
+and `stop_after`. Implement-only handoff uses `next_action:implement, stop_after:IMPLEMENT`;
+on completion return `next_action:quality` to the coordinator. QUALITY repairs follow ec-quality.
+The user can authorize the coordinator to fix a small change directly in either mode.
 
 ## Stage dispatch
 
@@ -158,7 +176,8 @@ clears the pending action so the corrected action can proceed; never overwrite a
 pending action.
 
 Creation and claim return `spec_context.consumption` for the stored selection. Consume it before
-dispatching a stage. After session resume or design sync, call `resume-spec-context --agent
+dispatching a stage. Reuse a matching current-session receipt (`spec_context.reused:true`) and context already loaded.
+If context was lost, the session is new, or design changed, call `resume-spec-context --agent
 <agent-id> --session-file <P>` and consume its returned closure. A blocked context requires
 source repair or design sync; never continue from a handoff summary alone. If `spec_change` is
 pending, resume that confirmed change on the bound original file before implementation/QUALITY.
@@ -211,8 +230,9 @@ acceptance-diff choice and returns to the stage required by the state API.
 For an explicitly confirmed rollback, scope reduction, or bounded correction of an active task,
 call `begin-correction --file <existing-task-file> ... --summary <confirmed-change>
 [--risk <actual-new-risk>] --agent <agent-id> --session-file <P>`. The runtime preserves the plan,
-unaffected Units and evidence, consumes old QUALITY state, and enters IMPLEMENT at the mechanical
-minimum for these files. Do not reconstruct the original task or its documents. Synchronize only
+unaffected Units and evidence. In QUALITY it prepares an in-stage repair bundle; use
+`start-quality-repair` and `complete-quality-repair` without a stage transition. Other active stages
+use IMPLEMENT at the mechanical minimum for these files. Do not reconstruct the original task or its documents. Synchronize only
 conflicting source Spec clauses once when needed; then continue the correction. Never restore an
 entire file over unrelated user edits. A new feature or expanded contract still needs ANALYSIS.
 

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

@@ -12,7 +12,7 @@ Start every work reply with the single Markdown blockquote status line injected
 then a blank line. Do not render the machine breadcrumbs to the user.
 
 `{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
-task-frozen execution mode; session overrides take precedence over project settings.
+task-frozen execution mode; behavior settings resolve per field: session > optional local ~/.easy-coding/config.yaml > project > defaults.
 When effective/frozen unit_test_mode is `ut` or `tdd`, insert `· **UT**` or `· **TDD**`
 immediately after Workflow. For `none`, omit this segment and preserve the status-line format.
 
@@ -43,17 +43,18 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
+- Approval mode is session override > local ~/.easy-coding/config.yaml > project `behavior.approval_mode` > `guard`; workflow mode
   is the mechanical minimum for the current actual change. Approval controls waiting;
   workflow controls execution depth. Do not recommend or inflate the calculated mode.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically; Auto advances all legal green edges. A new code diff after the QUALITY
-  checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
+  automatically; Auto advances all legal green edges. Dispatch retains the explicit scope/executor
+  decision, merged with any required approval. A new code diff after the QUALITY
+  checkpoint also pauses across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
   Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
-- Unit test strategy is session override > project `behavior.unit_test_mode` > `none`.
+- Unit test strategy is session override > local ~/.easy-coding/config.yaml > project `behavior.unit_test_mode` > `none`.
   Values are `none`, `ut`, and `tdd`; both enabled strategies share `ut_coverage_threshold`
-  (session > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
+  (session > local > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
   and repository baselines. `none` adds no coverage work and retains ordinary task verification.
   UT requires passed local unit tests and changed-production-line coverage, without test-first
   ordering, RED/GREEN artifacts, or a separate TDD review. TDD additionally requires its lifecycle
@@ -113,7 +114,7 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   confirmed design changes first use `begin-spec-change`, then revision + READY + `sync-spec-design`.
   Creation/claim returns selected source context; session resume and design sync require
-  `resume-spec-context` before work. Pending changes block implementation/acceptance across agents.
+  `resume-spec-context` only when current-session context is missing or design changed; otherwise reuse it. Pending changes block implementation/acceptance across agents.
   Preserve the original writer actor while retaining the current owner during reconciliation.
   Never hand-edit `EDS:EXECUTION`.
   Selected source tasks remain `implemented` through local QUALITY and become `verified`
@@ -124,8 +125,9 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
   projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
-  effective confirmation mode; its checkpoint records any accepted post-quality diff digest
-  and decision. Once memory processing completes, COMPLETE is automatic.
+  effective confirmation mode. Record reusable development knowledge and source references;
+  acceptance digests and process evidence stay in task records. Do not add reports or repeated
+  checks for memory. 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
@@ -166,3 +168,19 @@ speculative fallback/retry/compatibility logic, or defensive copying.
 
 Add project-specific instructions below this line. The generated region above is managed by
 easy-coding-harness and is replaced on `easy-coding upgrade`.
+
+## Cooperation and bounded QUALITY repair
+
+`cooperate_mode: default | dispatch` is independent of approval and unit-test strategy, with
+session > optional local `~/.easy-coding/config.yaml` > project > default precedence. Reads never
+create local config; ec-config changes only explicitly selected fields and can restore inheritance.
+Default preserves stage-boundary handoff. Dispatch supports manual implementation and QUALITY
+repair handoff; the user can always select current-Agent execution. Preserve the task coordinator,
+use existing plan/evidence references and stop at the handoff's `stop_after`. Never launch another Agent.
+Dispatch requires one user decision on scope and executor, even under Auto; combine any approval
+with that same decision and never ask again on claim. Ordinary repairs stay in QUALITY using
+begin-correction, start-quality-repair and complete-quality-repair. Only changed requirements,
+contracts or a replaced main implementation plan justify returning to ANALYSIS/IMPLEMENT.
+Review and verification remain read-only checks; approved repairs happen between them. Reuse
+unaffected evidence, review the repair delta and run affected checks only. Do not rebuild the plan
+or repeat completed checks because of handoff, stage labels or descriptive check-name changes.

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

@@ -12,7 +12,7 @@ Start every work reply with the single Markdown blockquote status line injected
 then a blank line. Do not render the machine breadcrumbs to the user.
 
 `{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
-task-frozen execution mode; session overrides take precedence over project settings.
+task-frozen execution mode; behavior settings resolve per field: session > optional local ~/.easy-coding/config.yaml > project > defaults.
 When effective/frozen unit_test_mode is `ut` or `tdd`, insert `· **UT**` or `· **TDD**`
 immediately after Workflow. For `none`, omit this segment and preserve the status-line format.
 
@@ -41,17 +41,18 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
+- Approval mode is session override > local ~/.easy-coding/config.yaml > project `behavior.approval_mode` > `guard`; workflow mode
   is the mechanical minimum for the current actual change. Approval controls waiting;
   workflow controls execution depth. Do not recommend or inflate the calculated mode.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically; Auto advances all legal green edges. A new code diff after the QUALITY
-  checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
+  automatically; Auto advances all legal green edges. Dispatch retains the explicit scope/executor
+  decision, merged with any required approval. A new code diff after the QUALITY
+  checkpoint also pauses across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
   Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
-- Unit test strategy is session override > project `behavior.unit_test_mode` > `none`.
+- Unit test strategy is session override > local ~/.easy-coding/config.yaml > project `behavior.unit_test_mode` > `none`.
   Values are `none`, `ut`, and `tdd`; both enabled strategies share `ut_coverage_threshold`
-  (session > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
+  (session > local > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
   and repository baselines. `none` adds no coverage work and retains ordinary task verification.
   UT requires passed local unit tests and changed-production-line coverage, without test-first
   ordering, RED/GREEN artifacts, or a separate TDD review. TDD additionally requires its lifecycle
@@ -111,7 +112,7 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   confirmed design changes first use `begin-spec-change`, then revision + READY + `sync-spec-design`.
   Creation/claim returns selected source context; session resume and design sync require
-  `resume-spec-context` before work. Pending changes block implementation/acceptance across agents.
+  `resume-spec-context` only when current-session context is missing or design changed; otherwise reuse it. Pending changes block implementation/acceptance across agents.
   Preserve the original writer actor while retaining the current owner during reconciliation.
   Never hand-edit `EDS:EXECUTION`.
   Selected source tasks remain `implemented` through local QUALITY and become `verified`
@@ -122,8 +123,9 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
   projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
-  effective confirmation mode; its checkpoint records any accepted post-quality diff digest
-  and decision. Once memory processing completes, COMPLETE is automatic.
+  effective confirmation mode. Record reusable development knowledge and source references;
+  acceptance digests and process evidence stay in task records. Do not add reports or repeated
+  checks for memory. 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
@@ -161,3 +163,19 @@ speculative fallback/retry/compatibility logic, or defensive copying.
 
 Add project-specific instructions below this line. The generated region above is managed by
 easy-coding-harness and is replaced on `easy-coding upgrade`.
+
+## Cooperation and bounded QUALITY repair
+
+`cooperate_mode: default | dispatch` is independent of approval and unit-test strategy, with
+session > optional local `~/.easy-coding/config.yaml` > project > default precedence. Reads never
+create local config; ec-config changes only explicitly selected fields and can restore inheritance.
+Default preserves stage-boundary handoff. Dispatch supports manual implementation and QUALITY
+repair handoff; the user can always select current-Agent execution. Preserve the task coordinator,
+use existing plan/evidence references and stop at the handoff's `stop_after`. Never launch another Agent.
+Dispatch requires one user decision on scope and executor, even under Auto; combine any approval
+with that same decision and never ask again on claim. Ordinary repairs stay in QUALITY using
+begin-correction, start-quality-repair and complete-quality-repair. Only changed requirements,
+contracts or a replaced main implementation plan justify returning to ANALYSIS/IMPLEMENT.
+Review and verification remain read-only checks; approved repairs happen between them. Reuse
+unaffected evidence, review the repair delta and run affected checks only. Do not rebuild the plan
+or repeat completed checks because of handoff, stage labels or descriptive check-name changes.