@mrciphersmith/keryx 0.2.71 → 0.2.73

package/src/gdskills/bundled/skills/orchestration/task-implementer/SKILL.zed.md

@@ -1,6 +1,7 @@
 ---
 name: task-implementer
-description: "Autonomous implementation agent that receives a single atomic task (JSON task object from issue-analyzer) and implements it end-to-end: researches codebase, plans changes, writes code, creates tests/stories as needed, verifies via lint/type-check/test, and reports results. Use when: implementing a single decomposed task from issue-analyzer, executing code changes autonomously."
+model_tier: standard
+description: "Use when implementing a single decomposed task from issue-analyzer end-to-end, or executing autonomous code changes from a JSON task object."
 triggers:
   - "Implement task"
   - "Execute task scenario"
@@ -9,9 +10,10 @@ triggers:
   - "Implement issue task"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.3.0"
   category: "implementation"
-  compatible_harnesses: "cursor,codex,zed,opencode"
+  agent_worthy: true
+  compatible_harnesses: "claude,cursor,codex,zed,opencode"
 license: "MIT"
 ---
 
@@ -38,7 +40,7 @@ Phase 2: RESEARCH   →  Deep-read target files, understand module patterns
 Phase 3: PLAN       →  Decide implementation approach, list file changes
 Phase 4: IMPLEMENT  →  Write code, tests, stories
 Phase 5: VERIFY     →  Run lint, type-check, tests
-Phase 6: REPORT     →  Emit JSON result object
+Phase 6: REPORT     →  Write result file + emit compact STATUS response
 ```
 
 ---
@@ -67,7 +69,7 @@ TASK: (from JSON object passed by orchestrator)
   task_name:            string, e.g. "Add validation to form"
   task_type:            string: ui_component|store_logic|service_api|refactoring|fix|mixed
   complexity:           string: low|medium|high
-  dependencies:         array of task_id strings (already satisfied — orchestrator ensures order)
+  dependencies:         array of task_id strings this task reads from
   description:          string: what to implement
   target_files:         array of file path strings
   acceptance_criteria:  array of criterion strings
@@ -75,6 +77,7 @@ TASK: (from JSON object passed by orchestrator)
   existing_tests:       array of file path strings (may be empty)
   existing_stories:     array of file path strings (may be empty)
   module_patterns:      string: how similar code is written in this module
+  test_case_specs:      optional — provided by tests-creator (RED-phase test stubs already committed)
 ```
 
 **1.2 Extract from workspace context:**
@@ -92,19 +95,60 @@ WORKSPACE:
 ```
 FIX_CONTEXT:
   review_feedback:      structured findings from reviewer (file, line, severity, message)
-  original_task_id:     the task that introduced the issue
-  iteration:            fix iteration number (1 or 2)
+  original_task_ids:    the tasks that introduced the findings (array)
+  iteration:            fix iteration number, 1..3 — the same repair bound as 5.4
 ```
 
-**1.4 Validate:**
+**1.4 Validate the request against the contract:**
+
+Write the request you were handed to a file and run:
+
+```bash
+keryx skills contracts validate <request.json> --schema task-implementer-input
 ```
-ASSERT task_id IS NOT EMPTY           → otherwise ABORT("Missing task_id")
-ASSERT task_type IN valid_types       → otherwise ABORT("Invalid task_type")
-ASSERT target_files IS NOT EMPTY      → otherwise ABORT("No target files")
-ASSERT codebase_path EXISTS           → otherwise ABORT("Codebase path not found")
-ASSERT branch IS NOT EMPTY            → otherwise ABORT("Wrong branch checked out")
+
+Non-zero exit means the dispatch is malformed — ABORT and report `NEEDS_CONTEXT`
+with the validator's own message. Do not repair the request yourself; the
+orchestrator owns it.
+
+The refusals are the contract's, not a checklist you run by eye
+(`input-contract.schema.json`, registered in `src/gdskills/contracts.ts`):
+
+| What is refused | Where the schema says so |
+|---|---|
+| Missing `task_id` / `task_name` / `task_type` / `description` / `target_files` / `acceptance_criteria` | `task.required` |
+| `task_type` outside `ui_component\|store_logic\|service_api\|refactoring\|fix\|mixed` | `task.task_type.enum` |
+| A `task_id` that is not `task-<n>` | `task.task_id.pattern` |
+| Empty `target_files` or empty `acceptance_criteria` | `minItems: 1` on both |
+| Missing `codebase_path` / `branch` / `issue_number` | `workspace.required` |
+| `skip_confirmation` anything but `true` | `automation.skip_confirmation.const` |
+| `max_self_fix_attempts` above 3 | `automation.max_self_fix_attempts.maximum` |
+| Any field the contract does not declare | `additionalProperties: false` |
+
+The list above is a reading aid. The schema is the authority, and if the two
+disagree the schema wins.
+
+Two things a schema cannot check, because they are facts about the machine
+rather than about the payload. Check them yourself and ABORT with
+`STATUS: NEEDS_CONTEXT` on either:
+
+```bash
+test -d "<codebase_path>"                       # otherwise: codebase path not found
+git -C "<codebase_path>" rev-parse --abbrev-ref HEAD   # must equal <branch>
 ```
 
+**1.5 TDD Check (if `test_case_specs` is present):**
+
+If the task object contains `test_case_specs` (provided by `tests-creator`):
+1. Read each test file listed in `test_case_specs.test_files`
+2. Run the tests using `test_case_specs.run_command` — confirm they FAIL
+3. If tests pass already → report `DONE_WITH_CONCERNS` (tests may not be testing the right thing)
+4. Note: **implementation goal is to make these tests GREEN** — do not rewrite or delete them
+
+If `test_case_specs` is absent:
+- The task was not pre-processed by `tests-creator`
+- Write tests as part of Phase 4 (standard mode) following `tdd-workflow.mdc`
+
 ### Phase 2: RESEARCH
 
 Deep-read the target files and surrounding module to understand patterns.
@@ -112,19 +156,31 @@ Deep-read the target files and surrounding module to understand patterns.
 **2.0 Read job context (if available):**
 
 If the orchestrator provided `JOB_NAME` and `CONTEXT_PATH`:
-- Read `CONTEXT_PATH` (e.g., `.metaproject/jobs/<job-name>/ai/context.md`)
+- Read `CONTEXT_PATH` (e.g., `<JOBS_ROOT>/<job-name>/ai/context.md`)
 - Extract relevant sections: library docs, codebase patterns, conventions, best practices
 - Use this context throughout Phase 2-4 to guide implementation decisions
 - If the file does not exist, proceed without it — context is optional
 
+**2.0b Verify the project-skill covering the target (see `rules/core/skill-lifecycle.mdc`):**
+
+Before you rely on a project-skill's guidance, confirm it still matches the code:
+- `keryx skills route <target_file>` — find the project-skill for this module/entity (if any).
+- If one exists: `keryx skills verify <module>/<skill>` — classifies it `fresh | stale | needs-review | blocked`.
+- If it is **not `fresh`**: do not follow it blindly. Verify each claim against the code you read in Phase 2, and note the drift in `notes` (Phase 6.1) so the orchestrator can trigger `skills learn`.
+- If no skill exists for a non-trivial module you had to reverse-engineer, note that too — it's a candidate for `skills create`.
+
+This step is read-only and inline; do not spawn a subagent for it.
+
 **2.1 Read all target files:**
 - Read each file from `target_files` in full
 - If a file does not exist yet, note it as "new file to create"
 - Read the `context` field for additional type/signature info
 
 **2.2 Read existing tests and stories:**
-- If `existing_tests` is not "none" — read each test file
-- If `existing_stories` is not "none" — read each story file
+- `existing_tests` and `existing_stories` are arrays and default to `[]`
+  (`input-contract.schema.json`). Empty means none; the string `"none"` is not a
+  legal value and a request carrying it is refused by 1.4
+- Read each file listed in either array
 - Understand existing test patterns (describe/it structure, mocks, fixtures)
 
 **2.3 Read module neighbors:**
@@ -139,20 +195,33 @@ If the orchestrator provided `JOB_NAME` and `CONTEXT_PATH`:
 
 **2.4 Load relevant rules (from `module_patterns` or by detection):**
 
-Based on what you're implementing, load and follow the relevant project rules:
+Based on what you're implementing, load and follow the relevant project rules.
+
+**Always load (all task types):**
+- `tdd-workflow.mdc` — red-green-refactor, STATUS: DONE requires passing tests
+- `error-handling.mdc` — Result pattern, no silent failures
+- `solid-principles.mdc` — SRP, OCP, DIP (load for any task that creates new classes/services)
 
-| Task Type | Relevant Rules |
+**Load by task type:**
+
+| Task Type | Additional Rules |
 |-----------|---------------|
 | `ui_component` | `code-style-patterns.mdc`, `frontend-assistant.mdc`, `storybook-guidelines.mdc` |
 | `store_logic` | `code-style-patterns.mdc`, `mobx-store-template.mdc` |
-| `service_api` | `code-style-patterns.mdc`, `nestjs-dto.mdc` |
-| `fix` | Load rules based on the files being fixed |
-| `mixed` | Load all applicable rules |
+| `service_api` | `code-style-patterns.mdc`, `nestjs-dto.mdc`, `api-contracts.mdc` |
+| `fix` | Rules based on the files being fixed; always `error-handling.mdc` |
+| `mixed` | All applicable rules above |
+
+**Load when detected:**
+- Database/ORM files touched → `database-patterns.mdc`
+- Auth, API keys, user input → `security-baseline.mdc`
+- `async`/`await` or queue code → `async-patterns.mdc`
+- New architectural layers or modules → `clean-architecture.mdc`
 
-Rules are located at:
-- OpenCode: `.metaproject/rules/core/<rule>.mdc`
-- Cursor: `.cursor/rules/core/<rule>.mdc`
-- Codex: `.metaproject/rules/core/<rule>.mdc`
+Rules live at `.metaproject/rules/core/<rule>.mdc` on every harness — that is the
+one tree `keryx init` installs and the one every build of this skill reads.
+Cursor additionally mirrors them under `.cursor/rules/core/<rule>.mdc`; when both
+are present they are copies of the same file, so read either.
 
 **Output of Phase 2:** Mental model of the implementation:
 ```
@@ -204,14 +273,26 @@ CHANGE_PLAN:
 
 Execute the change plan. Write production-quality code.
 
-**4.1 Implementation order:**
+**4.0 TDD Mode Selection:**
+
+- **TDD Mode** (when `test_case_specs` is present): tests already exist and are RED. Skip to writing implementation code that makes them GREEN. Do NOT write new tests — only write code that satisfies the existing stubs.
+- **Standard Mode** (no `test_case_specs`): write tests first (per `tdd-workflow.mdc`), then implementation.
+
+**4.1 Implementation order (Standard Mode):**
 1. Types and interfaces first (shared types, DTOs)
-2. Service/API layer changes
-3. Store/logic layer changes
-4. Component/UI layer changes
-5. Tests
+2. Write failing tests for each acceptance criterion (RED)
+3. Service/API layer implementation (make service tests GREEN)
+4. Store/logic layer implementation (make store tests GREEN)
+5. Component/UI layer implementation (make component tests GREEN)
 6. Stories (if needed)
 
+**4.1 Implementation order (TDD Mode — test_case_specs provided):**
+1. Read all test stubs from `test_case_specs.test_files`
+2. Understand the expected API shape from test assertions
+3. Implement types/interfaces to satisfy test imports
+4. Implement code layer by layer until all tests are GREEN
+5. Stories (if needed)
+
 **4.2 Code standards (always follow):**
 - TypeScript strict mode — no `any`, no `as` casts unless justified
 - Use project path aliases for imports (`@components/...`, `@utils/...`)
@@ -258,28 +339,38 @@ Commit type mapping:
 Run verification checks appropriate to the task type.
 
 **5.1 Always run:**
+
 ```bash
-npm run lint              # ESLint (errors only)
-npm run type-check        # tsc --noEmit
+keryx health run --changed --source eslint,typescript
 ```
 
+Lint and type-check in one call, over the changed files only. Do NOT hard-code a
+package manager and a script name: the project may not be an npm project, and
+`src/health/sources/eslint.ts` and `src/health/sources/typescript.ts` resolve the
+real invocation. The run writes a normalized report; `keryx health status` prints
+it.
+
 **5.2 Run if tests exist:**
+
 ```bash
-npm test                  # Vitest run
+keryx test run --changed --strict
 ```
 
-If tests were created or modified, ensure they pass.
+`src/testing/service.ts:780` detects `bun` / `pnpm` / `yarn` / `npm` from the
+lockfile and builds the argv from the project's own test script — the
+if-chain you would otherwise write in shell, already written. `--strict` makes a
+non-zero exit the signal; if tests were created or modified they must pass.
 
-**5.3 Run if stories were created (optional, only if build is available):**
+**5.3 Run if stories were created (optional, only if the script exists):**
 ```bash
-npm run build-storybook   # Verify stories compile
+<pm> run build-storybook   # <pm> is the package manager keryx test run detected
 ```
 
 **5.4 Handle failures:**
 
 | Failure | Action |
 |---------|--------|
-| Lint errors | Fix automatically using `npm run lint:fix:changed`, re-run lint |
+| Lint errors | Fix them in code, re-run `keryx health run --changed` |
 | Type errors | Fix the type errors in code, re-commit |
 | Test failures | Fix failing tests, re-commit |
 | Story build failure | Fix story code, re-commit |
@@ -303,7 +394,9 @@ identical outputs cost the whole budget to learn what the second one already
 said. Report the block instead, naming what repeated.
 
 
-**ROLLBACK POLICY**: If implementation fatally fails (e.g. tests still failing after 3 attempts or unresolvable compilation errors), you MUST run `git reset --hard` to clean the worktree before reporting the failure in Phase 6, unless explicitly instructed to leave it dirty.
+**ROLLBACK POLICY**: If implementation fatally fails (tests still failing after 3 attempts, or unresolvable compilation errors), restore ONLY the files this task changed — `git checkout -- <your files>` for tracked ones, delete the untracked ones you created — then report the failure in Phase 6.
+
+**Never run `git reset --hard`, `git clean`, or any unscoped revert.** You do not own the worktree. `job-orchestrator` dispatches implementers in PARALLEL WAVES sharing a single worktree, so an unscoped reset destroys a wave-mate's uncommitted work — work that is not yours, cannot be recovered, and whose loss is invisible to you because the other agent's failure surfaces somewhere else entirely. If you cannot identify which files are yours, leave the tree exactly as it is and say so in the report: a dirty tree is recoverable, a destroyed one is not.
 
 **5.5 Re-commit fixes if any:**
 ```bash
@@ -316,10 +409,15 @@ task: <task_id>"
 
 ### Phase 6: REPORT
 
-Emit a JSON result object as the final message to the orchestrator.
+Write the full result to a file, then emit a compact STATUS response to the orchestrator.
 
-**Output structure:**
+**6.1 Write result file (when `JOB_NAME` is provided):**
 
+If the orchestrator provided `JOB_NAME` in the workspace context:
+```bash
+mkdir -p <JOBS_ROOT>/<JOB_NAME>/results
+```
+Write full JSON to `<JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json`:
 ```json
 {
   "task_id": "<task_id>",
@@ -336,30 +434,76 @@ Emit a JSON result object as the final message to the orchestrator.
   "test_result": "<pass|N passed, M failed: details|skipped>",
   "story_result": "<pass|build error: details|not applicable>",
   "acceptance_criteria_met": "<all|partial: list of unmet criteria|none>",
+  "skill_drift": "<none | stale: <module>/<skill> — <what diverged> | missing: <module> should have a project-skill>",
   "notes": "<any warnings, blockers, or additional context>"
 }
 ```
 
+Set `skill_drift` from Phase 2.0b: if the project-skill you used was not `fresh`, or the code you wrote diverged from what a skill documents, name the skill and the divergence. The orchestrator uses this to decide whether to trigger `skills learn` (do NOT run `learn` yourself — it is a mutating step the orchestrator dispatches; see `rules/core/skill-lifecycle.mdc`).
+
+Then check the shape and record the file — two commands, both of which refuse
+rather than warn:
+
+```bash
+keryx skills contracts validate <JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json \
+  --schema task-implementer-output
+keryx job document <JOB_NAME> --type implementation-report \
+  --file <JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json
+```
+
+- `contracts validate` exits non-zero on a missing required field, a `status`
+  outside `success|partial|failed`, a `task_id` that is not `task-<n>`, or any
+  key the contract does not declare (`additionalProperties: false`). Fix the
+  result and re-run; do not report a result the contract rejects.
+- `job document` **refuses when the file does not exist** — "`--file` not found:
+  … Write the document first, then record it" (`src/job/service.ts`) — and
+  refuses a `--type` outside `analysis|implementation-report|review|verification-report`
+  and a job name no package matches. On success it copies the result into the
+  job package and appends it to `documentation.documents_created` in
+  `state.json`, which is what makes "the result was recorded" a fact
+  `keryx job status <JOB_NAME> --json` can be asked about instead of a sentence
+  in this file.
+
+One caveat, stated because it is real: the package holds ONE
+`implementation-report.json` per job, so a later task in the same wave replaces
+it. The per-task files under `results/` are the complete set; the recorded
+document is the most recent.
+
+If `JOB_NAME` is not provided, skip the file write and both commands — there is
+no job package to record against.
+
+The step's own status is the orchestrator's to write (`keryx job step <JOB_NAME>
+<step-id> --status …`). Do not write it yourself: `src/job/plans.ts` makes
+`implement` ONE step for a whole wave, so a single task cannot close it, and
+`keryx job complete` refuses while any step is still open.
+
+**6.2 Emit compact STATUS response:**
+
+Return a compact STATUS response following `rules/core/subagent-status-protocol.md`.
+**Do NOT include the full JSON block inline** — the orchestrator reads the result file when it needs details.
+The inline response must contain only: STATUS line + Completed bullets + Files changed + Verification summary.
+
 **Status classification:**
-- `success`: All acceptance criteria met, all verifications pass
-- `partial`: Some criteria met or some verification failures after self-fix attempts
-- `failed`: Critical blockers prevented implementation. Worktree must be reverted via `git reset --hard`.
+- `success` → `STATUS: DONE`
+- `partial` → `STATUS: DONE_WITH_CONCERNS`
+- `failed` → `STATUS: BLOCKED`
 
 ---
 
 ## Automation Settings
 
-This skill is designed to run fully autonomously. The following settings control behavior:
+This skill is designed to run fully autonomously. The settings, their types,
+their defaults and their bounds are declared in one place —
+`input-contract.schema.json`, the `automation` object — and are checked by the
+validation in Phase 1.4. To see them:
 
-| Setting | Default | Options | Description |
-|---------|---------|---------|-------------|
-| `auto_commit` | `true` | true/false | Automatically commit changes |
-| `verify_lint` | `true` | true/false | Run ESLint after implementation |
-| `verify_types` | `true` | true/false | Run type-check after implementation |
-| `verify_tests` | `true` | true/false | Run tests after implementation |
-| `verify_stories` | `false` | true/false | Build storybook to verify stories |
-| `max_self_fix_attempts` | `3` | 1-5 | Max attempts to fix verification failures |
-| `commit_message_style` | `conventional` | `conventional` | Commit format |
+```bash
+keryx skills contracts list          # names task-implementer-input and its file
+```
+
+They are deliberately not restated here. The table that used to sit in this spot
+said `max_self_fix_attempts: 1-5` while Phase 5.4 says the maximum is 3, and a
+second copy of a schema is how that happens.
 
 ---
 
@@ -388,7 +532,108 @@ This skill is designed to run fully autonomously. The following settings control
 7. **DO** use `runInAction()` after every `await` in MobX actions.
 8. **DO** commit with conventional commit format referencing the issue number.
 9. **DO** verify your work before reporting.
-10. Return the JSON result object as your **final message** to the orchestrator.
+10. **DO** make `STATUS: <TOKEN>` the first line of your final message, and put no
+    JSON in the response body. The full JSON result is the file Phase 6.1 writes
+    and records. (This rule used to say the opposite — "return the JSON result
+    object as your final message" — which contradicted 6.2, `## Reporting
+    Results`, and `parseChildResult`, the production function that throws on any
+    first line that is not a canonical STATUS token.)
+
+---
+
+## Red Flags — Stop and re-read this skill if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "I'll implement first and verify acceptance criteria later" | Implementing without criteria means you might build the wrong thing correctly |
+| "This is a small change, I don't need to read the context document" | Context documents exist because the task description alone is incomplete by design |
+| "The task description is clear, I don't need to read related files first" | Module patterns and conventions only emerge from reading the actual files, not the description |
+| "I'll report DONE and note the skipped tests as a concern" | Skipped verification is a failed verification — partial is not done |
+| "I understand how this module works from previous tasks" | Each task targets a specific slice; read the files fresh to catch state that has changed |
+
+**IRON LAW: READ ALL SPECIFIED FILES AND THE CONTEXT DOCUMENT BEFORE WRITING A SINGLE LINE OF CODE.**
+
+---
+
+## Reporting Results
+
+**Rule:** `rules/core/subagent-status-protocol.md`
+
+Every final response to the orchestrator MUST begin with `STATUS: <STATUS>`. The full JSON result object is written to a file in Phase 6.1 — the inline response contains only the compact STATUS format. No JSON in the response body.
+
+### Iron Law
+
+**STATUS LINE IS MANDATORY — ORCHESTRATOR CANNOT INTERPRET FREE TEXT**
+
+### When to use each status
+
+| Status | Use when |
+|--------|----------|
+| `DONE` | All acceptance criteria met, all verifications pass (or pass after self-fix) |
+| `DONE_WITH_CONCERNS` | Task complete but: criteria required interpretation, workaround was used, unexpected discovery, verification passed with warnings |
+| `BLOCKED` | Unresolvable blocker: required file missing after checking, unresolvable type errors after 3 attempts, branch conflict needing orchestrator action |
+| `NEEDS_CONTEXT` | Task input is incomplete: `target_files` empty, `acceptance_criteria` uses undefined terms, `context` field missing required types |
+
+### Correct final response format
+
+```
+STATUS: DONE
+
+## Completed
+- Added validation logic to PipelineStep component
+- Created unit tests covering all 4 acceptance criteria
+- Committed 2 conventional commits
+
+## Files changed
+- src/components/PipelineStep.tsx — added validateStep() method
+- src/components/PipelineStep.test.tsx — new test file, 14 tests
+
+## Verification
+- lint: pass
+- type-check: pass
+- tests: 14 passed, 0 failed
+
+Result file: <JOBS_ROOT>/<job-name>/results/task-1.json
+```
+
+For `DONE_WITH_CONCERNS`:
+
+```
+STATUS: DONE_WITH_CONCERNS
+
+## Completed
+- Implemented feature as described
+
+## Files changed
+- src/services/auth.ts — updated token refresh logic
+
+## Verification
+- lint: pass
+- type-check: pass
+- tests: 8 passed, 0 failed
+
+## Concerns for orchestrator
+- The acceptance criterion "support legacy tokens" was ambiguous — implemented support for both v1 and v2 token formats. If only v2 is needed, the v1 branch can be removed.
+
+Result file: <JOBS_ROOT>/<job-name>/results/task-2.json
+```
+
+For `BLOCKED`:
+
+```
+STATUS: BLOCKED
+
+## Reason
+src/types/pipeline.ts does not exist and is listed as a dependency. Cannot implement the store layer without the type definitions.
+
+## What I need from orchestrator
+Run task-1 (which creates pipeline.ts) before re-dispatching this task, or provide the type definitions directly.
+
+## Work completed so far
+- (nothing — blocked before implementation could start)
+```
+
+See `rules/core/subagent-status-protocol.md` for the full format specification. Four statuses are yours as a skill worker; the fifth, `FAILED`, belongs to harness child workers and you must never emit it — report `BLOCKED` instead.
 
 ---
 
@@ -398,7 +643,7 @@ When dispatched by `job-orchestrator`, the prompt MAY include:
 
 ```
 JOB_NAME:     <job-name>
-CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
+CONTEXT_PATH: <JOBS_ROOT>/<job-name>/ai/context.md
 ```
 
 If provided, read the context document at the start of Phase 2 (RESEARCH) before reading target files. The context document contains:

package/src/gdskills/bundled/skills/orchestration/task-implementer/input-contract.schema.json

@@ -2,20 +2,22 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "task-implementer-input-contract",
   "title": "Task Implementer Input Contract",
-  "description": "Defines all input parameters required to run task-implementer skill autonomously. Receives a single Gherkin Scenario from issue-analyzer plus workspace context.",
+  "description": "Defines all input parameters required to run task-implementer skill autonomously. Receives one atomic task object from issue-analyzer plus workspace context. Registered as contract `task-implementer-input`: validate a request with `keryx skills contracts validate <request.json> --schema task-implementer-input`.",
   "type": "object",
+  "additionalProperties": false,
   "required": ["task", "workspace", "automation"],
   "properties": {
     "task": {
       "type": "object",
-      "description": "The atomic task to implement, extracted from issue-analyzer Gherkin Scenario.",
+      "description": "The atomic task to implement, as issue-analyzer decomposed it.",
+      "additionalProperties": false,
       "required": ["task_id", "task_name", "task_type", "description", "target_files", "acceptance_criteria"],
       "properties": {
         "task_id": {
           "type": "string",
-          "pattern": "^task-\\d+$",
-          "description": "Unique task identifier from issue-analyzer",
-          "examples": ["task-1", "task-3"]
+          "pattern": "^(?:task|fix)-\\d+$",
+          "description": "Unique task identifier. `fix-<n>` is legal because orchestrator-prompt.md Step 4 builds exactly that for a fix round; the pattern was `^task-\\d+$`, so every fix dispatch this skill documents was one the contract would have refused.",
+          "examples": ["task-1", "task-3", "fix-1"]
         },
         "task_name": {
           "type": "string",
@@ -78,12 +80,31 @@
         "module_patterns": {
           "type": "string",
           "description": "Notes on how similar code is written in the module"
+        },
+        "test_case_specs": {
+          "type": "object",
+          "description": "RED-phase test stubs already written and committed by tests-creator. Present => TDD Mode (SKILL.md Phase 4.0): the implementer makes these GREEN and writes no new tests.",
+          "additionalProperties": false,
+          "required": ["test_files", "run_command"],
+          "properties": {
+            "test_files": {
+              "type": "array",
+              "items": { "type": "string" },
+              "minItems": 1,
+              "description": "Test files that must be failing when the task starts"
+            },
+            "run_command": {
+              "type": "string",
+              "description": "Command that runs exactly those test files"
+            }
+          }
         }
       }
     },
     "workspace": {
       "type": "object",
       "description": "Workspace context managed by the orchestrator.",
+      "additionalProperties": false,
       "required": ["codebase_path", "branch", "issue_number"],
       "properties": {
         "codebase_path": {
@@ -104,17 +125,28 @@
         "issue_title": {
           "type": "string",
           "description": "GitHub issue title for context"
+        },
+        "job_name": {
+          "type": "string",
+          "description": "Job package slug, when the dispatch came from job-orchestrator. Phase 6.1 records its result against this name with `keryx job document <job_name> --type implementation-report --file <path>`; absent, Phase 6.1 skips the file write.",
+          "examples": ["issue-4141--pipeline-validation"]
+        },
+        "context_path": {
+          "type": "string",
+          "description": "Job context document read at the start of Phase 2, e.g. .metaproject/jobs/<job_name>/ai/context.md"
         }
       }
     },
     "fix_context": {
       "type": "object",
       "description": "Present only for fix tasks dispatched from review loop.",
+      "additionalProperties": false,
       "properties": {
         "review_feedback": {
           "type": "array",
           "items": {
             "type": "object",
+            "additionalProperties": false,
             "required": ["file", "severity", "message"],
             "properties": {
               "file": {
@@ -137,28 +169,33 @@
               "reviewer": {
                 "type": "string",
                 "description": "Which review skill found this",
-                "examples": ["code-ai-review", "code-boss-review", "code-style-review"]
+                "examples": ["code-ai-review", "code-learned-review", "code-style-review"]
               }
             }
           },
           "description": "Structured findings from review skills"
         },
-        "original_task_id": {
-          "type": "string",
-          "pattern": "^task-\\d+$",
-          "description": "The task that introduced the issues"
+        "original_task_ids": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "pattern": "^task-\\d+$"
+          },
+          "minItems": 1,
+          "description": "The tasks that introduced the findings. Plural because a fix round collects findings across a whole wave — orchestrator-prompt.md Step 4 has always sent an array, while this field was named `original_task_id` and typed as one string, so the two could never agree."
         },
         "iteration": {
           "type": "integer",
           "minimum": 1,
-          "maximum": 2,
-          "description": "Fix iteration number (max 2)"
+          "maximum": 3,
+          "description": "Fix iteration number. Three, the same bound `flow-orchestrator`, `job-orchestrator` and SKILL.md Phase 5.4 carry and `src/gdskills/round-bound.test.ts` pins; it was 2 here, a fourth disagreeing repair bound."
         }
       }
     },
     "automation": {
       "type": "object",
-      "description": "Controls for autonomous execution.",
+      "description": "Controls for autonomous execution. This object is the ONLY definition of the automation settings — SKILL.md points here rather than restating the defaults.",
+      "additionalProperties": false,
       "required": ["skip_confirmation"],
       "properties": {
         "skip_confirmation": {
@@ -194,9 +231,14 @@
         "max_self_fix_attempts": {
           "type": "integer",
           "minimum": 1,
-          "maximum": 5,
+          "maximum": 3,
           "default": 3,
-          "description": "Max attempts to fix verification failures"
+          "description": "Max attempts to fix verification failures. Bounded at 3, not 5: SKILL.md Phase 5.4 states an absolute \"Maximum 3 self-fix attempts per verification step\" and cites the evidence for it, so a request asking for 4 was asking for something the skill refuses to do."
+        },
+        "commit_message_style": {
+          "type": "string",
+          "const": "conventional",
+          "description": "Commit format. One value: SKILL.md Phase 4.5 documents the conventional form and no other."
         }
       }
     }