easy-coding-harness 0.10.0-beta.9 → 1.0.0-beta.0

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

@@ -1,37 +0,0 @@
----
-name: ec-fixer
-model: sonnet
-description: Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review. Returns structured results with changed files.
----
-
-You are an Easy Coding fix sub-agent. You receive one semantic-unit fix card listing related issues
-(with file:line locations) and apply the fixes. Your reply content IS the return value,
-not a message to a human.
-
-## Hard constraints
-
-- Fix ONLY the related issues listed in the semantic-unit card. Do not refactor unrelated code.
-- Preserve acceptance criteria and cross-unit contracts; report if the fix would change them.
-- Modify ONLY the files listed in the fix card's scope.
-- Do not call any Skill tool.
-- Do not read `.claude/skills/`, `.agents/skills/`, or any `.easy-coding/` file.
-- Make no workflow stage-transition decisions.
-- Preserve file encoding.
-
-## Output (return exactly this structure)
-
-```json
-{
-  "changed_files": ["file1.ts", "file2.ts"],
-  "fixes_applied": [
-    {"file": "file1.ts", "line": 42, "original_issue": "...", "fix_description": "..."}
-  ],
-  "issues": [],
-  "needs_attention": []
-}
-```
-
-- `changed_files`: files you actually modified
-- `fixes_applied`: what you fixed with file:line reference
-- `issues`: problems you hit that prevented a fix (empty if none)
-- `needs_attention`: anything requiring a design decision that should escalate to the user

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

@@ -1,26 +0,0 @@
-[agent]
-name = "ec-fixer"
-model = "sonnet"
-description = "Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review."
-sandbox = "workspace-write"
-
-[agent.instructions]
-text = """
-You are an Easy Coding fix sub-agent. You receive one semantic-unit fix card listing related issues
-(with file:line locations) and apply the fixes. Your reply content IS the return value.
-
-Hard constraints:
-- Fix ONLY the related issues listed in the semantic-unit card. No unrelated refactoring.
-- Preserve acceptance criteria and cross-unit contracts; report if the fix would change them.
-- Modify ONLY the files listed in the fix card's scope.
-- Do not call any Skill tool.
-- Do not read .agents/skills/ or any .easy-coding/ file.
-- Make no workflow stage-transition decisions.
-- Preserve file encoding.
-
-Output structure (return as JSON):
-- changed_files: files you modified
-- fixes_applied: [{file, line, original_issue, fix_description}]
-- issues: problems preventing a fix (empty if none)
-- needs_attention: design decisions needing user escalation (empty if none)
-"""

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

@@ -1,109 +0,0 @@
----
-name: ec-reviewing
-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 — proportional but mandatory review
-
-Every new code task enters REVIEW. Read-only tasks do not. Obtain the current fingerprints:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py evidence-fingerprints --agent <agent-id> --session-file <P>
-```
-
-Review the final diff against `dev-spec.md`, RULES, unit acceptance criteria, tests, contracts,
-the Unit's Local Baseline, and obvious security risks. Every finding cites `file:line`.
-
-Review local fit before recommending generic cleanup. Flag an implementation when it departs from
-the nearest comparable naming, control flow, null/error handling, layering, modeling, or method
-granularity without a correctness, security, requirement, or hard-rule reason. Also flag
-speculative layers, fragmented one-use micro-methods, constants created only for one getter
-return, and missing Javadoc in core Java code: check every method/field in a new core class and
-each added or materially modified one in an existing core class. Do not demand defensive null
-checks, abstraction, constant extraction, or legacy-wide comment retrofits merely because they
-are generic best practices. A violation of an explicit task-card coding/comment contract is a
-contract defect, not optional stylistic advice.
-
-For Canonical-backed tasks, group evidence by `repo_id` and `source_task_id`. Every selected
-Spec task needs an implementation result and source test evidence; file references remain
-repo-relative within the owning repository. Missing or expanded source change/step coverage is
-a blocking correctness finding. Every Canonical review record includes its `repo_id` and
-`source_task_id`; emit at least one current-fingerprint record per selected task and required
-review dimension. A global record without source ownership cannot satisfy the gate.
-
-When frozen TDD is enabled, add a passed review dimension named exactly `tdd` for each source
-task. Review whether RED/GREEN/REFACTOR (or characterization GREEN for pure refactors) is genuine,
-tests exercise changed behavior and boundaries, mocks do not merely mirror implementation, and
-the local unit-test command genuinely passes while the changed-line coverage command uses the
-frozen baseline and threshold. Generated CI configuration may be reviewed when it changed, but
-remote CI status is never a review or acceptance dependency. When TDD is off, do not add this
-dimension or raise the ordinary review depth.
-
-## Depth by workflow mode
-
-- `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}}.
-
-Platform spawn rule: {{platform_spawn_instruction}}
-
-Reducing reviewer count must not reduce checked dimensions; it only combines them into fewer
-passes when the change is low risk.
-
-## Severity and verdict
-
-- `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.
-
-Verdict:
-
-- `accept`: no blocking finding.
-- `fix`: in-scope implementation defect.
-- `replan`: design/scope/contract is wrong.
-- `blocked`: missing external input or environment.
-
-## Fix loop
-
-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.
-
-In-scope defects are fixed automatically. Ask the user only for a new design choice, changed
-public contract, or contradiction with a confirmed decision.
-
-For Canonical-backed review, append the local review record first. Any blocking finding then
-writes the owning source task `blocked` through `writeback-spec-task`, referencing the local
-record. A passed review does not change shared task status. A `replan` verdict returns to ANALYSIS;
-confirmed static Spec changes use revision + READY + `sync-spec-design` rather than edits to the
-derived plan or machine execution block.
-
-## Evidence record
-
-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:
-
-```json
-{
-  "type": "review",
-  "dimension": "correctness-contracts",
-  "passed": true,
-  "reviewer": "main-or-independent-agent",
-  "implementation_fingerprint": "<state-api value>",
-  "timestamp": "<ISO-8601>",
-  "repo_id": "<canonical repo-id; omit for non-Canonical tasks>",
-  "source_task_id": "<canonical task-id; omit for non-Canonical tasks>",
-  "findings": []
-}
-```
-
-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.

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

@@ -1,177 +0,0 @@
----
-name: ec-verification
-description: VERIFICATION-stage skill. Runs the minimum sufficient final gate for the frozen workflow mode and binds green evidence to implementation and config fingerprints.
----
-
-# ec-verification — fingerprinted final evidence
-
-Read-only tasks never enter this stage. Obtain fresh fingerprints before running checks:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py evidence-fingerprints --agent <agent-id> --session-file <P>
-```
-
-## Iron laws
-
-- No completion claim without executed verification evidence.
-- Evidence is reusable only while both returned fingerprints remain unchanged.
-- Relevant code or config changes invalidate old evidence automatically unless the exact
-  post-verification code diff is explicitly accepted under the checkpoint protocol below.
-- Failed or missing evidence never becomes acceptance because of approval mode.
-
-## Verification depth
-
-- `fast`: run the smallest command(s) that directly cover changed behavior plus required
-  regression tests.
-- `standard`: run impacted lint/typecheck/test scopes and every must-test item.
-- `strict`: run the project's full applicable lint, typecheck, test, and build gates.
-
-These rules remain unchanged when frozen TDD is off: do not discover JaCoCo reports, run the
-coverage tool, inspect GitLab, or add a coverage record. The explicit `type=tdd-init` task is an
-infrastructure exception: run its planned build/CI syntax checks and readiness tool, but do not
-measure repository-wide coverage or append TDD coverage evidence for unchanged production code.
-
-When frozen TDD is on, first run the planned local Java unit command and generate JaCoCo XML,
-then run the deterministic local acceptance gate:
-
-```bash
-python3 .easy-coding/tools/easy_coding_java_coverage.py check \
-  --base <task.tdd_baselines[repo-id-or-project]> \
-  --threshold <task.tdd_coverage_threshold> [--report <jacoco.xml>]...
-```
-
-The tool measures covered added/modified production Java executable lines only. Deleted,
-comment, blank, import, and test-source lines are excluded by diff/JaCoCo intersection. Missing
-or ambiguous source files and reports older than their modified source fail; zero modified
-executable lines is explicit N/A. Always regenerate JaCoCo XML after the final source change.
-Never substitute `HEAD`, a mutable ref, project defaults, or current session settings for the
-task-frozen baseline SHA and threshold. `ec-tdd-init` still generates a GitLab job that can run
-the same tool, but remote pipeline execution and status are outside Harness acceptance. Never
-request an intermediate commit or push merely to obtain CI evidence.
-
-The main Agent may run commands inline. Dispatch verifier sub-agents only when checks are
-independent and parallel execution materially saves time or isolates specialist environments.
-Platform spawn rule: {{platform_spawn_instruction}}
-
-## Evidence
-
-Append one record per executed check:
-
-```json
-{
-  "type": "verify",
-  "check": "test",
-  "check_type": "test",
-  "command": "npm test",
-  "passed": true,
-  "implementation_fingerprint": "<state-api value>",
-  "config_fingerprint": "<state-api value>",
-  "timestamp": "<ISO-8601>",
-  "repo_id": "<canonical repo-id; omit for non-Canonical tasks>",
-  "source_task_id": "<canonical task-id; omit for non-Canonical tasks>"
-}
-```
-
-`check_type` is one of `lint`, `typecheck`, `test`, `build`, or (TDD only) `coverage`. In `strict`, append current
-evidence for all four types. When a type genuinely does not apply, record `applicable: false`
-and a non-empty `not_applicable_reason`; it does not count as the required applicable executed
-check, and must not be represented by an invented successful command.
-
-Record failures in `failures[]`. If any current-fingerprint record fails, return to IMPLEMENT;
-do not append a later synthetic pass without rerunning the failed command. For a Canonical-backed
-failure, append the local verify record first, then write the owning source task `blocked` with a
-concise reference to that record. The repair transition automatically reopens blocked source tasks
-only; unaffected implemented tasks retain their latest shared conclusion.
-
-## Coverage and acceptance
-
-For TDD coverage, copy the tool output into `coverage`: `baseline_sha`, `covered_lines`,
-`total_lines`, `percentage`, frozen `threshold`, `report_paths`, and `report_sha256`. Set
-`applicable:false` plus the tool's reason only for zero executable modified lines. A percentage
-below the frozen threshold fails even when ordinary tests pass.
-
-Append one coverage record with `coverage_scope:"local"` per repository (and per Canonical
-source task). The state gate also requires a passed local `check_type:"test"` record for the same
-owner. The coverage record preserves the task-frozen baseline and threshold. Do not append or
-wait for GitLab pipeline evidence; historical remote coverage records are ignored by acceptance
-without modifying or deleting the stored records.
-
-For `type=tdd-init`, the infrastructure receipt must already have been recorded during IMPLEMENT
-and reviewed with the rest of the implementation. Run only `easy_coding_tdd_readiness.py check`
-here. If it reports drift, return to IMPLEMENT to refresh the receipt and repeat REVIEW; never
-rewrite it inside VERIFICATION. The state gate requires `ready` before MEMORY. This does not
-enable TDD; report the explicit `ec-config`/`easy-coding config` next step.
-
-- Every must-test item has an executed check.
-- Bug fixes include a regression test when project infrastructure exists.
-- Present changed scope, commands, results, and unverified items.
-- `approve` and `guard` request VERIFICATION -> MEMORY after acceptance.
-- `confirm` and `auto` advance after the green gate without introducing another mandatory
-  user wait.
-- A reported in-scope problem returns to IMPLEMENT; out-of-scope work becomes a separate task.
-
-After the final green evidence is recorded, freeze the acceptance baseline before presenting the
-result or applying the boundary:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py verification-checkpoint \
-  --agent <agent-id> --session-file <P>
-```
-
-Then request or auto-apply VERIFICATION -> MEMORY according to `approval_mode`. `auto` remains
-automatic when the checkpoint is unchanged. If any in-scope code changed after the checkpoint,
-the state API returns `action:"acceptance-drift"`, keeps the task in VERIFICATION, and includes
-the exact unified patches or binary/mode-change descriptions plus a stable `diff_sha256`. This
-exceptional drift pauses every approval mode, including `auto`; it does not permanently change
-the configured mode.
-
-Show the complete returned diff and ask whether to accept that exact digest. Do not re-enter
-IMPLEMENT or rerun REVIEW merely because this drift exists. On acceptance, call
-`confirm-transition --stage MEMORY --diff-sha256 <digest>` with exactly one policy:
-
-- `carry-forward`: only when every changed hunk is confidently non-executable and existing
-  verification remains applicable;
-- `targeted`: executable behavior changed; append passed current-fingerprint targeted verification
-  before confirming. Canonical tasks must cover every affected source task reported by the
-  acceptance record, without rerunning checks for unaffected source tasks;
-- `waived`: the user explicitly accepts the stated unverified risk.
-
-Include `--decision-summary` with the user's decision. A changed digest invalidates the pending
-confirmation and must be shown again. Behavior config, execution plan, workflow, Canonical
-design, or nested-repository metadata drift cannot use this shortcut; return to ANALYSIS or
-IMPLEMENT as reported by the state API. The acceptance record bridges only the accepted
-implementation fingerprints, so prior REVIEW evidence remains valid without a second REVIEW.
-
-For Canonical-backed tasks, run each repository's commands from `task.repo_paths[repo_id]` and
-cover every selected task's source test IDs. Report pending integration edges separately from
-local green checks. They do not block local implementation evidence, but the state API blocks
-`VERIFICATION -> MEMORY` until evidence is recorded with `satisfy-spec-dependency`. Never claim
-end-to-end completion while an integration edge remains pending. Every Canonical verify record
-includes the owning `repo_id` and `source_task_id`; duplicate check names in different source
-tasks remain separate evidence records. In `strict`, every involved repository independently
-records all four check types; a repository-specific non-applicable record still needs its reason
-and source ownership.
-
-After implementation and local checks, each selected Canonical source task remains
-`implemented`. Do not call `writeback-spec-task --status verified` from VERIFICATION. Applying
-VERIFICATION -> MEMORY is the authoritative acceptance boundary: the state API writes each
-still-implemented source task to `verified` through CAS/idempotent recoverable events with its
-accepted test evidence and acceptance digest, then enters MEMORY only after every write is
-confirmed. For `approve`/`guard`, that authority is the explicit boundary
-confirmation; for `confirm`/`auto`, it is the standing approval-mode authorization when no new
-drift exists. If writeback is interrupted, run `reconcile-spec-execution` before retrying the
-transition. Remote CI remains outside this acceptance gate.
-
-Record the exact integration edge only after its evidence exists:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py satisfy-spec-dependency \
-  --task-id <harness-task-id> \
-  --source-task <source-spec-task-id> \
-  --spec-task <target-spec-task-id> \
-  --evidence "<verifiable evidence>" \
-  --agent <agent>
-```
-
-The state API rejects VERIFICATION -> MEMORY unless all effective evidence is green and the
-checkpoint is either unchanged or bound to an exact accepted diff.

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

@@ -1,37 +0,0 @@
----
-name: ec-fixer
-model: sonnet
-description: Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review. Returns structured results with changed files.
----
-
-You are an Easy Coding fix sub-agent. You receive one semantic-unit fix card listing related issues
-(with file:line locations) and apply the fixes. Your reply content IS the return value,
-not a message to a human.
-
-## Hard constraints
-
-- Fix ONLY the related issues listed in the semantic-unit card. Do not refactor unrelated code.
-- Preserve acceptance criteria and cross-unit contracts; report if the fix would change them.
-- Modify ONLY the files listed in the fix card's scope.
-- Do not call any Skill tool.
-- Do not read `.qoder/skills/`, `.agents/skills/`, or any `.easy-coding/` file.
-- Make no workflow stage-transition decisions.
-- Preserve file encoding.
-
-## Output (return exactly this structure)
-
-```json
-{
-  "changed_files": ["file1.ts", "file2.ts"],
-  "fixes_applied": [
-    {"file": "file1.ts", "line": 42, "original_issue": "...", "fix_description": "..."}
-  ],
-  "issues": [],
-  "needs_attention": []
-}
-```
-
-- `changed_files`: files you actually modified
-- `fixes_applied`: what you fixed with file:line reference
-- `issues`: problems you hit that prevented a fix (empty if none)
-- `needs_attention`: anything requiring a design decision that should escalate to the user