@iowarp/clio-coder 0.4.6 → 0.4.8

package/skills/workflow/workflow-distiller/SKILL.md

@@ -1,201 +0,0 @@
----
-name: workflow-distiller
-description: "Packages a workflow that just happened into a reusable SKILL.md: reconstructs it from the session record, checks overlap with installed skills, gates on approval, then writes it following skill-craft. Not for authoring a skill with no prior workflow; use skill-craft."
-triggers:
-  - make this workflow a skill
-  - package what we just did
-  - turn this into a reusable workflow
-  - distill this repeated process
-  - create a skill from this session
-version: 0.4.1
-license: Apache-2.0
-allowed-tools:
-  - read
-  - grep
-  - find
-  - ls
-  - context
-  - write
-  - ask_user
-requires:
-  - skill:skill-craft
-clio-coder:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/workflow/workflow-distiller
-  audit: pass
-  provenance: designed
-  eval-status: smoke-checked
-  model-size: large
----
-
-# Workflow Distiller
-
-Turn a workflow that actually ran into a reusable skill. The distiller's
-identity is runtime truth: it reconstructs what happened from the visible
-session record, not from anyone's memory of it. Skip the ceremony when there
-is no prior workflow; a from-scratch skill is a SKILL.md written directly,
-following skill-craft. skill-craft also governs how every skill this
-distiller produces is written: description, body, and pruning rules live
-there, not here.
-
-## Arguments
-
-```text
-/skill workflow-distiller [<what to distill>]
-```
-
-With arguments, the text names the workflow to distill; without, distill
-whichever workflow just ran in this session. Everything else in the request
-(the conversation so far) is the session record Phase 1 reconstructs from,
-not more arguments.
-
-A live operator can answer Phase 2's interview and Phase 4's design gate for
-real - treat a real, answered `ask_user` reply as proof an operator is
-present and continue asking one question per round. There is no operator in
-a headless run: `ask_user` is not registered, so any call is refused as an
-unregistered tool rather than answered. When that
-is the run's condition, do not wait for a reply that cannot come: answer
-every remaining interview question and the Phase 4 gate yourself as an
-assumed-confirm monologue (state the question, give your best-grounded
-answer or design choice, mark it `assumed - confirm`) and proceed straight
-through to Phase 5, the same way as a live "looks fine, write it." A skill
-file is a plain, reversible artifact under version control, not an
-irreversible external action - write it and say so in the final reply,
-rather than stopping at the gate with nothing produced.
-
-`tasks` sits outside this skill's tool surface (`read`, `grep`, `find`,
-`ls`, `context`, `write`, `ask_user`) and any call is refused; the six
-phases above are the plan, not a task list. This skill never has `bash` or
-`git`, so it never commits or pushes the file it writes - say so in the
-final reply and let the user commit it.
-
-## Phase 1 - Reconstruct From Evidence
-
-Before asking anything, list the concrete steps that visibly executed in this
-session, in order: tools called, commands run, files touched, dispatches made,
-skills activated. Cite the conversation record for each step. Anything the
-user describes that did not visibly run is tagged `assumption` and becomes an
-interview question. This grounding step is mandatory and comes first; when the
-reconstruction and the user's memory disagree, the reconstruction wins and the
-disagreement is worth a question.
-
-## Phase 2 - Interview
-
-Use `ask_user` with `mode: "single_question"`, one question per round, bounded
-rounds (default 8, max 12), following the grill-me operating contract:
-recommended answer first when options are natural, stop signals ("stop",
-"enough", "later", cancel) respected immediately, answers translated into
-compact decisions. Question bank, roots before leaves:
-
-1. Confirm the reconstruction and resolve tagged assumptions.
-2. Inputs and outputs: what varies between runs, what is fixed.
-3. Recurrence: how often has this actually happened? A workflow that ran once
-   is usually not worth a skill; ask early and offer to stop.
-4. Per-step rigidity: must-match versus any-reasonable-approach.
-5. Failure behavior per step: ask the user, retry an alternative, or fail
-   loudly.
-6. Scope cuts: what the skill should refuse to do.
-7. Name (lowercase-hyphen).
-
-## Phase 3 - Overlap Check
-
-Call `context(scope="skills")` with no name to list installed skills. Judge
-overlap per step, not per workflow: if an installed skill's triggers cover a
-step, that step is referenced by name in the new skill body, never
-reimplemented, with a one-line rationale for the dependency. A different end
-goal does not excuse reimplementing a covered step. Record each reference as
-a `requires: [skill:<name>]` entry in the generated skill's frontmatter in
-Phase 5, so the loader warns when the dependency is missing.
-
-## Phase 4 - Design Gate
-
-Present a compact design summary and wait for explicit approval:
-
-```markdown
-## Skill Design - <name>
-Description draft: <triggers only, third person>
-Steps: <step, rigidity, on-failure> per line
-References: <skill:<name>, why> or none
-Scope: project | user (user only if the workflow crosses repositories)
-Validation scenario: <prompt, expected observable behavior>
-```
-
-No skill file is written before the user approves. "Looks fine, but change X"
-means revise and re-present. In a headless run with no operator (see
-Arguments), treat the design as approved once it is internally consistent
-with Phase 2's decisions, mark it `assumed - confirm` in your final reply,
-and proceed to Phase 5 - do not stop the run with a presented-but-unwritten
-design.
-
-## Phase 5 - Create
-
-Write `SKILL.md` under `.clio-coder/skills/<approved-name>/` with the
-frontmatter contract below - a triggers-only third-person description, and
-the pruning pass - with `requires: [skill:<name>]` for every skill the
-overlap check referenced. Do not try to load skill-craft's own file mid-run
-to check this: only one skill can be active at a time, and a second
-`context(scope="skills", name="skill-craft")` call is refused while this
-skill is still pending. The frontmatter contract, current as of this
-writing: `name`, `description` (third-person triggers, no "I"/"you"),
-`triggers` (a non-empty list), `version` (start `0.1.0`), `license`,
-`allowed-tools` (canonical lowercase Clio tool names only - `bash`/`git`
-capitalized or spelled differently is rejected), and `requires` when Phase 3
-found a reference. If in doubt about the exact shape, `read` an already-
-installed skill's `SKILL.md` (this skill's own file is always available) and
-mirror its frontmatter keys rather than guessing or trying to load
-skill-craft. Scope defaults to project; use the user skill store only when
-the user said the workflow crosses repositories. Placeholders replace every
-session-specific path, name, and value; distill the pattern, not the
-incident. Keep the generated skill under 120 lines; reference instead of
-inlining. If the session repeatedly dispatched the same worker pattern, also
-offer a recipe sketch for the agents surface, but do not write recipe files.
-
-## Phase 6 - Validate
-
-Record one RED-GREEN scenario agreed with the user: the prompt, and the
-observable behavior that distinguishes with-skill from without. `clio-coder
-skills validate` needs `bash`, which is outside this skill's tool surface -
-never attempt it; instead `read` the file back and confirm the frontmatter
-contract from Phase 5 by eye (required keys present, `allowed-tools` entries
-canonical lowercase, under the line budget), and say plainly that a real
-`clio-coder skills validate` pass is still owed once bash is available.
-Otherwise record the scenario in the skill body's example section as the
-standing validation obligation. This skill has no `bash`/`git`, so it never
-commits or pushes the file it writes; say so and let the user commit it.
-
-## Worked Example
-
-Session: the user fetched a CSV export, normalized column names with a small
-script, and verified row counts against the source, three sessions in a row.
-
-1. Reconstruct: `bash curl ...` (ran), `write normalize.py` + `bash python3
-   normalize.py` (ran), `bash wc -l` comparison (ran). User also mentions "and
-   I always spot-check five rows" - not visible this session, tagged
-   assumption.
-2. Interview: confirms reconstruction; spot-check confirmed as a real step;
-   recurrence "weekly"; normalization must-match, fetch any-approach; failure
-   on row-count mismatch must fail loudly; name `csv-ingest`.
-3. Overlap: the `context(scope="skills")` listing shows no fetch or CSV skill
-   installed; no references.
-4. Gate: summary presented; user approves after tightening the description.
-5. Create: write `.clio-coder/skills/csv-ingest/SKILL.md`, placeholders for the
-   export URL and column map; frontmatter contract confirmed by reading the
-   file back (no `bash`, so no `clio-coder skills validate` this turn).
-6. Validate: scenario "ingest this month's export" must show fetch,
-   normalize, count-verify, spot-check in that order; recorded in the body.
-
-## Red Flags
-
-- Writing any skill before the design gate is approved by a live operator,
-  or before a headless run has marked it `assumed - confirm`.
-- Stopping the run at Phase 4 with a presented-but-unwritten design when the
-  run is headless - that's the backlog pattern (guard an irreversible
-  action), and a written skill file is not that; it is reversible.
-- A reconstruction that lists steps nothing in the session shows.
-- Reimplementing an installed skill's job instead of referencing it.
-- Session-specific paths or values surviving into the generated skill.
-- Batching interview questions or ignoring a stop signal.
-- Distilling a one-off without asking about recurrence.
-- Calling `bash` for `clio-coder skills validate`, or `context` with a
-  second skill's name to consult it mid-run: both are outside this skill's
-  tool surface and refused.

package/skills/workflow/workflow-distiller/evals.md

@@ -1,225 +0,0 @@
-# Evals - workflow-distiller
-
-Baseline scenarios (run a subagent WITHOUT the skill to capture the gap, then
-WITH the skill to confirm it closes). Rubric is pass/fail per bullet.
-
-## S1 - "make what we just did a skill"
-
-Setup: Make what we just did a skill. For the record, this session we ran
-the release-notes workflow end to end: pulled the merged PR titles since
-the last tag with gh, grouped them by conventional-commit type, rewrote
-each group into user-facing bullets, and verified every PR number in the
-draft against the gh list before saving docs/release-notes.md. I also
-mentioned we sometimes ping the release channel afterwards, but we did not
-do that here.
-
-Expected:
-
-- Reconstructs the executed steps from the session record, in order, before
-  asking any question; unobserved steps the user mentions are tagged as
-  assumptions.
-- Interviews via `ask_user` with `mode: "single_question"`, one question per
-  round, bounded rounds.
-- Lists installed skills via `context(scope="skills")` with no name before
-  designing.
-- Presents a compact design summary and waits for explicit approval.
-- Writes the SKILL.md only after approval, with session-specific values
-  replaced by placeholders.
-- Records a RED-GREEN validation scenario.
-
-## S2 - overlap with an installed skill
-
-Setup: the workflow's retrieval step is already covered by an installed skill
-(for example arxiv-literature for paper retrieval).
-
-Expected:
-
-- The overlap check finds the installed skill.
-- The generated skill references it by name instead of reimplementing the
-  step, with a one-line rationale in the body.
-- The generated frontmatter carries `requires: [skill:<name>]` so the loader's
-  unmet-dependency warning arms when the referenced skill is absent.
-
-## S3 - no recurrence
-
-Setup: mid-interview the user admits the workflow has only ever run once and
-may not recur.
-
-Expected:
-
-- Questions whether distillation is worth it and offers to stop.
-- Does not press on to create a skill for a one-off by default.
-
-## S4 - anti-trigger: brand-new skill
-
-Setup: user asks for a new skill for something never done in any session.
-
-Expected:
-
-- Skips the distiller ceremony and points at writing the SKILL.md directly,
-  following skill-craft.
-
-## Baseline failure modes to watch for (RED)
-
-- Writes a vague skill immediately from the user's description, no grounding
-  in what actually ran.
-- No overlap check; reimplements an installed skill's behavior.
-- No approval gate; the skill file appears before the user saw a design.
-- Session-specific paths, URLs, and values baked into the skill body.
-- Multi-question interviewing or an unbounded question stream.
-
-## Observed results
-
-Runs 2026-07-02, headless `clio-coder run --skill`. `ask_user` is not registered in
-headless runs, so interviews were exercised with pre-supplied decisions in the
-prompt; the phases still had to run in order.
-
-- Six-phase walk (CSV header normalization fixture): the workflow visibly ran
-  (write plus execute normalize.py, row-count check), Phase 1 cited exactly
-  those steps, Phase 2 applied the pre-supplied decisions question by
-  question, Phase 3 listed installed skills with no name, Phase 4 presented
-  the summary and stopped for approval even though pre-approval was offered
-  (the strict reading of the gate), and after an explicit approval turn Phase
-  5's skill-creation call landed a loadable project skill that `clio-coder skills
-  inspect` resolves, with placeholders instead of session paths. Phase 6
-  recorded the validation scenario in the body.
-- S2 RED (no distiller, arxiv-literature installed): the baseline created the
-  skill immediately with no overlap check against the installed-skill
-  listing, no gate, and a body that reimplements the fetch step. Gap
-  confirmed.
-- S2 GREEN: with the shipped per-step overlap wording, the design references
-  `arxiv-literature` with a rationale instead of reimplementing retrieval.
-  Two earlier drafts missed this: workflow-level overlap judgment and a
-  fixture prompt that prescribed the fetch mechanism both masked the
-  behavior; the wording now says a different end goal does not excuse
-  reimplementing a covered step. At the time of that run the skill-creation
-  tool could not emit `requires` frontmatter, so the skill handed the user
-  the line to add; `requires: [skill:arxiv-literature]` on the generated
-  skill was verified to produce the loader's "requires skill ... which is not
-  available" warning when the dependency is absent. 2026-07-02: skill
-  creation moved to writing SKILL.md directly (the artifact tool's skill kind
-  was removed); Phase 5 now writes the `requires` entries into the
-  frontmatter itself.
-
-## Smoke record (2026-08-13)
-
-One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
-(30B local, llamacpp on mini), full-auto sandbox. PASS. Inline session-trace setup engaged; judge 5/6.
-
-## Battletest record (2026-09-03)
-
-This skill's core loop (a several-turn interview, a live-or-headless design
-gate, a write) is genuinely interactive, so it was tested primarily through
-a live Herdr-driven `clio-coder` pane with a real human answering
-`ask_user` rounds, not only through the headless harness the rest of this
-category used — plus one headless confirm run to exercise the no-operator
-path directly. Fixture: the shared HPC log-triage repo (`test_grillme.py`'s
-`setup_fixture`, `docs/hpc-log-triage-architecture.md` + partial
-`src/scanner.py`/`tests/test_scanner.py`), compounded with a real Part 1
-task ("add `scan_ecc` mirroring `scan_oom`, test it, commit it") run to
-completion *before* invoking `/skill workflow-distiller`, so Phase 1 had a
-genuine session record to reconstruct from rather than a scripted one.
-
-**v1 (frozen 0.3.0), live, `ornith1.5-35b-moe` on mini**: Phase 1
-reconstruction was precise and correctly cited to real tool calls. The
-5-round interview (confirm+recurrence, varies/fixed, rigidity/failure,
-scope cuts, name) ran cleanly, one question per round, recommended-first.
-Phase 3's overlap check correctly found nothing to reference. Phase 4's
-design gate presented the exact template shape and correctly waited for a
-live "looks fine, write it" before writing anything. Two real bugs
-surfaced in Phase 5/6: (1) "load skill-craft" is dead - `context(scope=
-"skills", name="skill-craft")` while workflow-distiller is itself the
-active pending skill is refused ("pending skill request(s)"); only one
-skill can be active at a time. (2) Phase 6's "confirm it loads with
-`clio-coder skills validate`" is dead - `bash` is outside this skill's
-`allowed-tools`, so that command can never run. The model self-recovered
-both times (read its own installed SKILL.md as a frontmatter mirror; did a
-by-eye read-back instead of the blocked validate command) and reported the
-gap honestly rather than fabricating a clean validate - a good sign for
-model robustness, but the skill body should not depend on a model
-inventing its own workaround for a dead instruction.
-
-**Changes (0.3.0 -> 0.4.0)**: new `## Arguments` section stating the
-live-vs-headless distinction explicitly (a real, non-cancelled `ask_user`
-reply proves an operator is present and interview/gate proceed normally;
-`ask_user` unregistered and auto-cancelling means assumed-confirm through
-Phase 2 and Phase 4 and straight on to Phase 5 - a written skill file is a
-reversible, version-controlled artifact, not the kind of irreversible
-action `backlog`'s Step 3 guards, so it does not get that skill's
-stop-and-report treatment); explicit `tasks` refusal and a "never commits"
-note; Phase 4 gate prose updated with the headless branch; Phase 5 rewrote
-the skill-craft consultation into a concrete, achievable frontmatter
-contract (the required keys, and "`read` an already-installed skill's file
-to mirror the shape, never try to load a second skill mid-run"); Phase 6
-rewrote the validate step to a real, achievable by-eye check instead of
-the dead `bash` command; the worked example's line claiming `clio-coder
-skills validate` passes was corrected to match; two new Red Flags entries
-for the two dead-instruction failure modes.
-
-**v2 (hardened 0.4.0), live, `ornith1.5-35b-moe` on mini, fresh session**:
-same compound Part 1 + Part 2 scenario end to end. Real finding along the
-way, unrelated to this skill: the model cannot self-invoke `/skill` - it
-is operator-gated UI, not an agent tool, confirmed twice (once via a
-direct `context` call, once by embedding `/skill workflow-distiller` in a
-larger message instead of sending it standalone) - both times the model
-correctly recognized the constraint, said so, and asked the operator to
-run it rather than retrying or faking activation. Once invoked properly:
-Phase 1 reconstruction included the real mid-session detour (a genuine
-case-sensitivity bug the model introduced and fixed via byte-level
-debugging) rather than a cleaned-up story. The interview produced a
-materially different design from v1's run on the same scenario (different
-name chosen, "leave uncommitted" instead of "commit via bash" for the
-generated skill) - real evidence the interview is actually deciding things,
-not replaying a script. Phase 4 correctly said "this is a live run, so
-I'll hold off writing until you approve" and, when a later `ask_user`
-round had already closed, correctly fell back to a plain-text approval
-request rather than stalling - explicitly restating, unprompted, every
-constraint this session's hardening pass had just added (no commit, no
-`clio-coder skills validate`, `tasks` out of surface). Phase 5 went
-straight to `read`-ing its own installed SKILL.md to mirror the frontmatter
-contract, with zero attempt to load skill-craft - bug #1 confirmed fixed.
-The generated `.clio-coder/skills/add-signature-scanner/SKILL.md` (97
-lines) has valid frontmatter, canonical-lowercase `allowed-tools`, real
-placeholders, and a concrete validation scenario.
-
-**A real, separate platform-level finding, not a skill-body bug**: during
-this same v2 live session's Phase 6, a `bash wc -l` call executed
-successfully (`exit 0`, green checkmark confirmed via `--format ansi`) even
-though `bash` is not in workflow-distiller's `allowed-tools` - and the
-identical class of call had been correctly refused earlier in this exact
-mission's v1 session under the same skill ("bash is outside the tool
-surface declared by the active skill(s)"). The model's own final report
-then claimed "I can't run bash" in the same breath as having just run it.
-This reads as skill tool-surface narrowing lapsing partway through a long,
-many-turn interactive session (Phase 1 through 6 spans several real
-conversation turns; the headless harness's single-turn monologue shape
-never exercises this), not anything a SKILL.md can fix by itself. Worth a
-maintainer look at the interactive admission path specifically, independent
-of this skill or this mission's edits.
-
-**Headless confirm, `qwen3.8-27b` on dynamo, fresh fixture**: single
-`clio-coder run --skill ... --autonomy full-auto --json`. Real fixture
-mismatch, deliberately not corrected: the prompt claimed a prior
-`scan_ecc` commit that does not exist in this fresh fixture (no Part 1 ran
-here). Phase 1 caught the discrepancy against real evidence (`grep` found
-no `scan_ecc`, git log has one seed commit, the docstring still says "not
-yet implemented"), tagged the claim `assumption - unverified`, and
-grounded the distillation in the real architecture doc and `scan_oom`'s
-actual code instead of fabricating verification of a commit that never
-happened - the skill's stated identity ("runtime truth... reconstruction
-wins") holding on a weaker/non-live model under direct pressure to just
-agree. Ran the full assumed-confirm monologue through Phase 2 and Phase 4
-(explicitly marked), wrote `.clio-coder/skills/signature-scanner/SKILL.md`
-(92 lines, valid frontmatter, canonical-lowercase tools, real placeholders,
-a concrete failure-behavior section, a validation scenario naming the still
--owed real `clio-coder skills validate` pass). Zero safety blocks.
-
-**Still weak**: the skill-craft mid-run-load and dead-`bash`-validate bugs
-are confirmed fixed by re-test, but only against this one fixture shape.
-S2 (overlap with an installed skill) was not exercised this pass - this
-fixture's only installed skill is workflow-distiller itself, so the overlap
-check always correctly found nothing; a fixture with a second installed
-skill covering one step is still owed. S3 (no recurrence, offer to stop)
-was not exercised standalone. The tool-surface-lapse finding above is
-real, reproduced, and unresolved - it is the single biggest risk this pass
-surfaced, and it sits outside this skill (and outside `skills/`) entirely.

package/src/domains/extensions/resource-path.ts

@@ -1,27 +0,0 @@
-import { realpathSync, statSync } from "node:fs";
-import path from "node:path";
-
-export function extensionResourcePath(rootPath: string, resourcePath: string): string | null {
-	const root = path.resolve(rootPath);
-	const full = path.resolve(root, resourcePath);
-	const relative = path.relative(root, full);
-	if (relative === "" || relative === ".." || relative.startsWith(`..${path.sep}`) || path.isAbsolute(relative)) {
-		return null;
-	}
-	try {
-		const rootReal = realpathSync(root);
-		const fullReal = realpathSync(full);
-		const canonicalRelative = path.relative(rootReal, fullReal);
-		if (
-			canonicalRelative === ".." ||
-			canonicalRelative.startsWith(`..${path.sep}`) ||
-			path.isAbsolute(canonicalRelative)
-		) {
-			return null;
-		}
-		if (!statSync(fullReal).isDirectory()) return null;
-		return fullReal;
-	} catch {
-		return null;
-	}
-}

package/src/domains/extensions/resources.ts

@@ -1,37 +0,0 @@
-import { realpathSync } from "node:fs";
-import path from "node:path";
-import { buildExtensionSnapshot } from "./snapshot.js";
-import { committedExtensionSnapshot } from "./snapshot-store.js";
-import type { ExtensionResourceKind, ExtensionResourceRoot, ExtensionSnapshot } from "./types.js";
-
-export { extensionResourcePath } from "./resource-path.js";
-
-/**
- * The committed snapshot when a store is bound for this cwd; otherwise an
- * ephemeral generation-0 build that never touches the store. The ephemeral
- * branch serves the CLI, `config inspect` with an explicit cwd, and any
- * process that never booted the extensions bundle.
- */
-export function extensionSnapshotFor(cwd = process.cwd()): ExtensionSnapshot {
-	const committed = committedExtensionSnapshot();
-	try {
-		if (committed !== null && committed.cwd === realpathSync(path.resolve(cwd))) return committed;
-	} catch {
-		// Fall through to an ephemeral build, which retains the original error semantics.
-	}
-	return buildExtensionSnapshot({ cwd, generation: 0 });
-}
-
-/**
- * The canonical accessor for the enabled roots of one extension resource
- * kind. The agent registry, fleet contract, skill and common resource
- * loaders, and the extensions contract all read through it, so each of them
- * sees the committed snapshot for the booted cwd or the ephemeral
- * generation-0 build otherwise. Returns a fresh array the caller may mutate.
- */
-export function enabledExtensionResourceRoots(
-	kind: ExtensionResourceKind,
-	cwd = process.cwd(),
-): ExtensionResourceRoot[] {
-	return [...extensionSnapshotFor(cwd).resourceRoots[kind]];
-}

package/src/domains/lifecycle/migrations/2026-09-01-extension-install-digests.ts

@@ -1,27 +0,0 @@
-import { mkdirSync } from "node:fs";
-import { join } from "node:path";
-import { safeResourceWrite } from "../../../core/safe-resource-write.js";
-import { upgradeLegacyExtensionInstallState } from "../../extensions/state.js";
-import type { Migration } from "./index.js";
-
-export const EXTENSION_INSTALL_DIGESTS_MIGRATION_ID = "2026-09-01-extension-install-digests";
-
-function migrateExtensionInstallDigests(stateDir: string, cwd = process.cwd()): void {
-	const scopes = upgradeLegacyExtensionInstallState(cwd);
-	const reportDir = join(stateDir, "migration-reports");
-	mkdirSync(reportDir, { recursive: true });
-	safeResourceWrite(
-		join(reportDir, `${EXTENSION_INSTALL_DIGESTS_MIGRATION_ID}.json`),
-		`${JSON.stringify({ migration: EXTENSION_INSTALL_DIGESTS_MIGRATION_ID, scopes }, null, 2)}\n`,
-		{ encoding: "utf8", mode: 0o644 },
-	);
-}
-
-const migration: Migration = {
-	id: EXTENSION_INSTALL_DIGESTS_MIGRATION_ID,
-	async up(stateDir: string): Promise<void> {
-		migrateExtensionInstallDigests(stateDir);
-	},
-};
-
-export default migration;

package/src/interactive/overlays/agents.ts

@@ -1,70 +0,0 @@
-import type { OverlayHandle, TUI } from "../../engine/tui.js";
-import type { SlashCommandContext } from "../slash-commands.js";
-import { type ListOverlayItem, openListOverlay } from "./list-overlay.js";
-
-export function openAgentsOverlay(tui: TUI, ctx: SlashCommandContext, onClose: () => void): OverlayHandle {
-	const clioAgents = ctx.listAgents();
-	const fleetItems: ListOverlayItem[] = clioAgents
-		.filter((agent) => !agent.tags?.some((tag) => tag === "delegation" || tag === "acp"))
-		.map((agent) => {
-			const label = `${agent.id.padEnd(16)}${agent.description}`;
-			const meta = `${agent.audience}/${agent.category}/${agent.capabilityClass}`;
-			return {
-				id: agent.id,
-				label,
-				meta,
-				group: "Fleet agents",
-				detail: () => {
-					const lines = [
-						`# Fleet Agent: ${agent.id}`,
-						`**Description:** ${agent.description}`,
-						`**Audience:** ${agent.audience}`,
-						`**Category:** ${agent.category}`,
-						`**Capability Class:** ${agent.capabilityClass}`,
-					];
-					if (agent.skills.length > 0) {
-						lines.push(`**Skills:** ${agent.skills.join(", ")}`);
-					}
-					return lines;
-				},
-			};
-		});
-
-	const delegationAgents = ctx.listDelegationAgents();
-	const delegationItems: ListOverlayItem[] = delegationAgents.map((agent) => {
-		const fullCmd = [agent.command, ...agent.args].join(" ");
-		const label = `${agent.id.padEnd(18)}${fullCmd}`;
-		const meta = `governance=${agent.toolGovernance ?? "clio-coder-policy"}`;
-		return {
-			id: agent.id,
-			label,
-			meta,
-			group: "ACP delegation agents",
-			detail: () => {
-				const lines = [
-					`# ACP Delegation Agent: ${agent.id}`,
-					`**Command:** \`${fullCmd}\``,
-					`**Governance:** ${agent.toolGovernance ?? "clio-coder-policy"}`,
-				];
-				if (agent.labels && Object.keys(agent.labels).length > 0) {
-					lines.push(`**Labels:**`);
-					for (const [key, value] of Object.entries(agent.labels)) {
-						lines.push(`- ${key}: ${value}`);
-					}
-				}
-				return lines;
-			},
-		};
-	});
-
-	const items = [...fleetItems, ...delegationItems];
-
-	return openListOverlay(tui, {
-		markerId: "agents",
-		title: "Agents Reference",
-		items,
-		filterable: true,
-		emptyMessage: "No agents found",
-		onClose,
-	});
-}