@jaybeeuu/agent-cortex 2.1.0 → 2.3.0

package/.changeset/README.md

@@ -1,8 +0,0 @@
-# Changesets
-
-Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
-with multi-package repos, or single-package repos to help you version and publish your code. You can
-find the full documentation for it [in our repository](https://github.com/changesets/changesets).
-
-We have a quick list of common questions to get you started engaging with this project in
-[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).

package/.changeset/config.json

@@ -1,11 +0,0 @@
-{
-  "$schema": "https://unpkg.com/@changesets/config@3.1.4/schema.json",
-  "changelog": "@changesets/cli/changelog",
-  "commit": false,
-  "fixed": [],
-  "linked": [],
-  "access": "public",
-  "baseBranch": "main",
-  "updateInternalDependencies": "patch",
-  "ignore": []
-}

package/.github/workflows/ci.yml

@@ -1,302 +0,0 @@
-name: CI
-
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-    # The default types (opened/synchronize/reopened) would make the documented
-    # `no-publish` opt-out unreachable: labelling a PR after the check failed
-    # would never re-trigger it, and a manual re-run replays the original event
-    # payload. Label events keep the gate honest in both directions — adding the
-    # label turns it green, removing it turns it red again.
-    types: [opened, synchronize, reopened, labeled, unlabeled]
-
-jobs:
-  setup:
-    name: Setup
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      - name: Setup pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 12
-          run_install: false
-
-      - name: Cache pnpm store
-        uses: actions/cache@v4
-        with:
-          path: ~/.pnpm-store
-          key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
-          restore-keys: |
-            ${{ runner.os }}-pnpm-
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      - name: Build
-        run: pnpm build
-
-
-  changeset-check:
-    name: Changeset check
-    # The gate is a pure, idempotent recomputation of the diff plus PR metadata,
-    # so every pull_request event must run it. Do NOT narrow this to the
-    # labels that can change the verdict: GitHub reports a skipped job as a
-    # success (docs.github.com - about-status-checks), so skipping on unrelated
-    # label churn would silently turn a failing gate green and let a
-    # changeset-less PR merge.
-    if: github.event_name == 'pull_request'
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      # Publishing is the default: every PR must add a changeset. The only
-      # exemptions are the changesets bot's Version Packages PR (it consumes
-      # changesets and adds none) and PRs explicitly labelled `no-publish`.
-      # Deciding that in code keeps the rule unit-tested; this step only feeds
-      # it the diff and the PR metadata.
-      - name: Require a changeset unless labelled no-publish
-        env:
-          BASE_REF: ${{ github.event.pull_request.base.ref }}
-          PR_HEAD_REF: ${{ github.event.pull_request.head.ref }}
-          PR_ACTOR: ${{ github.event.pull_request.user.login }}
-          PR_LABELS: ${{ toJSON(github.event.pull_request.labels.*.name) }}
-        run: |
-          git diff --name-status "origin/${BASE_REF}...HEAD" | node scripts/check-changeset.mjs
-
-  lint:
-    name: Lint
-    needs: setup
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      - name: Cache pnpm store
-        uses: actions/cache@v4
-        with:
-          path: ~/.pnpm-store
-          key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
-          restore-keys: |
-            ${{ runner.os }}-pnpm-
-
-      - name: Setup pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 12
-          run_install: false
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      - name: Lint
-        run: pnpm lint
-
-  test:
-    name: Test
-    needs: setup
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      - name: Cache pnpm store
-        uses: actions/cache@v4
-        with:
-          path: ~/.pnpm-store
-          key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
-          restore-keys: |
-            ${{ runner.os }}-pnpm-
-
-      - name: Setup pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 12
-          run_install: false
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      - name: Test
-        run: pnpm test
-
-  claude-plugin-check:
-    name: Claude plugin materialiser check
-    needs: setup
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      - name: Cache pnpm store
-        uses: actions/cache@v4
-        with:
-          path: ~/.pnpm-store
-          key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
-          restore-keys: |
-            ${{ runner.os }}-pnpm-
-
-      - name: Setup pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 12
-          run_install: false
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      # The claude/ subtree is retired — the installer is the only generator
-      # (plain `agent-cortex install claude` materialises ~/.agent-cortex/claude;
-      # `--output <dir>` is generate-only for tests). There is no committed
-      # output to diff, so this job validates the materialiser itself: it must
-      # produce a complete, structural plugin (generated + hand-authored pieces),
-      # no symlinks, no literal {{TOOL:/{{PATH:/{{SECTION: tokens, and a
-      # plugin.json version tracking the package — exactly what a real install
-      # would ship.
-      - name: Materialise the Claude plugin and run structural checks
-        run: |
-          set -euo pipefail
-          OUT="$RUNNER_TEMP/claude-plugin-check"
-          node bin/agent-cortex.mjs install claude --output "$OUT"
-
-          # structure: generated + hand-authored pieces all present
-          test -f "$OUT/.claude-plugin/plugin.json"
-          test -f "$OUT/agents/plan.md"
-          test -f "$OUT/agents/ralph.md"
-          test -f "$OUT/skills/tdd/SKILL.md"
-          test -f "$OUT/hooks.json"
-          test -f "$OUT/hooks/scripts/notify.mjs"
-          test -f "$OUT/.mcp.json"
-          test -f "$OUT/scripts/statusline-command.sh"
-
-          # flat-copy guarantee: no symlinks in the materialised tree
-          if [ -n "$(find "$OUT" -type l)" ]; then
-            echo "::error::symlinks found in materialised Claude plugin"
-            exit 1
-          fi
-
-          # token substitution: no literal tokens survive materialisation
-          TOKENS=$(grep -rlE '\{\{(TOOL|PATH|SECTION):' "$OUT" || true)
-          if [ -n "$TOKENS" ]; then
-            echo "::error::literal substitution tokens in materialised Claude plugin:"
-            echo "$TOKENS"
-            exit 1
-          fi
-
-          # plugin version tracks the package (never stale)
-          PKG_VERSION=$(node -p "require('./package.json').version")
-          PLUGIN_VERSION=$(node -p "require('$OUT/.claude-plugin/plugin.json').version")
-          test "$PKG_VERSION" = "$PLUGIN_VERSION"
-
-  release:
-    name: Release
-    needs: [lint, test, claude-plugin-check]
-    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      pull-requests: write
-      # npm Trusted Publishing (OIDC): npm exchanges this id-token for a
-      # short-lived npm token at publish time — no token config or secret.
-      id-token: write
-    concurrency: ${{ github.workflow }}-${{ github.ref }}
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Setup Node
-        uses: actions/setup-node@v6
-        with:
-          node-version: 24
-
-      - name: Cache pnpm store
-        uses: actions/cache@v4
-        with:
-          path: ~/.pnpm-store
-          key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
-          restore-keys: |
-            ${{ runner.os }}-pnpm-
-
-      - name: Setup pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 12
-          run_install: false
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      # Labels are invisible on a push event, so resolve the PR merged for this
-      # commit through the API and read its labels. No new secret or scope: the
-      # job already holds pull-requests: write, gh is preinstalled, and
-      # GITHUB_TOKEN is already here. A commit with no merged PR (direct push)
-      # resolves to no labels — publish stays the default, so attempting to
-      # publish an already-published version still fails loudly.
-      - name: Resolve publish command
-        id: gate
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          labels=$(gh api "repos/${{ github.repository }}/commits/${{ github.sha }}/pulls" \
-            --jq '[.[] | select(.merged_at != null) | .labels[].name]')
-          publish=$(node scripts/resolve-publish-command.mjs "$labels")
-          echo "publish=${publish}" >> "$GITHUB_OUTPUT"
-
-      - name: Create Release Pull Request or Publish
-        id: changesets
-        uses: changesets/action@v1
-        with:
-          # changesets/action execs these inputs via @actions/exec with NO shell:
-          # the string is split by argStringToArray on whitespace (single quotes
-          # survive literally), so each must be a single unquoted command token
-          # that runs a pnpm script. version-packages bumps the package version
-          # and rewrites CHANGELOG.md, and nothing else is committed: the Claude
-          # plugin is materialised at install time with the package version, so
-          # there is no committed output to regenerate.
-          version: pnpm version-packages
-          # pnpm publish-package when the merged PR is unlabelled, pnpm
-          # publish-noop when it carries `no-publish`.
-          publish: ${{ steps.gate.outputs.publish }}
-          commit: "chore: version packages"
-          title: "chore: version packages"
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          # Publish authenticates via npm Trusted Publishing (OIDC token
-          # exchange at publish time) — no NPM_TOKEN secret, no token config.
-          # Requires the one-time npm-side setup: npmjs.com → @jaybeeuu/
-          # agent-cortex → Access → Trusted Publishing, tied to GitHub repo
-          # jaybeeuu/agent-cortex + workflow .github/workflows/ci.yml.

package/.junie/guidelines.md

@@ -1,87 +0,0 @@
-# Beads Issue Tracking Instructions
-
-This project uses **Beads (bd)** for issue tracking. Use the bd CLI or MCP tools for all task management.
-
-## Core Workflow Rules
-
-1. **Track ALL work in bd** - Never use markdown TODOs or comment-based task lists
-2. **Check ready work first** - Run `bd ready` to find unblocked issues
-3. **Always include descriptions** - Provide meaningful context when creating issues
-4. **Link discovered work** - Use `discovered-from` dependencies for issues found during work
-5. **Sync at session end** - Run `bd dolt push` before ending your session
-
-## Quick Command Reference
-
-### Finding Work
-```bash
-bd ready              # Show unblocked issues ready for work
-bd list --status open # List all open issues
-bd show <id>          # View issue details
-bd blocked            # Show blocked issues and their blockers
-```
-
-### Creating Issues
-```bash
-bd create "Title" --description="Details" -t bug|feature|task -p 0-4 --json
-bd create "Found bug" --description="Details" --deps discovered-from:bd-42 --json
-```
-
-### Working on Issues
-```bash
-bd update <id> --claim               # Claim work atomically
-bd update <id> --priority 1          # Change priority
-bd close <id> --reason "Completed"   # Mark complete
-```
-
-### Dependencies
-```bash
-bd dep add <issue> <depends-on>      # Add dependency (issue depends on depends-on)
-bd dep add <issue> <depends-on> --type=related  # Soft link
-```
-
-### Syncing
-```bash
-bd dolt push  # ALWAYS run at session end - commits and pushes changes
-```
-
-## Issue Types
-
-- `bug` - Something broken that needs fixing
-- `feature` - New functionality
-- `task` - Work item (tests, docs, refactoring)
-- `epic` - Large feature composed of multiple issues
-- `chore` - Maintenance work (dependencies, tooling)
-
-## Priorities
-
-- `0` - Critical (security, data loss, broken builds)
-- `1` - High (major features, important bugs)
-- `2` - Medium (default, nice-to-have)
-- `3` - Low (polish, optimization)
-- `4` - Backlog (future ideas)
-
-## MCP Tools Available
-
-If the MCP server is configured, you can use these tools directly:
-- `mcp_beads_ready` - Find ready tasks
-- `mcp_beads_list` - List issues with filters
-- `mcp_beads_show` - Show issue details
-- `mcp_beads_create` - Create new issues
-- `mcp_beads_update` - Update issue status/priority
-- `mcp_beads_close` - Close completed issues
-- `mcp_beads_dep` - Manage dependencies
-- `mcp_beads_blocked` - Show blocked issues
-- `mcp_beads_stats` - Get issue statistics
-
-## Important Rules
-
-- ✅ Use bd for ALL task tracking
-- ✅ Always use `--json` flag for programmatic use
-- ✅ Link discovered work with `discovered-from` dependencies
-- ✅ Check `bd ready` before asking "what should I work on?"
-- ✅ Run `bd dolt push` at end of session
-- ❌ Do NOT create markdown TODO lists
-- ❌ Do NOT use external issue trackers
-- ❌ Do NOT duplicate tracking systems
-
-For more details, run `bd --help` or see the project's AGENTS.md file.

package/.junie/mcp/mcp.json

@@ -1,10 +0,0 @@
-{
-  "mcpServers": {
-    "beads": {
-      "args": [
-        "mcp"
-      ],
-      "command": "bd"
-    }
-  }
-}

package/AGENTS.md

@@ -1,153 +0,0 @@
-# AGENTS.md
-
-Instructions for agents working on this repository.
-
-## What This Repo Is
-
-A personal collection of custom agents and skills, shipped to pi and Claude Code, plus PI
-extensions and Claude hooks for enhancing the coding agent runtime. Changes here affect the
-behaviour of every agent, skill, and PI extension available in the author's coding sessions.
-
-## Structure
-
-```
-agent-cortex/
-├── package.json           # PI package manifest (pi: { extensions, skills }) + pi runtime deps
-├── agents/                # Custom agents — canonical composable <name>/ dirs
-│   ├── ralph/             #   composable format (shared agent.md + pi/, claude/) — see agents/README.md
-│   ├── plan/              #   "
-│   ├── ralph-plan/        #   "
-│   └── strategy/          #   "
-├── skills/               # Grouped by domain, discovered recursively
-│   ├── planning/         # Scope, spec, decompose
-│   ├── engineering/      # The coding loop
-│   ├── productivity/     # Workflow tooling
-│   ├── style/            # Conventions and standards
-│   ├── workflow/         # Orchestration and pipeline
-│   └── review/           # Auditing and maintenance
-├── extensions/           # PI extensions (one directory per extension, each with index.ts)
-│   └── skill-stats/
-│       ├── README.md      # Installation & usage
-│       └── index.ts       # Extension entrypoint
-├── hooks/                # Canonical Claude Code hooks (hooks.json + scripts — see docs/claude-hooks.md)
-│   └── claude/           #   generated into the plugin's hooks.json + hooks/ by bin/installers/claude.mjs
-├── claude/               # Committed Claude user-settings template — merged into ~/.claude/settings.json on install
-├── claude-extras/        # Hand-authored Claude plugin extras
-│   ├── .mcp.json         # MCP servers (context7, github) — copied into installs
-│   └── scripts/          # statusline-command.sh — copied into installs (executable)
-└── package.json          # PI package manifest (pi: { extensions, skills }) + pi runtime deps
-```
-
-## Versioning
-
-Use `pnpm changeset` for all version bumps. Never edit versions manually.
-`package.json` and `CHANGELOG.md` stay in lockstep automatically.
-See the `style-versioning` skill for the full workflow.
-
-## Changelog
-
-Generated automatically by changesets. Do not edit `CHANGELOG.md` manually.
-
-## Coding Conventions
-
-- **Landing method**: pull requests are squash-merged. Merge commits are disabled in the
-  repository settings and `main` requires linear history, so a branch's own commit shape never
-  reaches `main` — bring a behind branch up to date by merging `main` in rather than rebasing it.
-  `docs/commit-signing.md` records why squash is the only landing path that produces a signed
-  commit; the rebase-versus-merge reasoning lives in the `git-workflow` skill.
-- **Never block the main thread**: no `*Sync` functions (`readFileSync`, `spawnSync`, …).
-  Tooling code in `bin/`, `scripts/`, `lib/`, `hooks/`, and `test/` must be async —
-  enforced by `scripts/check-no-sync.mjs` (runs via `pnpm lint`). Skill-owned
-  scripts (`skills/*/scripts`) and `extensions/` are the remaining sync surfaces.
-- **Share generic tooling helpers in `scripts/lib/`**: tooling code (installers under
-  `bin/installers/`, hooks, other scripts) imports shared utilities from `scripts/lib/`
-  (e.g. `compose-agent.mjs`, `fs.mjs`) rather than redefining them inline.
-
-## Skill Conventions
-
-- **Skills are portable, not repo documentation.** `skills/` is installed onto arbitrary machines
-  (pi, Claude Code), so it describes general practice and the author's portable
-  preferences — never how this repository is configured or how to work in it. Facts about this
-  checkout (branch bases, merge method, signature rules, required checks, release mechanics) belong
-  in `AGENTS.md`, `docs/`, or the tracker. Repo-local `.agents/skills/` follows the same rule: a
-  skill is a skill, not a place for this repo's configuration.
-- `SKILL.md` must include a YAML front-matter block with `name` and `description`. `pnpm lint`
-  enforces this (`pnpm check:skills`), because PI silently drops a skill whose frontmatter it
-  cannot parse.
-- `description` must be ≤ 1024 characters. First sentence: what it does. Second: "Use when…".
-- Keep `SKILL.md` near the ~150-line target in `docs/skills/skill-anatomy.md`, overflowing into
-  purpose-named support files (`REFERENCE.md`, `EXAMPLES.md`, `FORMAT.md`). `style-tests`
-  deliberately sits at the top of that range rather than splitting — its principles must load
-  automatically with the skill.
-- Add utility scripts to `scripts/` when an operation is deterministic and would otherwise be
-  regenerated each time (e.g. install scripts, scanners).
-- Skill names use kebab-case and are grouped by prefix where related (e.g. `review-security`,
-  `review-code`; `style-code`, `style-comms`, `style-documentation`).
-
-## Agent Conventions
-
-- Agents live in composable `<name>/` directories under `agents/`: a shared `agent.md` body plus
-  per-harness subdirectories `pi/` and `claude/` (frontmatter.json and optional section files) per
-  the spec in `agents/README.md`. `ralph`, `plan`, `ralph-plan`, and `strategy` all use the
-  composable layout, and no flat agent file is committed — each harness renders its own at install
-  time. The Claude plugin is materialised by the install-time generator
-  `bin/installers/claude.mjs`: a plain `agent-cortex install claude` copies it into
-  `~/.agent-cortex/claude` (skills copied flat with `{{TOOL:...}}`/`{{PATH:...}}` substituted,
-  never symlinked), writes the marketplace manifest at
-  `~/.agent-cortex/.claude-plugin/marketplace.json`, merges the committed `claude/settings.json`
-  template into `~/.claude/settings.json`, and registers it with Claude Code via the
-  `claude plugin` CLI. The settings merge preserves personal config: the CLI owns exactly
-  `enabledPlugins` + `extraKnownMarketplaces`, and every other key is left untouched. Only
-  that settings template is committed under `claude/` — the generated plugin subtree is not;
-  hand-authored plugin extras live in `claude-extras/` (`.mcp.json`, `scripts/`), and
-  `--output <dir>` is the generate-only form (tests/CI materialiser checks); `ralph`
-  is authored natively in `agents-native/` and copied verbatim; the other agents compose from their
-  `claude/` harness dirs).
-- The pi package is materialised by `bin/installers/pi.mjs`: `agent-cortex install pi` stages a
-  self-contained pi package in `~/.agent-cortex/pi` (manifest, flat rendered agents, token-substituted
-  skills, a copy of `extensions/`, `token-map.json`, and the bundled `pi.packages` closure under
-  `node_modules/`) and registers that directory with pi through the `pi` CLI — pi's own
-  `~/.pi/agent/settings.json` is read, never written. `--output <dir>` stages only (no registration,
-  no sweep) and `--dry-run` reports the plan. Once registration succeeds, a one-shot migration sweeps
-  the copies the pre-staged-model installer rendered into `~/.pi/agent`, attributing them by name from
-  the package root and recording completion in `~/.agent-cortex/legacy-sweep.json`; `~/.pi/agent/extensions`
-  is never touched. Run it from the main checkout: the staged package is a snapshot of the checkout you
-  invoked, so a run from a ralph worktree stages that worktree's content.
-- Keep orchestration logic in the agent file; extract shared per-task workflow into a skill
-  so it can be reused (e.g. ralph delegates per-task stage execution to `run-pipeline-stage`).
-
-## PI Extension Conventions
-
-- PI extensions live in `extensions/`, one subdirectory per extension.
-- Each extension directory contains `index.ts` (entrypoint) and `README.md` (usage).
-- Extensions are auto-discovered when the repo is installed as a PI package via `pi install`.
-- Keep extensions lightweight: no internal LLM calls. Extensions observe events and provide
-  commands — they should not add token overhead.
-- Register CLI flags from the extension factory (load time), never from a `session_start`
-  handler: PI matches parsed CLI flags against the extensions loaded at startup, so late
-  registration makes the flag fail with `Unknown option`.
-- Extensions that persist data should write to `~/.pi/agent-cortex/` (global, cross-project)
-  and tag records with the project path for per-project slicing.
-- PI extensions with Claude Code equivalents are ported to `hooks/claude/`; the port/reject
-  audit with rationale lives in `docs/claude-hooks.md`.
-
-## User preferences
-
-Before making tooling or workflow decisions, read `docs/user-preferences.md` for the
-user's personal development preferences (e.g. preferred package manager, tooling
-choices). These preferences apply across all projects where this plugin is active.
-
-## Task tracking
-
-This project uses **bd (beads)** for task tracking.
-
-Run `bd prime` at the start of each session for context.
-
-Quick reference:
-- `bd ready` — list unblocked work
-- `bd create "Title" -p <0-3>` — create a task (P0 = critical)
-- `bd update <id> --claim` — claim a task
-- `bd close <id>` — complete a task
-- `bd dep add <A> <B>` — **"A depends on B"** (B blocks A). First arg waits, second arg
-  is waited-for. To express "X blocks Y", write `bd dep add Y X`.
-- `bd dolt push` — sync to remote at session end

package/agents/ralph/claude/polling.md

@@ -1,31 +0,0 @@
-## Spawning subagents (Claude Code)
-
-RALPH HAS ONLY ONE WAY TO SPAWN SUBAGENTS: call the **`Task`** tool (not bash, not any other tool).
-
-**`Task`** — Spawn a background sub-agent and return a task ID immediately.
-- `prompt` (string, required): Full task prompt for the sub-agent.
-- `cwd` (string, optional): Working directory for the sub-agent (default: current project root). Always set this to the feature worktree path when running stage chores.
-- `model`, `subagent_type` (optional): Overrides for the worker; the Implementer and Reviewer workers keep the default (full reasoning), the Fix worker uses `model: haiku`.
-
-The response is a plain task ID string. Store it in memory — you need it to track the worker against its parent bead. Use `TaskList`/`TaskGet` to see which workers are still running and `TaskStop` to cancel one.
-
-Rules:
-- NEVER use `bash` to spawn subagents (no `claude`, no `tsx`, no `node` scripts).
-- NEVER try to run subagent work inline yourself — you only orchestrate.
-- ALWAYS use `Task` for every subagent interaction; track running workers with `TaskList`/`TaskGet`.
-- ALWAYS set `cwd` to the feature worktree path when running stage chores.
-- ALWAYS keep the task ID in memory to correlate a completion with its parent bead.
-
-## Completion detection (Claude Code — event-driven, no polling)
-
-Claude Code **re-invokes you automatically when a background worker completes** — the worker's result is delivered to you inline on the wake-up. **Do not poll and do not `sleep`.** React to completions as they arrive.
-
-- There is **no poll timer anywhere in this pipeline**: nothing in initialization starts one, and there is nothing to kill in **HITL Pause** — when you stop, you simply stop. The harness wakes you again when the user re-invokes you.
-- There is **no log tailing on Claude**: workers' progress lines (`.agent-cortex/ralph/ralph-<parentId>.log`) are written by the workers themselves and surfaced by the harness with the completion — nothing to flush, nothing to poll. Produce the shared chat summaries from the delivered result instead.
-- On each completion, apply the shared handling in the **Event loop** section of agent.md (steps 3–8: correlate the task ID to its bead via `state.json`, parse the REPORT, close the chore, advance the parent, check for newly ready beads, run the shutdown check). `state.json` `logLine` tracking is not used on Claude.
-
-## Completion constraints
-
-- **Always** keep completion tracking active while worker results are outstanding — the harness delivers each completion precisely once; never re-request a result.
-- **Never** poll, **never** `sleep`, **never** start a background timer.
-- **Never** post empty status updates — only surface actual completions.