@jaybeeuu/agent-cortex 1.43.0 → 2.0.0

package/docs/research/disable-model-invocation.md

@@ -3,8 +3,7 @@
 Decision record for the frontmatter field this repo uses to keep rare or destructive
 skills out of automatic model routing (bead `agnt-ctx-yf24`).
 
-**Verdict:** rely on it for pi and Claude Code. Do not rely on it in Copilot CLI as
-"invoke-only" — there it means "unreachable through the model-facing skill tool".
+**Verdict:** rely on it for pi and Claude Code.
 
 ## What the field does
 
@@ -19,11 +18,10 @@ previously implied.
 | --- | --- | --- | --- |
 | pi 1.4.0 | Yes — byte-identical copy | Yes — hidden from the prompt, `/skill:name` still works | `bin/installers/pi.mjs:182-204`, `scripts/lib/compose-agent.mjs:69-95`; `dist/core/skills.js:262` (parse) and `:279` (filter); `docs/skills.md:53` |
 | Claude Code 2.1.294 | Yes — byte-identical copy | Yes — Claude cannot invoke it, `/skill-name` still works | `bin/installers/claude.mjs:160-201`, same token helper; [Claude Code skills docs](https://code.claude.com/docs/en/skills) ("Control who invokes a skill") |
-| Copilot CLI (1.0.55 locally, 1.0.80/1.0.83 upstream) | N/A — no copy; `plugin.json` `"skills": "skills/"` serves the repo tree in place | Auto-invocation suppressed, but explicit model invocation fails; `/skill-name` works | `plugin.json:12`; [github/copilot-cli#4438](https://github.com/github/copilot-cli/issues/4438) (open, retested 1.0.83) |
 
 Both materialisers copy `SKILL.md` as text and rewrite only `{{TOOL:...}}` /
 `{{PATH:...}}` tokens, so frontmatter keys they do not know pass through untouched —
-nothing re-serialises YAML. Verified by installing all three harnesses into
+nothing re-serialises YAML. Verified by installing both harnesses into
 `/var/tmp/dmi-check` and diffing `skills/productivity/teach/SKILL.md` (the repo's
 only current user of the field): both copies are byte-identical to the source.
 `claude plugin validate /var/tmp/dmi-check/claude/skills` passes, i.e. Claude Code's
@@ -58,46 +56,27 @@ Two Claude-specific caveats:
   frontmatter field itself still applies there — only that settings-based alternative
   is unavailable.
 
-**Copilot CLI.** The field is not in GitHub's skill documentation, which lists only
-`name`, `description`, `license`, and `allowed-tools`. In practice the CLI filters
-flagged skills out of the `skill()` tool's resolution list, so the model cannot call
-them even when the user names one: `Skill not found`. Only the interactive
-`/skill-name` slash command reaches a flagged skill, and `-p` mode has no slash path.
-Upstream issue #4438 is open.
-
-Local probing was not possible: the installed CLI is 1.0.55 (no `copilot skill`
-subcommand), and prompt runs are refused by this machine's org policy. The upstream
-report is the evidence for Copilot, tested on 1.0.80 and 1.0.83 — newer than 1.0.55,
-so this may differ locally, in either direction.
-
 ## Options for "explicit invocation only", evaluated
 
 | Option | Portable? | Enforced? | Verdict |
 | --- | --- | --- | --- |
-| `disable-model-invocation: true` | pi + Claude Code yes; Copilot suppresses but breaks tool-based invocation | Yes on pi/Claude | **Recommended** where suppressing auto-routing is the point and the explicit path is a human typing `/name` |
+| `disable-model-invocation: true` | pi + Claude Code yes | Yes | **Recommended** where suppressing auto-routing is the point and the explicit path is a human typing `/name` |
 | Naming convention (e.g. `manual-*`) | Yes | No — no harness reads names | Rejected: a human signal we already get from the body |
-| `metadata:` block | Yes (spec-legal) | No — pi and Claude read top-level keys only, Copilot undefined | Rejected: documentation that looks like enforcement |
+| `metadata:` block | Yes (spec-legal) | No — pi and Claude read top-level keys only | Rejected: documentation that looks like enforcement |
 | Keep such skills out of `skills/` | Yes | Yes, by not shipping the skill | Rejected: gives up the per-harness install entirely |
 
 ## Recommendation
 
 Use the field when the danger is fuzzy automatic matching and the intended explicit
 path is a human typing `/skill-name`: that is the case for a migration skill whose
-`--apply` renames labels workspace-wide. Accept, and document, that on Copilot CLI it
-also blocks model-mediated invocation, including `-p` runs — if a workflow needs
-non-interactive access to such a skill, do not set the field and instead disable the
-skill in that user's Copilot config (`copilot skill disable <name>`, or the `/skills`
-toggle), which is harness-native and per-user.
+`--apply` renames labels workspace-wide.
 
 ## Reproducing
 
 ```sh
 node bin/agent-cortex.mjs install claude  --output /var/tmp/dmi-check/claude
 node bin/agent-cortex.mjs install pi      --output /var/tmp/dmi-check/pi
-node bin/agent-cortex.mjs install copilot --output /var/tmp/dmi-check/copilot
 diff skills/productivity/teach/SKILL.md /var/tmp/dmi-check/claude/skills/teach/SKILL.md
 diff skills/productivity/teach/SKILL.md /var/tmp/dmi-check/pi/skills/productivity/teach/SKILL.md
 claude plugin validate /var/tmp/dmi-check/claude/skills
 ```
-
-The Copilot run writes only composed agent files — there is no skill copy to inspect.

package/docs/skills/skill-anatomy.md

@@ -14,8 +14,7 @@ Optional fields:
 - `disable-model-invocation`: hides the skill from automatic model routing; explicit
   `/skill-name` invocation still works. Set it when the danger is a fuzzy description
   match, e.g. a skill whose steps are destructive. Preserved and honoured by pi and
-  Claude Code; Copilot CLI suppresses auto-routing but then cannot reach the skill
-  through its model-facing tool. See `docs/research/disable-model-invocation.md`.
+  Claude Code. See `docs/research/disable-model-invocation.md`.
 
 ## Description format rules
 
@@ -35,7 +34,7 @@ Optional fields:
 
 ## Tool references
 
-Reference agent tools by `{{TOOL:name}}` token (canonical copilot name), never a
+Reference agent tools by `{{TOOL:name}}` token (canonical authoring name), never a
 hardcoded harness-specific name such as `bash`, `task`, or `read_agent` — installers
 substitute the per-harness name from `token-map.json` at install time. Add any new tool
 to the map's `tools` section in the same change; unknown tokens are hard errors. See

package/docs/technical-direction/harness-config.md

@@ -20,13 +20,14 @@ below no longer hold:
   that both load.
 
 `pi.packages` and `lib/pi-packages.mjs` are deleted, so the bespoke-pi-mechanism problem this
-memo was written to settle is closed. The Claude and Copilot analysis stands.
+memo was written to settle is closed. The Claude analysis stands; Copilot CLI is no longer a
+deploy target (`agnt-ctx-2rl`).
 
 ## Problem and target outcome
 
-- **What we are solving.** agent-cortex ships agents and skills to three harnesses (pi, Claude
-  Code, Copilot CLI) and needs a declared, reproducible set of *third-party* extensions those
-  agents depend on (pi packages / Claude plugins). Two bespoke mechanisms currently exist and
+- **What we are solving.** agent-cortex ships agents and skills to two harnesses (pi, Claude
+  Code) and needs a declared, reproducible set of *third-party* extensions those agents depend
+  on (pi packages / Claude plugins). Two bespoke mechanisms currently exist and
   disagree: `main` declares packages in `package.json` → `pi.packages` and provisions them from
   `lib/pi-packages.mjs`; the unmerged pi-harness epic (`agnt-ctx-dfq3`) declares them in
   `pi.extensions.json` / `claude.extensions.json` and provisions them via `agent-cortex ext
@@ -51,9 +52,6 @@ memo was written to settle is closed. The Claude and Copilot analysis stands.
 - **Claude is idiomatic two ways.** Machine state is `~/.claude/settings.json` → `enabledPlugins`
   + `extraKnownMarketplaces`. A plugin declares other plugins in `.claude-plugin/plugin.json` →
   `dependencies`, which Claude Code resolves and auto-installs.
-- **Copilot has no dependency mechanism.** `copilot plugin install/list/uninstall` exists, but its
-  state is auto-managed `~/.copilot/config.json` (not committable) and `plugin.json` declares no
-  dependencies.
 - **The epic already built two-thirds of the target.** Unmerged commit `afab2c6` (F3) materialises
   `pi/settings.json` + `pi/keybindings.json` from committed templates with merge-keep-personal and
   the CLI owning `packages`; `1ff212d` (F4) makes bundled pi extensions load via package
@@ -86,7 +84,7 @@ memo was written to settle is closed. The Claude and Copilot analysis stands.
   --json` are the exact machine-state comparison; drift self-heals on install.
 - **Cons.** pi bundling shifts update cadence to agent-cortex releases and grows the tarball;
   Claude cross-marketplace deps need an allowlist; the committed template also carries personal
-  settings; Copilot gets nothing.
+  settings.
 - **Risks.** Loading TS extensions from bundled `node_modules/`; maintaining the Claude
   cross-marketplace allowlist.
 
@@ -128,8 +126,6 @@ the epic, and delete `pi.packages` + `lib/pi-packages.mjs` from `main`.
 - **Committed personal settings.** `pi/settings.json` already carries models/theme; the template
   model makes the repo own the whole pi settings surface. Accepted; F3's merge preserves personal
   keys and only `packages` is CLI-owned.
-- **Copilot gets no mechanism.** Documented exception — the README says `copilot plugin install`.
-  Accepted because Copilot has no dependency field and no committable config.
 - **No dedicated diff command.** A read-only `status` is deferred until drift is shown to hurt.
 
 ## Validation plan
@@ -160,8 +156,6 @@ pi extension loads from `node_modules/` and an optional one is materialised from
   speculative and should be dropped rather than maintained.
 - Bundling `pi-web-access`'s native-ish dependency tree (unpdf, linkedom) proves brittle or
   unacceptable on a fresh machine.
-- Copilot gains a committable config or a plugin dependency field — revisit the documented
-  exception.
 - Drift between the committed template and the machine becomes a recurring annoyance — add the
   deferred read-only `status`.
 
@@ -175,8 +169,6 @@ pi extension loads from `node_modules/` and an optional one is materialised from
   (auto-install, cross-marketplace allowlist, tag naming).
 - Claude Code, *Settings* — https://code.claude.com/docs/en/settings (`enabledPlugins`,
   `extraKnownMarketplaces`).
-- GitHub Copilot CLI, *Plugin reference* — https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference
-  and *Configuration directory* — https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference
 - Code evidence (as of 2026-09 — `pi.packages` and `lib/pi-packages.mjs` were removed in
   `agnt-ctx-7kru.1`, see Status): `package.json` (`pi.packages`), `lib/pi-packages.mjs` (main's
   provisioner);

package/docs/user-preferences.md

@@ -1,8 +1,8 @@
 # User Preferences
 
 This file records personal development preferences for the author (**jaybeeuu**).
-Both Copilot CLI agents and PI coding agents should read this file for user-level
-context when making tooling and workflow decisions.
+Both pi and Claude Code agents should read this file for user-level context when
+making tooling and workflow decisions.
 
 ## Package manager
 

package/extensions/agent-modes/README.md

@@ -39,9 +39,9 @@ contract:
    from the tool set with a warning.
 
 Flat `agents/*.agent.md` files are parsed as a fallback when an agent has no
-composable directory — they are generated output (scripts/build-copilot-agents.mjs)
-but may exist for non-migrated agents. A composable directory always wins over its
-flat counterpart for the same agent id.
+composable directory — a staged pi package carries flat renders, and a hand-written
+agent may be a single flat file. A composable directory always wins over its flat
+counterpart for the same agent id.
 
 ## Development
 

package/extensions/agent-modes/discover.ts

@@ -18,9 +18,9 @@ import type { ThemeColor } from "@earendil-works/pi-coding-agent";
  *      and symlinked installs).
  *
  * Flat `agents/*.agent.md` files are parsed as a fallback for agents that have
- * no composable directory (they are generated output for Copilot, so they may
- * exist for any agent). A composable directory always wins over its flat
- * counterpart.
+ * no composable directory (a staged pi package ships flat renders, and a
+ * hand-written agent may be a single flat file). A composable directory always
+ * wins over its flat counterpart.
  */
 
 // ─── Types ───────────────────────────────────────────────────────────────────
@@ -40,7 +40,7 @@ export interface AgentDef {
   prompt: string;
 }
 
-export type HarnessId = "copilot" | "claude" | "pi";
+export type HarnessId = "claude" | "pi";
 
 export interface PathSpec {
   base: string;
@@ -431,8 +431,8 @@ function readFlatAgent(filePath: string, tokenMap: TokenMap | null): AgentDef |
  * Discover agents from the agents directory.
  *
  * Composable directories (`<name>/agent.md` + `<name>/pi/frontmatter.json`) are
- * the primary source. Flat `*.agent.md` files (generated output for Copilot) are
- * read only when no composable directory exists for that agent id. When
+ * the primary source. Flat `*.agent.md` files (a staged package's renders, or a
+ * hand-written agent) are read only when no composable directory exists for that agent id. When
  * `tokenMap` is omitted, token-map.json is loaded from the package root;
  * missing/unreadable maps fall back to the built-in copilot→pi translation.
  */

package/extensions/subagent/README.md

@@ -111,8 +111,8 @@ fire-and-forget orchestration:
 - **`read_agent`** — fallback: read one specific agent's output once you know it has
   finished (or query its `STILL RUNNING` state directly).
 
-These mirror Copilot CLI's `task`/`read_agent` model; `wait_for_agents` adds the
-blocking wait that Copilot's poll loop does manually. Abort (Ctrl+C) propagates: a
+These mirror the `task`/`read_agent` model the skills are authored against;
+`wait_for_agents` adds the blocking wait that a `read_agent` poll loop does manually. Abort (Ctrl+C) propagates: a
 pending `wait_for_agents` returns immediately with whatever is known so far.
 
 ## Output Display

package/extensions/subagent/agents.ts

@@ -155,8 +155,7 @@ function isRenderedAgentsTree(agentsDir: string): boolean {
  * renders the flat pi agents into `<package>/agents`.
  *
  * A source checkout contributes nothing: its `agents/` tree is the composable
- * source (composed at runtime by the agent-modes extension) alongside flat
- * renders for other harnesses — Copilot's, whose tool names pi does not have.
+ * source, composed at runtime by the agent-modes extension.
  */
 export function resolveUserAgentDirs(packageRoot: string = PACKAGE_ROOT): string[] {
 	const dirs: string[] = [];

package/lib/cli.mjs

@@ -1,4 +1,4 @@
-const SUPPORTED_HARNESSES = ["copilot", "claude", "pi"];
+const SUPPORTED_HARNESSES = ["claude", "pi"];
 
 // Options accepted by `install <harness>`. `--output`/`--dry-run` are shared by
 // the claude and pi installers; `--plugin-root` is pi-specific. Unknown or
@@ -87,11 +87,6 @@ Commands:
                                         registration cannot run (missing CLI,
                                         pre-v2 build); default warns and prints
                                         the manual registration commands
-                      Options (copilot):
-                        --output <dir>   Write the flat *.agent.md files to <dir>
-                                         (default: <package root>/agents — the dir
-                                         plugin.json "agents" scans)
-                        --dry-run        Print what would be generated without writing
                       Options (pi):
                         (no --output)         Materialise the pi package into
                                               ~/.agent-cortex/pi: package.json,
@@ -135,7 +130,10 @@ Commands:
 
 export function validateHarness(harness) {
   if (harness === null) {
-    return { ok: false, error: "Missing harness argument. Supported harnesses: copilot, claude, pi" };
+    return {
+      ok: false,
+      error: `Missing harness argument. Supported harnesses: ${SUPPORTED_HARNESSES.join(", ")}`,
+    };
   }
   if (!SUPPORTED_HARNESSES.includes(harness)) {
     return { ok: false, error: `Unknown harness "${harness}". Supported harnesses: ${SUPPORTED_HARNESSES.join(", ")}` };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaybeeuu/agent-cortex",
-  "version": "1.43.0",
+  "version": "2.0.0",
   "description": "Personal PI package with custom agents, skills, and extensions",
   "keywords": [
     "pi-package"
@@ -39,12 +39,10 @@
     "check:sync": "node scripts/check-no-sync.mjs",
     "test": "node --test test/*.test.mjs && pnpm -r test",
     "typecheck": "pnpm -r typecheck",
-    "build:copilot": "node scripts/build-copilot-agents.mjs",
     "changeset": "changeset",
-    "version-packages": "changeset version && bash scripts/sync-plugin-version.sh && pnpm build:copilot",
+    "version-packages": "changeset version",
     "publish-package": "TARBALL=$(pnpm pack | tail -n 1) && npm publish \"$TARBALL\" --provenance --access public",
     "publish-noop": "echo 'No publish: the merged PR carries the no-publish label.'",
-    "release": "changeset publish",
-    "postinstall": "bash scripts/install-instructions.sh"
+    "release": "changeset publish"
   }
 }

package/scripts/lib/compose-agent.mjs

@@ -1,8 +1,8 @@
 // Shared composer: reads a composable agent directory (agents/<name>/) and emits
-// the harness-specific agent content defined by agents/README.md. The Copilot
-// generator (scripts/build-copilot-agents.mjs) and the Claude install-time generator
-// (bin/installers/claude.mjs) compose from here, so the composable dirs are
-// the single source of truth and the flat/generated files stay in lockstep.
+// the harness-specific agent content defined by agents/README.md. The Claude and pi
+// install-time generators (bin/installers/claude.mjs, bin/installers/pi.mjs) compose
+// from here, so the composable dirs are the single source of truth and the generated
+// files stay in lockstep.
 //
 // Composition per the agents/README.md contract:
 //   1. {{SECTION:name}} is replaced with <dir>/<harness>/<name>.md content.
@@ -15,15 +15,15 @@
 // silently dropped section.
 //
 // Options (the pi installer passes `dropNullTools`, `pluginRoot` and
-// `resolveRelativePaths`; the copilot generator and claude installer use the strict defaults):
+// `resolveRelativePaths`; the claude installer uses the strict defaults):
 //   dropNullTools          replace null-mapped tool tokens with an empty string and
 //                          warn instead of throwing (pi's prose rule per the
 //                          token-map contract)
 //   pluginRoot             override the plugin_root used for resolved paths
 //                          (installers compute it from the actual install layout)
 //   resolveRelativePaths   non-keyed {{PATH:...}} args resolve to pluginRoot/arg
-//                          instead of staying verbatim (install time; the build
-//                          scripts leave them bare for Copilot CLI resolution)
+//                          instead of staying verbatim (install time; without it
+//                          they stay bare for runtime resolution)
 //   warn                   callback for drop/omit warnings (default: no-op; the
 //                          pi installer collects them into its result)
 //
@@ -61,7 +61,7 @@ function noop() {}
  *   the harness's section files before calling this.
  *
  * @param {string} content  Source text containing {{TOOL:...}}/{{PATH:...}} tokens
- * @param {string} harness  Harness id: "copilot" | "claude" | "pi"
+ * @param {string} harness  Harness id: "claude" | "pi"
  * @param {object} tokenMap Parsed token-map.json (from loadTokenMap)
  * @param {object} options  { dropNullTools, pluginRoot, resolveRelativePaths, warn, context }
  * @returns {string}
@@ -99,7 +99,7 @@ export function substituteTokens(content, harness, tokenMap, options = {}) {
  *
  * @param {string} root    Package root (contains agents/ and token-map.json)
  * @param {string} name    Agent directory name (e.g. "ralph", "plan")
- * @param {string} harness Harness id: "copilot" | "claude" | "pi"
+ * @param {string} harness Harness id: "claude" | "pi"
  * @returns {{ name: string, description: string, tools: string[], model?: string, argumentHint?: string, body: string }}
  */
 export async function composeAgent(root, name, harness, options = {}) {
@@ -218,7 +218,7 @@ function resolvePath(arg, harness, tokenMap, opts = {}) {
  *
  * @param {string[]} tools  Canonical tool names from a harness frontmatter.json
  * @param {object} tokenMap Parsed token-map.json (from loadTokenMap)
- * @param {string} harness  Harness id: "copilot" | "claude" | "pi"
+ * @param {string} harness  Harness id: "claude" | "pi"
  * @param {object} options  { warn }
  * @returns {string[]}
  */

package/skills/workflow/ralph/REFERENCE.md

@@ -116,7 +116,7 @@ When a verify or review stage fails:
 
 ## Log Polling
 
-Run whenever polling is triggered (timer or agent completion):
+Run whenever completion handling is triggered (an agent completion):
 
 1. **Query in-flight beads**: `bd list --status=in_progress --type=chore`. Extract each bead's ID and title.
 2. For each in-flight bead, read new lines from its **parent's** log file — logs are keyed by **parent** bead ID, so all stages of a feature share one file. Track the next unread line number per parent in memory, starting at 1:
@@ -167,7 +167,7 @@ Proceed here when no chore beads are in-flight, no `stage:*` chore beads are rea
 
    When you've completed the above, prompt me to continue.
    ```
-6. **Stop completely.** Do not restart the poll timer. Do not continue the event loop. Wait for the user to re-prompt before doing any further work.
+6. **Stop completely.** Do not continue the event loop. Wait for the user to re-prompt before doing any further work.
 
 ---
 
@@ -209,7 +209,7 @@ When `bd list --status=in_progress --type=chore` returns no results AND `bd read
 | File | Purpose |
 |------|---------|
 | `.agent-cortex/ralph/progress.md` | Human-readable snapshot. Regenerate: `workspace="/abs/path"; pnpm --prefix skills/workflow/run-pipeline-stage/scripts exec tsx generate-progress.ts --workspace "$workspace" > "$workspace/.agent-cortex/ralph/progress.md"`. `workspace` must be an **absolute** path — never `.` or `$(pwd)`. **Never hand-edit.** |
-| `.agent-cortex/ralph/state.json` | Runtime bookkeeping only: the poll-timer shellId (Copilot) and the in-flight agent-ID→bead mapping. Shape: `{ "timerShellId": null, "inflight": [ { "choreId": "...", "parentId": "...", "title": "...", "agentId": "...", "logLine": 1 } ] }`. Initialise at startup with `{ "timerShellId": null, "inflight": [] }`. Update after every dispatch and every agent completion. **Never hand-edit.** |
+| `.agent-cortex/ralph/state.json` | Runtime bookkeeping only: the in-flight agent-ID→bead mapping. Shape: `{ "inflight": [ { "choreId": "...", "parentId": "...", "title": "...", "agentId": "...", "logLine": 1 } ] }`. Initialise at startup with `{ "inflight": [] }`. Update after every dispatch and every agent completion. **Never hand-edit.** |
 | `.agent-cortex/ralph/ralph-*.log` | Per-parent log files written by subagents — every stage chore of a feature appends to `.agent-cortex/ralph/ralph-<parent-id>.log` (e.g. `ralph-abc-123.log`). |
 
 All task state is derived from beads; `state.json` holds only runtime bookkeeping:

package/skills/workflow/ralph/SKILL.md

@@ -7,7 +7,7 @@ description: "Run all pending beads end-to-end with up to 5 concurrent pipeline-
 
 Ralph is a parallel orchestration loop. It advances AFK task beads through pipeline-stage chores (`code` → `verify` → `review` → `document`), dispatching each stage as a background subagent in the feature's worktree, then opens review-gated feature and epic PRs and pauses for human merges. Ralph never writes code itself — it dispatches, tracks, and reports.
 
-State model: task state lives in beads (ready/in_progress via `bd`); the only local file is `.agent-cortex/ralph/state.json`, holding the poll-timer shellId and the agent-ID→bead mapping. Pipeline configuration comes from `skills/planning/create-task/pipeline.json`, and stage execution belongs to the `run-pipeline-stage` skill.
+State model: task state lives in beads (ready/in_progress via `bd`); the only local file is `.agent-cortex/ralph/state.json`, holding the agent-ID→bead mapping. Pipeline configuration comes from `skills/planning/create-task/pipeline.json`, and stage execution belongs to the `run-pipeline-stage` skill.
 
 ## When to use
 
@@ -28,14 +28,14 @@ State model: task state lives in beads (ready/in_progress via `bd`); the only lo
 1. Run `bd prime` and hold the output verbatim in memory.
 2. Ensure `.agent-cortex/` and `.agent-cortex/worktrees/` are in the project's `.gitignore` (append any that are missing).
 3. Create the workspace: `mkdir -p .agent-cortex/ralph`.
-4. Initialize state: write `.agent-cortex/ralph/state.json` with `{ "timerShellId": null, "inflight": [] }`.
+4. Initialize state: write `.agent-cortex/ralph/state.json` with `{ "inflight": [] }`.
 5. Read `skills/planning/create-task/pipeline.json` and hold it in memory — you need its `maxFixRounds` for the fix loop.
 6. Run `bd ready` and classify each available bead:
    - **Chore with a `stage:*` label**: pipeline stage bead — eligible for dispatch.
    - **Task or other type without an `implementation-type:*` label**: unexpected here — classification happens at planning time via `create-task`. Do not invoke `classify-bead`; treat as needs-refinement and note it for the shutdown summary.
    - **Task labelled `implementation-type:hitl`**: skip — record the ID for the Pending Human Action summary at shutdown.
 7. For each ready chore bead (up to 5), dispatch it from its parent's feature worktree (see _Dispatching a chore bead_ in REFERENCE.md — create branches/worktrees first).
-8. Hand over to your harness's completion-detection mechanism: Copilot keeps a `sleep 120` poll timer running in the background; PI keeps a {{TOOL:wait_for_agents}} call outstanding over every in-flight agent ID. If no chore was dispatched and HITL gate beads are pending (`bd list -l lifecycle:feature-pr -l implementation-type:hitl` or `bd list -l awaiting-epic-pr-merge`), go straight to HITL Pause (REFERENCE.md).
+8. Hand over to your harness's completion-detection mechanism: PI keeps a {{TOOL:wait_for_agents}} call outstanding over every in-flight agent ID. If no chore was dispatched and HITL gate beads are pending (`bd list -l lifecycle:feature-pr -l implementation-type:hitl` or `bd list -l awaiting-epic-pr-merge`), go straight to HITL Pause (REFERENCE.md).
 9. Regenerate `.agent-cortex/ralph/progress.md`:
    ```bash
    # workspace must be the absolute path you cd'd into — never . or $(pwd)
@@ -45,7 +45,7 @@ State model: task state lives in beads (ready/in_progress via `bd`); the only lo
 
 ### 2. Event loop
 
-On each completion notification (background agent finished, or the poll timer fired):
+On each completion notification (a background agent finished):
 
 1. Poll that parent's log for new lines — `tail -n +<nextLine> .agent-cortex/ralph/ralph-<parent-id>.log` (logs are keyed by parent bead ID, so every stage of a feature shares one file) — and post only new key events (stage transitions, test/lint results), never empty updates.
 2. Read the completed agent's output with {{TOOL:read_agent}} and parse its `---REPORT---` block for `BEAD_ID`, `STAGE_COMPLETED`, and the outcome.
@@ -97,7 +97,7 @@ On each completion notification (background agent finished, or the poll timer fi
 
 ## Philosophy / rationale
 
-- Orchestration state derives from beads so a crash loses nothing but an in-memory ID mapping: `state.json` holds only the poll-timer shellId and the agent-ID→bead mapping, never task state.
+- Orchestration state derives from beads so a crash loses nothing but an in-memory ID mapping: `state.json` holds only the agent-ID→bead mapping, never task state.
 - Classification happens up-front at planning time (`create-task`), so the loop can trust `bd ready` instead of re-interpreting each bead's intent.
 - Human review gates are non-negotiable because agent-authored changes still need a person to merge them.
 

package/test/cli.test.mjs

@@ -54,11 +54,6 @@ describe("parseArgs", () => {
     assert.deepStrictEqual(result, { command: "help" });
   });
 
-  it("returns { command: 'install', harness: 'copilot' } for install copilot", async () => {
-    const result = parseArgs(["install", "copilot"]);
-    assert.deepStrictEqual(result, { command: "install", harness: "copilot" });
-  });
-
   it("returns { command: 'install', harness: 'claude' } for install claude", async () => {
     const result = parseArgs(["install", "claude"]);
     assert.deepStrictEqual(result, { command: "install", harness: "claude" });
@@ -169,11 +164,17 @@ describe("buildHelpText", () => {
 
 describe("validateHarness", () => {
   it("returns ok for supported harnesses", async () => {
-    for (const h of ["copilot", "claude", "pi"]) {
+    for (const h of ["claude", "pi"]) {
       assert.deepStrictEqual(validateHarness(h), { ok: true });
     }
   });
 
+  it("returns error for copilot, which is no longer a deploy target", async () => {
+    const result = validateHarness("copilot");
+    assert.equal(result.ok, false);
+    assert.ok(result.error.includes("Unknown harness"));
+  });
+
   it("returns error when harness is null", async () => {
     const result = validateHarness(null);
     assert.equal(result.ok, false);
@@ -207,10 +208,10 @@ describe("CLI integration", () => {
     assert.ok(stdout.includes("Usage:"));
   });
 
-  it("exits 0 for install copilot", async () => {
-    const { exitCode, stdout } = await runCli(["install", "copilot"]);
-    assert.equal(exitCode, 0);
-    assert.ok(stdout.includes("copilot"));
+  it("exits 1 for install copilot, which is no longer a deploy target", async () => {
+    const { exitCode, stderr } = await runCli(["install", "copilot"]);
+    assert.equal(exitCode, 1);
+    assert.ok(stderr.includes("Unknown harness"));
   });
 
   it("exits 0 for install claude (into a temp output dir)", async () => {

package/token-map.README.md

@@ -1,7 +1,7 @@
 # token-map.json — multi-harness token substitution
 
 `token-map.json` is the central, single-source mapping of **tool names**, **paths**, and
-**agent naming conventions** across the three harnesses this repo ships to. It is the
+**agent naming conventions** across the two harnesses this repo ships to. It is the
 foundation for the install-time generation system: each harness installer (`agent-cortex
 install <harness>`) reads the map and substitutes `{{TOOL:...}}` / `{{PATH:...}}` tokens in
 the files it generates.
@@ -14,7 +14,6 @@ decisions behind the map.
 
 | id | Platform | Agent format | Plugin root |
 |---|---|---|---|
-| `copilot` | GitHub Copilot CLI | `agents/<name>/` composable dirs → generated `agents/*.agent.md` | `~/.copilot/installed-plugins/_direct/agent-cortex` |
 | `pi` | pi coding agent | `agents/<name>/` composable dirs (composed at runtime by agent-modes, or rendered install-time by `agent-cortex install pi`) | `~/.agent-cortex/pi` |
 | `claude` | Claude Code | `~/.agent-cortex/claude/agents/*.md` (materialised home install) | `${CLAUDE_PLUGIN_ROOT}` (env var) |
 
@@ -44,9 +43,9 @@ rather than inventing a dotted form:
 ### 2. What is mapped
 
 - **`tools`** — the twelve canonical tool names as authored in `agents/<name>/agent.md`
-  (copilot names are the authoring names). Each row gives the equivalent tool name per
-  harness. Source of truth for the copilot → claude half is `token-map.json`'s own claude
-  column, consumed by `bin/installers/claude.mjs` (the install-time generator — PR #91, #92); the pi column is grounded
+  (the canonical authoring names). Each row gives the equivalent tool name per harness.
+  The claude column is consumed by `bin/installers/claude.mjs` (the install-time
+  generator — PR #91, #92); the pi column is grounded
   in pi's documented built-in tool surface (`read`, `bash`, `edit`, `write`, `grep`, `find`,
   `ls`) plus `ask_questions` — added by the pi-questions package (mapped from
   `ask_user`) — and `task` / `read_agent` / `wait_for_agents` subagent tools, the last three
@@ -101,7 +100,7 @@ so the warn-and-omit path applies only to future null entries. See
 
 The full contract is embedded in `token-map.json` under `contract`. In summary, installers:
 
-1. Bind a harness id (`copilot` | `claude` | `pi`).
+1. Bind a harness id (`claude` | `pi`).
 2. Substitute in order: `SECTION` (left for the composer), then `TOOL`, then `PATH`.
 3. For `TOOL`: look up the canonical key, replace with the harness name; null → drop/omit;
    unknown → throw.
@@ -111,7 +110,7 @@ The full contract is embedded in `token-map.json` under `contract`. In summary,
 
 ## Authoring guidance
 
-- Write tokens with the **canonical (copilot) names**: `Use {{TOOL:task}} to spawn
+- Write tokens with the **canonical authoring names**: `Use {{TOOL:task}} to spawn
   subagents`, `Read {{PATH:skills/workflow/plan/SKILL.md}}`.
 - Never embed a harness-specific name in the canonical sources (`agents/<name>/agent.md`,
   `skills/**/SKILL.md`) — that defeats the map. The materialised Claude plugin
@@ -125,11 +124,9 @@ The full contract is embedded in `token-map.json` under `contract`. In summary,
 
 - `agents/README.md` — composable agent directory format (ADR #63), defines the token
   grammar the map implements.
-- `scripts/build-copilot-agents.mjs` / `bin/installers/copilot.mjs` — the copilot
-  harness token composer (scripts/lib/compose-agent.mjs) resolves `{{TOOL:...}}` /
-  `{{PATH:...}}` against the map and `{{SECTION:...}}` from the per-harness section
-  files; `bin/installers/copilot.mjs` is the shared generator both `pnpm build:copilot`
-  and `agent-cortex install copilot` run.
+- `scripts/lib/compose-agent.mjs` — the shared token composer: resolves `{{TOOL:...}}` /
+  `{{PATH:...}}` against the map and `{{SECTION:...}}` from the per-harness section files
+  for `bin/installers/claude.mjs` and `bin/installers/pi.mjs`.
 - `bin/installers/claude.mjs` — the single Claude generator: plain
   `agent-cortex install claude` materialises the plugin into `~/.agent-cortex/claude`
   with token-substituted skills, merges the committed `claude/settings.json` into