easy-coding-harness 0.8.3 → 0.9.0-beta.0

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

@@ -1,149 +1,100 @@
 ---
 name: ec-implementing
-description: IMPLEMENT-stage skill. Use when ec-workflow enters IMPLEMENT with a confirmed plan. Executes code or explicit no-code execution.jsonl units under strict scope control, enforces RULES compliance and encoding preservation, writes code-task tests per strategy, and dispatches sub-agents for every unit regardless of strategy.
+description: IMPLEMENT-stage skill. Executes the confirmed plan with workflow-mode-aware orchestration, strict scope control, shift-left tests, and structured execution evidence.
 ---
 
 # ec-implementing — execute the confirmed plan
 
-ec-workflow dispatches you when a confirmed task enters IMPLEMENT. You execute the confirmed
-delivery without re-opening decisions. Inputs: `task.json`, `dev-spec.md` (confirmed), `execution.jsonl`
-(plan record), `.easy-coding/RULES.md`, `.easy-coding/ABSTRACT.md`, and `test-strategy.md` for
-code tasks only. A read-only task has no test-strategy.md.
+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.
 
 Communicate with the user in the user's language.
 
-## Core discipline (non-negotiable)
-
-1. **Scope is law.** Only modify files listed in the dev-spec change-scope table. If you
-   discover you need another file, STOP and return to ANALYSIS to amend the plan. No
-   "while I'm here" edits.
-2. **RULES compliance.** Before each write, re-check the RULES sections relevant to that
-   file (use the unit's `rules_sections`). Violation → fix before writing, not after.
-3. **Encoding preservation.** Modifying an existing file keeps its original encoding
-   (UTF-8 / GBK / ...); never silently convert. New files follow the encoding declared in
-   the dev-spec.
-4. **Comment language.** Follow the project's existing comment language as recorded in RULES.
-   Do not decide it here.
-5. **Step-wise reporting.** After each file/module, emit a one-line progress note (file +
-   what changed). Do not batch everything into one final dump.
-6. **Self-audit gate.** When the unit is done, audit: are all edits within scope? any
-   undeclared dependency change? any leftover TODO/FIXME you introduced? Report failures;
-   never skip silently.
-7. **Tests (code tasks only, soft rule).** Write tests for [must-test]/[should-test] items per
-   test-strategy.md. Soft means: no project test infra → not forced; infra exists → required.
-   Read-only tasks have no test-strategy.md and write no tests.
-8. **No-code delivery is explicit and read-only.** Only a task whose `task.json.type` is
-   `doc`, `analysis`, or `report` may have `unit.files:[]`. Dispatch it with editable scope
-   `NONE — read-only deliverable`; the sub-agent modifies nothing and returns the full result
-   in `deliverable`. An empty scope on any code task is a gate failure, not permission to roam.
-
-## Sub-agent dispatch
-
-Read the `plan` record's `strategy` field. EVERY strategy dispatches sub-agents — the field
-only decides the orchestration shape, never whether the main agent writes code itself:
-
-- `single` → dispatch ONE sub-agent for the single unit.
-- `sequential` → dispatch sub-agents one at a time in dependency order (await each `result`
-  before dispatching the next).
-- `parallel` → dispatch sub-agents per level concurrently (see gate below).
-
-<HARD-GATE>
-EVERY STRATEGY = MANDATORY SUB-AGENT DISPATCH. NO EXCEPTIONS.
-
-You MUST dispatch sub-agents using {{sub_agent_dispatch}} for every unit, whatever the
-strategy. You are FORBIDDEN from implementing any unit yourself in the main agent. Doing the
-work inline instead of dispatching is a protocol violation equivalent to bypassing the
-ANALYSIS -> IMPLEMENT gate selected by the effective confirm mode.
-
-Self-check before writing ANY implementation code:
-- Am I about to write implementation code in the main agent? → STOP. Dispatch a sub-agent.
-- Did every unit get a dispatch (single=1, sequential=N serial, parallel=N concurrent)? If no → STOP.
-
-There is NO case where the main agent writes implementation code itself. Even a single unit
-goes through a sub-agent — this isolates implementation context from the main agent's window.
-</HARD-GATE>
-
-## Dispatch loop (all strategies)
-
-1. Read RULES.md and ABSTRACT.md once — the main agent pre-digests context; sub-agents never
-   read them.
-2. For each unit, build a **task card** (next section). Append a `dispatch` record before
-   dispatching and a `result` record per returned unit, to execution.jsonl.
-3. Dispatch according to strategy, via {{sub_agent_dispatch}}:
-   - `single` → dispatch the one unit, await its `result`.
-   - `sequential` → sort units by `depends_on`; dispatch one, await its `result`, then the next.
-   - `parallel` → sort `parallel_groups` by level; dispatch all units in a level concurrently,
-     await the level, then advance.
-   Platform spawn rule: {{platform_spawn_instruction}}
-4. After each unit/level returns: check for file conflicts (two units touched the same file),
-   collect `issues` and `needs_attention`. Resolve conflicts before advancing. For a no-code
-   unit, additionally require `changed_files:[]` and a non-empty string `deliverable`; a missing
-   deliverable or any file modification is a unit failure and must be re-dispatched.
-5. After recording a successful no-code result, output the complete `deliverable` to the user
-   verbatim in the current response before any summary or completion action. Never replace,
-   truncate, or hide it behind the one-line `summary` or leave it only in execution.jsonl.
-6. After all units/levels, summarize. For no-code delivery, the summary is supplemental and
-   must appear after the full deliverable.
-
-## Task card — the sub-agent contract
-
-The main agent builds the card; the sub-agent never hunts for context itself. Card template:
+## Non-negotiable gates
 
-```
+1. Modify only files in the confirmed change-scope table. A new file requirement returns the
+   task to ANALYSIS.
+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.
+4. Run the unit's cheapest meaningful test immediately after its implementation. Do not wait
+   until VERIFICATION to discover local contract mistakes.
+5. Append `dispatch` and `result` records for every unit, including main-agent execution.
+   Main-agent execution uses `reason:"main-inline:<workflow_mode>"`.
+6. A code task never transitions directly from IMPLEMENT to VERIFICATION. Every new code task
+   enters REVIEW.
+7. Read-only `doc` / `analysis` / `report` tasks remain `single` with `files:[]`, make no writes,
+   return a non-empty `deliverable`, then follow the mode-aware IMPLEMENT -> COMPLETE edge.
+
+## Choose the execution owner
+
+`strategy` defines dependency shape; `workflow_mode` defines assurance depth.
+
+### Fast
+
+- A single low-risk unit may be implemented inline by the main Agent.
+- Sequential units may stay inline when they share one small context and have no risky contract.
+- Dispatch a sub-agent only for genuine parallelism, specialist context, or context isolation.
+
+### Standard
+
+- A single bounded unit may be implemented inline.
+- Dispatch independent parallel units and units with distinct technical context.
+- Keep dependent units sequential and pass the completed contract forward.
+
+### Strict
+
+- Dispatch multi-unit or high-risk implementation to sub-agents using {{sub_agent_dispatch}}.
+- For a truly indivisible unit, the main Agent may implement only when dispatch adds no
+  independence; record why and require independent REVIEW later.
+- Process dependency levels in order. Platform spawn rule: {{platform_spawn_instruction}}
+
+The main Agent owns orchestration, conflict resolution, evidence writing, and stage decisions.
+Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow assets.
+
+## Task card
+
+```text
 # Task Card
-## Identity
-You are an Easy Coding implementation sub-agent. Complete the assigned unit and return
-structured results. Reply content IS the return value, not a message to a human.
-## Hard constraints
-- Do not call any Skill tool.
-- Do not read .claude/skills, .agents/skills, or any .easy-coding/ file.
-- Modify only files in "Editable scope".
-- Make no stage-transition decisions.
-## Task           {unit description extracted from dev-spec}
-## Delivery mode  {code | no-code read-only, derived from task.type and unit.files}
-## Editable scope {unit.files | NONE — read-only deliverable}
-## Coding rules   {RULES.md sections selected by unit.rules_sections}
-## Architecture   {ABSTRACT.md sections selected by unit.abstract_modules}
-## Output format
-Return: changed_files[], summary (one line), deliverable (full no-code result or null),
-issues[], needs_attention[].
+## Identity       Easy Coding implementation unit
+## Workflow Mode  {fast|standard|strict}
+## Task           {unit description}
+## Editable Scope {unit.files | NONE — read-only}
+## Acceptance     {unit.acceptance_criteria}
+## Test Points    {unit.test_points and exact targeted commands}
+## Contracts      {inputs, outputs, invariants shared with other units}
+## Risks          {known edge cases and compatibility risks}
+## Coding Rules   {pre-digested RULES sections}
+## Architecture   {pre-digested ABSTRACT sections}
+## Output
+changed_files[], summary, deliverable|null, issues[], needs_attention[]
 ```
 
-This enforces the three-layer escape guard: task boundary (only its files), stage boundary
-(no knowledge of the state machine), output boundary (structured return only). The sub-agent
-gets pre-digested context — it does not open RULES or ABSTRACT itself.
+## Dispatch and result loop
 
-## On unit failure or conflict
+1. Append a `dispatch` record before work begins.
+2. Execute according to dependency order and selected owner.
+3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
+4. Append one `result` record. Include unresolved issues rather than hiding them.
+5. If a result changes a cross-unit contract, stop dependent units and return to ANALYSIS.
+6. For parallel units, detect overlapping writes before advancing.
 
-A returned `issues` entry or a detected file conflict is handled by the MAIN agent. If a fix
-is needed, re-dispatch the unit with a `dispatch` record carrying a `reason` field. Do not
-let sub-agents re-dispatch each other.
+Do not emit a progress message for every trivial edit. Report at unit boundaries to reduce
+conversation overhead while keeping work observable.
 
 ## End state
 
-- **Code task:** after all units are done and self-audited, hand back to ec-workflow. In approve
-  mode it records IMPLEMENT -> REVIEW as the recommended pending edge and presents REVIEW /
-  skip to VERIFICATION / handoff. In guard/auto it automatically enters REVIEW. In lite it
-  automatically enters VERIFICATION and must not dispatch REVIEW.
-- **No-code read-only task:** after recording the successful result and showing the complete
-  deliverable, request COMPLETE in approve mode or auto-transition in guard/lite/auto. Do not
-  enter REVIEW, VERIFICATION, or MEMORY; do not write short or long memory. The state API only
-  accepts this terminal edge when the latest plan is `single` with `files:[]` and the latest
-  result has `changed_files:[]`, a non-empty `deliverable`, and no issues/needs_attention.
-  A matching `dispatch` record must immediately precede the accepted result among that unit's
-  execution records; an inline report without dispatch cannot complete.
-
-If something invalidates the plan before completion, select IMPLEMENT -> ANALYSIS and follow
-the effective confirm mode instead of improvising.
-
-## Self-check gates (before handing back)
-
-- [ ] EVERY unit was dispatched to a sub-agent — no inline implementation by the main agent? (VIOLATION if no)
-- [ ] Sequential units dispatched in dependency order; parallel units dispatched per level?
-- [ ] Each dispatched unit has a `dispatch` record in execution.jsonl?
-- [ ] Each returned unit has a `result` record?
-- [ ] No files modified outside the change-scope table?
-- [ ] For a no-code unit: changed_files is empty, deliverable is non-empty, and the full
-      deliverable was output verbatim to the user before completion?
-- [ ] For a no-code task: IMPLEMENT -> COMPLETE followed the effective confirm mode, with no
-      REVIEW, VERIFICATION, MEMORY, or memory write?
+- Code task: after all units and targeted checks pass, hand control to ec-workflow for
+  IMPLEMENT -> REVIEW.
+- Read-only task: output the full deliverable, then request or auto-apply IMPLEMENT -> COMPLETE.
+- New risk above the frozen mode: call `raise-workflow-mode`; modes may rise but never silently
+  fall after ANALYSIS.
+
+## Self-check
+
+- [ ] Every changed file is in scope and keeps its encoding.
+- [ ] Every unit has a dispatch/result pair and satisfied its acceptance criteria.
+- [ ] Targeted tests ran or a concrete blocker is recorded.
+- [ ] Cross-unit contracts still match.
+- [ ] Code tasks enter REVIEW, regardless of workflow mode.

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

@@ -1,162 +1,36 @@
 ---
 name: ec-memory
-description: MEMORY-stage skill — archive flow entered after a green VERIFICATION gate according to the effective confirm mode. Writes one schema-v2 short memory, runs the authoritative conditional long-memory gate, performs optional distillation, and automatically completes the task.
+description: MEMORY-stage skill. Creates a workflow-mode-aware schema-v2 checkpoint from existing task evidence and performs conditional long-memory distillation.
 ---
 
-# ec-memory — archive what was learned
+# ec-memory — evidence-derived checkpoint
 
-ec-workflow dispatches you during MEMORY after approve/guard/lite acceptance or an auto-mode green
-VERIFICATION gate. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
-`verify` records are precise source material), the changed-files list, existing memory files.
-Read-only `doc` / `analysis` / `report` tasks auto-complete from IMPLEMENT and never enter
-MEMORY or write task memory.
+MEMORY remains mandatory for code tasks. It must not re-analyze the repository or repeat the
+entire conversation. Generate from `task.json`, `dev-spec.md`, and `execution.jsonl`.
 
-Communicate with the user in the user's language. Memory file content follows the project's
-recorded comment/doc language.
+## Depth by workflow mode
 
-## Step 1 — write one short memory entry
+- `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.
 
-Create one file under `.easy-coding/memory/short/` following the format in
-`.easy-coding/memory/SHORT_MEMORY_TEMPLATE.md`. File naming convention:
-`{memory_id}_{YYYYMMDD}_{smart_name}.md`. Generate the id first with
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-new-id --session-file <P> --agent <agent-id>`.
-Use the returned `memory_id` unchanged as both the filename prefix and the frontmatter `id`.
-It uses UUIDv7, so agents never scan the directory or calculate a shared numeric sequence.
-Keep the readable `smart_name` suffix. The entry is immutable after creation.
-Frontmatter (all fields required):
+Every memory uses schema 2 and includes `workflow_mode` in frontmatter. Generate its UUIDv7 ID
+through:
 
-```yaml
----
-memory_schema: 2
-id: {memory_id returned by memory-new-id, exact}
-source_task: {current task id, exact}
-date: {YYYY-MM-DD}
-task_type: {feature | bugfix | refactor | perf | doc | workflow}
-project_mode: {startup | iteration}
-domain:
-  - {business domain or module}
-tags:
-  - {keyword}
-related_files:
-  - {key file or module}
-commit: {hash | none}
-verification: {passed | partial | not_run}
-memory_value: {business | technical | both | none}
-target_long: {BUSINESS | TECHNICAL | BOTH | NONE}
----
-The body follows the template structure: Task Summary, Execution Evidence, Business Memory
-Candidates, Technical Memory Candidates, Non-Distillation Content, and Related Memories.
-Pull facts from execution.jsonl result/verify records, not from a fuzzy memory of the
-conversation. Refer to SHORT_MEMORY_TEMPLATE.md for the complete section format.
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-new-id --agent <agent-id>
 ```
 
-If the task was cross-repo, record the repo names involved and the collaboration reason.
-
-After the file is successfully written, record the checkpoint immediately:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-short-complete --session-file <P> --file "<relative-short-memory-path>" --agent <agent-id>`.
-Use the returned `status_context` as authoritative. On resume, if `memory_progress` already
-shows `short_memory_written:true`, do not create a duplicate entry; continue from Step 2.
-The state API validates `memory_schema: 2`, requires `source_task` to equal the current task id,
-requires a UUIDv7 id that exactly matches the filename prefix, and fingerprints the file. Do not
-reuse an older task's memory file as this checkpoint.
-
-## Supermodule memory routing
-
-If the current project config contains `supermodule.role: super-parent`, archive memory by
-ownership:
-
-- Cross-repo business context, parent orchestration decisions, and multi-repo contracts stay
-  in the parent `.easy-coding/memory`.
-- Technical memory that belongs to one child repo must be written to that child's
-  `.easy-coding/memory`, not only to the parent. Use changed file paths and module ownership
-  to decide the child.
-- Only write child memory files during this routing. Do not edit child task, session, state,
-  or dev-spec files from the parent workflow.
-- If a touched child repo has no initialized `.easy-coding/memory` directory, keep the memory
-  in the parent and mark it as "original child: <path>; child not initialized".
-- When child memory is written, the later git flow must commit and push the child repo before
-  the parent gitlink update.
-
-**Immutability:** Short memories are write-once. Never edit an existing short memory file —
-create a new one instead. Short memories serve as both a recent-detail sliding window and a
-distillation buffer for long-term memory.
-
-**Sliding window (informational):** The short memory directory has a soft cap defined by
-`memory.short_term_max` (default 10). Step 1 only writes and checkpoints one entry per
-completed task. It never decides whether to distill.
-
-## Step 2 — run the long-memory gate (CONDITIONAL)
-
-<HARD-GATE>
-LONG-MEMORY WORK IS CONTROLLED BY THE STATE API `memory` INSTRUCTION.
-
-Before performing ANY distillation work:
-1. After Step 1 is checkpointed, call
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-instruction --session-file <P>`.
-   This ordering is mandatory: the current task's short entry must be counted first.
-   The first successful call is frozen in `memory_progress.instruction`; resumed work reuses
-   the same action and trim count even after consumed short files are deleted.
-2. Treat the returned `memory.action` as authoritative. Do NOT recount short memories yourself and
-   do NOT override the state API instruction with prompt reasoning.
-3. If `action == "no-op"`: output "MEMORY: long-memory no-op (short memory count =
-   {short_count}, threshold = {short_term_max})". Do NOT read or modify long memory files.
-4. If `action == "distill"`: treat `memory.candidate_files` and `memory.kept_files` as the
-   frozen authoritative sets. Distill and delete exactly `candidate_files`; preserve every
-   `kept_files` entry. Do not rebuild either set from the live directory.
-
-This gate is absolute. Even a single short memory entry below threshold does NOT trigger
-long-term compression regardless of any other signal.
-</HARD-GATE>
-
-### When action == "distill": distillation flow
-
-Three-file long memory:
-- `MEMORY.md` — index of all entries with status (active | deprecated | superseded | deleted).
-- `BUSINESS.md` — business rules, domain knowledge, product decisions.
-- `TECHNICAL.md` — architecture decisions, implementation patterns, gotchas.
-
-Distillation steps:
-1. Use `memory.candidate_files` and `memory.kept_files`; their sizes correspond to
-   `memory.trim_count` and the retained window calculated at instruction time.
-2. Read the `target_long` of candidate short memories; route to business/technical.
-3. **Progressive loading** — read only the existing long entries matching this round's
-   domain/tags/related_files. No unbounded whole-repo memory scan.
-4. **Conflict resolution** by priority: current code > latest user confirmation > this
-   round's candidate > older long memory. On conflict, explain it before consolidating —
-   never silently pick a side.
-5. **Retirement check**: for older entries decide delete (no value) / merge (semantic
-   duplicate) / deprecate (was valid, now superseded).
-6. Update the `MEMORY.md` index to reflect every change.
-7. After the long-memory files and index are successfully written, delete the consumed
-   short-memory candidate files. Leave only the latest `short_term_keep` short memories.
-   This is sliding-window consumption after successful distillation, not destructive
-   deletion of durable long-term knowledge.
-
-After either branch succeeds, record completion with the same authoritative action:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-complete --session-file <P> --action <no-op|distill> --agent <agent-id>`.
-The state API rejects an action that disagrees with the current threshold calculation.
-For `distill`, it also rejects completion while any frozen candidate still exists or any
-frozen retained file is missing. A candidate checkpoint may disappear only because it is
-explicitly listed in `candidate_files`.
-
-## Step 3 — automatically enter COMPLETE
-
-Only after `memory_progress.completed:true`, hand control to ec-workflow to call:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage COMPLETE --agent <agent-id>`.
-MEMORY -> COMPLETE is a mechanical edge: do not create `pending_transition`, present another
-confirmation/handoff gate, or stop before closeout. Use the returned Ready status context and
-emit the final task summary.
-
-## ABSTRACT backfill / update
-
-While distilling technical memory, if you detect an architecture change — module added or
-removed, core flow changed, tech stack changed, or (startup projects) ABSTRACT.md does not
-exist yet — update `.easy-coding/ABSTRACT.md` and append a CHANGELOG.md entry (what changed,
-why). For startup projects this is where the first ABSTRACT gets generated from the now-real
-code.
+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.
 
-## Boundaries
+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.
 
-- Run only inside the archive flow. Memory for an unaccepted or closed task is dirty data.
-- Prefer merge/deprecate over destructive delete. Ask before destructive consolidation.
-- The main agent confirms and writes; a memory sub-agent may draft but not finalize.
+Complete processing with `memory-complete`. When the state API reports
+`memory_progress.completed:true`, call `auto-transition --stage COMPLETE`.

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

@@ -1,95 +1,76 @@
 ---
 name: ec-reviewing
-description: REVIEW-stage skill. Use when ec-workflow enters REVIEW. Reviews changed files across correctness, RULES compliance, completeness, tests, and security; returns a graded verdict (accept/fix/replan/blocked) with file-and-line evidence; dispatches multi-dimension sub-agents for every review regardless of change-set size.
+description: REVIEW-stage skill. Performs workflow-mode-aware review against the final implementation fingerprint, blocks only actionable acceptance risks, and records reusable evidence.
 ---
 
-# ec-reviewing — graded, evidence-backed review
+# ec-reviewing — proportional but mandatory review
 
-ec-workflow dispatches you when code IMPLEMENT finishes. Read-only `doc` / `analysis` / `report`
-tasks auto-complete from IMPLEMENT and never enter REVIEW. You judge the code change set and
-return a verdict that drives the next transition. Inputs: the changed files (from
-execution.jsonl `result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
-Lite-mode code tasks never enter REVIEW; they proceed from IMPLEMENT to VERIFICATION.
+Every new code task enters REVIEW. Read-only tasks do not. Obtain the current fingerprints:
 
-Communicate with the user in the user's language.
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py evidence-fingerprints --agent <agent-id> --session-file <P>
+```
 
-## Dimensions (check every one)
+Review the final diff against `dev-spec.md`, RULES, unit acceptance criteria, tests, contracts,
+and obvious security risks. Every finding cites `file:line`.
 
-1. **Correctness** — does the change satisfy the dev-spec's requirement parse and change
-   plan? Edge cases, null/empty handling, off-by-one, async races.
-2. **Compliance** — RULES.md: naming, format, comment language, error handling.
-3. **Completeness** — is every file in the change-scope table actually handled? No half-done
-   units.
-4. **Tests** — do [must-test]/[should-test] items have real test cases? Bug fix has a
-   regression test?
-5. **Security** — obvious risks only: hardcoded secrets, SQL string concatenation, unvalidated
-   external input, path traversal.
+## Depth by workflow mode
 
-## Evidence gate
+- `fast`: main Agent performs one final-diff self-review across correctness, scope, tests, and
+  obvious security risks.
+- `standard`: dispatch one independent focused reviewer covering correctness, contract
+  completeness, tests, and compliance.
+- `strict`: dispatch at least two independent dimensions (correctness/contracts and
+  compliance/tests/security) in parallel via {{sub_agent_dispatch}}.
 
-Every finding cites a concrete `file:line`. "Looks good" / "seems fine" is not a review
-result. No finding without a location.
-
-## Verdict (exactly one)
-
-- `accept` — all dimensions pass. Request REVIEW -> VERIFICATION.
-- `fix` — problems found, fixable within the current plan. Auto-fix via sub-agents (see below).
-- `replan` — the plan itself is flawed (wrong approach, missing design). Request REVIEW -> ANALYSIS.
-- `blocked` — external blocker (missing dependency, environment). Pause and report.
-
-## Auto-fix flow (on `fix` verdict)
+Platform spawn rule: {{platform_spawn_instruction}}
 
-<HARD-GATE>
-Bug-level issues (correctness errors, compliance violations, missing edge-case handling)
-are fixed DIRECTLY by dispatching fix sub-agents. Do NOT ask the user for permission to
-fix bugs. The user confirmed the plan — bugs in that plan's execution are implementation
-defects, not design decisions.
+Reducing reviewer count must not reduce checked dimensions; it only combines them into fewer
+passes when the change is low risk.
 
-ONLY escalate to the user when:
-- The fix requires a DESIGN CHOICE (two equally valid approaches, ambiguous requirement)
-- The fix would change the public API contract beyond what the dev-spec specifies
-- The finding contradicts something the user explicitly confirmed at a stage boundary
-</HARD-GATE>
+## Severity and verdict
 
-Fix dispatch flow:
-1. Collect all `fix`-worthy findings from review sub-agents.
-2. Group findings by file. For each group, build a fix task card:
-   - Files to fix (from the findings)
-   - The specific issues with file:line citations
-   - The suggested fix direction from the reviewer
-   - Relevant RULES sections
-3. Dispatch fix sub-agents (ec-fixer, one per file group) via {{sub_agent_dispatch}}.
-   Platform spawn rule: {{platform_spawn_instruction}}
-4. On return: merge results, append `result` records to execution.jsonl.
-5. Re-enter REVIEW (counts toward the fix-loop ceiling of 3).
+- `error`: demonstrably breaks an acceptance criterion, contract, security boundary, or build.
+  Blocks transition.
+- `warning`: credible risk. Blocks only when it can affect a confirmed acceptance criterion.
+- `info`: maintainability suggestion or optional improvement. Never blocks the current task.
 
-## Fix-loop ceiling
+Verdict:
 
-Maximum 3 fix rounds. A 4th would mean the approach is wrong → auto-escalate to `replan`.
+- `accept`: no blocking finding.
+- `fix`: in-scope implementation defect.
+- `replan`: design/scope/contract is wrong.
+- `blocked`: missing external input or environment.
 
-## Sub-agent dispatch (ALWAYS)
+## Fix loop
 
-<HARD-GATE>
-REVIEW ALWAYS USES SUB-AGENTS regardless of the number of changed files. This prevents
-context pollution in the main agent's window. You MUST NOT review code inline — dispatch
-sub-agents for every review.
-</HARD-GATE>
+1. Merge findings by semantic unit, not by file or reviewer.
+2. Prefer returning the bundle to the original implementation context.
+3. Run targeted checks for the affected unit, then re-review only the affected dimensions.
+4. Expand to full review only if the fix changes scope, public contracts, or shared behavior.
+5. If the same issue class survives two consecutive rounds, stop blind repair and return
+   `replan` or `blocked` with evidence.
 
-Dispatch two parallel review sub-agents:
-- R1: correctness — does the implementation match the dev-spec requirement?
-- R2: compliance — does the code obey RULES?
+In-scope defects are fixed automatically. Ask the user only for a new design choice, changed
+public contract, or contradiction with a confirmed decision.
 
-Each sub-agent returns `{dimension, findings[], severity, suggestion}`. The MAIN agent
-merges and dedups findings and decides the verdict — sub-agents cannot trigger stage
-transitions.
+## Evidence record
 
-Platform spawn rule: {{platform_spawn_instruction}}
+Append one final record per executed dimension for the current implementation fingerprint.
+Fast and Standard normally use `combined`; Strict uses at least two distinct dimension names:
 
-## Output
+```json
+{
+  "type": "review",
+  "dimension": "correctness-contracts",
+  "passed": true,
+  "reviewer": "main-or-independent-agent",
+  "implementation_fingerprint": "<state-api value>",
+  "timestamp": "<ISO-8601>",
+  "findings": []
+}
+```
 
-Append `review` records to execution.jsonl, one per dimension:
-`{"type":"review","dimension":"correctness","findings":[{"file":"...","line":42,"issue":"...","severity":"warn"}]}`.
-Then state the verdict and hand back to ec-workflow.
-For `accept` or `replan`, ec-workflow follows the effective confirm mode for the corresponding
-transition. A `fix` round stays inside REVIEW and therefore
-does not create a status transition unless the outcome changes.
+The state API rejects REVIEW -> VERIFICATION when any latest dimension evidence is missing,
+stale, failed, or contains an `error`. Strict also requires at least two passed dimensions. A
+code change after review produces a new fingerprint and invalidates all prior dimensions.