@kody-ade/kody-engine-lite 0.1.105 → 0.1.106

package/kody.config.schema.json

@@ -201,6 +201,11 @@
             "readyTimeout": {
               "type": "number",
               "description": "Seconds to wait for the server to be ready. Default: 30"
+            },
+            "env": {
+              "type": "array",
+              "items": { "type": "string" },
+              "description": "List of GitHub secret names to forward as environment variables for the dev server process (e.g., ['BLOB_READ_WRITE_TOKEN', 'DATABASE_URL']). These are injected into the workflow env block during 'kody init'."
             }
           },
           "required": ["command", "url"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kody-ade/kody-engine-lite",
-  "version": "0.1.105",
+  "version": "0.1.106",
   "description": "Autonomous SDLC pipeline: Kody orchestration + Claude Code + LiteLLM",
   "license": "MIT",
   "type": "module",

package/prompts/autofix.md

@@ -5,35 +5,48 @@ mode: primary
 tools: [read, write, edit, bash, glob, grep]
 ---
 
-You are an autofix agent. The verification stage failed. Fix the errors below.
+You are an autofix agent following the Superpowers Systematic Debugging methodology. The verification stage failed. Fix the errors below.
 
-IRON LAW: NO FIXES WITHOUT INVESTIGATION FIRST. Do not jump to changing code. Understand the failure first.
+IRON LAW: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. If you haven't completed Phase 1, you cannot propose fixes.
 
-## Phase 1 — Investigate (do this BEFORE any edits)
-1. Read the full error output — what exactly failed?
-2. Identify the affected files — Read them to understand context
-3. Check recent changes: run `git diff HEAD~1` to see what changed
-4. Classify the failure pattern:
+## Phase 1 — Root Cause Investigation (BEFORE any edits)
+1. Read the full error output — what exactly failed? Full stack traces, line numbers, error codes.
+2. Identify the affected files — Read them to understand context.
+3. Check recent changes: run `git diff HEAD~1` to see what changed.
+4. Trace the data flow backward — find the original trigger, not just the symptom.
+5. Classify the failure pattern:
    - **Type error**: mismatched types, missing properties, wrong generics
    - **Test failure**: assertion mismatch, missing mock, changed behavior
    - **Lint error**: style violation, unused import, naming convention
    - **Runtime error**: null reference, missing dependency, config issue
    - **Integration failure**: API contract mismatch, schema drift
-5. Identify root cause — is this a direct error in new code, or a side effect of a change elsewhere?
-
-## Phase 2 — Fix (only after root cause is clear)
-1. Try quick wins first: run configured lintFix and formatFix commands via Bash
-2. For type errors: fix the type mismatch at its source, not by adding type assertions
-3. For test failures: fix the root cause (implementation or test), not both — determine which is correct
-4. For lint errors: apply the specific fix the linter suggests
-5. For integration failures: trace the contract back to its definition, fix the mismatch at source
-6. After EACH fix, re-run the failing command to verify it passes
-7. If a fix introduces new failures, REVERT and try a different approach
-8. Do NOT commit or push — the orchestrator handles git
+6. Identify root cause — is this a direct error in new code, or a side effect of a change elsewhere?
+
+## Phase 2 — Pattern Analysis
+1. Find working examples — search for similar working code in the same codebase.
+2. Compare against the working version — what's different?
+3. Form a single hypothesis: "I think X is the root cause because Y."
+
+## Phase 3 — Fix (only after root cause is clear)
+1. Try quick wins first: run configured lintFix and formatFix commands via Bash.
+2. Implement a single fix — ONE change at a time, not multiple changes at once.
+3. For type errors: fix the type mismatch at its source, not by adding type assertions.
+4. For test failures: fix the root cause (implementation or test), not both — determine which is correct.
+5. For lint errors: apply the specific fix the linter suggests.
+6. For integration failures: trace the contract back to its definition, fix the mismatch at source.
+7. After EACH fix, re-run the failing command to verify it passes.
+8. If a fix introduces new failures, REVERT and try a different approach — don't pile fixes.
+9. Do NOT commit or push — the orchestrator handles git.
+
+## Red Flags — STOP and return to Phase 1 if you catch yourself:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see"
+- "I don't fully understand but this might work"
+- Proposing solutions before tracing the data flow
 
 ## Rules
 - Fix ONLY the reported errors. Do NOT make unrelated changes.
-- Minimal diff — use Edit for surgical changes, not Write for rewrites
-- If the failure is pre-existing (not caused by this PR's changes), document it and move on
+- Minimal diff — use Edit for surgical changes, not Write for rewrites.
+- If the failure is pre-existing (not caused by this PR's changes), document it and move on.
 
 {{TASK_CONTEXT}}

package/prompts/review-fix.md

@@ -5,19 +5,23 @@ mode: primary
 tools: [read, write, edit, bash, glob, grep]
 ---
 
-You are a review-fix agent. The code review found issues that need fixing.
+You are a review-fix agent following the Superpowers Executing Plans methodology.
 
-RULES:
+The code review found issues that need fixing. Treat each Critical/Major finding as a plan step — execute in order, verify after each one.
+
+RULES (Superpowers Executing Plans discipline):
 1. Fix ONLY Critical and Major issues (ignore Minor findings)
 2. Use Edit for surgical changes — do NOT rewrite entire files
 3. Run tests after EACH fix to verify nothing breaks
-4. If a fix introduces new issues, revert and try a different approach
-5. Do NOT commit or push — the orchestrator handles git
+4. If a fix introduces new issues, revert and try a different approach — don't pile fixes
+5. Document any deviations from the expected fix
+6. Do NOT commit or push — the orchestrator handles git
 
-Read the review findings carefully. For each Critical/Major finding:
+For each Critical/Major finding:
 1. Read the affected file to understand full context
-2. Make the minimal change to fix the issue
-3. Run tests to verify the fix
-4. Move to the next finding
+2. Understand the root cause — don't just patch the symptom
+3. Make the minimal change to fix the issue
+4. Run tests to verify the fix
+5. Move to the next finding
 
 {{TASK_CONTEXT}}

package/prompts/taskify.md

@@ -7,7 +7,15 @@ tools: [read, glob, grep]
 
 You are a task classification agent following the Superpowers Brainstorming methodology.
 
-Before classifying, examine the codebase to understand the project structure, existing patterns, and affected files. Use Read, Glob, and Grep to explore.
+## MANDATORY: Explore Before Classifying
+
+Before classifying, you MUST explore the project context:
+1. **Examine the codebase** — Use Read, Glob, and Grep to understand project structure, existing patterns, and affected files.
+2. **Find existing solutions** — Search for how similar problems are already solved in this codebase. If a pattern exists, the task should reuse it.
+3. **Challenge assumptions** — Does the task description assume an approach? Are there simpler alternatives? Apply YAGNI ruthlessly.
+4. **Identify ambiguity** — Could the requirements be interpreted two ways? Are there missing edge case decisions?
+
+## Output
 
 Output ONLY valid JSON. No markdown fences. No explanation. No extra text before or after the JSON.
 
@@ -18,22 +26,26 @@ Required JSON format:
   "description": "Clear description of what the task requires",
   "scope": ["list", "of", "exact/file/paths", "affected"],
   "risk_level": "low | medium | high",
-  "hasUI": true,
+  "existing_patterns": ["list of existing patterns found that the implementation should reuse"],
   "questions": []
 }
 
-hasUI heuristics:
-- true: task touches frontend files (.tsx, .jsx, .vue, .svelte, .css, .scss, .html), UI components, pages, layouts, or styles
-- false: task is purely backend, CLI, API, database, config, docs, or infrastructure
-
 Risk level heuristics:
 - low: single file change, no breaking changes, docs, config, isolated scripts, test additions, style changes
 - medium: multiple files, possible side effects, API changes, new dependencies, refactoring existing logic
 - high: core business logic, data migrations, security, authentication, payment processing, database schema changes
 
-Questions rules:
+existing_patterns rules:
+- List patterns found in the codebase that are relevant to this task
+- Include the file path and a brief description of the pattern
+- If no relevant patterns exist, use an empty array []
+- These inform the planner — reuse existing solutions, don't invent new ones
+
+Questions rules (Superpowers Brainstorming discipline):
 - ONLY ask product/requirements questions — things you CANNOT determine by reading code
 - Ask about: unclear scope, missing acceptance criteria, ambiguous user behavior, missing edge case decisions
+- Challenge assumptions — if the task implies an approach, consider simpler alternatives
+- Check for ambiguity — could requirements be interpreted two ways?
 - Do NOT ask about technical implementation — that is the planner's job
 - Do NOT ask about things you can find by reading the codebase (file structure, frameworks, patterns)
 - If the task is clear and complete, leave questions as an empty array []

package/templates/kody.yml

@@ -103,111 +103,11 @@ jobs:
         if: steps.safety.outputs.valid == 'true'
         id: parse
         env:
-          BODY: ${{ github.event.comment.body }}
-        run: |
-          # Extract: @kody [mode] [task-id] [--from stage]
-          KODY_ARGS=$(echo "$BODY" | grep -oP '(?:@kody|/kody)\s+\K.*' || echo "")
-
-          # Extract flags first (before positional parsing)
-          FROM_STAGE=$(echo "$KODY_ARGS" | grep -oP '(?<=--from )\S+' || echo "")
-          FEEDBACK=$(echo "$KODY_ARGS" | grep -oP '(?<=--feedback ")[^"]*' || echo "")
-          COMPLEXITY=""
-          if echo "$KODY_ARGS" | grep -q -- '--complexity'; then
-            COMPLEXITY=$(echo "$KODY_ARGS" | tr ' ' '\n' | grep -A1 -- '--complexity' | tail -1)
-          fi
-          DRY_RUN="false"
-          if echo "$KODY_ARGS" | grep -q -- '--dry-run'; then
-            DRY_RUN="true"
-          fi
-
-          # Strip flags and their values for clean positional parsing
-          POSITIONAL=$(echo "$KODY_ARGS" | sed -E \
-            -e 's/--from\s+\S+//g' \
-            -e 's/--feedback\s+"[^"]*"//g' \
-            -e 's/--complexity\s+\S+//g' \
-            -e 's/--dry-run//g' \
-            -e 's/--ci-run-id\s+\S+//g' \
-            -e 's/\s+/ /g' -e 's/^ //' -e 's/ $//')
-
-          MODE=$(echo "$POSITIONAL" | awk '{print $1}')
-          TASK_ID=$(echo "$POSITIONAL" | awk '{print $2}')
-
-          # Validate mode — after flag stripping, only positional args remain
-          case "$MODE" in
-            full|rerun|fix|fix-ci|status|approve|review|resolve|bootstrap) ;;
-            *)
-              # First positional isn't a known mode — treat as task-id
-              if [ -n "$MODE" ]; then
-                TASK_ID="$MODE"
-              fi
-              MODE="full"
-              ;;
-          esac
-
-          ISSUE_NUM="${{ github.event.issue.number }}"
-
-          # For approve mode: extract answer body and convert to rerun
-          # Must run BEFORE task-id generation so we don't create a new task
-          # approve: extract answers, convert to rerun
-          if [ "$MODE" = "approve" ]; then
-            APPROVE_BODY=$(echo "$BODY" | sed -n '/\(@kody\|\/kody\)\s*approve/,$p' | tail -n +2)
-            FEEDBACK="$APPROVE_BODY"
-            MODE="rerun"
-          fi
-
-          # fix: extract description as feedback, convert to fix command
-          if [ "$MODE" = "fix" ]; then
-            FIX_BODY=$(echo "$BODY" | sed -n '/\(@kody\|\/kody\)\s*fix/,$p' | tail -n +2)
-            if [ -n "$FIX_BODY" ]; then
-              FEEDBACK="$FIX_BODY"
-            fi
-            # Leave TASK_ID empty — entry.ts finds latest task for issue
-          fi
-
-          # fix-ci: extract body as feedback + CI run ID
-          if [ "$MODE" = "fix-ci" ]; then
-            FIX_CI_BODY=$(echo "$BODY" | sed -n '/\(@kody\|\/kody\)\s*fix-ci/,$p' | tail -n +2)
-            if [ -n "$FIX_CI_BODY" ]; then
-              FEEDBACK="$FIX_CI_BODY"
-            fi
-            CI_RUN_ID=$(echo "$FIX_CI_BODY" | grep -oP 'Run ID:\s*\K\d+' || echo "")
-          fi
-
-          # Bootstrap mode: set task-id and skip normal pipeline
-          if [ "$MODE" = "bootstrap" ]; then
-            TASK_ID="bootstrap-$(date +%y%m%d-%H%M%S)"
-          fi
-
-          # Auto-generate task-id if not provided (only for full mode)
-          if [ -z "$TASK_ID" ] && [ "$MODE" = "full" ]; then
-            TASK_ID="${ISSUE_NUM}-$(date +%y%m%d-%H%M%S)"
-          fi
-
-          # Detect if this comment is on a PR (PRs are issues in GitHub API)
-          PR_NUMBER=""
-          if [ -n "${{ github.event.issue.pull_request }}" ]; then
-            PR_NUMBER="$ISSUE_NUM"
-          fi
-
-          # For review mode on a PR comment: use the PR number directly
-          if [ "$MODE" = "review" ] && [ -n "$PR_NUMBER" ]; then
-            TASK_ID="review-pr-${PR_NUMBER}-$(date +%y%m%d-%H%M%S)"
-          fi
-
-          echo "task_id=$TASK_ID" >> $GITHUB_OUTPUT
-          echo "mode=$MODE" >> $GITHUB_OUTPUT
-          echo "from_stage=$FROM_STAGE" >> $GITHUB_OUTPUT
-          echo "issue_number=$ISSUE_NUM" >> $GITHUB_OUTPUT
-          echo "pr_number=$PR_NUMBER" >> $GITHUB_OUTPUT
-          {
-            echo "feedback<<KODY_EOF"
-            echo "$FEEDBACK"
-            echo "KODY_EOF"
-          } >> $GITHUB_OUTPUT
-          echo "complexity=$COMPLEXITY" >> $GITHUB_OUTPUT
-          echo "ci_run_id=${CI_RUN_ID:-}" >> $GITHUB_OUTPUT
-          echo "dry_run=$DRY_RUN" >> $GITHUB_OUTPUT
-          echo "valid=true" >> $GITHUB_OUTPUT
+          COMMENT_BODY: ${{ github.event.comment.body }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+          ISSUE_IS_PR: ${{ github.event.issue.pull_request }}
+          TRIGGER_TYPE: comment
+        run: kody-engine-lite ci-parse
 
   # ─── Orchestrate ─────────────────────────────────────────────────────────────
   orchestrate:
@@ -255,9 +155,6 @@ jobs:
 
       - run: pnpm install --frozen-lockfile
 
-      - name: Install Kody Engine
-        run: npm install -g @kody-ade/kody-engine-lite
-
       - name: Install Claude Code CLI
         run: npm install -g @anthropic-ai/claude-code
 
@@ -269,10 +166,21 @@ jobs:
           git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
           git config user.name "github-actions[bot]"
 
+      - name: Export project secrets
+        env:
+          ALL_SECRETS: ${{ toJSON(secrets) }}
+        run: |
+          echo "$ALL_SECRETS" | jq -r 'to_entries[] | select(.key | test("^(GITHUB_TOKEN)$") | not) | @json' | while IFS= read -r entry; do
+            KEY=$(echo "$entry" | jq -r '.key')
+            VALUE=$(echo "$entry" | jq -r '.value')
+            DELIM="KODY_EOF_${KEY}"
+            echo "${KEY}<<${DELIM}" >> $GITHUB_ENV
+            echo "${VALUE}" >> $GITHUB_ENV
+            echo "${DELIM}" >> $GITHUB_ENV
+          done
+
       - name: Run Kody pipeline
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
-          ANTHROPIC_COMPATIBLE_API_KEY: ${{ secrets.ANTHROPIC_COMPATIBLE_API_KEY }}
           GH_TOKEN: ${{ steps.app-token.outputs.token || secrets.GITHUB_TOKEN }}
           TASK_ID: ${{ github.event.inputs.task_id || needs.parse.outputs.task_id }}
           MODE: ${{ github.event.inputs.mode || needs.parse.outputs.mode || 'full' }}
@@ -287,7 +195,7 @@ jobs:
         run: |
           if [ "$MODE" = "bootstrap" ]; then
             echo "Running bootstrap..."
-            kody-engine-lite bootstrap
+            npx kody-engine-lite bootstrap
           else
             CMD="run"
             [ "$MODE" = "rerun" ] && CMD="rerun"
@@ -303,7 +211,7 @@ jobs:
             # FEEDBACK is also passed via env var (avoids shell escaping issues)
             [ -n "$FEEDBACK" ] && ARGS="$ARGS --feedback \"$FEEDBACK\""
             [ "$DRY_RUN" = "true" ] && ARGS="$ARGS --dry-run"
-            kody-engine-lite $CMD $ARGS
+            npx kody-engine-lite $CMD $ARGS
           fi
 
       - name: Pipeline summary
@@ -349,10 +257,22 @@ jobs:
       github.event_name == 'pull_request' &&
       github.event.pull_request.merged == true
     runs-on: ubuntu-latest
+    permissions:
+      issues: write
     steps:
+      - name: Generate App token
+        id: app-token
+        if: vars.KODY_APP_ID != ''
+        uses: actions/create-github-app-token@v1
+        with:
+          app-id: ${{ vars.KODY_APP_ID }}
+          private-key: ${{ secrets.APP_PRIVATE_KEY }}
+          repositories: ${{ github.event.repository.name }}
+
       - name: Close linked issue
         uses: actions/github-script@v7
         with:
+          github-token: ${{ steps.app-token.outputs.token || secrets.GITHUB_TOKEN }}
           script: |
             // Extract issue number from branch name (e.g. "42--feature-name")
             const branch = context.payload.pull_request.head.ref;
@@ -496,17 +416,15 @@ jobs:
           node-version: 22
           cache: pnpm
       - run: pnpm install --frozen-lockfile
-      - name: Install Kody Engine
-        run: npm install -g @kody-ade/kody-engine-lite
       - name: Typecheck
         run: pnpm tsc --noEmit
       - name: CLI loads
-        run: kody-engine-lite --help
+        run: npx kody-engine-lite --help
       - name: Dry run
         run: |
           mkdir -p .kody/tasks/smoke-test
           echo "Smoke test task" > .kody/tasks/smoke-test/task.md
-          kody-engine-lite run --task-id smoke-test --dry-run || true
+          npx kody-engine-lite run --task-id smoke-test --dry-run || true
           if [ -f ".kody/tasks/smoke-test/status.json" ]; then
             echo "✓ status.json created"
             cat .kody/tasks/smoke-test/status.json