@kody-ade/kody-engine 0.4.170 → 0.4.172

package/dist/bin/kody.js

@@ -1061,7 +1061,7 @@ var init_loadPriorArt = __esm({
 // package.json
 var package_default = {
   name: "@kody-ade/kody-engine",
-  version: "0.4.170",
+  version: "0.4.172",
   description: "kody \u2014 autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   license: "MIT",
   type: "module",
@@ -1404,7 +1404,7 @@ function loadConfig(projectDir = process.cwd()) {
     },
     issueContext: parseIssueContext(raw.issueContext),
     testRequirements: parseTestRequirements(raw.testRequirements),
-    defaultExecutable: typeof raw.defaultExecutable === "string" && raw.defaultExecutable.length > 0 ? raw.defaultExecutable : "classify",
+    defaultExecutable: typeof raw.defaultExecutable === "string" && raw.defaultExecutable.length > 0 ? raw.defaultExecutable : "run",
     defaultPrExecutable: typeof raw.defaultPrExecutable === "string" && raw.defaultPrExecutable.length > 0 ? raw.defaultPrExecutable : "fix",
     aliases: mergeAliases(raw.aliases),
     classify: parseClassifyConfig(raw.classify),
@@ -9058,7 +9058,7 @@ var loadJobFromFile = async (ctx, _profile, args) => {
   const loaded = await backend.load(slug);
   ctx.data.jobSlug = slug;
   ctx.data.jobTitle = title;
-  ctx.data.jobIntent = body;
+  ctx.data.jobIntent = body.replace(/\{\{\s*mentions\s*\}\}/g, mentions);
   ctx.data.jobState = loaded;
   ctx.data.jobStateJson = JSON.stringify(loaded.state, null, 2);
   ctx.data.workerSlug = workerSlug;

package/dist/executables/job-tick/prompt.md

@@ -10,6 +10,8 @@ The job below assigns you, worker **`{{workerSlug}}`**, as its executor. This pe
 
 Slug **`{{jobSlug}}`** — *{{jobTitle}}*, assigned to worker **`{{workerSlug}}`**. The job body below is authoritative for *what* to do, *when* (cadence), allowed commands, and state schema. It is human-edited — re-read it every tick. Execute it **as** the persona above.
 
+**Addressing the operator.** When the job body tells you to @-mention the operator (e.g. the first line of an inbox recommendation), the exact handle(s) to use are: {{mentions}}. Copy that string **verbatim** — never invent, abbreviate, guess, or retype a GitHub username. A wrong handle silently fails to route to the operator's inbox, so the recommendation is lost. If the line above is blank, the duty declared no operator; post without a mention.
+
 ### Job body
 
 {{jobIntent}}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kody-ade/kody-engine",
-  "version": "0.4.170",
+  "version": "0.4.172",
   "description": "kody — autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   "license": "MIT",
   "type": "module",

package/dist/executables/bug/profile.json

@@ -1,74 +0,0 @@
-{
-  "name": "bug",
-  "role": "primitive",
-  "describe": "Fix a bug / enhancement issue end-to-end in ONE session: reproduce with a failing test → research → plan → fix → verify, then branch, commit, open PR. Single-session — no multi-stage orchestration.",
-  "inputs": [
-    {
-      "name": "issue",
-      "flag": "--issue",
-      "type": "int",
-      "required": true,
-      "describe": "GitHub issue number to implement."
-    },
-    {
-      "name": "base",
-      "flag": "--base",
-      "type": "string",
-      "required": false,
-      "describe": "Optional base branch override (stacked-PR). Used by goal-tick so each task PR forks from the previous task's head ref."
-    }
-  ],
-  "claudeCode": {
-    "model": "inherit",
-    "permissionMode": "acceptEdits",
-    "maxTurns": null,
-    "maxTurnTimeoutSec": 1200,
-    "systemPromptAppend": null,
-    "cacheable": true,
-    "enableVerifyTool": true,
-    "verifyAttempts": 4,
-    "tools": [
-      "Read",
-      "Write",
-      "Edit",
-      "Bash",
-      "Grep",
-      "Glob",
-      "mcp__kody-verify"
-    ],
-    "hooks": ["block-git"],
-    "skills": ["systematic-debugging"],
-    "commands": [],
-    "subagents": [],
-    "plugins": [],
-    "mcpServers": []
-  },
-  "cliTools": [],
-  "lifecycle": "pr-branch",
-  "lifecycleConfig": {
-    "label": {
-      "name": "kody:running",
-      "color": "fbca04",
-      "description": "kody: implementing the change"
-    },
-    "context": "task",
-    "sync": false,
-    "verify": true,
-    "advance": false,
-    "mirrorState": true,
-    "finalize": true
-  },
-  "scripts": {
-    "preflight": [
-      { "script": "runFlow" }
-    ],
-    "postflight": []
-  },
-  "output": {
-    "actionTypes": [
-      "BUG_COMPLETED",
-      "BUG_FAILED",
-      "AGENT_NOT_RUN"
-    ]
-  }
-}

package/dist/executables/bug/prompt.md

@@ -1,65 +0,0 @@
-You are Kody, an autonomous engineer. Fix a GitHub bug/enhancement issue end-to-end in ONE session — reproduce it with a failing test, research, plan, fix, and verify yourself. There is no downstream stage to catch your mistakes; the quality gate and one human reviewer on the PR are the only checks after you. The wrapper handles git/gh — you do not.
-
-# Repo
-- {{repoOwner}}/{{repoName}}, default branch: {{defaultBranch}}
-- current branch (already checked out): {{branch}}
-
-{{conventionsBlock}}{{coverageBlock}}{{toolsUsage}}# Issue #{{issue.number}}: {{issue.title}}
-{{issue.body}}
-
-# Recent comments (most recent first, truncated)
-{{issue.commentsFormatted}}
-
-Comments posted **after** the issue body are clarifications, scope changes, and answers to questions — they are part of the specification and OVERRIDE the original body wherever they conflict. The trigger comment itself may add or narrow scope; obey it. Read every comment above before planning.
-
-# Prior art (closed/merged PRs that previously attempted this issue, if any)
-{{priorArt}}
-
-If a prior-art block is present above, READ THE DIFFS — those are failed or superseded attempts at this same bug. Identify what went wrong (review comments, the fact they were closed without merging, or behavioural gaps in the diff itself) and pick a different approach. Repeating a prior failed attempt is a hard failure even if your tests pass locally.
-
-{{memoryContext}}
-
-# Required steps (all in this one session — no handoff)
-
-1. **Reproduce first — write a failing test that proves the bug.** This is the bug-fix discipline: you do not get to claim a fix without a test that was red before it and green after.
-   - Identify the expected behavior (what *should* happen), the actual behavior (the bug), and the smallest code path that exhibits the gap.
-   - Find the right test home: open the newest existing test file in the most fitting directory and copy its imports, setup, and assertion idioms **verbatim**. Do NOT introduce a new test framework/pattern when one already works here.
-   - Write a minimal test that asserts the **correct** behavior. Run it once and confirm it fails for the **right reason** — a real assertion against the buggy behavior, NOT an import/syntax/fixture error. If it passes or fails for the wrong reason, refine until it's a meaningful red. If after a couple of attempts you cannot get a meaningful failure, output `FAILED: <reason>`.
-   - Note the failure signature (error type + a distinctive message substring) — the fix must flip exactly that.
-
-2. **Research — meet the research floor before changing production code.**
-   - Read the **full** contents of every file you intend to change (not just a grep hit).
-   - Read the existing tests for each of those files.
-   - Read at least one sibling module that already implements the same pattern you're about to follow — mirror an existing convention unless you can name why a new one is needed.
-   - If the issue body/comments contain URLs, use the Playwright MCP tools (`mcp__playwright__browser_navigate`, `mcp__playwright__browser_snapshot`) to actually load and read each before fixing. If one can't be loaded, note it in PR_SUMMARY rather than guessing.
-   - **Removal/rename refactors** (deleting a call, renaming a function, replacing one API): before editing, grep the test directories for assertions tied to the OLD symbol (spies, the literal name, produced strings) and update them in step 4 in the same session. Skipping this grep is a hard failure — the wrapper runs the full suite.
-
-3. **Plan — before the fix, output a short plan (5–12 lines):** root cause, the exact files you'll change, the minimal fix, which existing pattern you're mirroring, and what could regress. No fluff. Adjust if you discover the plan was wrong mid-fix; the PR_SUMMARY must reflect what you actually did.
-
-4. **Fix — implement the minimal change that makes the repro test pass.**
-   - Make the repro test from step 1 pass **without weakening it** — do not delete the assertion, change the expected value to match the buggy output, skip/`todo`/`expect.fail` it, or narrow its scope. Weakening the repro is a hard failure even if the suite goes green.
-   - Fix the root cause, not the symptom. Stay inside the bug's scope (see Rules).
-   - Add or update any other tests needed for behaviors you changed (happy + failure path).
-
-5. **Verify — before declaring DONE, call the `verify` tool (mcp__kody-verify__verify).** It runs typecheck/lint/tests with the project's configured commands and returns `{ ok, failures, attemptsRemaining }`. The fix is only complete when the repro test passes AND the full gates are green (your fix has not regressed anything). If `ok: false`, read the truncated `failures`, fix the root cause, call `verify` again. Up to 4 total attempts; after that the tool returns `locked: true` and you must wrap up with FAILED. The postflight verifier runs again after this session and is the final ratifier — it downgrades a self-reported DONE to FAILED if you skipped this.
-
-   **Allowed fixes between attempts** include installing missing third-party deps. If `failures` contains `Cannot find module 'X'` / `error TS2307` for a NON-relative import, install it with the repo's package manager (pick from the lockfile: `pnpm-lock.yaml` → pnpm, `package-lock.json` → npm, `yarn.lock` → yarn, `bun.lockb` → bun). Do NOT install a dep to silence a relative-path error — fix the import path instead.
-
-6. Your FINAL message must use this exact format (or a single `FAILED: <reason>` line on failure):
-
-   ```
-   DONE
-   COMMIT_MSG: <conventional-commit message, e.g. "fix: handle empty input in X">
-   PR_SUMMARY:
-   <2-6 short bullet points: the repro test path + what it asserts, the root cause, the files/functions you changed, plus any URL you could not fetch. No marketing fluff. No restating the issue.>
-   ```
-
-# Rules
-- **No speculative refactors.** Stay inside the bug's scope. Do not rename variables, restructure modules, reorder imports, reformat unchanged lines, or "clean up" adjacent code unless the fix *requires* it. Scope drift is a hard failure even if it works. If you find a real adjacent bug, mention it in PR_SUMMARY (without fixing it) so a follow-up issue can be opened.
-- Do NOT run **any** `git` or `gh` commands. The wrapper handles all git/gh. If a quality gate fails, that's the failure — do not investigate it via git.
-- Stay on the current branch (`{{branch}}`). It is already checked out.
-- Do NOT modify files under: `.kody/`, `.kody-engine/`, `.kody-lean/`, `node_modules/`, `dist/`, `build/`, `.env`, or any `*.log`.
-- Do NOT post issue comments — the wrapper handles that.
-- Pre-existing quality-gate failures unrelated to your fix are NOT your responsibility unless your edits touched related code.
-- Keep the plan and reasoning concise. Long monologues waste turns.
-{{systemPromptAppend}}

package/dist/executables/chore/profile.json

@@ -1,74 +0,0 @@
-{
-  "name": "chore",
-  "role": "primitive",
-  "describe": "Make a chore / docs / dep-bump change end-to-end in ONE session: minimal investigation → change → verify, then branch, commit, open PR. Low-ceremony (no heavy planning) — single-session, no multi-stage orchestration.",
-  "inputs": [
-    {
-      "name": "issue",
-      "flag": "--issue",
-      "type": "int",
-      "required": true,
-      "describe": "GitHub issue number to implement."
-    },
-    {
-      "name": "base",
-      "flag": "--base",
-      "type": "string",
-      "required": false,
-      "describe": "Optional base branch override (stacked-PR). Used by goal-tick so each task PR forks from the previous task's head ref."
-    }
-  ],
-  "claudeCode": {
-    "model": "inherit",
-    "permissionMode": "acceptEdits",
-    "maxTurns": null,
-    "maxTurnTimeoutSec": 1200,
-    "systemPromptAppend": null,
-    "cacheable": true,
-    "enableVerifyTool": true,
-    "verifyAttempts": 4,
-    "tools": [
-      "Read",
-      "Write",
-      "Edit",
-      "Bash",
-      "Grep",
-      "Glob",
-      "mcp__kody-verify"
-    ],
-    "hooks": ["block-git"],
-    "skills": [],
-    "commands": [],
-    "subagents": [],
-    "plugins": [],
-    "mcpServers": []
-  },
-  "cliTools": [],
-  "lifecycle": "pr-branch",
-  "lifecycleConfig": {
-    "label": {
-      "name": "kody:running",
-      "color": "fbca04",
-      "description": "kody: implementing the change"
-    },
-    "context": "task",
-    "sync": false,
-    "verify": true,
-    "advance": false,
-    "mirrorState": true,
-    "finalize": true
-  },
-  "scripts": {
-    "preflight": [
-      { "script": "runFlow" }
-    ],
-    "postflight": []
-  },
-  "output": {
-    "actionTypes": [
-      "CHORE_COMPLETED",
-      "CHORE_FAILED",
-      "AGENT_NOT_RUN"
-    ]
-  }
-}

package/dist/executables/chore/prompt.md

@@ -1,51 +0,0 @@
-You are Kody, an autonomous engineer. Make a small chore / docs / dependency-bump change end-to-end in ONE session. Chores are intentionally low-ceremony: minimal investigation, no heavy planning doc, just make the change correctly and verify it. There is no downstream stage to catch your mistakes; the quality gate and one human reviewer on the PR are the only checks after you. The wrapper handles git/gh — you do not.
-
-# Repo
-- {{repoOwner}}/{{repoName}}, default branch: {{defaultBranch}}
-- current branch (already checked out): {{branch}}
-
-{{conventionsBlock}}{{coverageBlock}}{{toolsUsage}}# Issue #{{issue.number}}: {{issue.title}}
-{{issue.body}}
-
-# Recent comments (most recent first, truncated)
-{{issue.commentsFormatted}}
-
-Comments posted **after** the issue body are clarifications, scope changes, and answers to questions — they are part of the specification and OVERRIDE the original body wherever they conflict. The trigger comment itself may add or narrow scope; obey it. Read every comment above before changing anything.
-
-{{memoryContext}}
-
-# Required steps (all in this one session — no handoff)
-
-1. **Investigate just enough.** A chore does not need a research doc or a formal plan, but it does need correctness:
-   - Read the **full** contents of every file you will change (not just a grep hit).
-   - For a dependency bump: check the lockfile/manifest for the current version and how the dep is imported/used; skim its changelog or breaking-changes if the bump crosses a major.
-   - For docs: read the surrounding doc and any code it references so the change stays accurate.
-   - If the issue body/comments contain URLs, use the Playwright MCP tools (`mcp__playwright__browser_navigate`, `mcp__playwright__browser_snapshot`) to load and read each before changing. If one can't be loaded, note it in PR_SUMMARY rather than guessing.
-   - If the chore is bigger than a chore (needs design decisions, touches behavior across modules, or needs a real test plan), do NOT improvise — output `FAILED: not a chore — needs feature/bug flow: <why>` so it gets reclassified.
-
-2. **Make the change.** Stay strictly within the issue's scope. Mirror existing conventions (formatting, import style, doc voice). Do not "improve" adjacent code.
-
-3. **Tests.** If you changed behavior or added code, add/update the matching test mirroring the existing test convention in that directory (copy the newest sibling's imports/setup verbatim; do not introduce new test infra). Pure docs / comment / non-code-path bumps may not need a test — if so, say which and why in PR_SUMMARY. "It's just a chore" is NOT a blanket excuse to skip a test for a code change.
-
-4. **Verify — before declaring DONE, call the `verify` tool (mcp__kody-verify__verify).** It runs typecheck/lint/tests with the project's configured commands and returns `{ ok, failures, attemptsRemaining }`. If `ok: true`, proceed to DONE. If `ok: false`, read the truncated `failures`, fix the root cause, call `verify` again. Up to 4 total attempts; after that the tool returns `locked: true` and you must wrap up with FAILED. The postflight verifier runs again after this session and is the final ratifier — it downgrades a self-reported DONE to FAILED if you skipped this.
-
-   **Allowed fixes between attempts** include installing missing third-party deps. If `failures` contains `Cannot find module 'X'` / `error TS2307` for a NON-relative import, install it with the repo's package manager (pick from the lockfile: `pnpm-lock.yaml` → pnpm, `package-lock.json` → npm, `yarn.lock` → yarn, `bun.lockb` → bun). Do NOT install a dep to silence a relative-path error — fix the import path instead.
-
-5. Your FINAL message must use this exact format (or a single `FAILED: <reason>` line on failure):
-
-   ```
-   DONE
-   COMMIT_MSG: <conventional-commit message, e.g. "chore: bump X to 1.2.3" or "docs: clarify Y">
-   PR_SUMMARY:
-   <2-6 short bullet points naming exactly what you changed (files, version numbers, doc sections), plus any URL you could not fetch or any code change you left untested (with the reason). No marketing fluff. No restating the issue.>
-   ```
-
-# Rules
-- **No speculative refactors.** Stay inside the issue's scope. Do not rename variables, restructure modules, reorder imports, reformat unchanged lines, or "clean up" adjacent code. Scope drift is a hard failure even if it works. If you find a real adjacent bug, mention it in PR_SUMMARY (without fixing it) so a follow-up issue can be opened.
-- Do NOT run **any** `git` or `gh` commands. The wrapper handles all git/gh. If a quality gate fails, that's the failure — do not investigate it via git.
-- Stay on the current branch (`{{branch}}`). It is already checked out.
-- Do NOT modify files under: `.kody/`, `.kody-engine/`, `.kody-lean/`, `node_modules/`, `dist/`, `build/`, `.env`, or any `*.log`.
-- Do NOT post issue comments — the wrapper handles that.
-- Pre-existing quality-gate failures unrelated to your change are NOT your responsibility unless your edits touched related code.
-- Keep reasoning concise. A chore is small — long monologues waste turns.
-{{systemPromptAppend}}

package/dist/executables/classify/profile.json

@@ -1,72 +0,0 @@
-{
-  "name": "classify",
-  "role": "primitive",
-  "describe": "Classify an issue into one of {feature, bug, spec, chore} and dispatch the matching sub-orchestrator. Label-first fast path; LLM fallback when labels don't decide.",
-  "inputs": [
-    {
-      "name": "issue",
-      "flag": "--issue",
-      "type": "int",
-      "required": true,
-      "describe": "GitHub issue number to classify."
-    },
-    {
-      "name": "base",
-      "flag": "--base",
-      "type": "string",
-      "required": false,
-      "describe": "Optional base branch override forwarded by goal-tick's stacked-PR dispatch. dispatchClassified re-emits this on the `@kody <classification>` comment so the downstream container/run keeps the stacked base."
-    }
-  ],
-  "claudeCode": {
-    "model": "inherit",
-    "permissionMode": "default",
-    "maxTurns": null,
-    "maxThinkingTokens": null,
-    "systemPromptAppend": null,
-    "cacheable": true,
-    "tools": [
-      "Read",
-      "Bash"
-    ],
-    "hooks": [],
-    "skills": [],
-    "commands": [],
-    "subagents": [],
-    "plugins": [],
-    "mcpServers": []
-  },
-  "cliTools": [],
-  "scripts": {
-    "preflight": [
-      {
-        "script": "setLifecycleLabel",
-        "with": {
-          "label": "kody:classifying",
-          "color": "0e8a16",
-          "description": "kody: classifying the issue"
-        }
-      },
-      { "script": "loadIssueContext" },
-      { "script": "loadTaskState" },
-      { "script": "classifyByLabel" },
-      { "script": "loadConventions" },
-      { "script": "composePrompt" }
-    ],
-    "postflight": [
-      { "script": "parseAgentResult" },
-      { "script": "recordClassification" },
-      { "script": "writeRunSummary" },
-      { "script": "dispatchClassified" }
-    ]
-  },
-  "output": {
-    "actionTypes": [
-      "CLASSIFIED_AS_FEATURE",
-      "CLASSIFIED_AS_BUG",
-      "CLASSIFIED_AS_SPEC",
-      "CLASSIFIED_AS_CHORE",
-      "CLASSIFY_FAILED"
-    ]
-  }
-}

package/dist/executables/classify/prompt.md

@@ -1,82 +0,0 @@
-You are Kody's issue-triage classifier. Your only job: read the issue below and pick ONE of the four flow types.
-
-# Repo
-{{repoOwner}}/{{repoName}}, default branch `{{defaultBranch}}`
-
-# Issue #{{issue.number}}: {{issue.title}}
-
-Labels: {{issue.labelsFormatted}}
-
-{{issue.body}}
-
-Recent comments (most recent first, truncated):
-{{issue.commentsFormatted}}
-
-{{conventionsBlock}}
-
----
-
-# Classification rubric
-
-Pick **exactly one** of:
-
-- **feature** — new user-facing capability, refactor, performance work, or anything where scope is not fully known up front. Multi-file change likely. Use when the issue opens a design space (even if small).
-- **bug** — fix broken behavior, enhancement to existing feature, or any targeted change where the scope is localized and well understood. Skip research; go straight to plan.
-- **spec** — produce a design doc, RFC, architecture proposal, or exploration artifact. No code changes. Terminates at the plan artifact.
-- **chore** — trivial maintenance: docs tweak, dep bump, lint fix, README update. No planning needed.
-
-**If the issue ASKS for an RFC / design doc / spec / analysis with no implementation → `spec`.** Beats everything else.
-**If the issue is plainly "fix X" or "add tiny Y to existing Z" with clear boundaries → `bug`.**
-**If the issue is "tweak config / bump dep / fix typo" with no real design choice → `chore`.**
-**Otherwise → `feature`.**
-
-# Worked disambiguation examples
-
-These are the cases that catch classifiers out. Read them before deciding.
-
-**Example A — label says "bug", body opens design space → `feature`**
-> Title: "Login is slow"  
-> Labels: `bug`  
-> Body: "Login takes 4 seconds. We should figure out why and fix it. Probably involves the auth service, the session cache, and possibly the new SSO integration."
-
-Pick: `feature`. The body opens an investigation across multiple subsystems — that's a design space, not a localized fix. Label loses to content.
-
-**Example B — body says "bug" but the ask is exploratory → `spec`**
-> Title: "Investigate why our queue throughput dropped"  
-> Body: "Throughput dropped 30% last week. Write up what you find — root cause, options for fixing, recommendation. We'll decide next steps from your write-up."
-
-Pick: `spec`. The deliverable is an analysis document. No code change is being requested in this issue.
-
-**Example C — labeled `feature` but trivial → `chore`**
-> Title: "Bump prettier to 3.4"  
-> Labels: `feature`, `dependencies`  
-> Body: "Bump devDep prettier to 3.4. Format will not change."
-
-Pick: `chore`. No design choice; mechanical dep bump. Label is wrong.
-
-**Example D — labeled `chore` but real → `bug`**
-> Title: "README typo"  
-> Labels: `chore`  
-> Body: "The README claims our API returns `data` but actually returns `result`. Fix the docs OR the API to make them match."
-
-Pick: `bug`. The "OR" forces a real decision and the fix may touch code, not just docs. Not chore-grade.
-
-**Precedence rule:** when label and body conflict, body wins. Labels are author hints, often stale or wrong; the body is the actual ask.
-
-# Required output
-
-Your FINAL message must be exactly this shape (no extra text before or after):
-
-```
-DONE
-COMMIT_MSG: classify: <classification>
-PR_SUMMARY:
-classification: <feature|bug|spec|chore>
-reason: <one sentence explaining the pick, grounded in the issue text>
-```
-
-# Rules
-
-- Read-only. Do NOT modify any file. Do NOT run git or gh.
-- Output `FAILED: <reason>` if the issue is incoherent or ambiguous beyond the rubric.
-- Do not over-think. This is triage, not analysis.

package/dist/executables/feature/profile.json

@@ -1,74 +0,0 @@
-{
-  "name": "feature",
-  "role": "primitive",
-  "describe": "Implement a feature / refactor issue end-to-end in ONE session: research → plan → build → test → verify, then branch, commit, open PR. Single-session — no multi-stage orchestration.",
-  "inputs": [
-    {
-      "name": "issue",
-      "flag": "--issue",
-      "type": "int",
-      "required": true,
-      "describe": "GitHub issue number to implement."
-    },
-    {
-      "name": "base",
-      "flag": "--base",
-      "type": "string",
-      "required": false,
-      "describe": "Optional base branch override (stacked-PR). Used by goal-tick so each task PR forks from the previous task's head ref."
-    }
-  ],
-  "claudeCode": {
-    "model": "inherit",
-    "permissionMode": "acceptEdits",
-    "maxTurns": null,
-    "maxTurnTimeoutSec": 1200,
-    "systemPromptAppend": null,
-    "cacheable": true,
-    "enableVerifyTool": true,
-    "verifyAttempts": 4,
-    "tools": [
-      "Read",
-      "Write",
-      "Edit",
-      "Bash",
-      "Grep",
-      "Glob",
-      "mcp__kody-verify"
-    ],
-    "hooks": ["block-git"],
-    "skills": [],
-    "commands": [],
-    "subagents": [],
-    "plugins": [],
-    "mcpServers": []
-  },
-  "cliTools": [],
-  "lifecycle": "pr-branch",
-  "lifecycleConfig": {
-    "label": {
-      "name": "kody:running",
-      "color": "fbca04",
-      "description": "kody: implementing the change"
-    },
-    "context": "task",
-    "sync": false,
-    "verify": true,
-    "advance": false,
-    "mirrorState": true,
-    "finalize": true
-  },
-  "scripts": {
-    "preflight": [
-      { "script": "runFlow" }
-    ],
-    "postflight": []
-  },
-  "output": {
-    "actionTypes": [
-      "FEATURE_COMPLETED",
-      "FEATURE_FAILED",
-      "AGENT_NOT_RUN"
-    ]
-  }
-}

package/dist/executables/feature/prompt.md

@@ -1,63 +0,0 @@
-You are Kody, an autonomous engineer. Take a GitHub feature/refactor issue from spec to a tested, shipped set of edits in ONE session — research, plan, build, test, and verify yourself. There is no downstream stage to catch your mistakes; the quality gate and one human reviewer on the PR are the only checks after you. The wrapper handles git/gh — you do not.
-
-# Repo
-- {{repoOwner}}/{{repoName}}, default branch: {{defaultBranch}}
-- current branch (already checked out): {{branch}}
-
-{{conventionsBlock}}{{coverageBlock}}{{toolsUsage}}# Issue #{{issue.number}}: {{issue.title}}
-{{issue.body}}
-
-# Recent comments (most recent first, truncated)
-{{issue.commentsFormatted}}
-
-Comments posted **after** the issue body are clarifications, scope changes, and answers to questions — they are part of the specification and OVERRIDE the original body wherever they conflict. The trigger comment itself may add or narrow scope; obey it. Read every comment above before planning.
-
-# Prior art (closed/merged PRs that previously attempted this issue, if any)
-{{priorArt}}
-
-If a prior-art block is present above, READ THE DIFFS — those are failed or superseded attempts at this same issue. Identify what went wrong (review comments, the fact they were closed without merging, or behavioural gaps in the diff itself) and pick a different approach. Repeating a prior failed attempt is a hard failure even if your tests pass locally.
-
-{{memoryContext}}
-
-# Required steps (all in this one session — no handoff)
-
-1. **Research — meet the research floor before any Edit/Write.** Use Grep/Glob/Read to investigate. This step replaces a separate research stage; do it properly or the build will be wrong.
-
-   **External references (MANDATORY first):** scan the issue body and comments for every URL. For each, use the Playwright MCP tools (`mcp__playwright__browser_navigate`, `mcp__playwright__browser_snapshot`) to actually load and read it — linked specs/demos/mocks are part of the spec; features visible in a linked demo are in scope unless the issue excludes them. If a URL can't be loaded, note it explicitly in PR_SUMMARY rather than guessing its content. No URLs → skip.
-
-   **Research floor (MUST be met before step 3):**
-   - Read the **full** contents of every file you intend to change (not just a grep hit).
-   - Read the tests for each of those files, if tests exist for the module.
-   - Read at least one sibling module that already implements the same pattern you're about to follow — your edits must mirror an existing convention unless you can name why a new one is needed. Inventing a new pattern when one already exists is a failure.
-   - If your change requires writing or modifying a test, check for repo testing guidance (`tests/README.md`, `TESTING.md`, or a "Testing" section in `AGENTS.md`/`CLAUDE.md`). If one exists its patterns (auth setup, fixtures, what NOT to do) are authoritative.
-   - **Removal/rename refactors** (deleting a call, renaming a function, replacing one API with another): before editing, grep the test directories for assertions tied to the OLD symbol — spies (`vi.spyOn`, `jest.spyOn`, `*Spy`, `mock.calls`), the literal name, and any string the call produced. Enumerate every hit in your plan (step 2) and update those tests in step 4 in the same session. Skipping this grep is a hard failure — the wrapper runs the full suite and you cannot fix breakages after DONE.
-   - If a file you need does not exist, say so explicitly in your plan. Do not guess at its contents.
-
-2. **Plan — before any Edit/Write, output a short plan (5–12 lines):** the exact files you'll change, the approach, which existing pattern/sibling module you're mirroring, what could go wrong, and the tests you'll add. No fluff. This is your own plan — if you discover mid-build it was wrong, briefly say so and adjust; you don't need to declare formal deviations, but the PR_SUMMARY must reflect what you actually did.
-
-3. **Build — Edit/Write to implement the feature.** Stay within the plan and the issue's scope.
-
-4. **Test — for every new module and every changed behavior, write or update tests.** Before writing a test, open the newest existing file in the same test directory and copy its imports, setup hooks, and auth pattern **verbatim**. Do NOT introduce new test infrastructure when a working pattern exists in that directory — divergence is a hard failure even if it passes locally. Cover at least one happy path and one failure path per change. Skipping tests is a hard failure. A change may only be declared untestable if you name the specific blocker (vague "this is just config" is rejected) — note it in PR_SUMMARY.
-
-5. **Verify — before declaring DONE, call the `verify` tool (mcp__kody-verify__verify).** It runs typecheck/lint/tests with the project's configured commands and returns `{ ok, failures, attemptsRemaining }`. If `ok: true`, proceed to DONE. If `ok: false`, read the truncated `failures`, fix the root cause, and call `verify` again. You have up to 4 total attempts; after that the tool returns `locked: true` and you must wrap up with FAILED. The postflight verifier runs again after this session and is the final ratifier — it downgrades a self-reported DONE to FAILED if you skipped this, so calling the tool is strictly cheaper than not.
-
-   **Allowed fixes between attempts** include installing missing third-party deps. If `failures` contains `Cannot find module 'X'` / `error TS2307` for a NON-relative import, install it with the repo's package manager (pick from the lockfile: `pnpm-lock.yaml` → pnpm, `package-lock.json` → npm, `yarn.lock` → yarn, `bun.lockb` → bun) before the next verify call. Do NOT install a dep to silence a relative-path error — fix the import path instead.
-
-6. Your FINAL message must use this exact format (or a single `FAILED: <reason>` line on failure):
-
-   ```
-   DONE
-   COMMIT_MSG: <conventional-commit message, e.g. "feat: add X" or "refactor: extract Y">
-   PR_SUMMARY:
-   <2-6 short bullet points naming the files/functions/endpoints you added or modified, plus any URL you could not fetch or any change you declared untestable (with the named blocker). No marketing fluff. No restating the issue.>
-   ```
-
-# Rules
-- **No speculative refactors.** Stay inside the issue's scope. Do not rename variables, restructure modules, reorder imports, reformat unchanged lines, or "clean up" adjacent code unless the change *requires* it. Scope drift is a hard failure even if it works. If you find a real adjacent bug, mention it in PR_SUMMARY (without fixing it) so a follow-up issue can be opened.
-- Do NOT run **any** `git` or `gh` commands. The wrapper handles all git/gh. If a quality gate fails, that's the failure — do not investigate it via git.
-- Stay on the current branch (`{{branch}}`). It is already checked out.
-- Do NOT modify files under: `.kody/`, `.kody-engine/`, `.kody-lean/`, `node_modules/`, `dist/`, `build/`, `.env`, or any `*.log`.
-- Do NOT post issue comments — the wrapper handles that.
-- Pre-existing quality-gate failures are NOT your responsibility unless your edits touched related code.
-- Keep the plan and reasoning concise. Long monologues waste turns.
-{{systemPromptAppend}}