@goondocks/myco 0.18.0 → 0.18.1

package/dist/src/agent/definitions/tasks/skill-survey.yaml

@@ -1,15 +1,16 @@
 name: skill-survey
 displayName: Skill Candidate Survey
 description: >-
-  Analyze vault knowledge for procedural skill candidates. Identifies
-  clusters of related sessions, spores, and plans that describe how
-  to accomplish tasks in this project.
+  Analyze vault knowledge for procedural domain candidates. Identifies
+  broad categories of recurring developer work — not individual micro-
+  procedures — that warrant guided skill context.
 agent: myco-agent
 prompt: >-
-  Survey the vault knowledge graph for procedural skill candidates.
+  Survey the vault knowledge graph for procedural domain candidates.
+  The instruction contains pre-assembled vault context.
 isDefault: false
 model: claude-sonnet-4-6
-maxTurns: 65
+maxTurns: 35
 timeoutSeconds: 600
 schedule:
   enabled: true
@@ -17,167 +18,160 @@ schedule:
   runIn:
     - idle
 phases:
-  - name: explore-spores
+  - name: explore
     prompt: |
-      Identify procedural patterns from spores and entities.
-      You are one of three parallel exploration phases — focus only on spores.
-      Budget is tight — be efficient, not exhaustive.
+      The instruction contains pre-assembled vault context: digest,
+      recent wisdom spores, decisions, gotchas, sessions, and the
+      current skill inventory. Read it carefully — this is your
+      primary input.
 
-      1. Read the digest (vault_read_digest) for a high-level overview.
-         This gives you the landscape in one call.
+      Your goal: identify PROCEDURAL DOMAINS — broad categories of
+      recurring work where a developer benefits from guided context.
 
-      2. Query wisdom spores (vault_spores, observation_type: wisdom).
-         These are highest signal — synthesized from multiple sessions.
+      ## What is a procedural domain?
 
-      3. Query decisions and gotchas (vault_spores, limit 30 each).
-         One page per type is sufficient — don't paginate exhaustively.
+      A domain groups related procedures that share prerequisite
+      knowledge. Think "extending the daemon infrastructure" (covering
+      PowerManager jobs, MCP tools, config writes, notification
+      wiring) — NOT "registering a PowerManager job" alone.
 
-      4. Check vault_entities for high-mention components.
+      Good domain examples:
+      - "Vault schema and data layer extension" (migrations, tables,
+        queries, FTS indexes, constants)
+      - "Agent pipeline task authoring" (YAML anatomy, phases,
+        scheduling, parameter injection, fault tolerance)
+      - "Symbiont integration lifecycle" (manifests, hooks, config
+        directories, capture rules, installer registration)
 
-      Group findings by procedural topic ("how to do X").
-      Stop when you have a clear picture — diminishing returns
-      from additional queries waste turns.
-    tools:
-      - vault_spores
-      - vault_entities
-      - vault_edges
-      - vault_read_digest
-    maxTurns: 15
-    required: true
-    readOnly: true
+      Bad examples (too narrow — these are SECTIONS within a domain):
+      - "How to register a PowerManager job"
+      - "Adding an FTS5 index"
+      - "Writing a symbiont capture rule"
 
-  - name: explore-sessions
-    prompt: |
-      Identify procedural workflows from session history.
-      You are one of three parallel exploration phases — focus only on sessions.
-      Budget is tight — be efficient, not exhaustive.
+      ## Scale guidance
 
-      1. List recent sessions (vault_sessions, limit 20). Read summaries
-         to identify multi-step workflows and recurring implementation patterns.
+      20-30 broad skills for a complex project is the right order
+      of magnitude. If a topic would be a section heading within a
+      broader skill, it is not its own candidate.
 
-      2. Do 2-3 targeted FTS searches for procedural keywords:
-         vault_search_fts with queries like "migration step", "configure install",
-         "refactor debug". Combine related terms in ONE query rather than
-         searching each keyword separately.
+      ## Process
 
-      Group findings by procedural topic ("how to do X").
-      Stop when you have a clear picture — you don't need to search
-      every possible keyword.
-    tools:
-      - vault_sessions
-      - vault_search_fts
-    maxTurns: 10
-    required: true
-    readOnly: true
+      1. Read the pre-assembled context for orientation.
 
-  - name: explore-plans
-    prompt: |
-      Identify procedures from plans and artifacts.
-      You are one of three parallel exploration phases — focus only on plans.
-      Budget is tight — be efficient, not exhaustive.
+      2. Use vault tools for TARGETED follow-up on promising
+         clusters. The baseline gives you direction — follow threads
+         that suggest a procedural domain exists.
 
-      Plans contain explicit step-by-step procedures and design decisions.
-      They are often the most directly skill-ready content.
+         Good follow-up queries:
+         - vault_search_fts to find additional sessions touching
+           a domain you spotted in the digest
+         - vault_spores to read full content of high-signal spores
+           summarized in the baseline
+         - vault_entities for components with high mention counts
+           that might anchor a domain
 
-      1. Use vault_search_semantic with 2-3 broad queries to find plans:
-         - "implementation plan design architecture"
-         - "migration setup configuration deployment"
-         Combine related concepts in each query. Do NOT search each
-         keyword separately.
+         Do NOT exhaustively paginate or search every keyword.
+         You have ~12 tool calls — use them purposefully.
 
-      2. If semantic search returns thin results, do ONE targeted FTS
-         search for a specific procedural term.
+      3. Group findings into candidate domains. For each domain,
+         note: the core theme, which procedures it covers, and
+         which source items provide evidence.
 
-      Group findings by procedural topic ("how to do X").
-      Stop when you have coverage — more queries have diminishing returns.
+      Store your domain clusters in working notes for the next phase.
     tools:
-      - vault_search_semantic
+      - vault_spores
+      - vault_entities
+      - vault_edges
+      - vault_sessions
       - vault_search_fts
-    maxTurns: 22
+      - vault_search_semantic
+    maxTurns: 15
     required: true
     readOnly: true
 
-  - name: evaluate
+  - name: synthesize-evaluate
+    model: claude-sonnet-4-6
     prompt: |
-      Three parallel exploration phases have completed — one explored
-      spores and entities, one explored sessions, one explored plans.
-      Their findings are in the prior context.
+      The explore phase identified procedural domain clusters from
+      the vault. Now evaluate each and create candidates for domains
+      that pass all criteria.
 
-      BEFORE creating any candidates, you MUST load the dedup context:
-      1. vault_skill_records (action: list) — all active skills on disk
+      BEFORE creating any candidates, load the dedup context:
+      1. vault_skill_records (action: list) — all active skills
       2. vault_skill_candidates (action: list) — all existing candidates
-      Keep both lists for reference throughout this phase.
-
-      For each procedural cluster identified, evaluate ALL of these
-      criteria. A candidate must pass EVERY one:
-
-      1. PROCEDURE TEST: Is this "how to do X in this project"?
-         "What is X" or "X exists" is knowledge, not a skill. Skip it.
-
-      2. REPEATABILITY TEST: Will someone need to do this again?
-         Skills are repeatable how-to's for recurring tasks — things
-         a developer will do more than once as the project grows.
-         One-time fixes, bug patches, version-specific workarounds,
-         and already-applied migration steps are NOT skills. They are
-         vault knowledge (spores/wisdom) that should stay as spores.
-         Ask: "if a new contributor joined tomorrow, would they ever
-         need to follow this procedure?" If the answer is "no, it was
-         done once and the result is permanent," it is not a skill.
-         Examples of SKILLS: adding a new symbiont, creating a DB
-         migration, registering an MCP tool, authoring an agent task.
-         NOT skills: fixing a specific bug, applying a one-off schema
-         change, adapting to a framework update, addressing a one-off
-         behavioral change in a dependency.
-
-      3. CROSS-SESSION EVIDENCE: Knowledge from 2+ sessions, 3+ source
-         items across sessions, spores, and plans.
-
-      4. DEDUPLICATION (mandatory — failures here create real problems):
-         Check BOTH lists from step 0 above.
-         - If an active skill record's name or description covers the
-           same procedure, do NOT create a duplicate. Skip it entirely.
-         - If a non-dismissed candidate covers the same topic, UPDATE
-           that candidate with new evidence instead of creating a new one.
-         - If a generated/dismissed candidate covered this, it was
-           already handled. Do not re-create it.
-
-      5. CONFIDENCE SCORE (0.0-1.0):
-         - Knowledge density (more sources = higher)
+      Keep both lists for reference.
+
+      ## Evaluation criteria
+
+      Each candidate must pass ALL of these at the DOMAIN level:
+
+      1. PROCEDURE TEST: Does this domain describe "how to do a
+         family of related tasks in this project"? A domain about
+         "what X is" or "X exists" is knowledge, not a skill.
+
+      2. REPEATABILITY TEST: Will developers need these procedures
+         again as the project grows? Domains covering extension
+         points (adding new X, extending Y) are strong candidates.
+         One-time fixes and bug patches are NOT skills.
+
+      3. BREADTH TEST: Does this domain cover 2+ distinct procedures
+         that share prerequisite knowledge? A single procedure is
+         too narrow — it should be a section within a broader domain.
+         If you can't imagine 3+ major section headings, it's not
+         broad enough.
+
+      4. CROSS-SESSION EVIDENCE: Knowledge from 2+ sessions and 3+
+         source items (spores, sessions, plans).
+
+      5. DEDUPLICATION: Check BOTH lists from step 0.
+         - If an active skill already covers this domain, skip.
+         - If the domain SUBSUMES existing narrow skills (the domain
+           is broader and the narrow skills are sections within it),
+           create the candidate with `supersedes` listing the narrow
+           skill names as a JSON array. The dedup gate exempts
+           superseded skills from vocabulary overlap checks.
+         - If a non-dismissed candidate covers the same domain,
+           UPDATE it with new evidence instead of creating.
+         - Dismissed candidates: the gate allows creation with a
+           warning. If the dismissed topic is a narrow subset of
+           your broader domain, proceed.
+
+      6. CONFIDENCE SCORE (0.0-1.0):
+         - Domain breadth (more procedures covered = higher)
          - Cross-session evidence (wider = higher)
-         - Presence of wisdom spores (higher quality signal)
-         - Presence of plans with step-by-step procedures (higher)
-
-      For each valid candidate, use vault_skill_candidates (action: create)
-      with topic, rationale, confidence, and source_ids (JSON array of
-      {id, type} objects referencing the spores, sessions, and plans).
-
-      IMPORTANT: Write the rationale field as markdown. Include these
-      sections in every rationale:
-      - **Procedure verdict**: PASS/FAIL
-      - **Repeatability verdict**: PASS/FAIL with justification
-      - **Cross-session evidence**: session IDs and source count
-      - **Existing coverage**: list the skills/candidates you checked
-        and why this is genuinely new (not "NONE" — name what you checked)
-      Use **bold** for verdicts, numbered lists for steps, `code` for
-      file paths and function names. The rationale is displayed directly
-      to the user in the dashboard.
-
-      If an existing candidate has new evidence, use vault_skill_candidates
-      (action: update) to increase confidence and add source_ids.
-
-      Dismiss candidates whose underlying knowledge has been superseded
-      (action: update, status: dismissed).
-
-      Report a summary of candidates created, updated, and dismissed
-      using vault_report.
+         - Wisdom spore presence (higher quality signal)
+         - Plan presence (step-by-step procedures = higher)
+
+      ## Creating candidates
+
+      Use vault_skill_candidates (action: create) with:
+      - topic: the domain name (e.g., "Vault Schema and Data Layer Extension")
+      - rationale: markdown with these sections:
+        - **Domain scope**: what procedures this covers (bulleted list)
+        - **Procedure verdict**: PASS/FAIL
+        - **Repeatability verdict**: PASS/FAIL with justification
+        - **Breadth verdict**: PASS/FAIL with section count estimate
+        - **Cross-session evidence**: session IDs and source count
+        - **Existing coverage**: skills/candidates checked and why this
+          is new or broader (name what you checked, not "NONE")
+        - **Supersedes**: which existing narrow skills this replaces
+          (if any)
+      - confidence: 0.0-1.0
+      - source_ids: JSON array of {id, type} objects
+      - supersedes: JSON array of skill names this replaces (or omit)
+
+      If an existing candidate has new evidence, use action: update.
+
+      Dismiss candidates whose underlying knowledge has been
+      superseded (action: update, status: dismissed).
+
+      Report a summary via vault_report.
     tools:
       - vault_skill_candidates
       - vault_skill_records
       - vault_set_state
       - vault_report
-    maxTurns: 12
+    maxTurns: 15
     required: true
     dependsOn:
-      - explore-spores
-      - explore-sessions
-      - explore-plans
+      - explore

package/dist/src/agent/definitions/tasks/supersession-sweep.yaml

@@ -13,7 +13,7 @@ description: >
   Records resolution events for audit trail.
 agent: myco-agent
 isDefault: false
-model: claude-sonnet-4-6
+model: claude-haiku-4-5-20251001
 maxTurns: 30
 timeoutSeconds: 300
 

package/dist/src/cli.js

@@ -2,5 +2,5 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/cli.ts
-await import("../cli-IIMBALPV.js");
+await import("../cli-D3TJYJ2U.js");
 //# sourceMappingURL=cli.js.map

package/dist/src/daemon/main.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/daemon.ts
-var { main } = await import("../../main-6PY3ITQ5.js");
+var { main } = await import("../../main-5THODR77.js");
 await main();
 //# sourceMappingURL=main.js.map

package/dist/src/hooks/post-tool-use.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/post-tool-use.ts
-var { main } = await import("../../post-tool-use-DENRI5WB.js");
+var { main } = await import("../../post-tool-use-FRTSICC3.js");
 await main();
 //# sourceMappingURL=post-tool-use.js.map

package/dist/src/hooks/session-end.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/session-end.ts
-var { main } = await import("../../session-end-OUTY7AFF.js");
+var { main } = await import("../../session-end-SMU55UCM.js");
 await main();
 //# sourceMappingURL=session-end.js.map

package/dist/src/hooks/session-start.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/session-start.ts
-var { main } = await import("../../session-start-5MB3LFOA.js");
+var { main } = await import("../../session-start-NIMWEOIZ.js");
 await main();
 //# sourceMappingURL=session-start.js.map

package/dist/src/hooks/stop.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/stop.ts
-var { main } = await import("../../stop-YGHODSP7.js");
+var { main } = await import("../../stop-7AKYBJJ2.js");
 await main();
 //# sourceMappingURL=stop.js.map

package/dist/src/hooks/user-prompt-submit.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/user-prompt-submit.ts
-var { main } = await import("../../user-prompt-submit-4IBFUYQ3.js");
+var { main } = await import("../../user-prompt-submit-IZJC3NV7.js");
 await main();
 //# sourceMappingURL=user-prompt-submit.js.map

package/dist/src/mcp/server.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/mcp-server.ts
-var { main } = await import("../../server-6SUNYDV7.js");
+var { main } = await import("../../server-PTXLVVEE.js");
 await main();
 //# sourceMappingURL=server.js.map

package/dist/src/symbionts/manifests/codex.yaml

@@ -11,6 +11,8 @@ hookFields:
   lastResponse: last_assistant_message
 capture:
   planDirs: []
+  planTags:
+    - proposed_plan
   rules:
     # Ephemeral sub-invocation filter (structural, two-layer defense).
     #
@@ -51,13 +53,49 @@ capture:
       action: drop
       reason: ephemeral-sub-invocation
 
-    # NOTE: the VS Code Codex extension wraps user prompts with an IDE
-    # context preamble (`# Context from my IDE setup:` … `## My request
-    # for Codex:`). Stripping that belongs in a follow-up that keys on
-    # the transcript's `session_meta.payload.originator == "codex_vscode"`
-    # signal rather than matching preamble text, per Chris's correctness
-    # bar against fragile text matching. Leaving unfiltered for now —
-    # session data is preserved, just shown with the wrapper.
+    # Layer 3 — sub-agent thread spawn filter (structural).
+    #
+    # Codex spawns sub-agents (thread_spawn) for code review, testing,
+    # etc. These write real transcript files but are NOT user-initiated
+    # sessions. Their session_meta has:
+    #   "source": {"subagent": {"thread_spawn": {...}}}
+    # while user sessions have "source": "vscode" or similar strings.
+    #
+    # This condition reads the transcript's first JSON line and checks
+    # the dot-path field — a structural signal that won't drift.
+    - event: session_start
+      scope: this_agent
+      when:
+        transcript_meta_field_exists: source.subagent
+      action: drop
+      reason: subagent-thread-spawn
+
+    # Layer 4 — safety net for sub-agent prompts that slip past
+    # SessionStart (e.g. transcript not yet flushed).
+    - event: user_prompt
+      scope: this_agent
+      when:
+        transcript_meta_field_exists: source.subagent
+      action: drop
+      reason: subagent-thread-spawn
+
+    # Codex Desktop wraps user prompts with a file-mention preamble when
+    # screenshots or files are attached:
+    #   "# Files mentioned by the user:\n## <filename>: <path>\n## My request for Codex:\n<actual prompt>"
+    # Strip the preamble so the captured prompt contains only the user's text.
+    - event: user_prompt
+      scope: this_agent
+      when:
+        prompt_contains: "## My request for Codex:"
+      action: rewrite_prompt
+      extract_after: "## My request for Codex:\n"
+      reason: codex-desktop-file-preamble
+
+    # NOTE: the VS Code Codex extension uses a different preamble
+    # (`# Context from my IDE setup:` … `## My request for Codex:`).
+    # Keying on the shared `## My request for Codex:` marker above
+    # should handle both Desktop and VS Code variants. If the VS Code
+    # preamble diverges, add a separate rule keyed on its specific marker.
 registration:
   hooksTarget: .codex/hooks.json
   mcpTarget: .codex/config.toml

package/dist/src/worker/src/index.ts

@@ -32,6 +32,7 @@ const EMBEDDABLE_TABLES: Record<string, string> = {
   sessions: 'summary',
   plans: 'content',
   artifacts: 'content',
+  skill_records: 'description',
 };
 
 /** All tables the sync endpoint accepts records for. */
@@ -269,7 +270,11 @@ async function handleSync(request: Request, env: Env): Promise<Response> {
           if (table === 'spores' && record.data.status === 'superseded') {
             embeddingTasks.push(() => deleteVector(env, table, id, machine_id));
           } else {
-            embeddingTasks.push(() => embedAndUpsert(env, table, id, machine_id, textContent));
+            // Include domain-specific metadata for richer search results
+            const extra: Record<string, string> = {};
+            if (table === 'skill_records' && record.data.name) extra.name = record.data.name as string;
+            if (table === 'spores' && record.data.observation_type) extra.observation_type = record.data.observation_type as string;
+            embeddingTasks.push(() => embedAndUpsert(env, table, id, machine_id, textContent, extra));
           }
         }
       }
@@ -311,6 +316,7 @@ async function embedAndUpsert(
   id: string,
   machineId: string,
   text: string,
+  extra?: Record<string, string>,
 ): Promise<void> {
   const vector = await embedText(env.AI, text);
   const vid = vectorId(table, id, machineId);
@@ -318,7 +324,7 @@ async function embedAndUpsert(
     {
       id: vid,
       values: vector,
-      metadata: { table, id, machine_id: machineId },
+      metadata: { table, id, machine_id: machineId, ...extra },
     },
   ]);
 }

package/dist/src/worker/src/schema.ts

@@ -198,6 +198,7 @@ const SKILL_CANDIDATES_TABLE = `
     status          TEXT NOT NULL DEFAULT 'identified',
     source_ids      TEXT NOT NULL DEFAULT '[]',
     skill_id        TEXT,
+    supersedes      TEXT,
     approved_at     INTEGER,
     created_at      INTEGER NOT NULL,
     updated_at      INTEGER NOT NULL,
@@ -301,6 +302,7 @@ export async function initD1Schema(db: D1Database): Promise<void> {
   const migrations = [
     'ALTER TABLE skill_usage ADD COLUMN synced_at INTEGER',
     'ALTER TABLE skill_candidates ADD COLUMN approved_at INTEGER',
+    'ALTER TABLE skill_candidates ADD COLUMN supersedes TEXT',
   ];
   for (const sql of migrations) {
     try {

package/dist/{stats-DGI6B3HX.js → stats-GEOQ2DFF.js}

@@ -1,17 +1,17 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   gatherStats
-} from "./chunk-DLFDBKEV.js";
+} from "./chunk-LSP5HYOO.js";
 import {
   initVaultDb
-} from "./chunk-55QEICRO.js";
+} from "./chunk-TLK46KKD.js";
 import "./chunk-SAKJMNSR.js";
 import "./chunk-WYOE4IAX.js";
 import "./chunk-CML4MCYF.js";
 import "./chunk-2V7HR7HB.js";
 import "./chunk-MYX5NCRH.js";
-import "./chunk-BUIR3JWM.js";
-import "./chunk-EO2RQW4S.js";
+import "./chunk-XWOQL4XN.js";
+import "./chunk-W7WENJ6F.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-CKJAWZQE.js";
 import "./chunk-E7NUADTQ.js";
@@ -92,4 +92,4 @@ function formatUptime(seconds) {
 export {
   run
 };
-//# sourceMappingURL=stats-DGI6B3HX.js.map
+//# sourceMappingURL=stats-GEOQ2DFF.js.map

package/dist/{stop-YGHODSP7.js → stop-7AKYBJJ2.js}

@@ -2,15 +2,15 @@ import { createRequire as __cr } from 'node:module'; const require = __cr(import
 import {
   normalizeHookInput,
   readStdin
-} from "./chunk-PFWIPRF6.js";
+} from "./chunk-YZPI2Y3E.js";
 import {
   resolveVaultDir
 } from "./chunk-5ZT2Q6P5.js";
 import {
   DaemonClient
-} from "./chunk-BUIR3JWM.js";
-import "./chunk-EO2RQW4S.js";
-import "./chunk-FABWUX5G.js";
+} from "./chunk-XWOQL4XN.js";
+import "./chunk-W7WENJ6F.js";
+import "./chunk-DPSLJ242.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-CKJAWZQE.js";
 import "./chunk-E7NUADTQ.js";
@@ -45,4 +45,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=stop-YGHODSP7.js.map
+//# sourceMappingURL=stop-7AKYBJJ2.js.map

package/dist/{stop-failure-7IJTPJ6W.js → stop-failure-NLE2EURG.js}

@@ -1,13 +1,13 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   sendEvent
-} from "./chunk-VOCGURV7.js";
+} from "./chunk-N75GMQGA.js";
 import "./chunk-V7XG6V6C.js";
-import "./chunk-PFWIPRF6.js";
+import "./chunk-YZPI2Y3E.js";
 import "./chunk-5ZT2Q6P5.js";
-import "./chunk-BUIR3JWM.js";
-import "./chunk-EO2RQW4S.js";
-import "./chunk-FABWUX5G.js";
+import "./chunk-XWOQL4XN.js";
+import "./chunk-W7WENJ6F.js";
+import "./chunk-DPSLJ242.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-CKJAWZQE.js";
 import "./chunk-E7NUADTQ.js";
@@ -27,4 +27,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=stop-failure-7IJTPJ6W.js.map
+//# sourceMappingURL=stop-failure-NLE2EURG.js.map

package/dist/{subagent-start-ZBQ5PJB5.js → subagent-start-LBNZF2TG.js}

@@ -1,13 +1,13 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   sendEvent
-} from "./chunk-VOCGURV7.js";
+} from "./chunk-N75GMQGA.js";
 import "./chunk-V7XG6V6C.js";
-import "./chunk-PFWIPRF6.js";
+import "./chunk-YZPI2Y3E.js";
 import "./chunk-5ZT2Q6P5.js";
-import "./chunk-BUIR3JWM.js";
-import "./chunk-EO2RQW4S.js";
-import "./chunk-FABWUX5G.js";
+import "./chunk-XWOQL4XN.js";
+import "./chunk-W7WENJ6F.js";
+import "./chunk-DPSLJ242.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-CKJAWZQE.js";
 import "./chunk-E7NUADTQ.js";
@@ -27,4 +27,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=subagent-start-ZBQ5PJB5.js.map
+//# sourceMappingURL=subagent-start-LBNZF2TG.js.map