@goondocks/myco 0.21.0 → 0.21.2

package/dist/{session-2ZEPLWW6.js → session-NJCUW3OX.js}

@@ -1,9 +1,9 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   initVaultDb
-} from "./chunk-JR54LTPP.js";
+} from "./chunk-W5L5IHP5.js";
 import "./chunk-SAKJMNSR.js";
-import "./chunk-VHNRMM4O.js";
+import "./chunk-OTQH5KZW.js";
 import "./chunk-X3IGT5RV.js";
 import {
   getSession,
@@ -13,8 +13,8 @@ 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-6FBLL7MD.js";
+import "./chunk-Z55WGA2J.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -72,4 +72,4 @@ ${target.summary}`);
 export {
   run
 };
-//# sourceMappingURL=session-2ZEPLWW6.js.map
+//# sourceMappingURL=session-NJCUW3OX.js.map

package/dist/{session-end-LWJYQAXX.js → session-end-XD27GRYF.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-6FBLL7MD.js";
+import "./chunk-Z55WGA2J.js";
+import "./chunk-Z66IT5KL.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -41,4 +41,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=session-end-LWJYQAXX.js.map
+//# sourceMappingURL=session-end-XD27GRYF.js.map

package/dist/{session-start-WTA6GCOQ.js → session-start-RDTXUSYL.js}

@@ -2,20 +2,20 @@ import { createRequire as __cr } from 'node:module'; const require = __cr(import
 import {
   composeSessionStartContext,
   shouldInjectSessionStartDigest
-} from "./chunk-DJ3IHNYO.js";
+} from "./chunk-TFRUDNLI.js";
 import {
   getCortexInstructions,
   shouldInjectCortex
-} from "./chunk-F3OEQYLS.js";
+} from "./chunk-DBBO6FHE.js";
 import "./chunk-RQSJLWP4.js";
 import {
   evaluateSessionCaptureRules,
   readTranscriptMeta
-} from "./chunk-XL75KZGI.js";
-import "./chunk-CESKJD44.js";
+} from "./chunk-EKZG2MCD.js";
+import "./chunk-DMPCC7V6.js";
 import {
   createSchema
-} from "./chunk-RL5R4CQU.js";
+} from "./chunk-DTWUHHFI.js";
 import {
   loadMergedConfig
 } from "./chunk-53RPGOEN.js";
@@ -28,18 +28,18 @@ 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";
+} from "./chunk-6FBLL7MD.js";
+import "./chunk-Z55WGA2J.js";
 import {
   loadManifests
-} from "./chunk-NGROSFOH.js";
+} from "./chunk-Z66IT5KL.js";
 import "./chunk-LPUQPDC2.js";
 import {
   DEFAULT_AGENT_ID,
@@ -131,4 +131,4 @@ async function main() {
 export {
   main
 };
-//# sourceMappingURL=session-start-WTA6GCOQ.js.map
+//# sourceMappingURL=session-start-RDTXUSYL.js.map

package/dist/{setup-llm-E7UU5IO7.js → setup-llm-FYPPJI6W.js}

@@ -2,11 +2,11 @@ import { createRequire as __cr } from 'node:module'; const require = __cr(import
 import {
   withEmbedding
 } from "./chunk-IPPMYQ2Y.js";
-import "./chunk-JR54LTPP.js";
+import "./chunk-W5L5IHP5.js";
 import {
   parseStringFlag
 } from "./chunk-SAKJMNSR.js";
-import "./chunk-VHNRMM4O.js";
+import "./chunk-OTQH5KZW.js";
 import "./chunk-X3IGT5RV.js";
 import {
   loadConfig,
@@ -16,8 +16,8 @@ import "./chunk-OUJSQSKE.js";
 import "./chunk-POEPHBQK.js";
 import "./chunk-MYX5NCRH.js";
 import "./chunk-ZXZPJJN3.js";
-import "./chunk-P66DLD6G.js";
-import "./chunk-BUTL6IFS.js";
+import "./chunk-6FBLL7MD.js";
+import "./chunk-Z55WGA2J.js";
 import "./chunk-LPUQPDC2.js";
 import "./chunk-6C6QZ4PM.js";
 import "./chunk-UUHLLQXO.js";
@@ -82,4 +82,4 @@ async function run(args, vaultDir) {
 export {
   run
 };
-//# sourceMappingURL=setup-llm-E7UU5IO7.js.map
+//# sourceMappingURL=setup-llm-FYPPJI6W.js.map

package/dist/src/agent/definitions/tasks/cortex-instructions.yaml

@@ -14,55 +14,61 @@ maxTurns: 12
 timeoutSeconds: 180
 schedule:
   enabled: true
-  intervalSeconds: 3600
+  intervalSeconds: 14400
   runIn:
     - idle
     - sleep
 
 prompt: |
-  Author compact session-start instructions for another coding agent.
+  You are producing session-start instructions for another coding agent
+  working in this project. The final artifact is written in the `author`
+  phase via `vault_report` with action "cortex_instructions". The `research`
+  phase does NOT draft markdown — it produces a compact situation brief
+  that the author phase shapes into prose.
 
   You will receive:
-  - current context configuration
-  - the available Myco tool capabilities
-  - tool guidance that must be encoded
-  - a digest excerpt plus recent sessions, spores, and plans
+  - current context configuration and capability summary
+  - tool guidance that must be encoded in the final instructions
+  - a digest excerpt plus recent sessions, spores (wisdom, decision, discovery),
+    and active plans
   - authoring requirements that constrain the final output
 
-  Your job is to produce concise markdown instructions for session start.
-
-  Requirements:
-  - Start with the heading `## Myco-Enabled Project`.
-  - Immediately follow with one brief sentence explaining that Myco provides project memory, prior decisions, plans, and retrieval tools for this project.
-  - Teach the most useful Myco tool behavior, not implementation details.
-  - Mention Myco tools using backticks.
-  - Use the recent vault context to make the instructions feel current when it adds signal.
-  - Keep the heading and intro brief so most tokens go to retrieval guidance.
-  - Keep the output compact and ready for direct injection.
-  - Do not restate AGENTS.md.
-  - Do not invent unavailable tools.
-  - Do not tell the agent to call `myco_skills`; project and Myco skills are already registered separately.
-
-  Call `vault_report` with action "cortex_instructions" and:
-  - summary: what the instructions emphasize
-  - details.content: the final markdown instructions
+  Do not restate AGENTS.md, installation details, or generic Myco boilerplate.
+  Do not invent unavailable tools. Do not tell the downstream agent to call
+  `myco_skills` — project and Myco skills are registered separately.
 
 phases:
   - name: research
+    reasoningLevel: default
     prompt: |
-      Review the provided digest excerpt and recent vault activity first.
+      Produce a compact situation brief. DO NOT write the final markdown
+      — that is the author phase's job.
+
+      Output exactly this structure as your phase summary:
 
-      Then use vault tools selectively to confirm what is current and high-signal
-      enough to deserve mention in the session-start instructions. Prefer the
-      smallest number of reads that sharpen the instructions.
+      ## Hotspots (2-3)
+      - <named workstream, plan, or branch> — <one sentence on why a new
+        agent working in this repo should know about it>
 
-      Focus on:
-      - which Myco MCP tools matter most right now
-      - which current project hotspots or active workstreams are worth naming
-      - whether recent sessions, spores, or active plans reveal a better tool-use hint
+      ## Recent signal
+      - <recent session title or spore worth citing> — <why it matters>
 
-      Do not spend time enumerating every note. Gather only what improves the
-      final session-start instructions.
+      ## Tool-use hint
+      - <one concrete hint a new agent would benefit from, grounded in
+        the recent activity above — e.g. "check active plans before
+        proposing X because plan Y already covers it">
+
+      Use the pre-assembled input (digest, recent sessions, spores,
+      active plans) as your starting point. Use `vault_search_fts`,
+      `vault_spores`, `vault_session_summary_material`, and
+      `vault_sessions` only to confirm a hotspot is current or to
+      disambiguate. Prefer active plans and the last 3 settled sessions
+      as anchors. If the input names a hotspot, verify it's still live
+      before keeping it — stale hotspots (work that has shipped and
+      moved on) are worse than no hotspot.
+
+      If you cannot identify 2-3 genuine hotspots, emit fewer — never
+      pad with boilerplate.
     tools:
       - vault_read_digest
       - vault_sessions
@@ -77,16 +83,32 @@ phases:
   - name: author
     dependsOn: [research]
     prompt: |
-      Write the final session-start instructions.
+      Write the final session-start markdown from the research brief.
+
+      Required structure:
+      - `## Myco-Enabled Project` heading, then one sentence explaining
+        that Myco provides project memory, prior decisions, plans, and
+        retrieval tools for this repository.
+      - A retrieval paragraph naming the highest-priority tools from the
+        tool guidance list (typically `myco_search`, `myco_recall`,
+        `myco_context`). Describe when each is useful, not what each
+        argument does.
+      - A plan-persistence paragraph naming `myco_plans` and
+        `myco_save_plan`.
+      - A `### Current workstreams` section that MUST cite at least
+        one active plan or recent session BY TITLE from the research
+        brief. If the research brief contains zero hotspots, write
+        "No active workstreams worth flagging right now." verbatim —
+        do not invent, recycle, or pad with stale items.
+      - A closing paragraph on `myco_remember` for saving discoveries.
 
-      The output should:
-      - open with the heading `## Myco-Enabled Project` and one brief sentence of context
-      - teach the agent how to retrieve the right Myco knowledge on demand and persist plans when appropriate
-      - mention the most relevant current project activity when it adds value
-      - avoid generic boilerplate
-      - avoid telling the agent to call `myco_skills`
+      Keep the output compact and ready for direct injection. Do not
+      restate AGENTS.md. Do not mention `myco_skills`.
 
-      Report the final markdown via `vault_report`.
+      Report the final markdown via `vault_report` with:
+      - action: "cortex_instructions"
+      - summary: what the instructions emphasize
+      - details.content: the final markdown
     tools:
       - vault_report
     maxTurns: 4

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
@@ -22,7 +25,7 @@ schedule:
   preCondition: has-active-skills
 params:
   assess_interval_hours: 24
-  max_skills_per_run: 8
+  max_skills_per_run: 3
 phases:
   - name: inventory
     reasoningLevel: low
@@ -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 2 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 2
+      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 2, 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