@goondocks/myco 0.18.0 → 0.19.0

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

@@ -33,34 +33,40 @@ phases:
       ---
       name: myco:kebab-case-name
       description: |
-        One paragraph that serves as the PRIMARY triggering mechanism.
-        Be explicit about when this skill activates. Include concrete
-        keywords, file names, and scenarios. Be somewhat pushy to
-        counter undertriggering — include "even if the user doesn't
-        explicitly ask for [topic]" language when appropriate.
+        One paragraph serving as the PRIMARY triggering mechanism.
+        Cover the full procedural domain — mention all the major
+        procedures this skill covers. Be explicit about when this
+        activates. Include "even if the user doesn't explicitly
+        ask for [topic]" language when appropriate.
       managed_by: myco
       user-invocable: true
       allowed-tools: Read, Edit, Write, Bash, Grep, Glob
       ---
 
-      # Skill Title
+      # Domain Title
 
-      Brief context paragraph (2-3 sentences) explaining what this
-      procedure accomplishes and when you'd use it.
+      Brief context paragraph (2-3 sentences) explaining the
+      procedural domain and when you'd use this skill.
 
       ## Prerequisites
 
-      What must be true before starting.
+      What must be true before starting any procedure in this domain.
 
-      ## Steps
+      ## Procedure A: [Name]
 
-      Numbered, concrete steps with file paths and code examples.
-      Each step should reference specific files in this project.
+      Steps for the first major procedure in this domain.
 
-      ## Common Pitfalls
+      ## Procedure B: [Name]
 
-      Inline with the steps where possible, or as a short section
-      at the end for cross-cutting gotchas.
+      Steps for the second major procedure.
+
+      ## Procedure C: [Name]
+
+      Steps for the third major procedure.
+
+      ## Cross-Cutting Gotchas
+
+      Pitfalls that span multiple procedures in this domain.
       ```
 
       ## Frontmatter Fields
@@ -79,21 +85,27 @@ phases:
 
       ## Writing Principles
 
+      - **This candidate represents a procedural domain** — a family
+        of related tasks that share prerequisite knowledge. The skill
+        should cover the full domain, not just a single procedure.
+      - **A well-scoped skill has 3-6 major sections**, each describing
+        a distinct procedure within the domain. If the candidate maps
+        to fewer than 2 sections, note this in the rationale — it may
+        be too narrow.
       - **Explain reasoning, not rigid rules.** "Because X, do Y"
-        is better than "ALWAYS do Y." Use theory of mind — the agent
-        using this skill is smart enough to understand WHY.
-      - **Stay under 500 lines.** Be concise but complete.
-      - **Use concrete file paths** from this project, not generic examples.
+        is better than "ALWAYS do Y." The agent using this skill
+        understands WHY.
+      - **Stay under 800 lines.** Be concise but complete.
+      - **Use concrete file paths** from this project.
       - **Include code patterns** where they help (inline code blocks).
       - **Include examples** — show input/output or before/after where
         it makes the procedure clearer.
-      - **Reference gotchas inline** where the developer would encounter
-        them, not in a separate section.
+      - **Reference gotchas inline** where the developer would
+        encounter them, not in a separate section.
       - **The description is the trigger.** An agent reading just the
-        description should know whether this skill applies to their task.
+        description should know whether this skill applies.
       - **Be general enough to survive change.** The skill should teach
-        the pattern, not just document the current state. If a file path
-        changes, the procedure should still make sense.
+        the pattern, not just document the current state.
 
       ## Tool Call
 
@@ -143,14 +155,19 @@ phases:
          function names, and code patterns from this project?
          Generic advice ("add a config file") is not enough.
 
-      4. **Length:** Under 500 lines?
+      4. **Length:** Under 800 lines?
+
+      5. **Domain scope:** Does this skill cover a procedural domain
+         (multiple related procedures as sections) or just a single
+         procedure? If single, flag as potentially too narrow. Count
+         the ## headings — expect 3-6 for a well-scoped domain skill.
 
-      5. **Conflicts:** Does it overlap with existing skills?
+      6. **Conflicts:** Does it overlap with existing skills?
          Use vault_skill_records (action: list) to check. The
          staging path's dedup gate already ran on your description;
          this is a sanity check on the procedural content itself.
 
-      6. **Accuracy:** Spot-check 2-3 specific claims against the
+      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.
 

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-X7CFP4YD.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-EIKBLOUL.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-TWBBBABS.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-PZ2OXBGG.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-FDGM56BX.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-WNKCMCGO.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-SOYL4OWF.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-O3UPJVBR.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/{stats-DGI6B3HX.js → stats-2STTARTC.js}

@@ -1,23 +1,23 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 import {
   gatherStats
-} from "./chunk-DLFDBKEV.js";
+} from "./chunk-OZF5EURR.js";
 import {
   initVaultDb
-} from "./chunk-55QEICRO.js";
+} from "./chunk-N77K772N.js";
 import "./chunk-SAKJMNSR.js";
 import "./chunk-WYOE4IAX.js";
-import "./chunk-CML4MCYF.js";
-import "./chunk-2V7HR7HB.js";
+import "./chunk-KSXTNYXO.js";
+import "./chunk-MDEUXYJG.js";
 import "./chunk-MYX5NCRH.js";
-import "./chunk-BUIR3JWM.js";
-import "./chunk-EO2RQW4S.js";
+import "./chunk-CYBC2HZ3.js";
+import "./chunk-2CKDAFSX.js";
 import "./chunk-LPUQPDC2.js";
-import "./chunk-CKJAWZQE.js";
+import "./chunk-W4VHC2ES.js";
 import "./chunk-E7NUADTQ.js";
-import "./chunk-D7TYRPRM.js";
-import "./chunk-E4VLWIJC.js";
-import "./chunk-GDY63YAW.js";
+import "./chunk-6LQIMRTC.js";
+import "./chunk-ODXLRR4U.js";
+import "./chunk-U6PF3YII.js";
 import "./chunk-PZUWP5VK.js";
 
 // src/cli/stats.ts
@@ -92,4 +92,4 @@ function formatUptime(seconds) {
 export {
   run
 };
-//# sourceMappingURL=stats-DGI6B3HX.js.map
+//# sourceMappingURL=stats-2STTARTC.js.map