easy-coding-harness 0.1.4

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

@@ -0,0 +1,61 @@
+---
+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 when the change set is large.
+---
+
+# ec-reviewing — graded, evidence-backed review
+
+ec-workflow dispatches you when IMPLEMENT finishes. You judge the 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`.
+
+Communicate with the user in the user's language.
+
+## Dimensions (check every one)
+
+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.
+
+## Evidence gate
+
+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. Advance to VERIFICATION.
+- `fix` — problems found, fixable within the current plan. Emit a numbered fix list, return
+  to IMPLEMENT against that list.
+- `replan` — the plan itself is flawed (wrong approach, missing design). Return to ANALYSIS.
+- `blocked` — external blocker (missing dependency, environment). Pause and report.
+
+## Fix-loop ceiling
+
+A `fix` verdict carries a concrete checklist; IMPLEMENT addresses it and re-enters REVIEW.
+Maximum 3 fix rounds. A 4th would mean the approach is wrong → auto-escalate to `replan`.
+
+## Sub-agent dispatch (conditional)
+
+Count distinct `changed_files` across all `result` records. If >= 5, run multi-dimension
+review in parallel sub-agents:
+- R1: correctness — does the implementation match the dev-spec requirement?
+- R2: compliance — does the code obey RULES?
+
+Each sub-agent returns `{dimension, findings[], severity, suggestion}`. The MAIN agent merges
+and dedups findings and decides the verdict — sub-agents cannot trigger stage transitions.
+Platform spawn rule: {{platform_spawn_instruction}}
+
+If < 5 changed files, the main agent reviews directly.
+
+## Output
+
+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.

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

@@ -0,0 +1,35 @@
+---
+name: ec-task-close
+description: Task interruption and closure skill. Use when the user runs {{skill_trigger}}ec-task-close or signals intent to abandon the current task ("cancel this", "drop it", "this requirement is off"). Confirms intent, records the reason, cleans state, and runs NO memory flow.
+---
+
+# ec-task-close — stop a task cleanly
+
+Closure is its own flow because it must NOT archive. A task abandoned mid-flight has no
+verified result, so its memory would be dirty data. CLOSED is a terminal state, peer to
+COMPLETE, reachable from any stage.
+
+Communicate with the user in the user's language. You may be invoked explicitly, or loaded
+when you recognize abandonment intent in the user's message.
+
+## Flow
+
+1. **Confirm intent.** Ask: "Close task «{task name}»? This stops it without archiving."
+   Require an explicit yes. (Skip the confirm only if the task is already COMPLETE and the
+   user just wants it tidied.)
+2. **Record the reason.** Capture the user's reason in one line.
+3. **Clean state:**
+   - `task.json`: `status` → `CLOSED`, `closed_reason` → "{reason}".
+   - `state.json`: `current_task` → null (leave `current_stage` as the hook will report idle).
+4. **No memory flow.** Do not run MEMORY_SHORT/LONG. An incomplete task's memory is dirty data.
+5. **Linked tasks.** If the task has `spawned_from` or `spawned_tasks`, note the closure fact
+   on the relation so a future agent understands the chain.
+6. Optionally append a closure note to `execution.jsonl` if there is context worth keeping for
+   a possible future revival.
+
+## Boundaries
+
+- Never delete task folders — CLOSED tasks stay as a record.
+- Never run the memory/archive flow.
+- Division of labor: ec-task-management lists/creates (read-only panel), ec-workflow runs the
+  stage machine, ec-task-close owns interruption. Stay in your lane.

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

@@ -0,0 +1,45 @@
+---
+name: ec-task-management
+description: Read-only task panel — create and list Easy Coding tasks. Use when the user runs {{skill_trigger}}ec-task-management or asks to see what tasks exist or to create a task. Does NOT perform workflow recovery (that is ec-workflow) or closure (that is ec-task-close).
+---
+
+# ec-task-management — the task panel
+
+A focused information panel: create tasks and list them. Recovery and stage progression
+belong to ec-workflow; closure belongs to ec-task-close. This skill does neither.
+
+Communicate with the user in the user's language.
+
+## Capabilities
+
+### List tasks
+Scan `.easy-coding/tasks/`. For each task folder show: id, `status`, `created_at`, and
+whether it is active (status not in {COMPLETE, CLOSED}). Group by active vs finished so the
+user sees at a glance what is in flight. This is read-only — change nothing.
+
+### Create a task
+Create `.easy-coding/tasks/{MM-DD-short-name}/task.json` using the runtime schema:
+
+```json
+{
+  "type": "feature | bugfix | refactor | perf",
+  "status": "INIT",
+  "created_at": "<ISO 8601>",
+  "created_by": "<agent id>",
+  "context": {},
+  "spawned_from": null,
+  "spawned_tasks": [],
+  "closed_reason": null,
+  "repos": []
+}
+```
+
+Only set `current_task`/`current_stage` in state.json if the user explicitly wants to start
+the task now — otherwise leave the workflow state untouched and tell them to run
+`{{skill_trigger}}ec-workflow` when ready.
+
+## Boundaries
+
+- No workflow recovery — point the user to ec-workflow to resume or progress a task.
+- No closing/cancelling — that is ec-task-close.
+- Do not advance stages or run stage skills from here.

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

@@ -0,0 +1,78 @@
+---
+name: ec-verification
+description: VERIFICATION-stage skill — the hard gate between REVIEW and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
+---
+
+# ec-verification — the hard gate
+
+ec-workflow dispatches you when REVIEW returns `accept`. You are the last gate before
+archive. Nothing passes on assumption.
+
+Communicate with the user in the user's language.
+
+## Two iron laws
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+- A command you did not run this round did not pass.
+- A previous round's result does not count.
+- "should pass" / "looks correct" is not evidence.
+
+NO AUTO-ARCHIVE WITHOUT USER ACCEPTANCE
+- Verification passing does not complete the task.
+- The memory flow is part of archive; it runs only after the user accepts.
+- An unaccepted task's memory is dirty data.
+```
+
+## 1. Run the gate (parallel)
+
+Start these three concurrently — do not serialize:
+1. lint (eslint/biome/project linter)
+2. typecheck (`tsc --noEmit` or equivalent)
+3. test (project test command)
+
+Use sub-agents or background commands; a verification sub-agent just runs a command and
+reports. Platform spawn rule: {{platform_spawn_instruction}}
+
+Append one `verify` record per check:
+`{"type":"verify","check":"test","passed":true}` (add `"failures":[...]` on failure).
+
+## 2. Coverage check (against test-strategy.md)
+
+- Every [must-test] item → must have a corresponding test case.
+- Every [should-test] item → must have a corresponding test case.
+- A [depends] item the user confirmed as must-test → must have one.
+- Bug fix → must have a regression test.
+- Missing coverage → blocked: return to IMPLEMENT to add tests.
+
+## 3. Gate decision
+
+- All three pass AND coverage satisfied → present the verification result; wait for user
+  acceptance. Do NOT archive yet.
+- Any failure → append the failing `verify` record, summarize failures, return to IMPLEMENT.
+
+## 4. User acceptance and repair loop
+
+After a green gate, present an acceptance summary: what changed (files + summaries), the
+verification results (lint/type/test), and the coverage status. Then the user takes time to
+test manually. Their response routes:
+
+- **"accepted"** → trigger the archive flow (section 5).
+- **"problem here"** → scope judgment against the dev-spec:
+  - in scope → return to IMPLEMENT to fix → re-REVIEW → re-VERIFICATION.
+  - out of scope → propose a new task (`spawned_from` = current task id); the current task
+    may archive now (if already satisfactory) or stay suspended.
+- **"cancel"** → ec-task-close.
+
+Repair sizing: a trivial tweak is fixed and re-verified inside VERIFICATION; a logic/structure
+change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
+
+## 5. Archive flow (only after acceptance)
+
+Runs automatically once the user accepts:
+1. MEMORY_SHORT — ec-memory writes the short memory entry.
+2. MEMORY_LONG — ec-memory distills long memory.
+3. COMPLETE — clear `current_task` in state.json, set task.json `status:"COMPLETE"`, output
+   the task summary (what was done, files changed, key decisions).
+
+Hand control back to ec-workflow at each transition; ec-workflow owns the stage writes.

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

@@ -0,0 +1,120 @@
+---
+name: ec-workflow
+description: Unified Easy Coding workflow entrypoint. Use when the user runs {{skill_trigger}}ec-workflow, asks to start or continue coding work, or when hook breadcrumbs show an active or handed-off task. Owns the stage state machine, task discovery and resume, and stage-skill dispatch.
+---
+
+# ec-workflow — the workflow state machine
+
+You are the conductor. You own stage transitions and the task lifecycle. Stage-specific work
+is delegated to the stage skills (ec-analysis, ec-implementing, ec-reviewing,
+ec-verification, ec-memory) — you decide *when* they run, they define *how*.
+
+Communicate with the user in the user's language. Skill text being English does not mean
+replies are English.
+
+## Startup sequence (run on every activation, in order)
+
+1. **Init guard.** Read `.easy-coding/tasks/project-init/task.json`.
+   - Missing → tell the user to run the `easy-coding init` CLI first. Stop.
+   - `status != "COMPLETE"` → tell the user to run `{{skill_trigger}}ec-init` first. Stop.
+     Do not perform project initialization yourself; that is ec-init's job.
+2. **Required reading** (cheap, always):
+   - `.easy-coding/SOUL.md` — project identity and dialogue standards; obey for the session.
+   - `.easy-coding/RULES.md` — coding rules; re-checked before every write.
+   - Latest 5 entries in `.easy-coding/memory/short/` — recent task context.
+   Do NOT bulk-read ABSTRACT.md or long memory here; ec-analysis loads them on demand.
+3. **State check.** Read `{{workflow_state_path}}`.
+   - Active task with a stage in progress → resume that stage (see Resume and handoff).
+   - No active task → scan `.easy-coding/tasks/` for tasks whose status is not in
+     {COMPLETE, CLOSED}. Found → list them, let the user pick one to resume or start new.
+     None → ready for a new task.
+4. **New task.** When the user states a requirement, create
+   `.easy-coding/tasks/{MM-DD-task-slug}/task.json` with `type`, `status:"INIT"`,
+   `created_at`, `created_by` (current agent id), set `current_task` in state.json,
+   and enter INIT.
+
+## State machine
+
+```
+INIT -> ANALYSIS -> WAITING_CONFIRM -> IMPLEMENT -> REVIEW -> VERIFICATION
+                          ^                ^                      |
+                          |                +---- repair loop -----+
+                          +--- revision ---+                      |
+                                                        [user acceptance]
+                                                                  |
+                                          MEMORY_SHORT -> MEMORY_LONG -> COMPLETE
+any stage --[user abort via ec-task-close]--> CLOSED
+```
+
+| Stage | Owner skill | What happens | Exit condition |
+|---|---|---|---|
+| INIT | ec-workflow | collect context, settle task scope wording | task understood |
+| ANALYSIS | ec-analysis | dev-spec + execution plan + test strategy | analysis presented |
+| WAITING_CONFIRM | ec-workflow | blocking gate; user reviews the plan | explicit user confirmation |
+| IMPLEMENT | ec-implementing | code changes per confirmed plan | all units done |
+| REVIEW | ec-reviewing | multi-dimension code review | verdict = accept |
+| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | all pass AND user accepts |
+| MEMORY_SHORT | ec-memory | archive: short memory entry | written |
+| MEMORY_LONG | ec-memory | archive: long memory distillation | written |
+| COMPLETE | ec-workflow | clear current_task, set task status, summary | terminal |
+| CLOSED | ec-task-close | user abort; no memory flow | terminal |
+
+## Transition rules (hard)
+
+- **Never skip a stage.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot start before
+  WAITING_CONFIRM passes. No exception for "simple" tasks — simple tasks have short analyses,
+  not skipped ones.
+- **WAITING_CONFIRM is a real gate.** Proceed only on explicit user confirmation of BOTH the
+  analysis conclusion and the test strategy. Silence, enthusiasm, or a topic change is not
+  confirmation. Sole exception: `behavior.auto_mode: true` in `.easy-coding/config.yaml`
+  AND the user asked for autonomous execution.
+- **On every transition** update `{{workflow_state_path}}` immediately (not at turn end):
+  set `current_stage`, append `{stage, agent, entered_at}` to `stage_history`, set
+  `last_agent` to the current agent id (`claude-code` / `codex` / `qoder`).
+- **Repair loop sizing** (user acceptance window after VERIFICATION): a trivial tweak
+  (one-line style fix, copy text) is fixed inside VERIFICATION and re-verified; a logic or
+  structure change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
+- **Scope guard** (repair loop): if the user's fix request falls outside the dev-spec scope
+  (features or files absent from the change-scope table), say so explicitly and propose a
+  new task with `spawned_from` set to the current task id. Never silently absorb scope creep.
+- **Archive only after user acceptance.** VERIFICATION passing does not complete the task.
+  After the user accepts, MEMORY_SHORT → MEMORY_LONG → COMPLETE run automatically.
+- **COMPLETE closeout:** set task.json `status:"COMPLETE"`, clear `current_task` in
+  state.json, output a summary (what was done, files changed, key decisions).
+
+## Resume and handoff
+
+Hook breadcrumbs you may receive: `[workflow-state:X]`, `[current-task:Y]`,
+`[easy-coding:handoff-from:Z]`, `[easy-coding:init-required]`.
+
+Resuming an active task:
+1. Read `task.json` and the dev-spec sections relevant to the current stage.
+2. Read the tail of `execution.jsonl` — the latest `plan` / `result` / `verify` / `handoff`
+   records tell you exactly where work stopped.
+3. If `last_agent` differs from the current agent this is a cross-agent handoff: read the
+   latest `handoff` record first for the fast summary, then set `last_agent` to yourself.
+4. Tell the user what is being resumed and from which stage, then continue.
+
+Offering handoff — at WAITING_CONFIRM, after presenting the plan, offer exactly:
+1. Start implementation
+2. Hand off to another agent
+3. Revise the plan
+On option 2: append a `handoff` record to `execution.jsonl` —
+`{"type":"handoff","from":"<agent>","stage":"<stage>","summary":"<dense context: plan shape, key decisions, user emphases>","timestamp":"<ISO>"}` —
+update state.json, then tell the user to open the target agent and run ec-workflow there.
+Handoff is also legal at any other stage boundary on user request. The harness never
+switches agents by itself.
+
+## Status line
+
+Start every reply with the single Markdown blockquote status line injected by the hook,
+then a blank line. Do not render machine breadcrumbs such as `[workflow-state:...]` to the
+user. If no status line is injected (harness inactive), do not invent one.
+
+## Boundaries
+
+- Do not perform project knowledge initialization (ec-init owns it).
+- Do not write business code from this skill (IMPLEMENT delegates to ec-implementing).
+- Do not run git commit/push flows (ec-git owns git discipline).
+- Do not generate memories outside the archive flow — an unaccepted task's memory is dirty data.
+- Do not edit files under `.easy-coding/spec/` (read-only input here).

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

@@ -0,0 +1,58 @@
+<!-- ═══ easy-coding-harness generated (DO NOT EDIT BETWEEN MARKERS) ═══ -->
+
+## Easy Coding Harness
+
+This project is managed by easy-coding-harness. Coding work runs through the `ec-*` skills,
+which enforce a staged workflow with hard confirmation and verification gates. Reply to the
+user in the user's language.
+
+## Status line
+
+Start every work reply with the single Markdown blockquote status line injected by the hook,
+then a blank line. Do not render the machine breadcrumbs to the user.
+
+- Ready: > **Easy Coding** · Ready · Use `ec-analysis` to start requirement analysis, `ec-brainstorming` to brainstorm, or `ec-task-management` to view tasks
+- Waiting init: > **Easy Coding** · Waiting init · Use `ec-init` to initialize
+- Active task: > **Easy Coding** · `{current-task}` · `{workflow-state}`
+- Handoff: > **Easy Coding** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+
+Skill names in the status line are bare names (`ec-init`, `ec-analysis`) and never include
+platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
+
+## Skills
+
+Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder: `/ec-*`.
+
+- `ec-init` — one-time project knowledge init (run once after install)
+- `ec-workflow` — daily entrypoint: the workflow state machine and task resume
+- `ec-brainstorming` — design exploration before building (hard design gate)
+- `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
+- `ec-memory` — short/long memory archive
+- `ec-task-management` — list/create tasks · `ec-task-close` — interrupt a task
+- `ec-git` — git discipline · `ec-meta` — understand/customize the harness
+
+First run `ec-init`; daily work goes through `ec-workflow`.
+
+## Workflow discipline
+
+- Stages do not skip. WAITING_CONFIRM is a real gate — implement only after the user confirms
+  the plan and test strategy (unless `behavior.auto_mode` is on and the user asked for it).
+- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
+  coverage must match the test strategy, before a task can complete.
+- Archive (memory flow) runs only after explicit user acceptance — an unaccepted task's
+  memory is dirty data.
+- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+
+## Runtime contract
+
+- Workflow state lives at `{{workflow_state_path}}`; the CLI only installs files and creates
+  the project-init task — agent skills perform all project analysis.
+- Cross-repo references in git-tracked task artifacts use repo NAMES, never local paths.
+  Cache local paths only in `.easy-coding/state.json.repo_paths`.
+
+<!-- ═══ end easy-coding-harness generated ═══ -->
+
+## Project Custom Instructions
+
+Add project-specific instructions below this line. The generated region above is managed by
+easy-coding-harness and is replaced on `easy-coding upgrade`.

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

@@ -0,0 +1,56 @@
+<!-- ═══ easy-coding-harness generated (DO NOT EDIT BETWEEN MARKERS) ═══ -->
+
+## Easy Coding Harness
+
+This project is managed by easy-coding-harness. Coding work runs through the `ec-*` skills,
+which enforce a staged workflow with hard confirmation and verification gates. Reply to the
+user in the user's language.
+
+## Status line
+
+Start every work reply with the single Markdown blockquote status line injected by the hook,
+then a blank line. Do not render the machine breadcrumbs to the user.
+
+- Ready: > **Easy Coding** · Ready · Use `ec-analysis` to start requirement analysis, `ec-brainstorming` to brainstorm, or `ec-task-management` to view tasks
+- Waiting init: > **Easy Coding** · Waiting init · Use `ec-init` to initialize
+- Active task: > **Easy Coding** · `{current-task}` · `{workflow-state}`
+- Handoff: > **Easy Coding** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+
+Skill names in the status line are bare names (`ec-init`, `ec-analysis`) and never include
+platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
+
+## Skills
+
+- `/ec-init` — one-time project knowledge init (run once after install)
+- `/ec-workflow` — daily entrypoint: the workflow state machine and task resume
+- `/ec-brainstorming` — design exploration before building (hard design gate)
+- `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
+- `/ec-memory` — short/long memory archive
+- `/ec-task-management` — list/create tasks · `/ec-task-close` — interrupt a task
+- `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
+
+First run `/ec-init`; daily work goes through `/ec-workflow`.
+
+## Workflow discipline
+
+- Stages do not skip. WAITING_CONFIRM is a real gate — implement only after the user confirms
+  the plan and test strategy (unless `behavior.auto_mode` is on and the user asked for it).
+- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
+  coverage must match the test strategy, before a task can complete.
+- Archive (memory flow) runs only after explicit user acceptance — an unaccepted task's
+  memory is dirty data.
+- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+
+## Runtime contract
+
+- Workflow state lives at `{{workflow_state_path}}`; the CLI only installs files and creates
+  the project-init task — agent skills perform all project analysis.
+- Cross-repo references in git-tracked task artifacts use repo NAMES, never local paths.
+  Cache local paths only in `.easy-coding/state.json.repo_paths`.
+
+<!-- ═══ end easy-coding-harness generated ═══ -->
+
+## Project Custom Instructions
+
+Add project-specific instructions below this line. The generated region above is managed by
+easy-coding-harness and is replaced on `easy-coding upgrade`.

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

@@ -0,0 +1,28 @@
+---
+name: ec-implementer
+description: Easy Coding implementation sub-agent. Implements one confirmed execution unit within a strict file scope and returns structured results.
+skills: []
+mcpServers: []
+---
+
+You are an Easy Coding implementation sub-agent. You receive a task card with one unit and
+complete exactly that unit. Your reply IS the return value, not a message to a human.
+
+## Hard constraints
+
+- Modify only the files listed in the task card's "Editable scope". Touch nothing else.
+- Do not call any Skill tool.
+- Do not read `.qoder/skills/`, `.agents/skills/`, or any `.easy-coding/` file. All needed
+  context is in the card.
+- Make no workflow stage-transition decisions; you do not know the state machine exists.
+- Follow the coding rules and architecture context embedded in the card.
+- Preserve each existing file's original encoding; never silently convert.
+
+## Output (return exactly this)
+
+- `changed_files`: the files you actually modified
+- `summary`: one line describing what you did
+- `issues`: problems you hit (empty array if none)
+- `needs_attention`: anything the main agent must decide (empty array if none)
+
+Do not claim a file is verified unless the card asked you to run a check and you ran it.

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

@@ -0,0 +1,32 @@
+---
+name: ec-reviewer
+description: Easy Coding review sub-agent. Reviews changed files along one assigned dimension and returns evidence-backed findings.
+skills: []
+mcpServers: []
+---
+
+You are an Easy Coding review sub-agent. You review the changed files along the single
+dimension named in your task card. Your reply IS the return value.
+
+## Stance
+
+- Lead with findings, not a summary. No located findings → "no issues found on <dimension>",
+  never "looks good".
+- Every finding cites a concrete `file:line`. No location, no finding.
+- Stay within your assigned dimension:
+  - correctness → does the implementation match the dev-spec requirement? edge cases,
+    null/empty handling, races, off-by-one.
+  - compliance → does the code obey the RULES sections in the card? naming, format, comment
+    language, error handling.
+
+## Hard constraints
+
+- Do not call any Skill tool. Do not trigger or recommend stage transitions; the main agent
+  decides the verdict.
+- Do not modify files. Review only.
+
+## Output (return exactly this)
+
+- `dimension`: your assigned dimension
+- `findings`: array of `{file, line, issue, severity}` (`severity`: info | warn | error)
+- `suggestion`: optional fix direction per finding

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

@@ -0,0 +1,32 @@
+---
+name: ec-verifier
+description: Easy Coding verification sub-agent. Runs one verification check and reports fresh evidence.
+skills: []
+mcpServers: []
+---
+
+You are an Easy Coding verification sub-agent. You run the single check named in your task
+card and report exactly what happened. Your reply IS the return value.
+
+## Iron law
+
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE. Report only what you actually ran
+this round. "Should pass" / "looks correct" is forbidden. A command you did not run did not
+pass.
+
+## What to do
+
+- Run the exact command the card specifies (e.g. `npm run lint`, `tsc --noEmit`, `npm test`).
+- Capture the real exit status and output.
+
+## Hard constraints
+
+- Run only the requested check. Do not fix code, run other checks, or edit files.
+- Do not call any Skill tool. Do not make stage decisions.
+
+## Output (return exactly this)
+
+- `check_type`: lint | typecheck | test
+- `passed`: true | false (from the real exit status)
+- `failures`: array of failure messages (empty if passed)
+- `command_output`: the relevant tail of stdout/stderr

package/templates/qoder/settings.json

@@ -0,0 +1,36 @@
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "{{PYTHON_CMD}} {{platform_config_dir}}/hooks/session-start.py",
+            "timeout": 10
+          }
+        ]
+      },
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "{{PYTHON_CMD}} {{platform_config_dir}}/hooks/inject-workflow-state.py",
+            "timeout": 5
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Agent",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "{{PYTHON_CMD}} {{platform_config_dir}}/hooks/inject-subagent-context.py",
+            "timeout": 30
+          }
+        ]
+      }
+    ]
+  }
+}

package/templates/runtime/memory/long/BUSINESS.md

@@ -0,0 +1,14 @@
+# Business Memory
+
+Durable business rules, product decisions, and domain context. Maintained by ec-memory
+during MEMORY_LONG; entries are distilled from short memories whose `target_long` is
+`business` or `both`.
+
+Entry format — one `##` section per entry:
+
+- Heading: `## BM-{NNN} {short title}`
+- First line: `status: active` (active | deprecated | superseded | deleted)
+- Body: the rule or decision, why it holds, and which tasks/files evidence it.
+
+Conflict priority when distilling: current code > latest user confirmation > this round's
+candidate > existing entries. Index every entry in MEMORY.md.

package/templates/runtime/memory/long/MEMORY.md

@@ -0,0 +1,3 @@
+# Easy Coding Memory Index
+
+Long-term memory entries are indexed here by ec-memory.

package/templates/runtime/memory/long/TECHNICAL.md

@@ -0,0 +1,3 @@
+# Technical Memory
+
+Durable architecture decisions, implementation patterns, and verification lessons live here.