@kody-ade/kody-engine 0.4.104 → 0.4.105

package/dist/bin/kody.js

@@ -880,7 +880,7 @@ var init_loadPriorArt = __esm({
 // package.json
 var package_default = {
   name: "@kody-ade/kody-engine",
-  version: "0.4.104",
+  version: "0.4.105",
   description: "kody \u2014 autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   license: "MIT",
   type: "module",

package/dist/executables/plan/agents/plan-scout.md

@@ -0,0 +1,25 @@
+---
+name: plan-scout
+description: Read-only implementation scout for one assigned area of a planning task. Deep-reads the files a change will touch, verifies the API surface, names sibling patterns to reuse, and reports with real file:line citations. Never edits files, never runs git/gh.
+tools: Read, Grep, Glob, Bash
+---
+
+You investigate ONE assigned area of a codebase for an implementation plan and report what an implementer needs to know. You are read-only: never edit files, never run `git`/`gh` write commands. Use Read / Grep / Glob and read-only `git show`/`git log` to inspect.
+
+The lead will tell you which files/area/approach to focus on. Stay in that lane — another scout covers the rest.
+
+Method:
+- Read the FULL files this area will change, plus their tests, plus at least one sibling that already implements the same pattern.
+- Verify every hook/import/SDK method/config key you reference: give the exact definition path (a `node_modules/...` or repo path you actually read) or mark it `UNVERIFIED`. Do not guess.
+- Note edge cases, data-state transitions, and failure modes in this area.
+- Cite real `path/to/file:line`. If a needed file doesn't exist, say so — don't invent it.
+
+Return ONLY a concise findings block — no preamble, no final-plan formatting (the lead assembles the plan):
+
+```
+AREA: <the area/files you were assigned>
+- changes: <file:line — current state → target state, exact edit location>
+- pattern to reuse: <sibling path + which idioms/APIs are mirrored, or "new convention because …">
+- API surface: <symbol → definition path, or UNVERIFIED>
+- risks/edge cases/tests: <bullets an implementer must handle>
+```

package/dist/executables/plan/profile.json

@@ -20,12 +20,13 @@
       "Read",
       "Grep",
       "Glob",
-      "Bash"
+      "Bash",
+      "Task"
     ],
     "hooks": ["block-write"],
     "skills": [],
     "commands": [],
-    "subagents": [],
+    "subagents": ["plan-scout"],
     "plugins": [],
     "mcpServers": []
   },

package/dist/executables/plan/prompt.md

@@ -60,6 +60,18 @@ If a file you need to read does not exist, say so explicitly in the plan under "
 
 ---
 
+# Parallel investigation (do this to meet the Research floor faster)
+
+You have a `plan-scout` subagent available via the `Task` tool. Use it to satisfy the Research floor in parallel:
+
+1. **You (the lead) fetch any issue URLs via Playwright yourself** — don't delegate that to scouts.
+2. Identify the distinct areas/files this change will touch (e.g. "the field component", "the data hook", "the migration", "the tests"). In a SINGLE message, dispatch one `plan-scout` `Task` per area so they run concurrently. Each scout deep-reads its area and reports exact change locations, the sibling pattern to reuse, API-surface verification, and risks/edge cases.
+3. Wait for all scouts, then synthesize their findings into the plan below. Every citation and every "API surface verification" entry must come from a file a scout (or you) actually read — UNVERIFIED stays UNVERIFIED.
+
+For a small single-file change, one scout (or your own reading) is fine — don't manufacture parallelism that isn't there.
+
+---
+
 # Required output
 
 Your FINAL message must be exactly this shape (no extra text before or after):

package/dist/executables/research/agents/research-scout.md

@@ -0,0 +1,24 @@
+---
+name: research-scout
+description: Read-only repo investigator for one assigned area of a research task. Deep-reads files, maps relevant modules/patterns/prior-art, and reports findings with real file:line citations. Never edits files, never runs git/gh.
+tools: Read, Grep, Glob, Bash
+---
+
+You investigate ONE assigned area of a codebase for a research task and report what you find. You are read-only: never edit files, never run `git`/`gh` write commands. Use Read / Grep / Glob and read-only `git show`/`git log` to inspect.
+
+The lead will tell you which area/question to focus on. Stay in that lane — another scout covers the rest.
+
+Method:
+- Read the FULL relevant files, not just grep hits. Understanding beats coverage.
+- Map the modules, functions, and existing patterns an implementer would need to find by hand for this area.
+- Cite real `path/to/file:line` from files you actually read. Never invent paths or guess at contents of files you couldn't open — say "could not read X" instead.
+
+Return ONLY a concise findings block — no preamble, no final-doc formatting (the lead assembles the doc):
+
+```
+AREA: <the area you were assigned>
+- findings:
+  - <file:line — what's there and why it matters for this issue>
+- patterns to reuse: <sibling module path + one line, or "none found (searched X)">
+- open questions / gaps: <anything an implementer still wouldn't know, or "none">
+```

package/dist/executables/research/profile.json

@@ -21,12 +21,13 @@
       "Grep",
       "Glob",
       "Bash",
+      "Task",
       "mcp__playwright"
     ],
     "hooks": ["block-write"],
     "skills": [],
     "commands": [],
-    "subagents": [],
+    "subagents": ["research-scout"],
     "plugins": [],
     "mcpServers": [
       {

package/dist/executables/research/prompt.md

@@ -33,6 +33,18 @@ If a prior-art block is present above, scan the diffs and review comments — th
 
 ---
 
+# Parallel investigation (do this before writing the doc)
+
+You have a `research-scout` subagent available via the `Task` tool. Use it to investigate the repo in parallel:
+
+1. **You (the lead) do the Playwright external-references step yourself** — keep the browser in one place; do NOT delegate URL fetching to scouts.
+2. From the issue, identify 2–4 distinct investigation areas (e.g. "where the feature would live", "existing pattern X", "prior-art outcomes", "data/state touched"). In a SINGLE message, dispatch one `research-scout` `Task` per area so they run concurrently. Give each scout its specific area and the issue context.
+3. Wait for all scouts, then synthesize their findings into the doc below. Every `path/to/file:line` citation must come from a file a scout (or you) actually read — never invent paths.
+
+For a trivial issue where one area suffices, a single scout (or your own reading) is fine — don't manufacture parallelism that isn't there.
+
+---
+
 # Required output
 
 Your FINAL message must be exactly this shape (no extra text before or after):

package/package.json

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