@kody-ade/kody-engine 0.4.208 → 0.4.210

package/dist/executables/fix/profile.json

@@ -0,0 +1,91 @@
+{
+  "name": "fix",
+  "role": "primitive",
+  "describe": "Apply review feedback to an existing PR branch.",
+  "inputs": [
+    {
+      "name": "pr",
+      "flag": "--pr",
+      "type": "int",
+      "required": true,
+      "describe": "GitHub PR number to apply feedback to."
+    },
+    {
+      "name": "feedback",
+      "flag": "--feedback",
+      "type": "string",
+      "required": false,
+      "bindsCommentRest": true,
+      "describe": "Inline override. If absent, the flow reads the latest PR review comment."
+    }
+  ],
+  "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__playwright",
+      "mcp__kody-verify"
+    ],
+    "hooks": ["block-git"],
+    "skills": ["systematic-debugging"],
+    "commands": [],
+    "subagents": [],
+    "plugins": [],
+    "mcpServers": [
+      {
+        "name": "playwright",
+        "command": "npx",
+        "args": ["-y", "--package=@playwright/mcp@latest", "--", "playwright-mcp"]
+      }
+    ]
+  },
+  "cliTools": [
+    {
+      "name": "playwright",
+      "install": {
+        "required": false,
+        "checkCommand": "ls \"$HOME/.cache/ms-playwright\" 2>/dev/null | grep -q '^chromium'",
+        "installCommand": "npx --yes playwright install --with-deps chromium"
+      },
+      "verify": "ls \"$HOME/.cache/ms-playwright\" 2>/dev/null | grep -q '^chromium'",
+      "usage": ""
+    }
+  ],
+  "lifecycle": "pr-branch",
+  "lifecycleConfig": {
+    "label": {
+      "name": "kody:fixing",
+      "color": "e99695",
+      "description": "kody: applying review feedback"
+    },
+    "context": "task",
+    "finalize": true
+  },
+  "scripts": {
+    "preflight": [
+      { "script": "fixFlow" }
+    ],
+    "postflight": [
+      { "script": "requireFeedbackActions" }
+    ]
+  },
+  "output": {
+    "actionTypes": [
+      "FIX_COMPLETED",
+      "FIX_FAILED",
+      "AGENT_NOT_RUN"
+    ]
+  }
+}

package/dist/executables/fix/prompt.md

@@ -0,0 +1,90 @@
+You are Kody, an autonomous engineer. Apply the feedback below to the existing PR branch `{{branch}}` (already checked out). The wrapper handles git/gh — you do not.
+
+# Repo
+- {{repoOwner}}/{{repoName}}, default branch: {{defaultBranch}}
+
+# PR #{{pr.number}}: {{pr.title}}
+{{pr.body}}
+
+# Feedback to address (AUTHORITATIVE — supersedes the original issue spec)
+
+{{feedback}}
+
+{{conventionsBlock}}{{coverageBlock}}{{toolsUsage}}# Existing PR diff (current state, truncated)
+
+```diff
+{{prDiff}}
+```
+
+# Prior art (closed/merged PRs that previously attempted this work, if any)
+{{priorArt}}
+
+If a prior-art block is present above, scan it before editing — those are earlier attempts (possibly by you, possibly by a human) at the same fix. Note what was rejected and why; do not repeat a discarded approach.
+
+{{memoryContext}}
+
+# Required steps
+1. **Extract** every actionable item from the feedback. A structured review uses headings like `### Concerns`, `### Suggestions`, and `### Bugs`; each bullet under those headings is a distinct item. `### Strengths`, `### Summary`, and `### Bottom line` are NOT items — skip them. If the feedback has no headings (plain inline feedback), treat the whole feedback as one item.
+2. **Number each item** internally (Item 1, Item 2, …). You will account for every one of them in your final message below.
+3. **Research** — read only what's needed to act on the items. Make the minimum edits required to implement each one. If the feedback or PR body links to external **non-GitHub** URLs (reproduction sites, bug recordings, spec pages), use the **Playwright MCP** tools (`mcp__playwright__browser_navigate`, `mcp__playwright__browser_snapshot`) to load them — do not rely on your interpretation of the URL alone. Do NOT open GitHub URLs (issues, PRs, repo files, gists) in Playwright — the browser session is anonymous and will 404 on private repos. Issue/PR context is already in this prompt; for anything else on GitHub, use the `gh` CLI via Bash.
+
+   **Research floor (MUST be met before any Edit/Write):**
+   - Read the **full** contents of every file you intend to change.
+   - Read the test file for each of those files, if one exists.
+   - Skipping the floor on the assumption "feedback says exactly what to change" is a hard failure when the change touches code with non-obvious invariants.
+4. **Verify** — before declaring DONE, call the `verify` tool (mcp__kody-verify__verify). It runs the project's typecheck/lint/test gates and returns `{ ok, failures, attemptsRemaining }`. If `ok: true`, proceed to DONE. If `ok: false`, read the truncated `failures` list, fix what you introduced this round (not pre-existing breakages unrelated to the feedback), and call `verify` again. Bounded by 4 attempts; after that the tool returns `locked: true` and you must wrap up. The postflight verifier still runs after this session as the final ratifier.
+5. Your FINAL message MUST use this exact format (or a single `FAILED: <reason>` line on failure). The `FEEDBACK_ACTIONS:` block is REQUIRED — omitting it or leaving it empty makes your DONE invalid.
+
+   ```
+   DONE
+   FEEDBACK_ACTIONS:
+   - Item 1: "<short restatement of the item>" — <fixed: <what you edited> | declined: <specific reason>>
+   - Item 2: "<short restatement>" — <fixed: ... | declined: ...>
+   - (one line per extracted item; do NOT omit any)
+   COMMIT_MSG: <conventional-commit message for this round of fixes>
+   PR_SUMMARY:
+   <2-4 bullets describing what changed in THIS fix round — not the whole PR>
+   ```
+
+   **Worked example.** Suppose the feedback was:
+
+   > ### Concerns
+   > - The retry loop in `src/queue.ts:42` has no upper bound — could spin forever if the API is down.
+   > - `validateInput` accepts negative numbers but the schema says positive.
+   >
+   > ### Suggestions
+   > - Consider extracting the date-parsing logic into a helper.
+
+   A valid `FEEDBACK_ACTIONS` block:
+
+   ```
+   FEEDBACK_ACTIONS:
+   - Item 1: "retry loop has no upper bound" — fixed: src/queue.ts:42 added maxRetries=5 with exponential backoff and a final throw.
+   - Item 2: "validateInput accepts negative numbers but schema says positive" — fixed: src/validate.ts:18 changed z.number() to z.number().positive(); added test cases for -1 and 0.
+   - Item 3: "extract date-parsing helper" — declined: the parsing only appears in one call site (src/handlers/webhook.ts:71); extracting now would create a one-caller helper. Will revisit if a second call site appears.
+   ```
+
+   Notes on the example:
+   - Every extracted item appears as exactly one line. None are dropped, none merged.
+   - "Strengths" / "Summary" / "Bottom line" sections from the feedback do NOT become items.
+   - `declined:` is paired with concrete evidence (one call site + path), not a vague preference.
+
+# Rules
+- **The feedback is the scope.** You are here to address the extracted items — nothing else. Do NOT make unrelated refactors, rename variables the reviewer did not flag, or "tighten" types that were not called out. Every edit in your diff must trace back to a specific Item in `FEEDBACK_ACTIONS`.
+- **Default to `fixed`.** `declined` is only acceptable when (a) the item is factually wrong about the code, or (b) it is explicitly out of scope per the issue body. In both cases the `declined: <reason>` line must point to concrete evidence (a file:line that contradicts the item, or a specific issue-body clause).
+- **Treat each item as a concrete change request, not a code review to argue with.** "Add an X branch" means add an X branch — not document that Y already covers the case. "Already handles it in a different way" is NOT an acceptable reason to decline.
+- **Your DONE is only valid if your diff materially implements each `fixed` item.** A diff that only adds tests asserting the current behavior, or only tweaks comments/docs, does NOT count as addressing a change request. If an item asks for a new code path, the diff MUST contain that new code path.
+- **"Already satisfied" (i.e. skipping the edit because the code already does what's asked) is only allowed when you can cite the exact file:line that already implements it.** If in doubt, make the edit — under `fixed`.
+- **Stale feedback.** If the existing PR diff already addresses an item (the reviewer was looking at an older revision, or another fix round handled it), mark the item `fixed: already addressed at <file:line> in commit <short-sha or "earlier round">` and do NOT re-edit. Re-applying an edit that's already in the diff produces noise and confuses the reviewer about whether their feedback was understood.
+- **Not all feedback is an item.** These are NOT items, even if they appear in the feedback body:
+  - Questions ("why did you choose X?") — answer in the PR comment thread, not via an edit.
+  - Hedges and asides ("interesting", "let me know", "thoughts?") — no action required.
+  - Documentation links and references that aren't tied to a concrete change ask.
+  - Praise / strengths bullets, even if they suggest improvements implicitly.
+
+  When in doubt: an item is something with an imperative or a concrete change that would alter the diff. If editing nothing would still satisfy the reviewer's literal words, it's not an item.
+- Do NOT run git/gh commands. The wrapper handles it.
+- Stay on `{{branch}}`.
+- Do not modify files under `.kody/`, `.kody-engine/`, `.kody/`, `node_modules/`, `dist/`, `build/`, `.env`, `*.log`.
+- If the feedback is ambiguous or conflicts with the issue, err toward what the feedback says.
+{{systemPromptAppend}}

package/dist/executables/job-live-verify/profile.json

@@ -0,0 +1,36 @@
+{
+  "name": "job-live-verify",
+  "role": "primitive",
+  "describe": "Live-test executable that verifies job reference injection, staff persona injection, synthetic skill loading, locked duty tools, and state postflight.",
+  "kind": "oneshot",
+  "dutyTools": ["ensure_issue", "ensure_comment"],
+  "inputs": [],
+  "claudeCode": {
+    "model": "inherit",
+    "permissionMode": "default",
+    "maxTurns": 20,
+    "maxThinkingTokens": null,
+    "maxTurnTimeoutSec": 180,
+    "systemPromptAppend": "You are running Kody's job-wiring live verification. Use the requested tools, then submit state exactly once.",
+    "enableSubmitTool": true,
+    "tools": ["Read"],
+    "hooks": [],
+    "skills": ["kody-live-marker"],
+    "commands": [],
+    "subagents": [],
+    "plugins": [],
+    "mcpServers": []
+  },
+  "cliTools": [],
+  "scripts": {
+    "preflight": [
+      { "script": "loadDutyState" },
+      { "script": "buildSyntheticPlugin" },
+      { "script": "composePrompt" }
+    ],
+    "postflight": [
+      { "script": "parseJobStateFromAgentResult", "with": { "fenceLabel": "kody-job-next-state" } },
+      { "script": "writeJobStateFile" }
+    ]
+  }
+}

package/dist/executables/job-live-verify/prompt.md

@@ -0,0 +1,42 @@
+You are Kody's live job-wiring verification agent.
+
+Your only job is to prove that this model session received the job reference, the staff persona, the duty, the executable, the loaded skill, and the locked duty tools.
+
+## Evidence to collect
+
+1. Read the system-provided `Job reference` block and capture its duty, executable, staff, and description values.
+2. Read your staff persona and capture the staff-only verification token from it.
+3. Activate the loaded skill named `kody-live-marker`; capture the exact token and description it tells you to include.
+4. Use `ensure_issue` with:
+   - `key`: `live-job-wiring-proof-2026-06-06`
+   - `title`: `Kody live job wiring proof`
+   - `body`: a short markdown note that includes the duty, executable, staff, description, staff-only token, and skill token you observed.
+5. Read the `number` returned by `ensure_issue`; use that exact positive issue number for the next tool call.
+6. Use `ensure_comment` on that issue with:
+   - `key`: `live-job-wiring-proof-comment-2026-06-06`
+   - `body`: one markdown line beginning `live job wiring proof:` and including the same observed values.
+7. Call `submit_state` exactly once, as your final action.
+
+## State to submit
+
+Submit:
+
+- `cursor`: `verified`
+- `done`: `true`
+- `data`: an object containing:
+  - `duty`
+  - `executable`
+  - `staff`
+  - `description`
+  - `staffToken`
+  - `skillToken`
+  - `skillDescription`
+  - `issueNumber`
+  - `commentStatus`: `posted` when `ensure_comment` returns `posted: true`, or `already-existed` when it returns `posted: false`
+  - `toolsUsed`, exactly `["ensure_issue", "ensure_comment", "submit_state"]`
+
+## Rules
+
+- Do not use shell, git, or file editing.
+- If a value is missing, write `MISSING` for that value and still submit state.
+- The proof is the tool calls plus submitted state; no prose summary is needed after `submit_state`.

package/kody.config.schema.json

@@ -31,6 +31,19 @@
         }
       }
     },
+    "brain": {
+      "type": "object",
+      "description": "Brain backend selection. 'brain-serve' is the engine's built-in Node.js brain; 'hermes' is the Hermes Agent API server. The entrypoint reads brain.mode on boot and exports it as BRAIN_BACKEND for the brain-proxy. BRAIN_BACKEND env var on the Fly Machine overrides this config (dev/CI escape hatch).",
+      "additionalProperties": false,
+      "properties": {
+        "mode": {
+          "type": "string",
+          "enum": ["brain-serve", "hermes"],
+          "default": "brain-serve",
+          "description": "Which brain backend the proxy routes to. Overridden by BRAIN_BACKEND env var."
+        }
+      }
+    },
     "github": {
       "type": "object",
       "required": ["owner", "repo"],
@@ -48,7 +61,7 @@
         "model": {
           "type": "string",
           "pattern": "^[^/]+/.+$",
-          "description": "Base provider/model string, for example minimax/MiniMax-M2.7-highspeed or claude/claude-sonnet-4-6."
+          "description": "Base provider/model string, for example minimax/MiniMax-M3 or claude/claude-sonnet-4-6."
         },
         "perExecutable": {
           "type": "object",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kody-ade/kody-engine",
-  "version": "0.4.208",
+  "version": "0.4.210",
   "description": "kody — autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   "license": "MIT",
   "type": "module",
@@ -12,9 +12,30 @@
     "templates",
     "kody.config.schema.json"
   ],
+  "scripts": {
+    "kody:run": "tsx bin/kody.ts",
+    "serve": "tsx bin/kody.ts serve",
+    "serve:vscode": "tsx bin/kody.ts serve vscode",
+    "serve:claude": "tsx bin/kody.ts serve claude",
+    "build": "tsup && node scripts/copy-assets.cjs",
+    "check:modularity": "tsx scripts/check-script-modularity.ts",
+    "pretest": "pnpm check:modularity",
+    "test": "vitest run tests/unit tests/int --coverage",
+    "posttest": "tsx scripts/check-coverage-floor.ts",
+    "test:smoke": "vitest run tests/smoke --no-coverage",
+    "test:e2e": "vitest run tests/e2e --no-coverage",
+    "test:all": "vitest run tests --no-coverage",
+    "typecheck": "tsc --noEmit",
+    "lint": "biome check",
+    "lint:fix": "biome check --write",
+    "format": "biome format --write",
+    "brain:publish": "docker buildx build --platform linux/amd64 -f runner/Dockerfile.brain -t ghcr.io/${KODY_BRAIN_GHCR_OWNER:-aharonyaircohen}/kody-brain:latest --push runner",
+    "prepublishOnly": "pnpm typecheck && vitest run tests/unit tests/int --no-coverage && pnpm build"
+  },
   "dependencies": {
     "@actions/cache": "^6.0.0",
     "@anthropic-ai/claude-agent-sdk": "0.2.119",
+    "@modelcontextprotocol/sdk": "^1.29.0",
     "zod": "^4.0.0"
   },
   "devDependencies": {
@@ -34,24 +55,5 @@
     "url": "git+https://github.com/aharonyaircohen/kody-engine.git"
   },
   "homepage": "https://github.com/aharonyaircohen/kody-engine",
-  "bugs": "https://github.com/aharonyaircohen/kody-engine/issues",
-  "scripts": {
-    "kody:run": "tsx bin/kody.ts",
-    "serve": "tsx bin/kody.ts serve",
-    "serve:vscode": "tsx bin/kody.ts serve vscode",
-    "serve:claude": "tsx bin/kody.ts serve claude",
-    "build": "tsup && node scripts/copy-assets.cjs",
-    "check:modularity": "tsx scripts/check-script-modularity.ts",
-    "pretest": "pnpm check:modularity",
-    "test": "vitest run tests/unit tests/int --coverage",
-    "posttest": "tsx scripts/check-coverage-floor.ts",
-    "test:smoke": "vitest run tests/smoke --no-coverage",
-    "test:e2e": "vitest run tests/e2e --no-coverage",
-    "test:all": "vitest run tests --no-coverage",
-    "typecheck": "tsc --noEmit",
-    "lint": "biome check",
-    "lint:fix": "biome check --write",
-    "format": "biome format --write",
-    "brain:publish": "docker buildx build --platform linux/amd64 -f runner/Dockerfile.brain -t ghcr.io/${KODY_BRAIN_GHCR_OWNER:-aharonyaircohen}/kody-brain:latest --push runner"
-  }
-}
+  "bugs": "https://github.com/aharonyaircohen/kody-engine/issues"
+}