easy-coding-harness 1.0.1 → 1.1.0-beta.0

package/package.json

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

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

@@ -48,3 +48,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - `checks`: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.

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

@@ -53,3 +53,9 @@ dimension named in your task card. Your reply IS the return value.
 - `repo_id` and `source_task_id`: copy unchanged when present in the task card
 - `findings`: array of `{file, line, issue, severity}` (`severity`: info | warning | error)
 - `suggestion`: optional fix direction per finding
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
+- Review code and test behavior only. Do not reconstruct fingerprints or inspect workflow
+  history. Passed work stays passed until relevant inputs change; suggestions do not block.

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

@@ -45,4 +45,8 @@ Output (return exactly this):
 - checks: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
 """

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

@@ -50,4 +50,10 @@ Output (return exactly this):
 - repo_id and source_task_id: copy unchanged when present in the task card
 - findings: array of {file, line, issue, severity} (severity: info | warning | error)
 - suggestion: optional fix direction per finding
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
+- Review code and test behavior only. Do not reconstruct fingerprints or inspect workflow
+  history. Passed work stays passed until relevant inputs change; suggestions do not block.
 """

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

@@ -21,12 +21,8 @@ Communicate with the user in the user's language.
 4. Inspect concrete code paths and tests. Expand context only when evidence reveals another
    dependency or risk.
 
-Apply a progressive cost budget while doing this work. A likely Fast task reads only the nearest
-comparable implementation, its direct contracts, and targeted tests. Standard reads the affected
-module closure. Expand into cross-module or repository-wide context only after concrete evidence
-shows the compound high-risk and complexity signals required for Strict. Do not scan unrelated
-repositories, the full Spec, broad Git history, or every architecture section merely to prove
-that a bounded task might be complicated.
+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
 `selected_spec_tasks`, and only their stored `task.repo_paths` bindings. Schema, Spec ID, design
@@ -73,7 +69,8 @@ when local evidence conflicts or a deviation can change the contract, risk, or a
 
 ## Analysis artifacts
 
-Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
+For a non-TDD Fast task use the compact form below. Otherwise copy
+`.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
 Keep every mandatory section. The `### 决策闭环` (Decision Closure) and `### Workflow Mode`
 sections are required. The decision section must contain exactly one standalone
 `decision_status: closed` marker, and no other `decision_status` marker may appear elsewhere in
@@ -153,7 +150,7 @@ line count, or create many one-use helpers, merely to make the plan look modular
 clear semantic boundary, reuse point, or independently testable responsibility. Use parallel only
 for truly independent write scopes. Better unit contracts reduce later QUALITY rework.
 
-Every Harness task is a repository-mutation task and requires `test-strategy.md`. Pure read-only
+Standard/Strict tasks require `test-strategy.md`; compact Fast tasks keep checks in the plan. Pure read-only
 conversation never enters ANALYSIS and creates no task.
 
 ## Optional Java TDD analysis
@@ -172,8 +169,7 @@ When TDD is enabled for a Java code task, make `test-strategy.md` record:
 
 - detected Java/JUnit build system, exact unit-test command, production/test source roots, and
   JaCoCo XML paths;
-- immutable Git baseline SHA and the configured changed-production-line threshold; design tests
-  toward 100% while treating the threshold as the mechanical minimum;
+- immutable Git baseline SHA and the configured changed-production-line threshold; meet that threshold without adding assertions or tests solely to reach 100%;
 - feature/bug RED -> GREEN -> REFACTOR evidence, or for pure refactors a pre-change
   characterization GREEN -> post-change GREEN sequence without inventing a RED failure;
 - the local unit-test command and local changed-line acceptance command. Record that
@@ -201,60 +197,27 @@ mode decision before advancing. The CLI never installs JaCoCo or edits CI automa
 
 ## Workflow mode calculation
 
-Resolve configured mode from the state snapshot:
+Execution mode equals the mechanical minimum for the actual current scope. Do not propose a
+higher mode or ask the user to select one. Old configured/frozen modes do not raise the minimum.
+Use `propose-workflow-mode --agent <agent-id> --session-file <P>` once after the plan exists;
+it returns the calculated mode and reasons, so a separate floor/proposal round is unnecessary.
 
-`session.workflow_mode > project behavior.workflow_mode > adaptive`
+For a non-TDD Fast task, dev-spec.md may use the compact form:
 
-After writing the execution plan, ask the state API to calculate the mechanical minimum:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py workflow-floor \
-  --agent <agent-id> --session-file <P>
-```
-
-Use its `minimum_mode` and `reasons` as the proposal floor. You may raise this result when
-uncertainty or user preference requires more rigor, but never lower or replace it with a
-self-reported floor. The state API rechecks the floor when the proposal is saved and frozen.
-
-The calculation is intentionally Standard-centered:
-
-- `fast`: up to three coherent low-risk units in one actually modified repository, at most eight
-  changed files, no explicit high-risk signal, and no public or cross-repository contract impact.
-  Small parameter changes, bounded field/mapping edits, and a few ordinary model files should
-  normally remain Fast.
-- `standard`: the default for ordinary business work. Four or more units, more than eight files,
-  bounded compatibility work, actual but contained multi-repository changes, broad low-risk work,
-  and bounded high-risk work remain Standard.
-- `strict`: requires both an explicit high-risk signal and concrete complexity/blast-radius
-  evidence. Complexity means actual multi-repository edits, at least five units, at least fifteen
-  changed files, or a public/cross-repository contract. Parallel execution is a Standard signal
-  by itself. Generic domain words in a risk description, title, file path, Spec repository
-  catalog, or unselected task are never sufficient evidence of high risk.
-
-Repository count comes only from repositories that own files in current plan units. Canonical
-Spec metadata, unselected tasks, dependency summaries, unused `repo_paths`, and supermodule child
-registrations do not raise the mode. A real multi-repository change is a Standard signal by
-itself and reaches Strict only when an explicit high-risk signal is also present.
-
-If configuration is concrete, it is also a floor. The selected mode may be raised by the user
-but never placed below either floor. The Agent must not raise an adaptive proposal to Strict from
-vague uncertainty or a domain keyword; cite both the explicit risk and the concrete complexity
-signal. Explain the decision and state-specific effects in the dev-spec.
-
-Persist the proposal before requesting ANALYSIS -> IMPLEMENT:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py propose-workflow-mode \
-  --configured <adaptive|fast|standard|strict> \
-  --selected <fast|standard|strict> \
-  --minimum <fast|standard|strict> \
-  --source <project|session|adaptive|user> \
-  --reason "<reason>" \
-  --agent <agent-id> --session-file <P>
+```markdown
+<!-- easy-coding:compact -->
+decision_status: closed
+Goal: <confirmed behavior>
+Scope: <exact files and preservation boundary>
+Acceptance: <observable outcome and minimum check>
 ```
 
-Repeat `--reason` for distinct material risks. Re-running the command replaces the proposal
-while still in ANALYSIS.
+Record Unit `input_files` for the known additional direct inputs (an empty list means the
+Unit files are self-contained). Include shared helpers, fixtures, schemas and configuration
+actually consumed by its checks. Without a declared closure, checks cover the owning module.
+Build commands still include their module compilation inputs. Do not infer a whole-program call graph. Keep Unit contracts and test points in the existing execution plan. Do not duplicate them across
+full template chapters or create a separate test strategy for this compact form. Canonical work
+consumes the selected source closure; it does not redesign unrelated selected tasks.
 
 ## User presentation and transition
 
@@ -263,9 +226,9 @@ pasting the full `dev-spec.md`. The receipt must contain:
 
 - the core solution and affected scope/units;
 - acceptance and test-strategy highlights;
-- configured, minimum, and selected workflow modes with reasons;
+- the computed minimum workflow mode and its concrete reasons;
 - the material risks and explicit acceptance boundaries;
-- explicit user ability to request a higher mode or a permitted lower mode.
+- the computed minimum mode as an execution fact, without offering mode choices.
 
 End the summary with the absolute path to
 `.easy-coding/tasks/<task-id>/dev-spec.md`. When the current client supports local-file Markdown
@@ -305,6 +268,6 @@ If evidence requires changing Canonical task boundaries, contracts, files, symbo
 or dependencies, obtain confirmation and run `begin-spec-change --affected-task <id> --summary
 <confirmed-change> --agent <agent-id> --session-file <P>` before editing. This persists the
 intent across handoffs and blocks implementation/acceptance until synchronization. Update the original static design with revision +1,
-restore READY, and call `sync-spec-design --affected-task ...`. This invalidates the old local
-plan. Run `resume-spec-context` after synchronization, then refresh derived artifacts. Never
+restore READY, and call `sync-spec-design --affected-task ...`. For bounded corrections this refreshes only affected Unit mappings; other design changes
+invalidate the old local plan. Run `resume-spec-context` after synchronization, then refresh derived artifacts. Never
 substitute edits to the derived `dev-spec.md`, and never edit `EDS:EXECUTION` by hand.

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

@@ -13,7 +13,7 @@ and available actions. Never mutate project or session settings without an expli
 Call `snapshot` and show project, session, effective, and frozen task values for:
 
 - `approval_mode`;
-- `workflow_mode`;
+- the mechanically calculated workflow mode (read-only);
 - `tdd_enabled` and `tdd_coverage_threshold`.
 
 Use the returned fields directly, including `project_tdd_enabled`, `session_tdd_enabled`,
@@ -42,7 +42,7 @@ and accept that exact new diff; this exception does not convert `auto` into `gua
 ## Project configuration
 
 Use `easy-coding config` for project settings. The CLI confirms one atomic update of Approval,
-Workflow, TDD, and (when enabled) the threshold. The threshold must be an integer from 1 to 100.
+TDD, and (when enabled) the threshold. Execution depth is calculated automatically. The threshold must be an integer from 1 to 100.
 Enabling TDD is rejected atomically unless `ec-tdd-init` readiness is currently `ready`.
 
 ## Session configuration
@@ -54,10 +54,6 @@ 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>
 
-# workflow
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-workflow-mode --mode adaptive|fast|standard|strict --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-workflow-mode --agent <agent-id> --session-file <P>
-
 # TDD; omitting threshold preserves an existing session threshold, otherwise project/default 90 applies
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-tdd --enabled true|false [--threshold 1..100] --agent <agent-id> --session-file <P>
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-tdd --agent <agent-id> --session-file <P>
@@ -76,3 +72,6 @@ settings on failure; never offer or persist "enable now, initialize later". Norm
 changes do not require initialization, and a CLI upgrade must preserve project/session TDD values.
 Readiness means infrastructure can measure future changed production lines. It does not certify
 repository-wide coverage and does not require tests for unchanged historical code.
+
+Execution depth always equals the current mechanical minimum. Legacy workflow_mode settings
+remain readable but do not raise it. Do not offer mode choices or recommend changing to Lite.

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

@@ -21,17 +21,26 @@ to QUALITY's Verification Gate. TDD is the only exception because RED/GREEN/REFA
 part of the implementation method; current-fingerprint green evidence may be reused by QUALITY.
 
 When frozen TDD is enabled, every feature/bug unit must capture a meaningful failing unit test
-before production code (RED), the smallest passing implementation (GREEN), and a green refactor.
+before production code (RED) and the smallest passing implementation (GREEN). Refactor only
+when a concrete improvement is needed; unchanged GREEN inputs do not require another run.
 Pure refactors instead capture a passing characterization test before the change and rerun it
 afterward. Never fake RED evidence. Keep tests deterministic, boundary-focused, and minimally
-mocked, and design changed production code toward 100% unit coverage.
+mocked, and meet the confirmed changed-line threshold without expanding scope for extra coverage.
 
 Communicate with the user in the user's language.
 
+For a bounded correction already routed by `begin-correction`, use the existing plan and the
+returned file scope. Restoring known behavior needs the affected regression checks, not an
+artificial RED/REFACTOR cycle. Preserve all unrelated Unit progress. A correction of generated
+tracking metadata is handled once; do not reopen design or rewrite the complete plan for it.
+
+When a lifecycle check is necessary, call `prepare-check` before running it and `record-check`
+afterward as documented in ec-quality. QUALITY reuses these input-bound results.
+
 ## Non-negotiable gates
 
-1. Modify only files in the confirmed change-scope table. A new file requirement returns the
-   task to ANALYSIS.
+1. Modify only confirmed files. Return to ANALYSIS only for a substantive scope/contract
+   expansion; restoring a previously mapped file uses the correction scope.
 2. Preserve existing encoding and project comment conventions.
 3. Each unit must carry `acceptance_criteria`, `test_points`, `contracts`, and `risks`.
    Missing unit context is an analysis defect; do not make the implementer rediscover it.
@@ -88,6 +97,11 @@ Communicate with the user in the user's language.
 14. Use one blank line between coherent logic sections. Do not create noisy blank-line gaps or
     compress unrelated steps into an unreadable block.
 
+Keep validation at its responsible boundary. Do not repeat internal null/state checks already
+covered by the contract. Without an explicit requirement or demonstrated defect, add no fallback,
+retry, compatibility branch, idempotency change, defensive copy, or speculative error handling.
+An added validation needs a concrete triggering input and the failure it prevents.
+
 ## Choose the execution owner
 
 `strategy` defines dependency shape; `workflow_mode` defines assurance depth.
@@ -176,7 +190,8 @@ checks:[], issues:[], needs_attention:[]
 8. If a static Canonical change is confirmed, first persist it with `begin-spec-change
    --affected-task <id> --summary <confirmed-change> --agent <agent-id> --session-file <P>`.
    Revise the original design by exactly one revision, validate READY and use `sync-spec-design`;
-   then `resume-spec-context` and rebuild the local plan in ANALYSIS. Never edit the
+   then `resume-spec-context`. A bounded correction preserves the plan and continues IMPLEMENT;
+   substantive expansion returns to ANALYSIS. Never edit the
    machine-owned execution block. If a writeback was
    interrupted, run `reconcile-spec-execution` with the stored idempotent pending action.
    Reconciliation only consumes dispatch/result evidence created after the current `in_progress`
@@ -188,8 +203,8 @@ conversation overhead while keeping work observable.
 ## End state
 
 - After all units are implemented, hand control to ec-workflow for IMPLEMENT -> QUALITY.
-- New risk above the frozen mode: call `raise-workflow-mode`; modes may rise but never silently
-  fall after ANALYSIS.
+- A concrete new risk changes the calculated minimum: update its Unit risk and call
+  `raise-workflow-mode` to recalculate. The argument cannot inflate the mechanical result.
 
 ## Self-check
 

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

@@ -13,24 +13,40 @@ does not modify source, tests, configuration, plans, or task scope.
 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,
 changes, Steps and Tests against the candidate. Pending `spec_change` blocks QUALITY acceptance
-until source revision synchronization and ANALYSIS replanning have completed.
+until the source revision is synchronized. Bounded corrections refresh only their affected Unit
+mappings and continue IMPLEMENT; substantive expansion returns to ANALYSIS.
 
-Call `evidence-fingerprints` once and use the returned implementation/config fingerprints for
-the whole attempt. It also returns the runtime-owned `quality_attempt` number, start time, evidence
-boundary, and repair count. Every Review and Verification record in this attempt must carry that
-same candidate fingerprint and `quality_attempt` number. If the candidate changes, return to
-IMPLEMENT; the state API finalizes the old attempt as `cancelled` before the transition. Never mix
-evidence from two candidates.
+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
+runtime internals to reconstruct old candidates, or ask a reviewer to audit workflow bookkeeping.
 
-`execution.jsonl` is append-only. Do not write `type:"quality"` yourself. The state API appends
-exactly one fingerprint-bound finalized record when QUALITY passes, leaves for repair/replan, or is
-cancelled by candidate drift, rework, or task closure. Retries reuse that record instead of
-duplicating it. An incomplete, duplicate, or out-of-sequence quality record blocks the transition.
+For each distinct review or verification, prepare its actual inputs before executing it:
 
-Review Gate and Verification Gate are independent and may run in parallel. Review never executes
-commands. Verification never edits files. If a hard blocker makes remaining work meaningless,
-cancel the other checks explicitly and record the cancellation; do not start repair while a gate
-is still running or unacknowledged.
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py prepare-check \
+  --record '<review/verify JSON with unit_id, dimension or check/check_type/command>' \
+  --agent <agent-id> --session-file <P>
+```
+
+When `reusable:true`, use the returned evidence index and skip that check. Otherwise run the
+specified check once, then register its real result:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py record-check \
+  --prepared-id <returned-id> --result '<JSON with passed, exit_code for verification, findings/reviewer for review>' \
+  --agent <agent-id> --session-file <P>
+```
+
+Preparation binds code/test inputs, module dependencies, build files and the actual command.
+Use the analyzed Unit `input_files` closure for additional helpers/fixtures/configuration, and record intentional
+environment overrides in the check descriptor. Production-only reviews may declare
+`review_scope:"production"`; test review still covers changed test behavior. A result is accepted
+only if its inputs remained unchanged. One grouped Maven `-Dtest=A,B` execution covers both source
+commands when all other arguments agree. Do not run individual commands and then repeat a combined
+clean run. IMPLEMENT results and prior attempts use the same reuse mechanism.
+
+Record failed checks with failure_classes. Review and Verification remain independent; cancel a
+meaningless remaining check when a concrete blocker is found. Aggregate the repair once.
 
 ## Workflow depth
 
@@ -54,7 +70,7 @@ is still running or unacknowledged.
   checks. A repository merely mentioned by a Spec, dependency, supermodule, or path map is not in
   scope.
 - When frozen TDD is enabled, include the required TDD review dimension, local unit test, and
-  changed-production-line coverage. Record one coverage result with `coverage_scope:"local"`;
+  changed-production-line coverage at the confirmed threshold. Record one coverage result with `coverage_scope:"local"`;
   GitLab coverage is informative, not a task acceptance gate. Reuse current-fingerprint GREEN
   evidence from IMPLEMENT instead of rerunning an identical command.
 
@@ -143,12 +159,12 @@ After repair, choose the minimum honest evidence refresh:
 - localized business code: delta review plus impacted tests;
 - contract/config/plan/shared behavior: rerun all applicable gates for the affected scope.
 
-When uncertain, rerun rather than infer. On the next attempt, the state API emits an append-only
-`quality-carry-forward` record only for Canonical repositories whose plan and repository content
-fingerprints are unchanged and whose sources are not hard/contract downstream of a changed source;
-it references the exact passed evidence indices from the consumed repair attempt. Never copy or
-relabel old evidence yourself. Strict may consume that state-owned record for independent,
-unaffected repositories, but must rerun every affected or dependency-invalidated repository gate.
+Use the runtime's reusable/changed-input result to decide what remains. Changes to a plan
+narrative, stage, approval mode or Spec revision alone do not require test execution. Refresh only
+affected evidence, including actual shared dependencies; never restart all Units in the repository.
+Passed checks are terminal until their inputs change or a concrete new defect invalidates them.
+Suggestions never trigger another review round. No reviewer may demand new defensive checks
+without a concrete triggering input and demonstrated failure. Preserve the original error strategy.
 
 ## Acceptance boundary
 

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

@@ -33,10 +33,10 @@ Pure conversation, explanation, analysis, and read-only review stay Ready and cr
 - `tdd_enabled` independently activates Java TDD and changed-line coverage. It defaults off;
   `tdd_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
 
-Resolution order for each configured value is session override, then project config, then
-defaults (`guard`, `adaptive`). ANALYSIS resolves `adaptive` to a concrete mode, presents the
-selection and reasons, allows the user to change it within the risk floor, and freezes it when
-ANALYSIS -> IMPLEMENT is applied.
+Approval and TDD retain session-over-project precedence. 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.
 
 TDD resolves with the same session-over-project precedence and freezes its enabled flag and
 threshold on ANALYSIS -> IMPLEMENT. It may be enabled only after `ec-tdd-init` readiness passes;
@@ -206,19 +206,21 @@ passed current-fingerprint targeted check first. If the digest changes, inspect
 new diff. Config, plan, workflow, Canonical-design, or nested-repository drift is not an
 acceptance-diff choice and returns to the stage required by the state API.
 
-## Mode escalation
+## Current-change routing
 
-When implementation reveals a higher risk, call:
+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
+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.
 
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py raise-workflow-mode \
-  --mode standard|strict --reason "<new risk>" \
-  --agent <agent-id> --session-file <P>
-```
+## Recalculate actual risk
 
-Only upward changes are legal after ANALYSIS. During QUALITY, return to IMPLEMENT before
-raising the mode so the task re-enters QUALITY with fresh evidence. Scope or design changes return
-to ANALYSIS.
+Only an actual change in the current scope or risk changes execution depth. The runtime
+recalculates the minimum; old configuration, task size, and unrelated risks never raise it.
+There is no time, token, tool-count, or execution-budget gate.
 
 ## Handoff and closure
 

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

@@ -44,8 +44,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 ## Workflow discipline
 
 - Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
-  is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
-  workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
+  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
@@ -153,6 +153,12 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   not proof of writeback. Keep those facts and scopes separate.
 {{supermodule_boundary}}
 
+
+Execution efficiency: use begin-correction for confirmed bounded repairs; preserve unrelated
+Units and reuse input-bound checks through prepare-check/record-check. Stage or Spec revision
+changes alone do not invalidate tests. No execution budget. No repeated internal validation,
+speculative fallback/retry/compatibility logic, or defensive copying.
+
 <!-- ═══ end easy-coding-harness generated ═══ -->
 
 ## Project Custom Instructions

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

@@ -42,8 +42,8 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 ## Workflow discipline
 
 - Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
-  is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
-  workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
+  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
@@ -148,6 +148,12 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   not proof of writeback. Keep those facts and scopes separate.
 {{supermodule_boundary}}
 
+
+Execution efficiency: use begin-correction for confirmed bounded repairs; preserve unrelated
+Units and reuse input-bound checks through prepare-check/record-check. Stage or Spec revision
+changes alone do not invalidate tests. No execution budget. No repeated internal validation,
+speculative fallback/retry/compatibility logic, or defensive copying.
+
 <!-- ═══ end easy-coding-harness generated ═══ -->
 
 ## Project Custom Instructions

package/templates/qoder/agents/ec-implementer.md

@@ -50,3 +50,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - `checks`: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.

package/templates/qoder/agents/ec-reviewer.md

@@ -55,3 +55,9 @@ dimension named in your task card. Your reply IS the return value.
 - `repo_id` and `source_task_id`: copy unchanged when present in the task card
 - `findings`: array of `{file, line, issue, severity}` (`severity`: info | warning | error)
 - `suggestion`: optional fix direction per finding
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
+- Review code and test behavior only. Do not reconstruct fingerprints or inspect workflow
+  history. Passed work stays passed until relevant inputs change; suggestions do not block.