wicked-crew 0.9.3 → 0.9.5

package/dist/core/adapter.js

@@ -1,7 +1,8 @@
+import { builtinDefs as deriveBuiltinDefs } from './builtin-catalog.js';
 import { createRequire } from 'node:module';
 import { attachEngineBus, detachEngineBus } from './bus.js';
 import { mkdir, access, readFile, writeFile, chmod, rm, link, rename, realpath, stat } from 'node:fs/promises';
-import { existsSync, readdirSync, readFileSync, renameSync } from 'node:fs';
+import { existsSync } from 'node:fs';
 import { join, dirname, resolve, isAbsolute, relative, sep } from 'node:path';
 import { isPlainRunId, WALKTHROUGH_AUTHOR_SUBDIR, walkthroughRootDir } from './walkthrough-root.js';
 import { crewStateHome, isDefaultStateHome } from '../projects/state-home.js';
@@ -11,10 +12,8 @@ import { randomUUID } from 'node:crypto';
 import { DEFAULT_SETTINGS } from './types.js';
 import { BASE_SKILL_REF_SHAPE } from '../skills/base-skill.js';
 import { execCapped } from './exec.js';
-import { BUG_FIX_SWEEP_INSTRUCTIONS, composeDeliverWorkflow, DELIVER_PHASE_ID, deliverPresetStep, deliverIdentityFor, deliverRepoFor, EVIDENCE_FLOOR_PIN, isGitHubLogin, pushIdentityOf, readDeliverOriginUrl } from './deliver.js';
+import { composeDeliverWorkflow, DELIVER_PHASE_ID, deliverPresetStep, deliverIdentityFor, deliverRepoFor, isGitHubLogin, pushIdentityOf, readDeliverOriginUrl } from './deliver.js';
 import { engineCampaignDef, engineRosterJson } from './engine-roster.js';
-import { QE_AUTHOR_TESTS_WORKFLOW_DEF } from '../qe/author-workflow.js';
-import { CAMPAIGN_WORKFLOW_PREFIX } from '../campaigns/plan.js';
 import { composeDeliverableFloor } from './deliverable-floor.js';
 import { deliverCredentialsProbe } from './deliver-credentials.js';
 import { isSyntheticWorkflowId, resolveRunIdentity, verifiedEvidenceCatalog, wireIdentity, withPresetSystemFlag, withSystemFlag, } from './run-identity.js';
@@ -44,20 +43,6 @@ function parseEngineJson(raw, method) {
         throw new Error(`${method}: engine returned invalid JSON (${e instanceof Error ? e.message : String(e)})`);
     }
 }
-/**
- * Workflow overlay directory — mirrors the Rust `workflow_overlay_dir()` logic in
- * `pipeline.rs`. The Rust actor reads drop-in workflow JSONs from this path at startup
- * and (with registerWorkflow NAPI) at runtime. TS must write to the same location so
- * the files are picked up on the next daemon start.
- *   • `$WICKED_WORKFLOWS_DIR`  — explicit override (matches Rust env check)
- *   • `~/.config/wicked-core/workflows`  — default (matches Rust default)
- */
-function workflowOverlayDir() {
-    if (process.env.WICKED_WORKFLOWS_DIR)
-        return process.env.WICKED_WORKFLOWS_DIR;
-    const home = process.env.HOME ?? process.env.USERPROFILE ?? '/tmp';
-    return join(home, '.config', 'wicked-core', 'workflows');
-}
 /** Where the daemon persists system settings. Exported so tests write fixtures to the ONE
  *  spelling of this path (the tests/ tree is audited against spelling core paths itself).
  *
@@ -167,83 +152,6 @@ async function publishSettingsFile(linkPath, body, replace) {
  * the number a third time so a change to either side breaks a test rather than a deployment.
  */
 const STUDIO_SETTINGS_MAX_BYTES = 512 * 1024;
-/** Read user-registered workflow overlays from `dir` (the same dir `registerWorkflow` writes to).
- *
- * Skips: files whose id matches a built-in (those are `_writeBuiltinOverlay` artifacts written FOR
- * the Rust actor, not user workflows — including them would duplicate a built-in in `listWorkflows`),
- * non-`.json` files, and any file that does not parse into a `{id, phases[]}` shape (the Rust actor
- * skips an unreadable overlay too, so crew must not surface one it can't). A missing dir yields `[]`.
- *
- * Exported so the FINDING-002 restart-hydration path is unit-testable without spawning a Core. */
-export function readOverlayWorkflows(dir, builtinIds) {
-    let files;
-    try {
-        files = readdirSync(dir);
-    }
-    catch {
-        return []; // no overlay dir yet → nothing registered
-    }
-    const out = [];
-    for (const file of files) {
-        if (!file.endsWith('.json'))
-            continue;
-        const id = file.slice(0, -'.json'.length);
-        if (builtinIds.has(id))
-            continue; // a built-in overlay, not a user workflow
-        // A composed campaign-node workflow (TH-9): persisted here so the Rust actor reloads it at
-        // startup (a fresh-process resumeCampaign re-dispatches pending nodes by workflow id), but
-        // it is one node's private plumbing, not a user workflow — keep it out of the catalog.
-        if (id.startsWith(CAMPAIGN_WORKFLOW_PREFIX))
-            continue;
-        try {
-            const def = JSON.parse(readFileSync(join(dir, file), 'utf8'));
-            if (def && typeof def.id === 'string' && Array.isArray(def.phases))
-                out.push(def);
-        }
-        catch {
-            // Unparseable overlay — core would skip it at load, so crew skips it too.
-        }
-    }
-    return out;
-}
-/** Ask CORE's parser which drop-in defs it will actually honour (crew#718).
- *
- * {@link readOverlayWorkflows} checks a `{id, phases[]}` shape, which is not the engine's contract:
- * `WorkflowRegistry::load_dir` runs `refuse_reserved_id` + `WorkflowDef::validate()` and SKIPS the
- * file it rejects, loudly, on the daemon's stderr. So the catalog listed defs the engine had thrown
- * away at boot and the launch then 400'd `unknown workflow` — the MCP S8 dogfood's F-3, on a
- * hand-authored drop-in whose `executes_code` phase pinned no validator ("gate evaluates nothing").
- *
- * The same doctrine {@link CoreAdapter.registerWorkflow} states for the WRITE path applies here:
- * core's parser is the authority, so it is what we ask. Enumerating `validate()`'s rules in
- * TypeScript would be a second copy of core's schema — the drift that produced this defect.
- * `register` is the engine's `registerWorkflow` binding, which validates before it registers and
- * is idempotent on id, so re-offering a def the engine already loaded at boot is a same-content
- * overwrite; a def added to the dir after boot becomes launchable rather than being listed and
- * refused.
- *
- * `is_system` is stripped first, exactly as the two write paths do: it is crew's own display flag
- * and core's strict def parser rejects the key.
- *
- * Pure (no adapter state) so it is unit-testable without spawning a Core, like
- * {@link readOverlayWorkflows}.
- */
-export async function judgeOverlayWorkflows(defs, register) {
-    const accepted = [];
-    const refused = [];
-    for (const def of defs) {
-        const overlayDef = { ...def };
-        delete overlayDef.is_system;
-        try {
-            await register(JSON.stringify(overlayDef));
-            accepted.push(def);
-        }
-        catch (err) {
-            refused.push({ id: def.id, reason: err instanceof Error ? err.message : String(err) });
-        }
-    }
-    return { accepted, refused };
-}
 // The native addon is a CommonJS cdylib (`index.node`); load it with a CJS
 // require even though this daemon is ESM. This module is the ONLY place that
 // touches wicked-core-ts (DES-STUDIO-001 §5.2/§5.3), so the FINALIZING
@@ -432,241 +340,9 @@ function addonAtLeast(maj, min, pat) {
         return false;
     }
 }
-// ── Built-in workflow definitions (crew#44) ──────────────────────────────────
-// Static mirrors of wicked-core workflow defs: feature, bug, migration and domain-extraction, plus
-// crew's own defs. `chat` and `onboarding` are engine built-in PRESETS (DES-TEAMING-002 M3/M4),
-// launched by the same name with no def here; `survey-repo`, `memories`, `domain-graph-slice` and
-// `collab` are deleted (nothing launched them).
-// Swap for `this.core.listWorkflowsJson()` / `this.core.getWorkflowJson(id)` once
-// the wicked-core-ts NAPI methods land.
-/**
- * The ids wicked-core seeds itself, in `WorkflowRegistry::with_defaults()`.
- *
- * `launchRun`'s generic drop-in overlay write SKIPS every id in this set.
- * A file in that dir shadows the compiled built-in
- * *wholesale* — `register` overwrites by id and `load_dir` runs after `with_defaults` — so writing
- * this hand-transcribed mirror over the real def silently replaces it with a copy missing whatever
- * the def has grown since the mirror was transcribed. That is not hypothetical: the mirror predated
- * the evidence floors, so the write took `validator_pin` back off `feature.adversarial-review`,
- * `bug.verify` and `migration.verify` — the entire content of core's gate-floor change, undone by a
- * file write, with no error and a workflow still reporting the right id and phases (FINDING-049).
- *
- * The write exists for the ids core does NOT seed (domain-extraction and crew's own defs): for
- * those the overlay is the only reason they resolve at all, so it stays.
- */
-const CORE_SEEDED_WORKFLOWS = new Set(['feature', 'bug', 'migration']);
-// `EVIDENCE_FLOOR_PIN` (imported from ./deliver.js, defined once) is carried on the Evaluator phase
-// of feature/bug/migration AND, since wicked-core F-039, on their code-writing Creator phases
-// (`build`/`fix`/`execute`) — so the gate that was supposed to make the change re-derives its diff
-// and a distinct seat judges it, instead of approving nothing. What `listWorkflows()` serves IS what
-// `GET /api/v1/workflows` and the work-mode selector show, and a `null` here reads as "this phase
-// is ungated" — the opposite of the truth. Since wicked-core#414 the engine also REFUSES a mirror
-// that lags (a code phase whose gate evaluates nothing is rejected as authored), so these values
-// are part of the contract with the engine, not display only: the drift guards in
-// `tests/armed-workflow-served.test.ts` and `tests/builtin-overlay-shadow.test.ts` fail loudly
-// the moment core's defs move. As of FINDING-049 these defs are never written to core's overlay dir
-// (see CORE_SEEDED_WORKFLOWS).
-// `is_system` is NOT spelled on these defs: `withSystemFlag` stamps it from `SYSTEM_WORKFLOWS`
-// (core/run-identity.ts), the one list keyed by name that also classifies served runs (seam X2).
-/** QE-IN-APP-WORKFLOWS (operator ruling 2026-10-10): what a workflow that makes application changes
- *  requires — the defaults plus `qe_acceptance` — exactly as core's `feature`/`bug`/`migration`/
- *  `mcp-server` defs declare it (the mirror guards compare field for field). */
-const APP_CHANGE_INSTRUMENTS = ['distinct_evaluator', 'judge', 'qe_acceptance'];
-export const BUILTIN_WORKFLOWS = [
-    {
-        id: 'feature',
-        phases: [
-            { id: 'clarify', kind: 'recon', gate_type: 'value', gate: { human_confirm: { unconditional: false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'design', kind: 'recon', gate_type: 'strategy', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['clarify'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'build', kind: 'build', gate_type: 'execution', gate: 'auto', executes_code: true, verified_evidence: false, required_deliverables: [], depends_on: ['design'], role: 'creator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'adversarial-review', kind: 'review', gate_type: 'execution', gate: { human_confirm: { unconditional: false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['build'], role: 'evaluator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'test', kind: 'test', gate_type: 'execution', gate: { human_confirm_if: 'verdict_not_pass' }, executes_code: false, verified_evidence: true, required_deliverables: [], depends_on: ['build'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'review', kind: 'review', gate_type: 'execution', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['test'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-        ],
-        required_instruments: APP_CHANGE_INSTRUMENTS,
-    },
-    {
-        id: 'bug',
-        phases: [
-            { id: 'triage', kind: 'recon', gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'reproduce', kind: 'test', gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['triage'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            // DES-L9 (BC-60, core#432): the retired-behaviour sweep — the SAME literal core's `bug_def()` carries (wicked-core #522); pinned by a test
-            // so the two carriers cannot drift. `builtin-overlay-shadow.test.ts` tolerates exactly this one field while core MAIN has not merged #522
-            // (crew CI compares this mirror with core main); row 6.9 (the `^0.7.27` pin) removes that tolerance.
-            { id: 'fix', kind: 'build', instructions: BUG_FIX_SWEEP_INSTRUCTIONS, gate_type: 'execution', gate: 'auto', executes_code: true, verified_evidence: false, required_deliverables: [], depends_on: ['reproduce'], role: 'creator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'verify', kind: 'test', gate_type: 'execution', gate: { human_confirm_if: 'verdict_not_pass' }, executes_code: false, verified_evidence: true, required_deliverables: [], depends_on: ['fix'], role: 'evaluator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-        ],
-        required_instruments: APP_CHANGE_INSTRUMENTS,
-    },
-    {
-        id: 'migration',
-        phases: [
-            { id: 'plan', kind: 'recon', gate_type: 'strategy', gate: { human_confirm: { unconditional: false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'execute', kind: 'build', gate_type: 'execution', gate: 'auto', executes_code: true, verified_evidence: false, required_deliverables: [], depends_on: ['plan'], role: 'creator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'cutover', kind: 'build', gate_type: 'execution', gate: { human_confirm: { unconditional: true } }, executes_code: true, verified_evidence: false, required_deliverables: [], depends_on: ['execute'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'verify', kind: 'test', gate_type: 'execution', gate: { human_confirm_if: 'verdict_not_pass' }, executes_code: false, verified_evidence: true, required_deliverables: [], depends_on: ['cutover'], role: 'evaluator', skill_ref: null, allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN },
-            { id: 'cleanup', kind: 'build', gate_type: null, gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['verify'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-        ],
-        required_instruments: APP_CHANGE_INSTRUMENTS,
-    },
-    {
-        // capture-learnings (DES-MEM-FACETED-001 write side, onboarding): survey a just-indexed repo,
-        // then propose its durable learnings — BOTH faceted MEMORIES and repo POLICIES — as inert estate
-        // `proposal.submit` proposals (through garden's estate shim) a human later reviews.
-        //
-        // ONE workflow, not four. "Go multi-workflow" is realized as multi-PHASE composition inside a
-        // single governed run, NOT as separate churn-analysis / hotspot-read / derive-memories /
-        // derive-policies RUNS, because:
-        //   • Context threading: the learning method is a dependent chain (churn ranking → hotspot
-        //     cross-reference → capture). Crew threads each phase's output into the next phase's prompt
-        //     automatically (plan.rs folds prior context); separate runs share NOTHING, so a split would
-        //     sever that thread and each run would re-establish repo understanding from scratch.
-        //   • Council cost: every phase convenes a ~6-seat council (the ecosystem's spikiest operation,
-        //     serialized on purpose). Four runs multiply that; three phases in one run pay it once each.
-        //   • The Memories-vs-Policies review split is a proposal-KIND concern, not a workflow-identity
-        //     one: `kind_type` routes memory→studio Memories and policy:<type>→Steering downstream, so a
-        //     SINGLE `capture` phase emits both from the one shared understanding — splitting derive-
-        //     memories / derive-policies would re-run a council over the same context for no new evidence.
-        //   • Reuse already lives below the run: the reusable unit is the SKILL (and hotspot-read is
-        //     already a reusable capability via `wicked-garden-search`).
-        //
-        // The METHOD lives in the garden skill `wicked-garden-repo-learn`, referenced per-phase by
-        // `skill_ref` — the engine emits only a short `Invoke your skill "wicked-garden:repo-learn"…`
-        // directive and the worker loads SKILL.md from the installed plugin. The bounded git-churn
-        // sampling, the estate tool names (reached through the shim), and the proposal payload schemas that used to sit inline as
-        // ~600-column prose now live in that skill; the inline `instructions` here are a one-line phase
-        // ORIENTATION only. That matters because a governed worker's prompt rides a single PTY line capped
-        // at 1022 bytes (>=1023B is SILENTLY discarded — wicked-core execute_wrapped.rs), and the planner
-        // folds this text onto that line alongside the run intent, so long inline prose here would blow
-        // the line. Crew-only (NOT core-seeded), so the overlay write is the only def the engine resolves
-        // — no core mirror, and deliberately NOT in builtin-overlay-shadow's MIRRORED_IDS.
-        //
-        // The shim's `wicked-estate-mcp --readonly` opens the operator GLOBAL memory store and permits
-        // `proposal.submit` (a safe write, provenance server-stamped from the WICKED_RUN_* markers on the
-        // worker env — DES-L4 PR-③/⑦; there is no CLI-registered estate MCP on the worker any more),
-        // so proposals land in the same queue the studio Memories/Policies surfaces review. Onboarding IS
-        // about the repo, so the skill tags learnings `repo:`/`project:`.
-        id: 'capture-learnings',
-        phases: [
-            { id: 'churn', kind: 'recon', instructions: "Phase 1/3 CHURN: produce a ranked list of this repo's most actively-changed files and directories over the last ~12 months, plus the repo's real name (manifest or git remote) and parent project. Use the skill's bounded/sampled git-churn method — never stream the whole history. Do not read code deeply yet; the next phase targets these areas.", gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: 'wicked-garden-repo-learn', allowed_skills: [], validator_pin: null },
-            { id: 'hotspots', kind: 'recon', instructions: "Phase 2/3 HOTSPOTS: cross-reference the prior churn ranking with wicked-estate hotspot / blast-radius signals to find the load-bearing code, then READ it through the estate shim (`wicked-garden run scripts/_estate_client.py --readonly call …`, the skill's grounding path) to build a real technical understanding of how the system fits together — not a file listing. Reuse wicked-garden-search for the hotspot signals; follow the skill.", gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['churn'], role: 'neutral', skill_ref: 'wicked-garden-repo-learn', allowed_skills: [], validator_pin: null },
-            // (BC-80, wicked-core#535) `requires_capture_report`: the engine's capture-report floor reads
-            // the phase's output marker, so a capture run whose skill loaded and never ran can no longer
-            // report `completed` with 0 proposals — a missing marker, a failed submission and proposals
-            // derived but never submitted each deny into the human gate. An honest 0 passes. The
-            // instruction MANDATES the marker; garden's repo-learn skill carries the same contract, and
-            // the counts land on the unit (`capture_report`), which `GET /runs/:id` serves.
-            { id: 'capture', kind: 'build', instructions: "Phase 3/3 CAPTURE: from the prior churn + hotspot understanding, submit durable learnings as estate proposals through the shim's `propose` per the skill's capture contract — BOTH memories (facts / how-it-works) and policies (enforced conventions), one proposal per item, tagged repo/project. Each is inert until human review; never include secrets or personal data. END with `wicked-capture-report {\"derived\": N, \"submitted\": M, \"failed\": K}` — always, even on a degrade or a legitimate 0 (which is acceptable).", gate_type: 'value', gate: 'auto', executes_code: false, requires_capture_report: true, verified_evidence: false, required_deliverables: [], depends_on: ['hotspots'], role: 'creator', skill_ref: 'wicked-garden-repo-learn', allowed_skills: [], validator_pin: null },
-        ],
-    },
-    {
-        // "Add with chat" for the Steering surface (STEERING program) — the dedicated entry point
-        // behind POST /governance/steering/author. TH-12 propose-as-gate: the run analyzes the
-        // operator's intent + the named files/dirs, then the TERMINAL `propose` phase emits the
-        // PROPOSED steering rules and its unconditional human gate pauses the run `awaiting_human`
-        // (core evaluates a terminal phase's own gate before finalize — seam finding #4), so the
-        // operator approves/amends/rejects via the standard POST /runs/:id/gate. Approved rules land
-        // CREW-SIDE on that approve: the gate handler writes them through the governed rules seam
-        // with `provenance.source: "chat"` (api/steering-landing.ts, crew#388) — the run itself must
-        // never write the store, which is why both phases say so out loud. The propose phase hands
-        // the rules back in its REPLY — one ```json fenced array — and the landing reads them from the
-        // unit's stored output (#789). It used to be told to write the array to a file in the per-run
-        // inbox under the home config; a seat's sandbox refuses a write outside its workspace (codex's
-        // "approval request failed"), so every author run reported a failed write and the rules only
-        // landed through the transcript anyway. The reply is now the designed path, not a fallback.
-        //
-        // Crew-authored drop-in: NOT in CORE_SEEDED_WORKFLOWS, so launchRun's
-        // `_writeBuiltinOverlay` write is the only way core resolves the id — the same delivery
-        // mechanism every crew drop-in uses.
-        id: 'steering-author',
-        phases: [
-            { id: 'analyze', kind: 'recon', instructions: 'Read the operator intent and every file or directory listed in the problem statement. Identify candidate steering rules: durable, prescriptive statements a coding agent must follow, each classified into one steering type (architecture, development, security, testing, operations, compliance, design-ux). For each candidate note the statement, steering type, severity, and the evidence in the source material. Analysis only — do not write any rule to any store, and do not emit final rule JSON yet.', gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-            { id: 'propose', kind: 'recon', instructions: 'From the prior analysis, emit the PROPOSED steering rules as one JSON array. Each entry is a conformance-rule object: id (PAT-<digits> for rule_type "pattern", POL-<digits> for "policy"), rule_type, statement, severity (info|warn|error|critical), confidence (a NUMBER 0..1), steering_type (default to the type named in the problem statement), provenance {"source":"chat"}, and — only where the source material supports them — the enforcement fields applies_to (array of phase tokens or globs), excludes, weight, obligations (array of strings), criteria (ONE string, never a list). Omit targets, effect and trigger unless you can express them in the store schema exactly: targets is a {language, layer, framework} facet OBJECT (never a file list — files belong in applies_to), and trigger is a structured condition object (never prose). Put that JSON array in your reply, ONCE, as a single ```json fenced block (the whole array, valid JSON): your reply IS the proposal — crew reads the array from it when the human approves. Do not write it to any file and do not create files for it. This output is a PROPOSAL for the human gate: rules land in the governance store only after approval, written crew-side — do not write any rule to any store yourself.', gate_type: 'value', gate: { human_confirm: { unconditional: true } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['analyze'], role: 'creator', skill_ref: null, allowed_skills: [], validator_pin: null },
-        ],
-    },
-    // The governed test-authoring workflow (wave 6 — F-7R2-003/004/005/012/014/015, R4-r2): recon →
-    // author (creator, evidence-floor pinned) → verify (a TOOL phase that RUNS every produced test
-    // under the repository's own harness and fails the unit when one fails or never ran) → review
-    // (evaluator ≠ creator). Delivery is appended per run by the engine-side composition (`deliver:
-    // "pr"`), never performed by a worker. Def + verify script live in `qe/author-workflow.ts` so the
-    // e2e can assert the script's behaviour without reaching into this array. Crew-only drop-in (NOT
-    // core-seeded); the `wicked-garden-qe` skill carries the method (plan/author/review actions).
-    QE_AUTHOR_TESTS_WORKFLOW_DEF,
-    // The one workflow that ARMS the dual-validator gate: `coverage` carries an approved
-    // `validator_pin`, so layer 1 is live here and inert in every entry above. Transcribed
-    // field-for-field from the source of truth, `wicked-core/workflows/domain-extraction.json`
-    // (core ships it as a *drop-in*, not a seeded built-in, and exposes no dump command — hence a
-    // hand-transcribed mirror, like every other entry in this array).
-    //
-    // The pin is a content hash over the validator's criterion + script + approved flag. Core
-    // re-derives it in `domain_extraction.rs` and fails its own test if it drifts; if that test ever
-    // forces core's constant to change, THIS literal must change with it or crew will write an
-    // overlay that fails closed at plan time.
-    //
-    // Running it needs a one-time, idempotent `wicked-core seed-domain-validators` to vault + approve
-    // that validator. That step is deliberately manual — approval is an audited act a human/council
-    // owns, not something a daemon does unattended — and until it is run, a launch fails CLOSED at
-    // plan time rather than running the phase ungated. Not `is_system`: this is an operator-selectable
-    // work mode, unlike the dedicated-entry-point workflows above.
-    {
-        id: 'domain-extraction',
-        phases: [
-            // required_deliverables reconciled with core (wicked-core/workflows/domain-extraction.json):
-            // survey/analyze/extract annotate the estate STORE and domain-graph now PERSISTS the graph
-            // into the store (not a JSON file), so their evidence is DB state — verified by the coverage
-            // gate (reads the store) and domain-graph's fail-closed-on-coverage<1.0 — not a worktree file.
-            // Only coverage emits a genuine standalone report the deterministic floor reads. Declaring
-            // phantom files failed every phase under core's FINDING-101 deliverable gate.
-            //
-            // `coverage` is `executes_code: true` (wicked-core#414): it WRITES `coverage-report.json`
-            // into the worktree for its pinned validator to read, and an `executes_code: false` phase
-            // may write nothing there — the worktree guard has no exemptions, declared deliverables
-            // included. Its role stays `evaluator`; the deliver default keys off code-writing
-            // NON-EVALUATOR phases (`executes_code && role !== 'evaluator'`), so this def never delivers.
-            { id: 'survey', kind: 'recon', gate_type: null, gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: 'neutral', skill_ref: 'wicked-garden-domain', allowed_skills: [], validator_pin: null },
-            { id: 'analyze', kind: 'recon', gate_type: null, gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['survey'], role: 'neutral', skill_ref: 'wicked-garden-domain', allowed_skills: [], validator_pin: null },
-            { id: 'extract', kind: 'recon', gate_type: 'value', gate: 'auto', executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['analyze'], role: 'creator', skill_ref: 'wicked-garden-domain-extractor', allowed_skills: [], validator_pin: null },
-            { id: 'coverage', kind: 'test', gate_type: 'execution', gate: { human_confirm_if: 'verdict_not_pass' }, executes_code: true, verified_evidence: true, required_deliverables: ['coverage-report.json'], depends_on: ['extract'], role: 'evaluator', skill_ref: 'wicked-garden-domain-coverage', allowed_skills: [], validator_pin: 'bfe4020a365c598b' },
-            // domain-graph is a DETERMINISTIC Tool that runs `wicked-core domain-graph`, which PERSISTS the
-            // domain/requirement/rule graph into the repo store (core#237) — not an LLM skill that could hit
-            // a non-persisting hermetic fallback. Mirrors wicked-core/workflows/domain-extraction.json.
-            { id: 'domain-graph', executor: { type: 'tool', cmd: ['wicked-core', 'domain-graph', '--db', '{code_graph_db}', '--out', 'requirements_graph.json'] }, kind: 'build', gate_type: 'strategy', gate: { human_confirm: { unconditional: false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ['coverage'], role: 'neutral', skill_ref: null, allowed_skills: [], validator_pin: null },
-        ],
-    },
-    // The MCP-server drop-in (DES-mcp-server-workflow): transcribed field for field — every
-    // `instructions` string verbatim, the gates, pins, roles, skill_refs, depends_on and the install
-    // phase's `executor` — from the source of truth, `wicked-core/workflows/mcp-server.json` (core ships
-    // it as a drop-in, not a seeded built-in, so it is NOT in CORE_SEEDED_WORKFLOWS: launchRun writes
-    // this mirror to the overlay and hot-registers it, as for domain-extraction). It carries only the
-    // evidence-floor pin, so no seed step is needed. Deliver is composed per run and placed BEFORE
-    // `install` (`composeDeliverWorkflow` / `placeDeliverBeforeInstall`), so the pull request exists
-    // when the install gate asks. The install gate is `consent_before` (core#801, crew#888): the engine
-    // pauses with `gateKind: 'consent'` BEFORE the install runs and nothing pauses after it; the
-    // command execs the admitted garden at `WICKED_GARDEN_ROOT` (core#802), never PATH. The install
-    // Tool phase runs on the daemon host as the daemon user (the garden install script builds into
-    // ~/.wicked/mcp-servers/<key>, registers the server in this daemon's MCP tools and writes the CLI
-    // configurations through wicked-installer). core#820: an `install-plan` Tool phase dry-runs the
-    // install first (`--dry-run --json`, one plan line), the gate offers its choices
-    // (`consent:worker` default, `consent:operator`, `reject`) with each one's write targets, and the
-    // install runs with the chosen `--target "$WICKED_CONSENT_CHOICE"`. Field-for-field equal to
-    // core's `workflows/mcp-server.json` (tests/builtin-overlay-shadow.test.ts).
-    // Not `is_system`: an operator-selectable work mode.
-    {
-        id: 'mcp-server',
-        phases: [
-            { id: "scope", kind: "recon", gate_type: "value", gate: { "human_confirm": { "unconditional": false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: [], role: "neutral", skill_ref: "wicked-garden-mcp-scaffold", allowed_skills: [], validator_pin: null, instructions: "Decide what this MCP server exposes (tools, resources, prompts), the upstream's authentication scheme (bearer, API key, basic, OAuth2 client credentials — the server reads ONE secret variable <SERVER>_TOKEN and every other auth parameter from its committed mcp-server.config.json), the transport (stdio by default; httpStream only when the intent asks for a hosted server), and the target: this run's repository, at its root when the repository is new and near-empty, or in a named subdirectory when it already holds code. Say whether an OpenAPI document was given (URL or file), and whether the operator wants the server installed for running when the run completes (the install phase asks again at its gate). If the intent names a repository that is not this run's, say that the operator must create it with an initial commit and register it before a run can deliver into it; do not try to create one." },
-            { id: "source-discovery", kind: "recon", gate_type: null, gate: "auto", executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["scope"], role: "neutral", skill_ref: "wicked-garden-mcp-scaffold", allowed_skills: [], validator_pin: null, instructions: "With an OpenAPI document: run the skill's openapi action against the conversion service and report every tool it yields with its class (read, write, destructive), its input schema summary and its request mapping, plus the skipped operations and why. Without one: inventory the integration surface (SDK calls, CLI, database, events) into a candidate tool list with the same columns. Do not write code in this phase." },
-            { id: "design", kind: "recon", gate_type: "strategy", gate: { "human_confirm": { "unconditional": false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["source-discovery"], role: "neutral", skill_ref: "wicked-garden-mcp-scaffold", allowed_skills: [], validator_pin: null, instructions: "Produce the design: the final tool table (name, description, input schema, annotations, class), the resources and prompts if any, the authentication plan (the one secret variable, the committed non-secret parameters, which header, what fails at startup), and the observability plan (span names and attributes, the three instruments, log fields, what leaves the process and only when). Check each against the MCP-server steering rules MCPS-1001 to MCPS-1007 (recall them with rules.recall, scope wiki:governance, when an estate store is present; otherwise use the checklist in the skill) and against MCP-D2 and MCP-D4. If a rule cannot be recalled, say so, cite the skill's checklist instead, and never state what a rule id means when you could not read it. Name every deviation and why." },
-            { id: "build", kind: "build", gate_type: "execution", gate: "auto", executes_code: true, verified_evidence: false, required_deliverables: [], depends_on: ["design"], role: "creator", skill_ref: "wicked-garden-mcp-scaffold", allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN, instructions: "Scaffold the TypeScript server with the skill (--lang typescript) into the target directory. Branch A, with a tools.json from the conversion service: the generated tools ride the skeleton's REST runtime; adapt names, descriptions and annotations to the design. Branch B, without one: write each tool by hand with a zod schema on the same skeleton. Either way: the one secret variable and the committed mcp-server.config.json the design named, the conformance smoke and one contract test per tool under npm test, the typecheck, lint and test scripts present, an SPDX header on every source file, telemetry exporters armed only by OTEL_EXPORTER_OTLP_ENDPOINT. Build it and run the skill's probe; put the probe JSON in your output." },
-            { id: "test", kind: "test", gate_type: "execution", gate: { "human_confirm_if": "verdict_not_pass" }, executes_code: false, verified_evidence: true, required_deliverables: [], depends_on: ["build"], role: "neutral", skill_ref: "wicked-garden-qe-contract-testing-engineer", allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN, instructions: "Judge the verify floor's report of the repository's own checks (typecheck, lint, test) and the tests themselves: every tool in the design has a contract test, the conformance smoke covers initialize, tools/list, tools/call, the missing-credential startup failure and the httpStream 401 path, and nothing in the tree holds a secret value. A tool without a test, or a smoke that does not exercise the failure paths, is a FAIL with the tool named." },
-            { id: "security-review", kind: "review", gate_type: "execution", gate: { "human_confirm": { "unconditional": false } }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["test"], role: "evaluator", skill_ref: "wicked-garden-platform-security-engineer", allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN, instructions: "Review the diff cold against MCPS-1004 and MCPS-1005 and MCP-D2: the one secret read from the environment only and never logged, returned or accepted as an argument; non-secret auth parameters in the committed config; authentication on every tool and resource (authenticate on httpStream, canAccess on every tool); input validated before the handler runs; upstream requests pinned to the configured base URL with allowlisted arguments and no redirects; a rate limit that answers a user error. Cite file and line for every finding." },
-            { id: "observability-review", kind: "review", gate_type: "execution", gate: { "human_confirm_if": "verdict_not_pass" }, executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["test"], role: "evaluator", skill_ref: "wicked-garden-qe-observability-test-engineer", allowed_skills: [], validator_pin: EVIDENCE_FLOOR_PIN, instructions: "Review the diff cold against MCPS-1002 and MCPS-1003: one span per tool call with the server, tool, request id and outcome attributes and a child span per upstream request; the three instruments recorded; logs through loglayer with trace and span ids stamped, a request-scoped child logger per call, console output on stderr only; nothing exported unless the operator sets an OTLP endpoint. Cite file and line for every finding." },
-            { id: "install-plan", kind: "build", gate_type: "execution", gate: "auto", executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["security-review", "observability-review"], role: "neutral", skill_ref: null, allowed_skills: [], validator_pin: null, executor: { "type": "tool", "cmd": ["bash", "-c", "exec \"${WICKED_GARDEN_ROOT:?the engine handed this Tool phase no garden root; refusing to resolve wicked-garden from PATH}/scripts/wicked-garden\" run scripts/mcp/install.py --from-run --dry-run --json"] }, instructions: "Plan the install without writing anything: resolve, on this host and as the daemon user, every file and directory each install choice would write — Install for workers (the default: the staged copy under ~/.wicked/mcp-servers/<key>/current, the wicked-crew MCP tools registry and the worker homes' CLI configurations under ~/.wicked-worker) and Also install into my CLIs (the worker set plus your own CLI configurations, such as ~/.claude.json, ~/.codex/config.toml and the opencode configuration) — and print them as one JSON plan line, so the install's consent gate can list them before you answer." },
-            { id: "install", kind: "build", gate_type: "execution", gate: "consent_before", executes_code: false, verified_evidence: false, required_deliverables: [], depends_on: ["install-plan"], role: "neutral", skill_ref: null, allowed_skills: [], validator_pin: null, executor: { "type": "tool", "cmd": ["bash", "-c", "exec \"${WICKED_GARDEN_ROOT:?the engine handed this Tool phase no garden root; refusing to resolve wicked-garden from PATH}/scripts/wicked-garden\" run scripts/mcp/install.py --from-run --target \"${WICKED_CONSENT_CHOICE:?the consent gate recorded no install choice}\" --json"] }, instructions: "Install for running — or update the installed copy when this server key is already installed. Nothing has been installed yet: this asks before the install runs, and each answer lists exactly the files it would write (from the install-plan dry run). Install for workers (the default) builds the server from this run's tree into ~/.wicked/mcp-servers/<key>/current, registers it in wicked-crew's MCP tools under its key (an existing entry is re-registered in place; the first use of a changed tool still asks) and writes it into the worker homes' CLI MCP configurations — program-owned files only. Also install into my CLIs does the same and also writes it into your own CLI MCP configurations through wicked-installer (one entry per key, never a second copy; CLI entries carry no secret). Both probe tools/list. The one secret variable <SERVER>_TOKEN is named, never written: when the daemon cannot resolve it the registration is reported as pending with the remedy. Writes happen on the daemon host as the daemon user. Decline for not now — the pull request already delivered stays as it is." },
-        ],
-        required_instruments: APP_CHANGE_INSTRUMENTS,
-    },
-].map(withSystemFlag);
+// ── Built-in workflows (X-MIG M11) ───────────────────────────────────────────
+// No mirrors: the built-ins are the engine's built-in presets, read once at boot and laid over the
+// phase catalog (`core/builtin-catalog.ts`, `loadBuiltinCatalog`). One source; nothing to drift.
 /**
  * Chat is not available in this deployment at all — a capability gap, never a bad request.
  *
@@ -806,95 +482,6 @@ export class GovernanceReplayUnsupportedError extends Error {
 }
 /** The engine's own way of reporting a build that cannot do chat, raised at call time. */
 const ENGINE_CHAT_UNSUPPORTED = /chat unsupported/i;
-/**
- * Quarantine a pre-#197 `onboarding.json` left in the overlay dir.
- *
- * This package used to write that file on every launch, baked with ONE repo's absolute paths. It no
- * longer does — core declares `{repo_root}` / `{code_graph_db}` and binds them per run
- * (wicked-core#179). But the overlay dir is PERSISTENT STATE, and the engine's `load_dir` registers
- * whatever it finds there, replacing a compiled def by id, wholesale.
- *
- * So an upgraded deployment keeps running the last file the old code wrote. Not intermittently:
- * EVERY onboarding run indexes whichever repo happened to be registered last before the upgrade.
- * Observed exactly that on this host after #197 merged — three fresh registrations in three
- * different orgs all indexed `agentic-products/eliza`, the last repo seeded before the fix.
- *
- * Renamed rather than deleted. The file is almost certainly machine-written, but the overlay dir is
- * an operator-facing extension point and silently destroying something out of it is not this
- * process's call. The rename is enough to stop the shadow, and leaves the evidence in place.
- */
-function quarantineStaleOnboardingOverlay() {
-    const stale = join(workflowOverlayDir(), 'onboarding.json');
-    if (!existsSync(stale))
-        return; // the ordinary case on a clean install
-    // Only a PRE-#197 artifact, never an operator's override. `registerWorkflow()` writes user
-    // definitions into this same directory, and parking one on every boot would delete a deliberate
-    // customization each time it was re-registered.
-    //
-    // The signature is specific: old crew baked one repo's ABSOLUTE paths into the tool commands. A
-    // def carrying `{repo_root}` / `{code_graph_db}`, or agent phases, or relative commands, is not
-    // what this is looking for and is left alone. An operator who hand-writes absolute paths into a
-    // shared def has written the same bug, and gets the same treatment for the same reason.
-    let bakedPaths;
-    try {
-        const def = JSON.parse(readFileSync(stale, 'utf8'));
-        bakedPaths = (def.phases ?? [])
-            .flatMap((p) => (p.executor?.type === 'tool' ? (p.executor.cmd ?? []) : []))
-            .filter((arg) => arg.startsWith('/'));
-    }
-    catch {
-        // Unparseable: not ours to judge. The engine reports its own load failure.
-        return;
-    }
-    if (bakedPaths.length === 0)
-        return;
-    const parked = `${stale}.superseded-by-crew197`;
-    try {
-        renameSync(stale, parked);
-        console.warn(`[onboarding] removed a stale overlay that would have hijacked every onboarding run: ` +
-            `${stale} → ${parked}. It baked ${bakedPaths[0]} into a def shared by every repo, which is ` +
-            `what a pre-#197 crew wrote; the engine resolves it in preference to the built-in ` +
-            `(FINDING-075).`);
-    }
-    catch (err) {
-        // Loud, and non-fatal: the daemon still starts, but every onboarding on this host is wrong
-        // until the file goes, so the operator has to be told rather than left to discover it.
-        console.error(`[onboarding] FAILED to remove the stale overlay at ${stale}: ${err instanceof Error ? err.message : String(err)}. Until it is removed by hand, every onboarding run will index the repo baked into it, ` +
-            `whatever repo the run names (FINDING-075).`);
-    }
-}
-/**
- * The drop-in ids crew wrote into the overlay dir before DES-TEAMING-002 wave 1 retired them:
- * `chat` is the engine's built-in preset now, and `survey-repo`, `memories` and
- * `domain-graph-slice` are deleted. Exported for the quarantine test.
- */
-export const RETIRED_OVERLAY_IDS = ['chat', 'survey-repo', 'memories', 'domain-graph-slice'];
-/**
- * Park the overlay files older crews wrote for {@link RETIRED_OVERLAY_IDS}.
- *
- * `_writeBuiltinOverlay` wrote each of these on first launch, and the overlay dir is PERSISTENT: on
- * an upgraded host the engine's startup `load_dir` would keep the deleted workflows launchable, and
- * `hydrateFromOverlay` would serve them on `GET /workflows` as user workflows, where they are no
- * longer on the system list (review of wicked-crew#688). Renamed, not deleted, like the onboarding
- * quarantine above: the evidence stays, and a name retired by operator decision (2026-09-26) is
- * not a workflow any more — save a preset instead.
- */
-function quarantineRetiredOverlays() {
-    for (const id of RETIRED_OVERLAY_IDS) {
-        const stale = join(workflowOverlayDir(), `${id}.json`);
-        if (!existsSync(stale))
-            continue;
-        const parked = `${stale}.retired-des-teaming-002`;
-        try {
-            renameSync(stale, parked);
-            console.warn(`[workflows] parked ${stale} → ${parked}: \`${id}\` is retired (DES-TEAMING-002 wave 1` +
-                `${id === 'chat' ? '; chat is the engine\'s built-in preset' : '; the workflow is deleted'}).`);
-        }
-        catch (err) {
-            console.error(`[workflows] FAILED to park the retired overlay ${stale}: ${err instanceof Error ? err.message : String(err)}. The engine will keep resolving \`${id}\` from it until it is removed by hand.`);
-        }
-    }
-}
 /** The ids of a workflow's phases that carry a HUMAN gate (`human_confirm` unconditional, the
  * conditional `human_confirm_if`, or `consent_before` — crew#888, which pauses BEFORE the phase
  * runs) — i.e. the phases that will PAUSE for a person.
@@ -935,8 +522,6 @@ export class CoreAdapter {
     listeners = new Set();
     launchListeners = new Set();
     closed = false;
-    /** Built-in workflow ids whose overlay JSON has been written this process lifetime. */
-    _builtinOverlayWritten = new Set();
     /**
      * The estate db the Core actor was spawned over (`CoreAdapterOptions.dbPath` — the `--db`
      * flag / `~/.wicked-crew/core.db` default). Kept because some engine bindings take the db
@@ -1029,10 +614,6 @@ export class CoreAdapter {
         // it publishes `task.dispatched` / consumes `task.completed` around WHATEVER step runner the engine
         // wires (the production wrapped-CLI runner OR the deterministic stub), so a stub engine can arm it
         // for a fast, offline, deterministic proof of the event path.
-        // BEFORE the Core spawns: the actor reads the overlay dir at startup, so a stale
-        // `onboarding.json` has to be out of the way by then or it shadows the built-in def.
-        quarantineStaleOnboardingOverlay();
-        quarantineRetiredOverlays();
         // DES-TEAMING-002 T0: the engine gets the daemon's bus on EVERY boot (`WICKED_BUS_DB`); exec
         // mediation stays a separate switch (`WICKED_BUS_EXEC`), set only under `engineExec`, and the
         // engine's bus gate-judge path follows that switch — never the mere presence of a bus.
@@ -1692,29 +1273,6 @@ export class CoreAdapter {
                 workflowId = composed.id;
             }
             opts.workflow = workflowId;
-            if (workflowId === input.workflow) {
-                // Ensure DROP-IN workflow definitions are present in the Rust overlay dir on first use.
-                // Uses a dedicated helper (not registerWorkflow) to avoid adding built-ins to userWorkflows,
-                // which would duplicate them in listWorkflows(). The write is skipped after the first call
-                // per process lifetime.
-                //
-                // Ids core seeds itself are excluded: writing them shadows the real def with this stale
-                // mirror — see CORE_SEEDED_WORKFLOWS. Core resolves those from its own registry, so there is
-                // nothing to write and never was.
-                //
-                // Skipped entirely on the per-run deliver path above (workflowId !== input.workflow):
-                // the composed def carries the base's full phase list, so the run resolves its own
-                // registration and the base drop-in is not consulted.
-                const builtinDef = CORE_SEEDED_WORKFLOWS.has(input.workflow)
-                    ? undefined
-                    : BUILTIN_WORKFLOWS.find((w) => w.id === input.workflow);
-                if (builtinDef && !this._builtinOverlayWritten.has(input.workflow)) {
-                    // Mark before await so concurrent launchRun() calls for the same builtin
-                    // don't both pass the has() check and race to write the same file.
-                    this._builtinOverlayWritten.add(input.workflow);
-                    await this._writeBuiltinOverlay(builtinDef);
-                }
-            }
         }
         else if (input.deliver === 'pr' && input.plan === undefined) {
             // (A plan carries its deliver step above.) Fail loud, not silent: dropping the option would run to completion with the caller
@@ -1839,11 +1397,9 @@ export class CoreAdapter {
      *  (snake_case) — `campaigns/plan.ts` is the one producer of it in this daemon.
      *
      *  `workflows` are the composed per-node Tool workflows the def's run_specs reference; they
-     *  are armed FIRST (hot-register + overlay persist) so the engine can resolve them both now
-     *  and after a restart — a campaign is durable, so its node workflows must be too. Unlike a
-     *  deliver-composed def they are NOT purely ephemeral (`_armPerRunWorkflow`), and unlike a
-     *  user workflow they never enter `userWorkflows` or the catalog (the hydration filter in
-     *  `readOverlayWorkflows` skips the `campaign-` prefix). */
+     *  are armed FIRST, as system presets (X-MIG M11), so the engine resolves them both now and
+     *  after a restart — a campaign is durable, so its node workflows must be too. They never enter
+     *  `userWorkflows` or the work-mode catalog. */
     async launchCampaign(def, workflows = []) {
         const surface = this._campaigns('Launching a campaign');
         // (review-L1-598 M1) `denial_gate` is a 0.7.27 def field; an older addon's serde IGNORES it and
@@ -1867,21 +1423,22 @@ export class CoreAdapter {
         // the campaign is what the daemon can account for: pinned under `def.id` until its terminal frame.
         return this.handedToEngine('campaign', def.id, () => surface.launchCampaign(JSON.stringify(engineDef)));
     }
-    /** Arm one composed campaign-node workflow: validate-then-persist (the FINDING-002 ordering —
-     *  core's parser is the authority and runs BEFORE the overlay write), overlay file for
-     *  restart durability, no `userWorkflows` entry. */
+    /** Arm one composed campaign-node workflow as a PRESET (X-MIG M11): the preset store is the
+     *  engine's durable record, so a resumed campaign finds its node by name after a restart without
+     *  any file overlay. The node's one Tool phase becomes one `run` step carrying its command; the
+     *  engine composes it (its step rules apply), and the name keeps it a system preset, off every
+     *  picker (`isSystemWorkflow`). */
     async _armCampaignWorkflow(def) {
-        const core = this.core;
-        const register = core['registerWorkflow'];
-        if (typeof register !== 'function') {
-            // Unreachable on any addon that carries launchCampaign (registerWorkflow predates it by
-            // several releases), but the guard keeps the failure loud if that ever un-holds.
+        if (!this.presetsSupported())
             throw new CampaignsUnsupportedError('Arming a campaign node workflow');
-        }
-        await register.call(this.core, JSON.stringify(def));
-        const dir = workflowOverlayDir();
-        await mkdir(dir, { recursive: true });
-        await writeFile(join(dir, `${def.id}.json`), JSON.stringify(def, null, 2), 'utf8');
+        const steps = def.phases.map((p) => ({
+            catalog: 'run',
+            id: p.id,
+            kind: p.kind,
+            gate_type: p.gate_type,
+            ...(p.executor !== undefined ? { executor: p.executor } : {}),
+        }));
+        await this.putPreset(def.id, steps, undefined, 'crew-campaign');
     }
     /** Resume a campaign from its persisted state → the campaign status token. */
     resumeCampaign(id) {
@@ -2000,7 +1557,7 @@ export class CoreAdapter {
      * with no name (a user plan, free text, unknown) keeps the engine's id.
      */
     async sessionsDetail() {
-        const views = JSON.parse(await this.core.sessionsDetail());
+        const views = JSON.parse(await this.engineSessionsDetail());
         const needsLaunch = (v) => v.session.team_plan == null &&
             typeof v.session.workflow_id === 'string' &&
             isSyntheticWorkflowId(v.session.workflow_id);
@@ -2021,6 +1578,41 @@ export class CoreAdapter {
         }
         return views;
     }
+    /** The engine's sessions-detail fold running now, and the one every caller that arrived during it shares. */
+    detailRunning = null;
+    detailNext = null;
+    /**
+     * The engine's whole-store sessions-detail read, at most one running and one queued (crew#944).
+     * Each call is a fold on the engine's single actor, and the binding holds a libuv worker thread
+     * blocked on the actor's reply until it is served. So N concurrent run reads used to queue N
+     * folds and pin the whole pool, and `/health` (its ping, its state-home readdir) waited behind
+     * all of them. A caller that arrives while a fold runs shares the NEXT fold, which starts after
+     * the running one ends. It never takes the running one's answer, so every caller still reads
+     * a fold that started after it asked (a write it saw committed is in it). Each caller parses its
+     * own copy of the JSON, because callers decorate the views they get in place.
+     */
+    engineSessionsDetail() {
+        if (this.detailNext !== null)
+            return this.detailNext;
+        if (this.detailRunning === null)
+            return this.startSessionsDetail();
+        const next = this.detailRunning
+            .catch(() => undefined)
+            .then(() => {
+            this.detailNext = null;
+            return this.startSessionsDetail();
+        });
+        this.detailNext = next;
+        return next;
+    }
+    startSessionsDetail() {
+        const running = this.core.sessionsDetail().finally(() => {
+            if (this.detailRunning === running)
+                this.detailRunning = null;
+        });
+        this.detailRunning = running;
+        return running;
+    }
     /** A unit's captured transcript (string, or `null`). */
     async workOutput(unitId) {
         return JSON.parse(await this.core.workOutput(unitId));
@@ -2780,82 +2372,46 @@ export class CoreAdapter {
         return parseEngineJson(await importFn.call(this.core, JSON.stringify({ name, samples, ...(knowledgeDb !== undefined ? { knowledgeDb } : {}) })), 'governanceCorpusImport');
     }
     // ── Workflow viewer + builder (crew#44) ────────────────────────────────────
-    // Built-ins are static TypeScript mirrors of workflow.rs. User-registered
-    // workflows are added to `userWorkflows` and persisted to disk; the Rust actor
-    // picks them up via `register_workflow` NAPI (when available) for immediate use.
-    userWorkflows = new Map();
-    /** Whether {@link hydrateFromOverlay} has run this process lifetime. */
-    overlayHydrated = false;
-    /** Load user-registered workflows persisted to the overlay dir into `userWorkflows`, ONCE.
-     *
-     * FINDING-002 residual: `registerWorkflow` writes each def to the overlay dir AND to the in-memory
-     * `userWorkflows` Map, but the Map is process-local and empty on every daemon restart, and nothing
-     * read the dir back. So after a restart the Rust actor (which DOES load the overlay dir at startup)
-     * would launch a user workflow that `listWorkflows()`/`GET /workflows` no longer showed — it
-     * vanished from the registry while remaining runnable. Hydrating from the same dir the writer uses
-     * makes the two views agree again. */
-    hydrateFromOverlay() {
-        if (this.overlayHydrated)
-            return;
-        this.overlayHydrated = true;
-        const builtinIds = new Set(BUILTIN_WORKFLOWS.map((w) => w.id));
-        for (const def of readOverlayWorkflows(workflowOverlayDir(), builtinIds)) {
-            if (!this.userWorkflows.has(def.id))
-                this.userWorkflows.set(def.id, def);
-        }
-    }
-    /** Core's verdict on each hydrated drop-in, run ONCE per process (the same lifetime as
-     *  {@link hydrateFromOverlay} and as core's own boot-time `load_dir`). */
-    overlayVerdicts = null;
-    /** id → core's refusal reason, for the drop-ins `judgeOverlayOnce` dropped. */
-    overlayRefusals = new Map();
-    /** Drop the refused defs from `userWorkflows` and remember why, asking core's parser (crew#718).
-     *
-     * A build with no `registerWorkflow` binding has no validator to ask, so nothing is judged and
-     * the catalog reads exactly as it did before — the same floor {@link registerWorkflow} draws,
-     * on the read side where there is no state to corrupt. `registerWorkflow` has been declared
-     * (non-optional) in wicked-core-ts since 0.4.0. */
-    judgeOverlayOnce() {
-        this.overlayVerdicts ??= (async () => {
-            this.hydrateFromOverlay();
-            const core = this.core;
-            const register = core['registerWorkflow'];
-            if (typeof register !== 'function')
+    // Built-ins are the engine's built-in presets laid over its phase catalog (X-MIG M11:
+    // `loadBuiltinCatalog`, read once at boot). User-registered workflows are added to
+    // `userWorkflows` and hot-registered with the engine.
+    /** The built-in presets' defs as crew serves them (`core/builtin-catalog.ts`). Empty until
+     *  {@link loadBuiltinCatalog} ran — a directly-driven adapter (a test double, the CLI) serves none. */
+    builtinDefs = [];
+    /**
+     * Read the engine's built-in presets and its phase catalog ONCE and derive the built-in workflows
+     * crew serves (`GET /workflows`, the deliver text, delivery candidacy, acceptance). The built-ins
+     * are compiled into the engine, so one read holds until restart. An engine without presets or the
+     * catalog binding serves none (logged), never a guess.
+     */
+    async loadBuiltinCatalog(warn = (m) => console.warn(m)) {
+        try {
+            if (!this.presetsSupported())
                 return;
-            const { refused } = await judgeOverlayWorkflows([...this.userWorkflows.values()], (json) => register.call(this.core, json));
-            for (const r of refused) {
-                this.userWorkflows.delete(r.id);
-                this.overlayRefusals.set(r.id, r.reason);
-                console.warn(`wicked-crew: drop-in workflow '${r.id}' is NOT in the catalog — the engine refused it: ${r.reason}`);
-            }
-        })();
-        return this.overlayVerdicts;
+            const [presets, entries] = await Promise.all([this.listPresets(), this.catalog()]);
+            this.builtinDefs = deriveBuiltinDefs(presets, entries, warn).map(withSystemFlag);
+        }
+        catch (err) {
+            warn(`wicked-crew: could not read the engine's built-in presets — no built-in workflow is served: ${err instanceof Error ? err.message : String(err)}`);
+        }
     }
-    /** The workflow catalog `GET /workflows` serves: the defs the ENGINE accepted, plus the drop-ins
-     *  it refused with its own reason, so an unlaunchable def is named instead of offered (crew#718). */
+    userWorkflows = new Map();
+    /** The workflow catalog `GET /workflows` serves. `unavailable` stays on the wire, always empty:
+     *  it named the operator drop-ins the engine refused (crew#718), and drop-ins are retired
+     *  (X-MIG M11 — a file in the old overlay dir never runs; the engine names it once at boot). */
     async workflowCatalog() {
-        await this.judgeOverlayOnce();
-        return {
-            workflows: this.listWorkflows(),
-            unavailable: [...this.overlayRefusals].map(([id, reason]) => ({ id, reason })),
-        };
-    }
-    /** Core's refusal reason for `id`, or `null` when the engine never refused it (crew#718). */
-    async workflowRefusal(id) {
-        await this.judgeOverlayOnce();
-        return this.overlayRefusals.get(id) ?? null;
+        return { workflows: this.listWorkflows(), unavailable: [] };
     }
     listWorkflows() {
-        this.hydrateFromOverlay();
-        // Builtins first (stable ordering), but user-registered workflows take precedence when
-        // ids conflict — consistent with getWorkflow() which prefers userWorkflows.get().
+        // Built-ins first, and a built-in WINS a name conflict (X-MIG M11, codex r2 on crew A): a launch
+        // naming it resolves the engine's preset before any registered def, so the reader must serve
+        // what runs. Consistent with getWorkflow().
         const seen = new Set();
         const result = [];
-        for (const w of BUILTIN_WORKFLOWS) {
-            const override = this.userWorkflows.get(w.id);
+        for (const w of this.builtinDefs) {
             if (!seen.has(w.id)) {
                 seen.add(w.id);
-                result.push(withSystemFlag(override ?? w));
+                result.push(withSystemFlag(w));
             }
         }
         for (const w of this.userWorkflows.values()) {
@@ -2866,50 +2422,22 @@ export class CoreAdapter {
         }
         return result;
     }
+    /** The runtime-registered defs only (the user's and crew's seams'), without the built-in presets. */
+    listRuntimeWorkflows() {
+        return [...this.userWorkflows.values()].map(withSystemFlag);
+    }
     getWorkflow(id) {
-        this.hydrateFromOverlay();
-        const def = this.userWorkflows.get(id) ?? BUILTIN_WORKFLOWS.find((w) => w.id === id) ?? null;
+        // Preset first, as the engine resolves a launch (see listWorkflows).
+        const def = this.builtinDefs.find((w) => w.id === id) ?? this.userWorkflows.get(id) ?? null;
         return def === null ? null : withSystemFlag(def);
     }
-    /** Write a built-in workflow definition to the Rust overlay dir (and hot-register when possible).
-     *  Unlike registerWorkflow(), this does NOT touch userWorkflows, avoiding duplicates in listWorkflows(). */
-    async _writeBuiltinOverlay(def) {
-        const dir = workflowOverlayDir();
-        await mkdir(dir, { recursive: true });
-        const overlayDef = { ...def };
-        delete overlayDef.is_system;
-        const json = JSON.stringify(overlayDef);
-        const core = this.core;
-        const register = core['registerWorkflow'];
-        // Same validate-before-persist ordering as registerWorkflow (FINDING-002). This path had the
-        // identical defect — write first, validate last — which is the P3 shape this campaign keeps
-        // finding: N paths, one hardened. A mirror that drifted far enough for core to reject it would
-        // otherwise leave an unparseable *.json in the dispatch overlay dir, and core would skip it at
-        // the next load. Letting the rejection propagate instead fails the launch with core's own
-        // reason, which beats dispatching against a workflow core will silently drop.
-        if (typeof register === 'function') {
-            await register.call(this.core, json);
-        }
-        // Deliberately NOT the refusal registerWorkflow makes when the binding is absent, and the
-        // difference is the input, not the caller:
-        //   - a user def is arbitrary runtime input no test has ever seen, so unvalidatable means
-        //     unsafe to persist;
-        //   - a built-in mirror is asserted field-for-field against wicked-core's own
-        //     workflows/<id>.json by tests/builtin-overlay-shadow.test.ts, so its parseability is
-        //     established at build time rather than needing a runtime check.
-        // Refusing here would also break DELIVERY: this write is the only way core resolves a drop-in
-        // id, so a refusal turns a silent ungating into a hard "unknown workflow" — exactly the
-        // regression FINDING-084's first attempted fix caused.
-        await writeFile(join(dir, `${def.id}.json`), JSON.stringify(overlayDef, null, 2), 'utf8');
-    }
     /**
      * Arm a PER-RUN composed workflow def (crew#293 deliver, crew#311 deliverable floor) with the
      * engine — hot registration
-     * ONLY. Deliberately neither of the other two paths:
+     * ONLY. Deliberately not the other path:
      *   - not `registerWorkflow()`: the composed def must not enter `userWorkflows` or the overlay
      *     dir — it is launch input for one run, and persisting it would grow the catalog and the
-     *     overlay dir by one entry per delivered run;
-     *   - not `_writeBuiltinOverlay()`: same reason, no file.
+     *     overlay dir by one entry per delivered run.
      * The engine's `registerWorkflow` binding validates the def server-side and makes it visible
      * to the next `launchRun` with no restart — exactly the lifetime a per-run def needs. (The
      * def is consumed at PLANNING time; a later daemon restart resumes the run from its persisted
@@ -2929,56 +2457,32 @@ export class CoreAdapter {
         await register.call(this.core, JSON.stringify(def));
     }
     /**
-     * Register a user-authored workflow: persist to the Rust workflow overlay dir
-     * (`~/.config/wicked-core/workflows/<id>.json` or `$WICKED_WORKFLOWS_DIR`),
-     * update the in-memory registry, and (when core supports it) register in the
-     * Rust actor so runs using this workflow work immediately without a restart.
+     * Register a RUNTIME workflow def with the engine (X-MIG M11): crew's interactive seams that still
+     * hold a def (review, theme) register it at boot. The engine validates it and holds it in memory
+     * for this process; nothing is written to disk (operator drop-ins are retired, and a user saves a
+     * preset instead). Refused for a built-in preset's name, which a launch would never resolve to it.
      */
     async registerWorkflow(def) {
         const SAFE_ID = /^[a-zA-Z0-9][a-zA-Z0-9._-]*$/;
         if (!SAFE_ID.test(def.id) || def.id.length > 128) {
             throw new Error('workflow id must start with a letter/digit and contain only letters, digits, dots, hyphens, and underscores');
         }
-        const dir = workflowOverlayDir();
-        await mkdir(dir, { recursive: true });
-        const path = join(dir, `${def.id}.json`);
-        // Strip `is_system` before writing — the Rust core's overlay format does not recognise that
-        // field and silently drops any workflow whose JSON it cannot fully deserialise.
-        const overlayDef = { ...def };
-        delete overlayDef.is_system;
-        const json = JSON.stringify(overlayDef);
-        // VALIDATE BEFORE PERSISTING (FINDING-002). This ordering is the whole fix.
-        //
-        // The write used to come first and `registerWorkflow` last, so core's parser — the only thing
-        // that actually knows the overlay schema — ran AFTER the state was already mutated. Observed
-        // end to end: POST /api/v1/workflows answered
-        //   400 invalid workflow JSON: unknown field `name`, expected `id` or `phases`
-        // and the file was on disk anyway, `name` included, and served from `userWorkflows` as though
-        // registered. On the next daemon start core could not deserialise its own overlay file:
-        //   wicked-core: skipping workflow file .../probe-002-persist.json
-        // and the workflow VANISHED while its file remained. That is FINDING-002's root cause: not
-        // "registration is not durable" but "a rejected request persisted a def core cannot read".
-        //
-        // Core's parser is the authority, so it is what we ask. Enumerating the accepted fields in TS
-        // instead would be a second copy of core's schema — the exact drift this codebase keeps paying
-        // for, and `is_system` above is already one hand-maintained instance of it.
+        if (this.builtinDefs.some((w) => w.id === def.id)) {
+            // A def of a built-in preset's name would never run: a launch resolves the preset first.
+            throw new Error(`workflow id '${def.id}' is a built-in preset: a registered def of that name never runs (a launch resolves the preset first) — save your own preset under another name (PUT /presets/:name)`);
+        }
+        // `is_system` is crew's display flag; core's strict def parser rejects the key.
+        const engineDef = { ...def };
+        delete engineDef.is_system;
         const core = this.core;
         const register = core['registerWorkflow'];
         if (typeof register !== 'function') {
-            // No validator, so no safe way to persist: an unvalidated def written here is a file core
-            // may silently skip at load. Refusing is the honest outcome — and it is loud, unlike the
-            // vanishing act it replaces. `registerWorkflow` has been declared (non-optional) in
-            // wicked-core-ts since 0.4.0, so this is a real floor, not a routine path.
-            throw new Error('this wicked-core build exposes no registerWorkflow binding, so a workflow cannot be ' +
-                'validated before it is written; refusing to persist an unvalidated definition');
-        }
-        // Throws on a def core rejects — before anything is written or registered.
-        await register.call(this.core, json);
-        await writeFile(path, JSON.stringify(overlayDef, null, 2), 'utf8');
+            // No validator: refusing is the honest outcome (declared non-optional since core-ts 0.4.0).
+            throw new Error('this wicked-core build exposes no registerWorkflow binding, so a workflow cannot be validated and registered');
+        }
+        // Throws on a def core rejects — before crew's registry holds it.
+        await register.call(this.core, JSON.stringify(engineDef));
         this.userWorkflows.set(def.id, def);
-        // (crew#718) This def just passed core's own validator, so any earlier refusal under the same
-        // id is stale — the catalog must offer the replacement, not keep naming the version it refused.
-        this.overlayRefusals.delete(def.id);
         return def.id;
     }
     /**