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

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
 
@@ -53,10 +69,15 @@ is still running or unacknowledged.
 - For each actually modified repository, run all applicable lint, typecheck, test, and build
   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"`;
-  GitLab coverage is informative, not a task acceptance gate. Reuse current-fingerprint GREEN
-  evidence from IMPLEMENT instead of rerunning an identical command.
+
+### Unit test strategy (all depths)
+
+For frozen `unit_test_mode=ut|tdd` at any workflow depth, require passed local unit tests and
+changed-production-line coverage at `ut_coverage_threshold`. Run the related tests with coverage
+collection once and record both results from that execution (`coverage_scope:"local"`). Reuse
+unchanged input-bound evidence from IMPLEMENT or earlier attempts. Only `tdd` adds the TDD review
+dimension and lifecycle contract. UT reviews assertions within ordinary review and does not add a
+separate review. `none` adds no coverage gate. GitLab results are informative, not acceptance gates.
 
 ## Review Gate
 
@@ -143,12 +164,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-task-management/SKILL.md

@@ -13,7 +13,7 @@ panel and available actions, but do not mutate a session without an explicit cho
 Call the state API snapshot and show:
 
 - current task, stage, last Agent, and pending transition;
-- task `concrete_workflow_mode` and frozen TDD state when present;
+- task `concrete_workflow_mode` and frozen unit test strategy when present;
 - harness enabled/disabled and Lite Direct state;
 - active and resumable tasks.
 - for Canonical-backed tasks: source locator/path mode, Spec ID/design revision/design digest,
@@ -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, TDD, or the TDD coverage threshold, route there and do not mutate those fields here.
+Workflow, unit test strategy, or the shared coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 

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

@@ -1,11 +1,11 @@
 ---
 name: ec-tdd-init
-description: Initialize or refresh Java changed-line TDD coverage infrastructure before TDD can be enabled.
+description: Initialize or refresh Java changed-line TDD coverage infrastructure before UT or TDD can be enabled.
 ---
 
 # ec-tdd-init — Java changed-line gate initialization
 
-Communicate in the user's language. This skill owns TDD infrastructure readiness, not historical
+Communicate in the user's language. This skill owns shared UT/TDD infrastructure readiness, not historical
 test-debt cleanup. It must never bulk-generate tests for existing business code, require
 repository-wide coverage, or modify production behavior merely to raise coverage.
 
@@ -14,12 +14,12 @@ repository-wide coverage, or modify production behavior merely to raise coverage
 The only legal order is:
 
 ```text
-TDD off -> initialize infrastructure -> readiness ready -> user explicitly enables TDD
+unit_test_mode=none -> initialize infrastructure -> readiness ready -> user selects UT or TDD
 ```
 
 Run this skill as a dedicated code task with `type=tdd-init`. The state API always freezes that
-task with `tdd_enabled=false`, even when a legacy project/session setting or a suspended task has
-TDD enabled. Never offer "enable now and initialize later". Never enable TDD automatically after
+task with `unit_test_mode=none`, even when a legacy project/session setting or a suspended task has
+UT or TDD enabled. Never offer "enable now and initialize later". Never enable UT/TDD automatically after
 initialization.
 
 ## Read-only preflight
@@ -31,7 +31,7 @@ python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check --include-
 ```
 
 If it returns `ready`, report the recorded build/CI contract and stop without creating a task.
-The user may then use `ec-config` or `easy-coding config` to enable TDD.
+The user may then use `ec-config` or `easy-coding config` to select UT or TDD.
 
 If it returns `needs_init` or `needs_repair`, inspect only the reported infrastructure needed
 to form a confirmed initialization or repair plan:
@@ -102,5 +102,5 @@ reinitialization. Daily `check` validates local entry points and task-variable c
 return `needs_init`; damaged receipts or required entries return `needs_repair`. Repair the
 reported entry, repeat applicable tests, and preserve the user's TDD settings.
 
-After completion, report the unchanged TDD setting and provide the explicit project/session
+After completion, report the unchanged unit test strategy and provide the explicit project/session
 enable route when it is off. Do not treat readiness as consent to change it.

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

@@ -30,20 +30,20 @@ Pure conversation, explanation, analysis, and read-only review stay Ready and cr
   edge. The only additional 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.
-- `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.
+- `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.
 
-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 unit test strategy 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;
-there is no enabled-but-pending-initialization state. A dedicated `tdd-init` task always freezes
-TDD off so it can create or repair the required infrastructure without circular gating. When off,
-ordinary tasks add no CI scan, artifacts, commands, coverage work, or stronger acceptance. Use
-`ec-config` for all mode configuration.
+Unit test strategy uses the same session-over-project 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`
+task itself freezes strategy `none`; `none` adds no infrastructure scan or coverage gate.
+Both strategies reuse input-bound results and do not raise workflow depth.
 
 `confirm` and `auto` do not hide the proposal: show it in the plan. Confirm waits for that one
 plan decision; Auto continues immediately. Both remove later waiting, not quality gates.
@@ -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

@@ -13,8 +13,8 @@ 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.
-When effective/frozen TDD is enabled, insert `· **TDD**` immediately after Workflow. When it is
-disabled, omit the TDD segment entirely and preserve the existing status-line format.
+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.
 
 - Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, `ec-task-management` to manage tasks, or `ec-config` to inspect or change modes
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
@@ -34,7 +34,7 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-brainstorming` — design exploration before building (hard design gate)
 - `ec-analysis` `ec-implementing` `ec-quality` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
+- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/unit-test settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
 - `ec-no-harness` — bypass only Easy Coding for the current session
 - `ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
@@ -44,24 +44,25 @@ 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
   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.
-- TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
-  is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
-  build version/content changes require fresh task evidence, not reinitialization. Repair missing
-  local entries without resetting TDD; CLI upgrades preserve project/session/frozen task settings;
-  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
-  initializes only changed-line coverage infrastructure, never historical business-test coverage.
-  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
-  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
-  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
-  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
+- Unit test strategy is session override > 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,
+  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
+  and review dimension. Assertions remain part of ordinary review in UT.
+  Both currently support Java and reuse `ec-tdd-init` readiness, JaCoCo, and existing evidence
+  reuse. One test execution supplies tests plus coverage. No new stages or workflow escalation.
+  The dedicated `tdd-init` task freezes strategy `none`; readiness failure reports repair rather
+  than resetting configuration. CLI upgrades migrate old fields and preserve frozen task progress.
+  GitLab automation is infrastructure, not remote acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
   repository write, including documentation or configuration, uses the full state machine.
@@ -153,6 +154,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

@@ -13,8 +13,8 @@ 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.
-When effective/frozen TDD is enabled, insert `· **TDD**` immediately after Workflow. When it is
-disabled, omit the TDD segment entirely and preserve the existing status-line format.
+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.
 
 - Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, `ec-task-management` to manage tasks, or `ec-config` to inspect or change modes
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
@@ -32,7 +32,7 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-brainstorming` — design exploration before building (hard design gate)
 - `/ec-analysis` `/ec-implementing` `/ec-quality` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
+- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/unit-test settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
 - `/ec-no-harness` — bypass only Easy Coding for the current session
 - `/ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
@@ -42,24 +42,25 @@ 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
   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.
-- TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
-  is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
-  build version/content changes require fresh task evidence, not reinitialization. Repair missing
-  local entries without resetting TDD; CLI upgrades preserve project/session/frozen task settings;
-  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
-  initializes only changed-line coverage infrastructure, never historical business-test coverage.
-  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
-  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
-  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
-  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
+- Unit test strategy is session override > 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,
+  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
+  and review dimension. Assertions remain part of ordinary review in UT.
+  Both currently support Java and reuse `ec-tdd-init` readiness, JaCoCo, and existing evidence
+  reuse. One test execution supplies tests plus coverage. No new stages or workflow escalation.
+  The dedicated `tdd-init` task freezes strategy `none`; readiness failure reports repair rather
+  than resetting configuration. CLI upgrades migrate old fields and preserve frozen task progress.
+  GitLab automation is infrastructure, not remote acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
   repository write, including documentation or configuration, uses the full state machine.
@@ -148,6 +149,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.

package/templates/runtime/tools/easy_coding_java_coverage.py

@@ -191,16 +191,16 @@ def read_project_threshold(repo: Path) -> int:
                 schema_version = 0
             continue
         if (
-            schema_version >= 4
+            schema_version >= 6
             and in_behavior
-            and stripped.startswith("tdd_coverage_threshold:")
+            and stripped.startswith("ut_coverage_threshold:")
         ):
             try:
                 value = int(stripped.split(":", 1)[1].strip().strip("'\""))
             except ValueError as error:
-                raise CoverageError("Invalid behavior.tdd_coverage_threshold") from error
+                raise CoverageError("Invalid behavior.ut_coverage_threshold") from error
             if not 1 <= value <= 100:
-                raise CoverageError("TDD coverage threshold must be from 1 to 100")
+                raise CoverageError("Unit test coverage threshold must be from 1 to 100")
             return value
     return DEFAULT_THRESHOLD
 
@@ -294,7 +294,7 @@ def main() -> int:
             else read_project_threshold(repo)
         )
         if not 1 <= threshold <= 100:
-            raise CoverageError("TDD coverage threshold must be from 1 to 100")
+            raise CoverageError("Unit test coverage threshold must be from 1 to 100")
         reports = (
             sorted({Path(item).resolve() for item in args.report})
             if args.report