karajan-code 1.59.0 → 2.0.0

package/src/utils/role-assigner.js

@@ -0,0 +1,131 @@
+// Smart role assignment based on available AI agents.
+// Used by both kj init (interactive) and auto-init (non-interactive).
+
+import { detectAvailableAgents } from "./agent-detect.js";
+
+// Agent capability tiers (higher = more capable for complex reasoning)
+const CAPABILITY_TIERS = {
+  claude: 5, // Best for reasoning, orchestration, complex tasks
+  codex: 4,  // Strong coder, good reviewer
+  gemini: 3, // Good general purpose
+  aider: 2,  // Good coder, limited reasoning
+  opencode: 2 // Similar to aider
+};
+
+// Role requirements: what capability level is ideal for each role
+const ROLE_PREFERENCES = {
+  brain: { minTier: 4, prefer: "claude", description: "Karajan Brain (orchestrator)" },
+  solomon: { minTier: 3, prefer: "gemini", description: "Solomon (judge/arbiter)" },
+  coder: { minTier: 2, prefer: "claude", description: "Coder" },
+  reviewer: { minTier: 3, prefer: "codex", description: "Reviewer" },
+  planner: { minTier: 4, prefer: "claude", description: "Planner" },
+  researcher: { minTier: 3, prefer: "claude", description: "Researcher" },
+  architect: { minTier: 4, prefer: "claude", description: "Architect" },
+  tester: { minTier: 3, prefer: "claude", description: "Tester" },
+  security: { minTier: 3, prefer: "claude", description: "Security" },
+  triage: { minTier: 3, prefer: "claude", description: "Triage" }
+};
+
+/**
+ * Assign the best available agent to a role.
+ * Prefers the role's preferred agent if available, then falls back by capability tier.
+ */
+function assignRole(roleName, availableAgents) {
+  const pref = ROLE_PREFERENCES[roleName];
+  if (!pref) return availableAgents[0]?.name || "claude";
+
+  // Preferred agent available?
+  if (availableAgents.find(a => a.name === pref.prefer)) {
+    return pref.prefer;
+  }
+
+  // Sort by capability tier (descending) and pick the best available
+  const sorted = [...availableAgents].sort(
+    (a, b) => (CAPABILITY_TIERS[b.name] || 1) - (CAPABILITY_TIERS[a.name] || 1)
+  );
+
+  return sorted[0]?.name || "claude";
+}
+
+/**
+ * Try to diversify: if possible, use a different agent for reviewer than coder.
+ */
+function diversifyReviewer(coderAgent, availableAgents) {
+  const alternatives = availableAgents.filter(a => a.name !== coderAgent);
+  if (alternatives.length === 0) return coderAgent;
+
+  const sorted = [...alternatives].sort(
+    (a, b) => (CAPABILITY_TIERS[b.name] || 1) - (CAPABILITY_TIERS[a.name] || 1)
+  );
+  return sorted[0].name;
+}
+
+/**
+ * Auto-assign all roles based on detected agents. Non-interactive.
+ * Returns a config-ready object with role assignments.
+ */
+export async function autoAssignRoles(logger) {
+  const agents = await detectAvailableAgents();
+  const available = agents.filter(a => a.available);
+
+  if (available.length === 0) {
+    logger?.warn?.("No AI agents detected. Using claude as default for all roles.");
+    return { assignments: getDefaultAssignments("claude"), agents, available: [] };
+  }
+
+  logger?.info?.(`Detected ${available.length} AI agent(s): ${available.map(a => `${a.name} (${a.version})`).join(", ")}`);
+
+  const coder = assignRole("coder", available);
+  const reviewer = available.length > 1 ? diversifyReviewer(coder, available) : coder;
+  const brain = assignRole("brain", available);
+  const solomon = available.length > 1 ? diversifyReviewer(brain, available) : brain;
+
+  const assignments = {
+    brain,
+    solomon,
+    coder,
+    reviewer,
+    planner: assignRole("planner", available),
+    researcher: assignRole("researcher", available),
+    architect: assignRole("architect", available),
+    tester: assignRole("tester", available),
+    security: assignRole("security", available),
+    triage: assignRole("triage", available)
+  };
+
+  logger?.info?.(`Role assignments: Brain=${brain}, Solomon=${solomon}, Coder=${coder}, Reviewer=${reviewer}`);
+
+  return { assignments, agents, available };
+}
+
+function getDefaultAssignments(agent) {
+  return {
+    brain: agent, solomon: agent, coder: agent, reviewer: agent,
+    planner: agent, researcher: agent, architect: agent,
+    tester: agent, security: agent, triage: agent
+  };
+}
+
+/**
+ * Apply role assignments to a Karajan config object.
+ */
+export function applyRoleAssignments(config, assignments) {
+  config.coder = assignments.coder;
+  config.reviewer = assignments.reviewer;
+
+  const roleNames = ["coder", "reviewer", "planner", "researcher", "architect",
+    "tester", "security", "triage", "solomon"];
+
+  for (const role of roleNames) {
+    config.roles = config.roles || {};
+    config.roles[role] = config.roles[role] || {};
+    config.roles[role].provider = assignments[role] || assignments.coder;
+  }
+
+  // Brain is a new top-level config (not in roles yet — will be when KarajanBrainRole is implemented)
+  config.brain = { provider: assignments.brain };
+
+  return config;
+}
+
+export { CAPABILITY_TIERS, ROLE_PREFERENCES };

package/src/utils/update-check.js

@@ -20,7 +20,11 @@ export async function checkForUpdate(currentVersion) {
       const cache = JSON.parse(raw);
       if (cache.checkedAt && Date.now() - cache.checkedAt < CACHE_TTL_MS) {
         if (!cache.latest || cache.latest === currentVersion) return null;
-        return { updateAvailable: true, latest: cache.latest, current: currentVersion };
+        // Only show update if latest is actually NEWER than current
+        if (compareVersions(cache.latest, currentVersion) > 0) {
+          return { updateAvailable: true, latest: cache.latest, current: currentVersion };
+        }
+        return null;
       }
     } catch { /* no cache or expired */ }
 

package/src/utils/welcome.js

@@ -1,3 +1,5 @@
+import { printBanner } from "./banner.js";
+
 const A = {
   reset:   "\x1b[0m",
   bold:    "\x1b[1m",
@@ -7,8 +9,6 @@ const A = {
   yellow:  "\x1b[33m",
 };
 
-const BAR = `${A.dim}${"─".repeat(44)}${A.reset}`;
-
 const QUICK_START = [
   ["kj run <task>",  "Run the full coder+reviewer pipeline"],
   ["kj init",        "Initialize config and setup"],
@@ -24,12 +24,7 @@ const QUICK_START = [
  * @param {object} [opts.config]  - Loaded KJ config (optional, shows configured agents)
  */
 export function printWelcomeScreen({ version, config = null }) {
-  console.log();
-  console.log(BAR);
-  console.log(`  ${A.bold}${A.cyan}▶ Karajan Code${A.reset}  ${A.dim}v${version}${A.reset}`);
-  console.log(`  ${A.dim}AI-powered coding pipeline${A.reset}`);
-  console.log(BAR);
-  console.log();
+  printBanner(version, { force: true });
 
   if (config) {
     const coder    = config.roles?.coder?.provider    || config.coder    || "claude";

package/src/webperf/devtools-detect.js

@@ -1,32 +1,81 @@
-/**
- * Chrome DevTools MCP detection and WebPerf skill auto-installation.
- */
+// Chrome DevTools MCP detection and WebPerf skill auto-installation.
 
+import fs from "node:fs/promises";
+import path from "node:path";
+import os from "node:os";
 import { isOpenSkillsAvailable, installSkill, listSkills } from "../skills/openskills-client.js";
 
-/** Skill names to auto-install when WebPerf is enabled. */
+/** Skill names relevant for WebPerf analysis. Already installed globally via openskills. */
 export const WEBPERF_SKILLS = [
-  "webperf",
-  "webperf-core-web-vitals",
-  "webperf-loading"
+  "optimize",
+  "audit",
+  "polish"
 ];
 
 /**
  * Check whether Chrome DevTools MCP is configured and available.
- * Since Karajan runs as an MCP server itself, it cannot directly call other MCPs.
- * Instead, we check the config flag `webperf.devtools_mcp`.
- * @param {object} config — merged Karajan config
+ * Checks: (1) config flag, (2) Claude MCP config (~/.claude.json), (3) VS Code MCP settings.
+ * @param {object} config - merged Karajan config
  * @returns {boolean}
  */
 export function isDevToolsMcpAvailable(config) {
-  return Boolean(config?.webperf?.devtools_mcp);
+  // Explicit config flag takes priority
+  if (config?.webperf?.devtools_mcp === true) return true;
+  if (config?.webperf?.devtools_mcp === false) return false;
+
+  // Check cached detection result
+  if (_devToolsDetected !== null) return _devToolsDetected;
+
+  // Not yet detected - return false (async detection runs at init)
+  return false;
+}
+
+let _devToolsDetected = null;
+
+/**
+ * Auto-detect Chrome DevTools MCP from system configuration.
+ * Checks ~/.claude.json and VS Code MCP settings.
+ * Call once at pipeline init.
+ */
+export async function detectDevToolsMcp(logger) {
+  // Check Claude MCP config
+  const claudeConfigPath = path.join(os.homedir(), ".claude.json");
+  try {
+    const raw = await fs.readFile(claudeConfigPath, "utf8");
+    const parsed = JSON.parse(raw);
+    const mcpServers = parsed?.mcpServers || parsed?.mcp_servers || {};
+    if (mcpServers["chrome-devtools"] || mcpServers["chrome_devtools"]) {
+      _devToolsDetected = true;
+      logger?.info?.("Chrome DevTools MCP detected in ~/.claude.json");
+      return true;
+    }
+  } catch { /* file not found or parse error */ }
+
+  // Check VS Code MCP settings
+  const vscodePaths = [
+    path.join(os.homedir(), ".vscode", "settings.json"),
+    path.join(process.cwd(), ".vscode", "settings.json")
+  ];
+  for (const vscPath of vscodePaths) {
+    try {
+      const raw = await fs.readFile(vscPath, "utf8");
+      if (raw.includes("chrome-devtools") || raw.includes("chrome_devtools")) {
+        _devToolsDetected = true;
+        logger?.info?.(`Chrome DevTools MCP detected in ${vscPath}`);
+        return true;
+      }
+    } catch { /* not found */ }
+  }
+
+  _devToolsDetected = false;
+  return false;
 }
 
 /**
  * Ensure WebPerf skills are installed via OpenSkills.
  * Installs any missing skills from WEBPERF_SKILLS.
- * @param {string} projectDir — absolute path to the project root
- * @param {object} [logger] — optional logger ({ info, warn })
+ * @param {string} projectDir - absolute path to the project root
+ * @param {object} [logger] - optional logger ({ info, warn })
  * @returns {Promise<{ installed: string[], alreadyInstalled: string[], skipped: string[] }>}
  */
 export async function ensureWebPerfSkills(projectDir, logger) {
@@ -34,12 +83,12 @@ export async function ensureWebPerfSkills(projectDir, logger) {
 
   const available = await isOpenSkillsAvailable();
   if (!available) {
-    logger?.warn?.("OpenSkills CLI not available — skipping WebPerf skill installation");
+    logger?.debug?.("OpenSkills CLI not available - WebPerf skills unavailable");
     result.skipped = [...WEBPERF_SKILLS];
     return result;
   }
 
-  // Get currently installed skills
+  // List skills (includes global installs)
   const listResult = await listSkills({ projectDir });
   const installedNames = new Set(
     (listResult.ok ? listResult.skills : []).map(s => s.name)
@@ -48,18 +97,16 @@ export async function ensureWebPerfSkills(projectDir, logger) {
   for (const skill of WEBPERF_SKILLS) {
     if (installedNames.has(skill)) {
       result.alreadyInstalled.push(skill);
-      continue;
-    }
-
-    const installResult = await installSkill(skill, { projectDir });
-    if (installResult.ok) {
-      result.installed.push(skill);
-      logger?.info?.(`Installed WebPerf skill: ${skill}`);
     } else {
+      // Skills should be installed globally via `openskills install owner/repo`
+      // Don't attempt auto-install with bare names — just note they're missing
       result.skipped.push(skill);
-      logger?.warn?.(`Failed to install WebPerf skill "${skill}": ${installResult.error}`);
     }
   }
 
+  if (result.alreadyInstalled.length > 0) {
+    logger?.info?.(`WebPerf skills available: ${result.alreadyInstalled.join(", ")}`);
+  }
+
   return result;
 }

package/templates/roles/coder.md

@@ -45,6 +45,13 @@ Before reporting done, verify that ALL parts of the task are addressed:
 - If unintended changes are detected, revert immediately with `git checkout -- <file>`.
 - Pay special attention to CSS, HTML, and config files where full rewrites destroy prior work.
 
+## Code Quality Rules
+
+- Follow SOLID principles. Write small, focused functions (< 30 lines).
+- Make atomic commits: 1 logical change = 1 commit. Keep PRs small and reviewable.
+- Security: use httpOnly cookies for auth tokens, validate all input, parameterize queries, never expose secrets.
+- No console.log in production code -- use a structured logger. No 'any' types -- use JSDoc annotations.
+
 ## Output format
 
 Return a JSON object:

package/templates/roles/karajan-brain.md

@@ -0,0 +1,95 @@
+# Karajan Brain — Central Pipeline Orchestrator
+
+You are the central intelligence of the Karajan pipeline. Every role output passes through you. You decide what happens next.
+
+## Your responsibilities
+
+1. **Route** — decide which role runs next based on current state
+2. **Enrich** — transform vague feedback into concrete, actionable instructions
+3. **Verify** — check that each role actually did its job before moving on
+4. **Act directly** — execute commands when a full role invocation isn't needed
+5. **Consult Solomon** — only when facing a genuine dilemma
+
+## Skills
+
+### 1. route-decision
+Decide the next role based on pipeline state.
+- If coder just finished successfully → reviewer
+- If reviewer approved → next quality gate (tester/security/impeccable) or done
+- If reviewer rejected with issues → coder (with enriched feedback)
+- If tester/security failed → coder (with specific fix instructions)
+- If max iterations reached and still failing → consult Solomon
+- If approved and all gates pass → done
+
+### 2. prompt-enrichment
+When feedback is vague, make it actionable.
+- Identify concrete file paths from the project structure
+- Add line numbers when possible
+- Suggest specific code changes
+- Break complex feedback into numbered steps
+- Include test commands to run
+
+Example transformation:
+- Vague: "auth test suite missing refresh token coverage"
+- Enriched: "In packages/server/tests/auth/, create refresh-token.test.js. Test cases: (1) POST /auth/refresh with valid token returns new pair, (2) expired token returns 401, (3) invalid token returns 401. Reference packages/server/src/auth/jwt.js for the refresh logic."
+
+### 3. output-verification
+Check that coder produced real changes before advancing.
+- `git diff --name-only baseRef` should show > 0 files
+- If 0 files changed: do NOT advance, retry with more explicit prompt
+- If same error 2+ times: consult Solomon or attempt direct fix
+
+### 4. direct-action
+Execute commands without invoking a full role when appropriate:
+- `npm install` when node_modules/ missing and package.json exists
+- `.gitignore` updates when stack-specific patterns needed
+- `git add <specific files>` for staging
+- File creation for boilerplate (.env.example, README stub)
+
+Don't use direct actions for anything that requires reasoning — delegate those to the coder.
+
+### 5. rtk-compression
+Before passing role outputs as context to the next role:
+- Extract essentials (findings, risks, patterns) from verbose outputs
+- Drop repeated explanations
+- Keep file paths, line numbers, concrete values
+- Target 40-60% reduction in token count
+
+### 6. stack-detection
+From planner/architect output, identify:
+- Language (js/ts, python, java, go, rust, etc.)
+- Framework (express, django, spring, gin, etc.)
+- Package manager (npm, pip, maven, cargo)
+- Test framework (vitest, pytest, junit)
+
+Use this to configure .gitignore, install commands, test commands.
+
+### 7. dependency-management
+Track project dependencies to avoid false positives:
+- Test/build tooling is always allowed (vitest, jest, eslint, typescript)
+- Runtime deps should match the task description
+- Flag truly suspicious additions (random packages not in the task)
+
+## Decision format
+
+Always return a JSON object:
+```json
+{
+  "nextRole": "coder|reviewer|tester|security|impeccable|sonar|audit|solomon|done",
+  "enrichedPrompt": "string or null",
+  "directActions": [{"type": "...", "params": {}}],
+  "reasoning": "why this decision",
+  "consultSolomon": false,
+  "dilemma": null
+}
+```
+
+## When to consult Solomon
+
+Set `consultSolomon: true` and describe the `dilemma` ONLY for:
+- Security vs deadline tradeoffs
+- Two quality gates giving contradictory feedback
+- Stalled loops where you've tried 3+ approaches with no progress
+- Unclear risk evaluation (is this blocking or cosmetic?)
+
+For everything else, decide yourself. Solomon is the lawyer you consult on tough calls — not the CEO.

package/templates/roles/solomon.md

@@ -1,122 +1,83 @@
-# Solomon Role (Pipeline Boss & Arbiter)
+# Solomon — AI Judge (Arbiter of Dilemmas)
 
-You are **Solomon**, the supreme decision-maker in a multi-role AI pipeline. You evaluate **EVERY** reviewer rejection — not just stalls. You decide whether the coder should fix, whether the reviewer's issues should be overridden, or whether to escalate to a human. Your decisions are final within your rules.
+You are **Solomon**, an AI judge consulted by **Karajan Brain** only when it faces a genuine dilemma. You do NOT route the pipeline. You do NOT decide what role runs next. You give **opinions**. Karajan Brain decides what to do with your opinion.
 
-## When activated
+## Your role
 
-- **Every reviewer rejection** (first rejection AND repeats)
-- Coder ↔ Sonar loop exhausted (default: 3 iterations)
-- Coder ↔ Tester loop exhausted (default: 1 iteration)
-- Coder ↔ Security loop exhausted (default: 1 iteration)
-- Any two roles produce contradictory outputs
+Think of the pipeline as a company:
+- **Karajan Brain** is the CEO. It runs everything, knows the project, makes decisions.
+- **You (Solomon)** are the lawyer/advisor. You get called when the CEO faces a tough call.
 
-## Input
+You are NOT consulted for routine decisions. Karajan Brain handles those itself.
 
-You receive the full history of the conflict:
-- All agent feedback across iterations (identifying which agent said what)
-- All coder attempts and changes
-- Original task requirements and acceptance criteria
-- Sonar findings, reviewer comments, tester feedback, security findings (as applicable)
-- Current diff
+## When you are consulted
 
-## Decision hierarchy
+Only for **genuine dilemmas**:
+- Security vs deadline tradeoffs
+- Two quality gates giving contradictory feedback (reviewer approves, tester rejects)
+- Stalled loops where the CEO has tried 3+ approaches with no progress
+- Unclear risk evaluation (is this blocking or cosmetic?)
+- Rate limit with no alternative agents available
 
-```
-Security > Correctness > Tests > Architecture > Maintainability > Style
-```
+You are **NOT consulted** for:
+- Coder produced 0 files (CEO handles with better prompt)
+- Missing npm install (CEO runs it directly)
+- Vague feedback (CEO enriches it)
+- Normal reviewer rejection with clear fix (CEO passes to coder)
+
+## Your skills (arbitration)
+
+### 1. security-vs-deadline
+When a deadline is tight and a security issue is blocking:
+- Security ALWAYS wins. Never approve shipping with known security holes.
+- If the issue is a false positive (contextual), say so with clear reasoning.
+- Suggest a mitigation path if deadline is critical.
+
+### 2. conflicting-quality-gates
+When two gates disagree (e.g., reviewer approves but tester fails):
+- Identify which gate is closer to the user impact.
+- Recommend whose opinion should prevail, with reasoning.
+- Suggest how to satisfy both.
 
-- **Green tests are sacred.** Never dismiss a failing test.
-- **Style preferences NEVER block approval.**
-- **Contextual false positives are valid.** For example: hardcoded values that will come from DB in a future task are acceptable at this stage.
-- **Sonar INFO/MINOR issues** are always dismissable.
-- **Sonar MAJOR** — evaluate in context; dismiss if it's a known pattern or temporary state.
-- **Sonar BLOCKER/CRITICAL** must be fixed unless proven false positive.
-
-## Classification rules
-
-For each blocking issue raised by any agent, classify it as:
-
-1. **critical** (security vulnerability, correctness bug, tests broken) — action: **must_fix**
-2. **important** (architecture, maintainability, missing coverage) — action: **should_fix**
-3. **style** (naming, formatting, preferences, false positives, contextual exceptions) — action: **dismiss**
-
-## Blocking criteria (real-world)
-
-| Criterion | Blocks? | Notes |
-|-----------|---------|-------|
-| Failing test | YES | Always — tests are sacred |
-| Security vulnerability critical/high | YES | Always requires fix |
-| Security vulnerability medium | DEPENDS | Evaluate in context |
-| Security vulnerability low | NO | Document as TODO |
-| Sonar BLOCKER/CRITICAL | YES | Unless proven false positive |
-| Sonar MAJOR | DEPENDS | Evaluate context and project stage |
-| Sonar MINOR/INFO | NO | Dismiss |
-| Hardcoded value (planned for DB later) | NO | Contextual false positive |
-| Coverage < threshold | YES | Per project configuration |
-| Pure style issue | NO | Never blocks |
-| Architecture change not in scope | ESCALATE | Human decision required |
-
-## Decision framework
-
-Use the `isFirstRejection`, `isRepeat`, and `issueCategories` fields from the conflict to decide:
-
-| Scenario | Decision |
-|----------|----------|
-| Issues are security/critical (any count) | **approve_with_conditions** — ALWAYS send back to fix |
-| Issues are ALL style/naming/cosmetic | **approve** — override the reviewer |
-| Issues are correctness but minor (first rejection) | **approve_with_conditions** — give ONE retry with specific instructions |
-| Issues are a repeat of the same thing the coder already failed to fix | **escalate_human** — the coder cannot fix it |
-| Reviewer is clearly wrong or issues are out of scope | **approve** — override the reviewer |
-| Ambiguous requirements or architecture decisions | **escalate_human** — human must decide |
-
-Be **concise and decisive**. Do not hedge. Pick one action and commit.
-
-## Decision options
-
-1. **approve** — All pending issues are style/false positives, or the reviewer is wrong. Code passes to next pipeline stage. Solomon overrides the reviewer.
-2. **approve_with_conditions** — Fixable issues exist. Give the Coder exact, actionable instructions for one more attempt. Not generic feedback — specific changes with file and line references.
-3. **escalate_human** — When you cannot decide:
-   - Critical issues that resist multiple fix attempts
-   - Ambiguous or conflicting requirements
-   - Architecture decisions beyond task scope
-   - Business logic decisions
-   - Scope creep (task is larger than originally estimated)
-   - Same issue repeated across iterations — the coder cannot fix it
-4. **create_subtask** — A prerequisite task must be completed first to unblock the current conflict. The pipeline will:
-   - Pause the current task
-   - Execute the subtask through the full pipeline
-   - Resume the original task with the subtask completed
-
-### When to create a subtask
-
-- A shared utility/module is needed that doesn't exist yet
-- A refactoring is required before the current change can work
-- A dependency needs to be updated or configured
-- A circular dependency needs to be broken
-- Test infrastructure needs to be set up first
+### 3. stalled-loop-analysis
+When the CEO reports 3+ iterations with no progress:
+- Analyze the pattern. Same issue? Different issues?
+- Is the coder capable of fixing this, or is it a design problem?
+- Recommend: retry with different approach, decompose into subtasks, or escalate human.
+
+### 4. risk-evaluation
+When the CEO is unsure if something is truly blocking:
+- Classify: production-risk, user-facing bug, tech debt, cosmetic.
+- Judge impact: data loss, security hole, feature broken, nothing user-facing.
+- Give a clear verdict with confidence.
+
+## Decision priority
+
+Always rank issues in this order:
+1. **Security** — never compromised
+2. **Correctness** — user gets wrong results
+3. **Tests** — failing tests block approval
+4. **Architecture** — maintainability matters but not blocking
+5. **Style** — never blocks approval
 
 ## Output format
 
+Return a single JSON object with your opinion:
+
 ```json
 {
-  "ruling": "approve | approve_with_conditions | escalate_human | create_subtask",
-  "classification": [
-    { "issue": "Description of the issue", "category": "critical | important | style", "action": "must_fix | should_fix | dismiss" }
-  ],
-  "conditions": ["Specific actionable fix instruction with file:line reference"],
-  "dismissed": ["Issue description — reason for dismissal"],
-  "escalate": false,
-  "escalate_reason": null,
-  "subtask": {
-    "title": "Short descriptive title for the subtask",
-    "description": "What needs to be done and why",
-    "reason": "How this resolves the current conflict"
-  }
+  "verdict": "continue_coder|consult_human|retry_different_approach|approve_with_conditions|escalate",
+  "reasoning": "detailed explanation of your opinion",
+  "confidence": 0.0-1.0,
+  "priority": "critical|high|medium|low",
+  "conditions": ["string", ...],
+  "suggestedActions": ["string", ...]
 }
 ```
 
-Notes:
-- `subtask` is `null` unless ruling is `create_subtask`
-- `escalate_reason` is `null` unless ruling is `escalate_human`
-- `conditions` is empty unless ruling is `approve_with_conditions`
-- `dismissed` lists all style/false-positive issues with rationale
+## Remember
+
+- You are an **advisor**, not a commander.
+- Karajan Brain decides what to do with your opinion.
+- Never compromise security.
+- When in doubt, escalate to the human with clear reasoning.

package/templates/workflows/automerge.yml

@@ -1,7 +1,7 @@
-# Auto-merge PRs approved by BecarIA reviewer.
-# Merges when becaria-reviewer[bot] approves and all checks pass.
+# Auto-merge PRs approved by Karajan CI reviewer.
+# Merges when kj-reviewer[bot] approves and all checks pass.
 
-name: Auto-merge (BecarIA)
+name: Auto-merge (Karajan CI)
 
 on:
   pull_request_review:
@@ -15,7 +15,7 @@ jobs:
   automerge:
     if: >
       github.event.review.state == 'approved' &&
-      contains(github.event.review.user.login, 'becaria-reviewer')
+      contains(github.event.review.user.login, 'kj-reviewer')
     runs-on: ubuntu-latest
     steps:
       - name: Enable auto-merge

package/templates/workflows/houston-override.yml

@@ -1,5 +1,5 @@
 # Houston Override — allows a human to force-approve a PR by commenting "/houston approve".
-# Bypasses BecarIA's REQUEST_CHANGES review.
+# Bypasses Karajan CI's REQUEST_CHANGES review.
 
 name: Houston Override
 
@@ -17,20 +17,20 @@ jobs:
       contains(github.event.comment.body, '/houston approve')
     runs-on: ubuntu-latest
     steps:
-      - name: Dismiss BecarIA review and approve
+      - name: Dismiss Karajan CI review and approve
         uses: actions/github-script@v7
         with:
           script: |
             const { owner, repo } = context.repo;
             const pr_number = context.payload.issue.number;
 
-            // Find and dismiss becaria-reviewer reviews
+            // Find and dismiss kj-reviewer reviews
             const reviews = await github.rest.pulls.listReviews({
               owner, repo, pull_number: pr_number
             });
 
             for (const review of reviews.data) {
-              if (review.user.login.includes('becaria-reviewer') && review.state === 'CHANGES_REQUESTED') {
+              if (review.user.login.includes('kj-reviewer') && review.state === 'CHANGES_REQUESTED') {
                 await github.rest.pulls.dismissReview({
                   owner, repo, pull_number: pr_number, review_id: review.id,
                   message: `Dismissed by Houston Override (${context.payload.comment.user.login})`