@goondocks/myco 0.21.0 → 0.21.1

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

@@ -2,17 +2,20 @@ name: skill-evolve
 displayName: Skill Evolution
 description: >-
   Evaluate and evolve existing Myco-managed skills. Assesses content
-  freshness, identifies merge and narrowness opportunities, and
-  autonomously consolidates the skill inventory.
+  freshness against new spores AND codebase drift from refactors,
+  identifies merge and narrowness opportunities, and autonomously
+  consolidates the skill inventory.
 agent: myco-agent
 prompt: >-
-  Assess and evolve skills that have new knowledge or structural
-  overlap. The instruction contains pre-filtered skills with their
-  content, new spore IDs, and pre-computed similarity analysis.
+  Assess and evolve skills that have new knowledge, codebase drift,
+  or structural overlap. The instruction contains pre-filtered skills
+  with their content, new spore IDs, and pre-computed similarity
+  analysis; the verify phase fact-checks the broader active skill
+  set against the codebase.
 isDefault: false
 reasoningLevel: default
-maxTurns: 48
-timeoutSeconds: 1800
+maxTurns: 72
+timeoutSeconds: 2400
 schedule:
   enabled: false
   intervalSeconds: 900
@@ -81,13 +84,145 @@ phases:
     required: true
     readOnly: true
 
+  - name: verify
+    reasoningLevel: default
+    prompt: |
+      Fact-check active skills against the actual codebase. This phase
+      catches silent drift from refactors that didn't produce spores —
+      e.g., a file was renamed, a function was removed, a pattern was
+      replaced — so the spore-driven assessment in the next phase would
+      otherwise leave the skill's stale content in place.
+
+      ## Selection
+
+      List active skills via vault_skill_records (action: list,
+      status: active). Prioritize up to 3 skills with the OLDEST
+      `last_verified_at` in properties (missing/zero counts as oldest,
+      so never-verified skills sort to the front). If fewer than 3
+      active skills exist, verify them all. This watermark is
+      independent of `last_assessed_at` — it rotates verify coverage
+      even when assess never touches the skill, which is the whole
+      point: skills that never get new spores still need to be
+      fact-checked for silent refactor drift. Full rotation time
+      scales with the active skill count divided by 3, so a larger
+      skill inventory naturally stretches the verify cadence.
+
+      Skills flagged by the inventory phase (merge_candidates or
+      narrow_candidates in vault_state:skill-evolve-inventory) can be
+      skipped here — they're already going to be rewritten in act.
+
+      ## Per-skill procedure
+
+      For each selected skill:
+
+      1. Read full content via vault_skill_records (action: get).
+      2. Identify the 3-5 most LOAD-BEARING concrete claims. A claim
+         is load-bearing if the procedure depends on it being true.
+         Examples:
+         - "Edit `packages/myco/src/db/schema.ts`" — path claim
+         - "Call `setFocusedPanel()`" — identifier claim
+         - "The daemon restarts executor on SIGHUP" — behavior claim
+         Skip generic advice ("use good naming"), tool names that are
+         universal (e.g., `grep`), and illustrative code snippets that
+         aren't literal file content.
+      3. Verify each claim with the cheapest tool that answers it:
+         - **Path claim** → fs_read with a narrow line window (e.g.,
+           start_line=1, end_line=30). ENOENT or unrelated content =
+           MISSING/OUTDATED. For a DIRECTORY path, use fs_list or
+           fs_tree instead — fs_read on a directory returns an error
+           and burns a turn.
+         - **Identifier claim** → code_grep for the symbol with a
+           path+glob filter. Zero hits in expected location = MISSING.
+         - **Behavior claim** → code_grep for signature patterns that
+           would implement it. Zero hits = MISSING.
+
+         HARD LIMIT: **at most 2 tool calls per claim**, and **at most
+         4 claims per skill**, so ~8 filesystem calls per skill
+         absolute maximum. If your first grep returns too many hits
+         or the wrong ones, DO NOT refine and retry — accept
+         INCONCLUSIVE and move on. Exploratory refinement is exactly
+         how this phase burned through budget on earlier runs.
+
+      4. Categorize each claim: VERIFIED / MISSING / OUTDATED /
+         INCONCLUSIVE. INCONCLUSIVE is fine when the claim is too
+         fuzzy to verify cheaply — don't burn turns on it.
+
+      5. Aggregate for the skill:
+         - confidence: high (>=80% verified), medium, or low
+         - severity: none / minor (1 cosmetic miss) / major
+           (load-bearing miss) / critical (most refs gone)
+
+      6. Update the skill's verify watermark REGARDLESS of severity —
+         skipping this step on severity=none would make verify re-pick
+         the same skill forever. Example call:
+
+           vault_skill_records({
+             action: "update",
+             id: "<the-skill-uuid>",
+             properties: "{\"last_verified_at\": 1776580022}"
+           })
+
+         `properties` is a JSON string, merged into the skill's existing
+         properties. Any recent epoch-seconds integer works as the
+         timestamp — this is a rotation cursor, not an audit timestamp.
+
+      ## Budget discipline
+
+      Total budget for this phase: {{max_turns}} turns covering ALL
+      selected skills combined. Plan per-skill budget as roughly
+      `{{max_turns}} / skills_selected` turns. Recommended shape:
+      1 content read + up to 4 claim checks × up to 2 tool calls +
+      1 watermark write. Stop verifying a skill as soon as severity
+      is clear — finding one MISSING load-bearing claim is enough
+      to flag the skill; don't check remaining claims.
+
+      Prefer narrow fs_read windows (start/end lines) over whole-file
+      reads. Prefer code_grep with a path/glob filter over an open grep.
+      When a tool returns "Not a file" or zero matches, accept that
+      answer and move on — do not retry with adjusted args.
+
+      Tools available for this phase: {{phase_tools}}.
+
+      ## Store results
+
+      Store via vault_set_state (key: skill-evolve-drift) as JSON:
+      {
+        "verified_at": <epoch-seconds>,
+        "reports": [
+          {
+            "skill_id": "...",
+            "name": "...",
+            "severity": "none|minor|major|critical",
+            "confidence": "high|medium|low",
+            "notes": "Short: what's missing or outdated.",
+            "load_bearing_misses": ["claim 1", "claim 2"]
+          }
+        ]
+      }
+
+      Report via vault_report. If no active skills are selectable
+      (e.g., all were flagged by inventory for merge), store an empty
+      reports array and report skip.
+    tools:
+      - vault_skill_records
+      - vault_set_state
+      - vault_report
+      - fs_read
+      - fs_list
+      - code_grep
+    maxTurns: 24
+    required: true
+    dependsOn:
+      - inventory
+
   - name: assess
     reasoningLevel: default
     prompt: |
-      Read the inventory analysis from vault_state
-      (key: skill-evolve-inventory).
+      Read two pre-computed inputs from vault_state:
+        - key: skill-evolve-inventory (merge/narrow candidates)
+        - key: skill-evolve-drift (codebase verification reports)
 
-      There are TWO sources of skills to assess:
+      There are THREE sources of skills to assess:
 
       **A. Skills with new knowledge** — listed in the instruction
       with descriptions and new spore IDs (full content is NOT in
@@ -98,8 +233,8 @@ phases:
          get, id: "<name>") and verify 2-3 code references via
          vault_search_fts. Skip content reads for skills where
          the new spores are clearly unrelated.
-      3. Check the inventory analysis: is this skill also flagged
-         for merge or narrowness?
+      3. Check the inventory AND drift analyses: is this skill also
+         flagged for merge, narrowness, or codebase drift?
 
       **B. Inventory-flagged skills** — merge_candidates and
       narrow_candidates from the inventory analysis. These may NOT
@@ -109,12 +244,30 @@ phases:
       2. Verify the inventory's merge/narrow recommendation by
          reading both skills' content.
 
-      For ALL skills from both sources, classify with one of:
+      **C. Drift-flagged skills** — reports from the verify phase with
+      severity of `minor`, `major`, or `critical`. These may NOT appear
+      in the instruction (no new spores) but need attention because
+      their content no longer matches the codebase. For each drift
+      report not already covered above:
+      1. Read the skill's content via vault_skill_records (action: get).
+      2. Trust the verify phase's load_bearing_misses as the STALE
+         detail set. You do NOT need to re-run fs_read/code_grep —
+         the verify phase already did that work. Only re-check if
+         the verify report's confidence is low.
+      3. Major/critical severity with confidence high/medium should
+         classify as STALE (or DEPRECATED if the entire subsystem
+         described is gone). Minor severity may stay CURRENT unless
+         combined with new-spore evidence.
+
+      For ALL skills from all three sources, classify with one of:
          - CURRENT — still accurate, no changes needed.
-         - STALE — new knowledge changes specific steps, paths,
-           or gotchas. Note exactly WHAT is new.
+         - STALE — new knowledge OR drift report changes specific
+           steps, paths, or gotchas. Note exactly WHAT is new or
+           wrong (cite the drift report's load_bearing_misses if
+           that's the driver).
          - DEPRECATED — key code references are gone or the
            procedure is no longer relevant. Note what's missing.
+           Drift severity=critical is the strongest signal here.
          - MERGE — overlaps significantly with another skill
            (from inventory analysis). Note the TARGET skill to
            merge into.
@@ -122,10 +275,11 @@ phases:
            inventory analysis). Note the BROADER skill to absorb
            into.
 
-         Bias toward CURRENT. A skill that is 90% accurate is
-         better left alone than rewritten with risk of losing detail.
-         Only classify MERGE/NARROW when the inventory analysis
-         supports it AND you agree after reading the content.
+         Bias toward CURRENT for cosmetic issues. A skill that is 90%
+         accurate is better left alone than rewritten with risk of
+         losing detail. Do NOT bias toward CURRENT when a drift report
+         flags load-bearing misses with high confidence — that's
+         exactly the refactor-drift case this pipeline exists to catch.
 
       5. Update the skill's properties with the new watermark:
          vault_skill_records (action: update, id: <skill_id>,
@@ -143,8 +297,9 @@ phases:
       Report via vault_report.
 
       If the instruction says "No skills need assessment" AND the
-      inventory has no merge/narrow candidates, report skip via
-      vault_report and finish.
+      inventory has no merge/narrow candidates AND the drift report
+      has no minor+ severity entries, report skip via vault_report
+      and finish.
     tools:
       - vault_spores
       - vault_search_fts
@@ -155,6 +310,7 @@ phases:
     required: true
     dependsOn:
       - inventory
+      - verify
 
   - name: act
     reasoningLevel: low

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

@@ -11,7 +11,7 @@ prompt: >-
   source material. Stage the skill, validate it, then finalize it.
 isDefault: false
 reasoningLevel: default
-maxTurns: 30
+maxTurns: 32
 timeoutSeconds: 900
 schedule:
   enabled: false
@@ -177,9 +177,22 @@ phases:
          staging path's dedup gate already ran on your description;
          this is a sanity check on the procedural content itself.
 
-      7. **Accuracy:** Spot-check 2-3 specific claims against the
-         vault. Use vault_search_fts to verify file paths and
-         function names mentioned in the skill.
+      7. **Accuracy (codebase-grounded):** Identify the 3-5 most
+         LOAD-BEARING concrete claims — paths, function/class names,
+         patterns the procedure depends on — and verify each against
+         the actual source:
+         - **Path claim** → `fs_read` (narrow window). ENOENT or
+           unrelated content = FAIL.
+         - **Identifier claim** → `code_grep` with a path+glob filter.
+           Zero hits in the expected location = FAIL.
+         - **Behavior claim** → `code_grep` for signature patterns
+           that would implement it. Zero hits = FAIL.
+         Budget 1-2 tool calls per claim.
+
+         If any load-bearing claim FAILS, treat as a criterion failure
+         and re-stage with corrected content. Do not finalize a skill
+         whose load-bearing paths can't be verified against the
+         current codebase — that's how hallucinated paths ship.
 
       ## If criteria fail
 
@@ -216,9 +229,10 @@ phases:
       - vault_skill_records
       - vault_skill_candidates
       - vault_spores
-      - vault_search_fts
       - vault_report
-    maxTurns: 15
+      - fs_read
+      - code_grep
+    maxTurns: 18
     required: true
     dependsOn:
       - draft

package/dist/src/agent/definitions/tasks/vault-evolve.yaml

@@ -262,67 +262,77 @@ phases:
     reasoningLevel: default
     dependsOn: [consolidate]
     prompt: |
-      Assess current digest state and gather material for tier updates.
-      The 3 digest tier phases run in parallel after you — your summary
-      is their primary input. Be thorough.
-
-      ## Step 1: Check current state (budget: 2 turns)
-
-      Call `vault_read_digest` (no tier param) to see current digest state.
-      Note each tier's `generated_at` timestamp — this tells you how fresh
-      each tier is. Review the prior phase results (in your context):
-      - How many spores were created/superseded?
-      - How many entities/edges were added?
-      - Did consolidate or graph act on externally-created spores or entities?
-
-      If changes are minor (< 3 new spores, 0 entity changes), call
-      `vault_report` with action "skip" and reason explaining why the
-      current digest is still sufficient. STOP.
-
-      ## Step 2: Gather new material (budget: 5 turns)
-
-      Search for material relevant to what changed:
-      1. Call `vault_search_semantic` with themes from newly created/superseded
-         spores and new entity names
-      2. Call `vault_spores` to see recently created observations
-      3. Call `vault_sessions` for recent session context
-
-      ## Step 3: Produce detailed findings
-
-      Your final response is critical — the per-tier phases see it as their
-      primary context (they cannot call vault_spores or vault_sessions).
-      Structure your summary as:
-
-      **New material to integrate:**
-      - List each new insight, decision, pattern, gotcha with enough detail
-        that a tier writer can incorporate it without re-searching
-      - Include specific spore content, not just "3 new spores were created"
-
-      **Themes and connections:**
-      - What overarching themes connect the new material?
-      - What existing digest sections are affected?
-
-      **Per-tier freshness and guidance:**
-      For each tier, state whether it should UPDATE or SKIP based on both
-      the volume of new material AND the tier's `generated_at` freshness:
-      - A tier written < 30 minutes ago with only minor changes → SKIP
-      - A tier written hours ago or with significant changes → UPDATE
-      - Larger tiers (10000) tolerate more frequent updates since
-        they have room for incremental additions
-      - Smaller tiers (1500) should only update for material that
-        genuinely changes the executive picture
-
-      Per-tier directives:
-      - 10000: UPDATE/SKIP + what to add (any new content)
-      - 5000: UPDATE/SKIP + what to add (trade-offs and patterns)
-      - 1500: UPDATE/SKIP + what to add (only critical changes)
+      Gather material for AT MOST ONE digest tier update per run. The
+      rotation decision is made by the `vault_read_digest` tool, not
+      by you — the tool returns which tier needs attention (or tells
+      you to skip). Over 3 runs every tier gets one deep pass.
+
+      Total budget: {{max_turns}} turns.
+
+      ## Step 1: Get the rotation decision (1 turn)
+
+      Call `vault_read_digest` with:
+        pick: "rotate_oldest"
+        min_staleness_seconds: 1800
+
+      The tool returns one of two shapes:
+
+      **Skip shape** — `{mode:"rotate_oldest", skip:true, reason, all_tiers}`.
+      Every tier was generated within the last 30 minutes. Call
+      `vault_report` with action "skip" passing the reason through.
+      STOP — do not run steps 2-3.
+
+      **Rotate shape** — `{mode:"rotate_oldest", selected_tier,
+      selected_generated_at, selected_content, rotation_reason, all_tiers}`.
+      Proceed to step 2, scoped to `selected_tier`.
+
+      ## Step 2: Gather material for `selected_tier` (budget: half
+      of remaining)
+
+      Scope the search to what belongs at the selected tier:
+      - **1500 (executive briefing):** only critical decisions,
+        reversals, state-of-system changes.
+      - **5000 (deep onboarding):** trade-offs, patterns, active
+        decisions, unresolved gotchas.
+      - **10000 (full archive):** any new content worth preserving.
+
+      Use `vault_search_semantic` for themes from new/superseded spores,
+      `vault_spores` for specific content, `vault_sessions` for recent
+      session context. Make each call count — do not repeatedly search
+      for variations of the same theme. Accept "good enough" findings
+      and move on.
+
+      ## Step 3: Produce findings
+
+      Your final response is the per-tier phases' primary context
+      (they cannot call vault_spores or vault_sessions). Structure it:
+
+      **Chosen tier for this run: <selected_tier>**
+      Include the rotation_reason verbatim from the tool so readers
+      can audit the decision.
+
+      **New material to integrate (scoped to the chosen tier):**
+      - List each insight with enough detail that the tier writer can
+        incorporate it without re-searching
+      - Include specific spore content, not just spore counts
+
+      **Themes and connections** relevant to the chosen tier.
+
+      **Per-tier directives** — mark exactly the `selected_tier` as
+      UPDATE, the other two as SKIP, and include the tool's
+      rotation_reason in the UPDATE line:
+      - 10000: UPDATE or SKIP + one-line reason
+      - 5000: UPDATE or SKIP + one-line reason
+      - 1500: UPDATE or SKIP + one-line reason
+
+      Tools available: {{phase_tools}}.
     tools:
       - vault_spores
       - vault_sessions
       - vault_search_semantic
       - vault_read_digest
       - vault_report
-    maxTurns: 10
+    maxTurns: 12
     required: true
 
   - name: digest-10000

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-LNYSTDQM.js");
+await import("../cli-HSLIG7EX.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-5PRQNEEE.js");
+var { main } = await import("../../main-4J4QZZTZ.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-GMMSYBII.js");
+var { main } = await import("../../post-tool-use-TZINWWDH.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-LWJYQAXX.js");
+var { main } = await import("../../session-end-FS46UARX.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-WTA6GCOQ.js");
+var { main } = await import("../../session-start-46KPFV2H.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-WRBTXEVT.js");
+var { main } = await import("../../stop-OUEX6KA4.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-ME2TBKOS.js");
+var { main } = await import("../../user-prompt-submit-APMO6FVU.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-AHUR6CWF.js");
+var { main } = await import("../../server-AZJSTQEK.js");
 await main();
 //# sourceMappingURL=server.js.map

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

@@ -21,6 +21,13 @@ registration:
   # opencode.json hosts MCP + permissions under non-standard keys
   mcpTarget: opencode.json
   mcpServersKey: mcp
+  # Opencode prepends /opt/homebrew/bin ahead of ~/.local/bin in the env it
+  # gives MCP children, so `myco-run` resolves to the prod shim regardless
+  # of the user's shell PATH. Bake the runtime.command alias into the MCP
+  # command at install time so the spawn skips PATH resolution entirely.
+  # Every other symbiont resolves `myco-run` via PATH and then uses the
+  # shim's runtime.command walk-up — no install-time substitution needed.
+  substituteRuntimeCommand: true
   settingsTarget: opencode.json
   skillsTarget: .agents/skills
   # No instructionsFile — opencode reads AGENTS.md natively

package/dist/src/symbionts/templates/agents-starter.md

@@ -2,4 +2,4 @@
 
 <!-- This starter file was created by Myco. Replace it with your project's rules and conventions. -->
 
-Rules haven't been defined yet. Use the `/rules` skill to generate project rules, or edit this file directly.
+Rules haven't been defined yet. Use the `/myco-rules` skill to add durable project rules, or edit this file directly.

package/dist/{stats-DFG6S23S.js → stats-MKMETHMA.js}

@@ -1,19 +1,19 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   gatherStats
-} from "./chunk-75Z7UKDY.js";
+} from "./chunk-VRI56337.js";
 import {
   initVaultDb
-} from "./chunk-JR54LTPP.js";
+} from "./chunk-QDLVIW2O.js";
 import "./chunk-SAKJMNSR.js";
-import "./chunk-VHNRMM4O.js";
+import "./chunk-OTQH5KZW.js";
 import "./chunk-X3IGT5RV.js";
 import "./chunk-53RPGOEN.js";
 import "./chunk-OUJSQSKE.js";
 import "./chunk-POEPHBQK.js";
 import "./chunk-MYX5NCRH.js";
-import "./chunk-P66DLD6G.js";
-import "./chunk-BUTL6IFS.js";
+import "./chunk-KTTSXYEK.js";
+import "./chunk-ENZR5NG7.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -94,4 +94,4 @@ function formatUptime(seconds) {
 export {
   run
 };
-//# sourceMappingURL=stats-DFG6S23S.js.map
+//# sourceMappingURL=stats-MKMETHMA.js.map

package/dist/{stop-WRBTXEVT.js → stop-OUEX6KA4.js}

@@ -2,16 +2,16 @@ import { createRequire as __cr } from 'node:module'; const require = __cr(import
 import {
   normalizeHookInput,
   readStdin
-} from "./chunk-5ZG4RMUH.js";
+} from "./chunk-N2DGFACQ.js";
 import "./chunk-ZXZPJJN3.js";
 import {
   resolveVaultDir
-} from "./chunk-CUDIZJY7.js";
+} from "./chunk-TSM6VESW.js";
 import {
   DaemonClient
-} from "./chunk-P66DLD6G.js";
-import "./chunk-BUTL6IFS.js";
-import "./chunk-NGROSFOH.js";
+} from "./chunk-KTTSXYEK.js";
+import "./chunk-ENZR5NG7.js";
+import "./chunk-Z66IT5KL.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -46,4 +46,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=stop-WRBTXEVT.js.map
+//# sourceMappingURL=stop-OUEX6KA4.js.map

package/dist/{stop-failure-32MGIG2Q.js → stop-failure-2BWVNZEG.js}

@@ -1,14 +1,14 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   sendEvent
-} from "./chunk-G6QIBNZM.js";
+} from "./chunk-NFO7BRCO.js";
 import "./chunk-V7XG6V6C.js";
-import "./chunk-5ZG4RMUH.js";
+import "./chunk-N2DGFACQ.js";
 import "./chunk-ZXZPJJN3.js";
-import "./chunk-CUDIZJY7.js";
-import "./chunk-P66DLD6G.js";
-import "./chunk-BUTL6IFS.js";
-import "./chunk-NGROSFOH.js";
+import "./chunk-TSM6VESW.js";
+import "./chunk-KTTSXYEK.js";
+import "./chunk-ENZR5NG7.js";
+import "./chunk-Z66IT5KL.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -28,4 +28,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=stop-failure-32MGIG2Q.js.map
+//# sourceMappingURL=stop-failure-2BWVNZEG.js.map

package/dist/{subagent-start-VFGHQFVL.js → subagent-start-J4VV6DEE.js}

@@ -1,14 +1,14 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   sendEvent
-} from "./chunk-G6QIBNZM.js";
+} from "./chunk-NFO7BRCO.js";
 import "./chunk-V7XG6V6C.js";
-import "./chunk-5ZG4RMUH.js";
+import "./chunk-N2DGFACQ.js";
 import "./chunk-ZXZPJJN3.js";
-import "./chunk-CUDIZJY7.js";
-import "./chunk-P66DLD6G.js";
-import "./chunk-BUTL6IFS.js";
-import "./chunk-NGROSFOH.js";
+import "./chunk-TSM6VESW.js";
+import "./chunk-KTTSXYEK.js";
+import "./chunk-ENZR5NG7.js";
+import "./chunk-Z66IT5KL.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -28,4 +28,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=subagent-start-VFGHQFVL.js.map
+//# sourceMappingURL=subagent-start-J4VV6DEE.js.map