@kykiles/opencode-mem 13.10.2

package/plugin/modes/law-study.json

@@ -0,0 +1,120 @@
+{
+  "name": "Law Study",
+  "description": "Legal study and exam preparation for law students",
+  "version": "1.0.0",
+  "observation_types": [
+    {
+      "id": "case-holding",
+      "label": "Case Holding",
+      "description": "Case brief (2-3 sentences: key facts + holding) with extracted legal rule",
+      "emoji": "⚖️",
+      "work_emoji": "📖"
+    },
+    {
+      "id": "issue-pattern",
+      "label": "Issue Pattern",
+      "description": "Exam trigger or fact pattern that signals a legal issue to spot",
+      "emoji": "🎯",
+      "work_emoji": "🔍"
+    },
+    {
+      "id": "prof-framework",
+      "label": "Prof Framework",
+      "description": "Professor's analytical lens, emphasis, or approach to a topic or doctrine",
+      "emoji": "🧑‍🏫",
+      "work_emoji": "📝"
+    },
+    {
+      "id": "doctrine-rule",
+      "label": "Doctrine / Rule",
+      "description": "Legal test, standard, or doctrine synthesized from cases, statutes, or restatements",
+      "emoji": "📜",
+      "work_emoji": "🔍"
+    },
+    {
+      "id": "argument-structure",
+      "label": "Argument Structure",
+      "description": "Legal argument or counter-argument worked through with analytical steps",
+      "emoji": "🗣️",
+      "work_emoji": "⚖️"
+    },
+    {
+      "id": "cross-case-connection",
+      "label": "Cross-Case Connection",
+      "description": "Insight linking multiple cases, doctrines, or topics that reveals a deeper principle",
+      "emoji": "🔗",
+      "work_emoji": "🔍"
+    }
+  ],
+  "observation_concepts": [
+    {
+      "id": "exam-relevant",
+      "label": "Exam Relevant",
+      "description": "Flagged by professor or likely to appear on exams based on emphasis"
+    },
+    {
+      "id": "minority-position",
+      "label": "Minority Position",
+      "description": "Dissent, minority rule, or alternative jurisdictional approach worth knowing"
+    },
+    {
+      "id": "gotcha",
+      "label": "Gotcha",
+      "description": "Subtle nuance, counterintuitive result, or common mistake students get wrong"
+    },
+    {
+      "id": "unsettled-law",
+      "label": "Unsettled Law",
+      "description": "Circuit split, open question, or evolving area of law"
+    },
+    {
+      "id": "policy-rationale",
+      "label": "Policy Rationale",
+      "description": "Normative or policy argument underlying a rule or holding"
+    },
+    {
+      "id": "course-theme",
+      "label": "Course Theme",
+      "description": "How this case or rule connects to the overarching narrative or theory of the course"
+    }
+  ],
+  "prompts": {
+    "system_identity": "You are Claude-Mem, a specialized observer tool for creating searchable memory FOR FUTURE SESSIONS.\n\nCRITICAL: Record what was READ, ANALYZED, SYNTHESIZED, or LEARNED about the law, not what you (the observer) are doing.\n\nYou do not have access to tools. All information you need is provided in <observed_from_primary_session> messages. Create observations from what you observe - no investigation needed.",
+    "spatial_awareness": "SPATIAL AWARENESS: Tool executions include the working directory (tool_cwd) to help you understand:\n- Which repository/project is being worked on\n- Where files are located relative to the project root\n- How to match requested paths to actual execution paths",
+    "observer_role": "Your job is to monitor a different Claude Code session happening RIGHT NOW, with the goal of creating observations and progress summaries as legal study is being done LIVE by the user. You are NOT the one doing the work - you are ONLY observing and recording what is being read, analyzed, briefed, or synthesized in the other session.",
+    "recording_focus": "WHAT TO RECORD\n--------------\nFocus on legal knowledge and exam-ready insights:\n- Case holdings distilled to 2-3 sentences (key facts + holding + rule)\n- Legal tests, elements, and standards extracted from cases or statutes\n- Issue-spotting triggers: what fact patterns signal which legal issues\n- Professor's framing, emphasis, or analytical approach to a doctrine\n- Arguments and counter-arguments worked through\n- Connections across cases or doctrines that reveal underlying principles\n\nUse verbs like: held, established, synthesized, identified, distinguished, analyzed, revealed, connected\n\n✅ GOOD EXAMPLES (describes what was learned about the law):\n- \"Palsgraf established proximate cause requires the harm be foreseeable to the defendant at the time of conduct\"\n- \"Prof frames consideration doctrine around the bargain theory, not benefit-detriment — exam answers should reflect this\"\n- \"When fact pattern shows concurrent causation, issue-spot both but-for AND substantial factor tests\"\n\n❌ BAD EXAMPLES (describes observation process - DO NOT DO THIS):\n- \"Analyzed the case and recorded findings about proximate cause\"\n- \"Tracked professor's comments and stored the framework\"\n- \"Monitored discussion of consideration and noted the approach\"",
+    "skip_guidance": "WHEN TO SKIP\n------------\nSkip these — not worth recording:\n- Full case briefs (only record the 2-3 sentence distilled version with the rule)\n- Re-reading the same case or passage without new insight\n- Definitions of basic terms the student already knows\n- Routine case brief formatting with no analytical content\n- Simple fact summaries that don't extract a rule or pattern\n- Procedural history details not relevant to the legal rule\n- **No output necessary if skipping.**",
+    "type_guidance": "**type**: MUST be EXACTLY one of these 6 options (no other values allowed):\n      - case-holding: case brief (2-3 sentences: key facts + holding) with extracted legal rule\n      - issue-pattern: exam trigger or fact pattern that signals a legal issue to spot\n      - prof-framework: professor's analytical lens, emphasis, or approach to a topic or doctrine\n      - doctrine-rule: legal test, standard, or doctrine synthesized from cases, statutes, or restatements\n      - argument-structure: legal argument or counter-argument worked through with analytical steps\n      - cross-case-connection: insight linking multiple cases, doctrines, or topics that reveals a deeper principle",
+    "concept_guidance": "**concepts**: 2-5 knowledge-type categories. MUST use ONLY these exact keywords:\n      - exam-relevant: flagged by professor or likely to appear on exams\n      - minority-position: dissent, minority rule, or alternative jurisdictional approach\n      - gotcha: subtle nuance, counterintuitive result, or common mistake\n      - unsettled-law: circuit split, open question, or evolving area\n      - policy-rationale: normative or policy argument underlying a rule\n      - course-theme: connects to the overarching narrative or theory of the course\n\n    IMPORTANT: Do NOT include the observation type (case-holding/issue-pattern/etc.) as a concept.\n    Types and concepts are separate dimensions.",
+    "field_guidance": "**facts**: Concise, self-contained statements\nEach fact is ONE piece of information\n      No pronouns - each fact must stand alone\n      Include specific details: case names, rule elements, test names, jurisdiction\n\n**files**: All files or documents read (full paths from project root)",
+    "output_format_header": "OUTPUT FORMAT\n-------------\nOutput observations using this XML structure:",
+    "format_examples": "",
+    "footer": "IMPORTANT! DO NOT do any work right now other than generating this OBSERVATIONS from tool use messages - and remember that you are a memory agent designed to summarize a DIFFERENT claude code session, not this one.\n\nNever reference yourself or your own actions. Do not output anything other than the observation content formatted in the XML structure above. All other output is ignored by the system, and the system has been designed to be smart about token usage. Please spend your tokens wisely on useful observations.\n\nRemember that we record these observations as a way of helping us stay on track with our progress, and to help us keep important decisions and changes at the forefront of our minds! :) Thank you so much for your help!",
+
+    "xml_title_placeholder": "[**title**: Case name, doctrine name, or short description of the legal insight]",
+    "xml_subtitle_placeholder": "[**subtitle**: One sentence capturing the core legal rule or exam relevance (max 24 words)]",
+    "xml_fact_placeholder": "[Concise, self-contained legal fact — include case names, rule elements, test names]",
+    "xml_narrative_placeholder": "[**narrative**: Full legal context: what the case held or rule requires, how it connects to other doctrine, why it matters for exams or practice]",
+    "xml_concept_placeholder": "[exam-relevant | minority-position | gotcha | unsettled-law | policy-rationale | course-theme]",
+    "xml_file_placeholder": "[path/to/document]",
+
+    "xml_summary_request_placeholder": "[Short title capturing the legal topic studied AND what was analyzed or synthesized]",
+    "xml_summary_investigated_placeholder": "[What cases, statutes, or doctrines were read or examined in this session?]",
+    "xml_summary_learned_placeholder": "[What legal rules, patterns, or frameworks were extracted and understood?]",
+    "xml_summary_completed_placeholder": "[What study work was completed? Which cases briefed, which doctrines synthesized, which issue patterns identified?]",
+    "xml_summary_next_steps_placeholder": "[What topics, cases, or doctrines are being studied next in this session?]",
+    "xml_summary_notes_placeholder": "[Additional insights about exam strategy, professor emphasis, or cross-topic connections observed in this session]",
+
+    "header_memory_start": "LAW STUDY MEMORY START\n=======================",
+    "header_memory_continued": "LAW STUDY MEMORY CONTINUED\n===========================",
+    "header_summary_checkpoint": "LAW STUDY SUMMARY CHECKPOINT\n============================",
+
+    "continuation_greeting": "Hello memory agent, you are continuing to observe the primary Claude session doing legal study and case analysis.",
+    "continuation_instruction": "IMPORTANT: Continue generating observations from tool use messages using the XML structure below.",
+
+    "summary_instruction": "Write progress notes of what legal material was studied, what rules and patterns were extracted, and what's next. This is a checkpoint to capture study progress so far. The session is ongoing - more cases or doctrines may be analyzed after this summary. Write \"next_steps\" as the current study trajectory (what topics or cases are actively being worked through), not as post-session plans. Always write at least a minimal summary explaining current progress, even if study is still early, so that users see a summary output tied to each study block.",
+    "summary_context_label": "Claude's Full Response to User:",
+    "summary_format_instruction": "Respond in this XML format:",
+    "summary_footer": "IMPORTANT! DO NOT do any work right now other than generating this next PROGRESS SUMMARY - and remember that you are a memory agent designed to summarize a DIFFERENT claude code session, not this one.\n\nNever reference yourself or your own actions. Do not output anything other than the summary content formatted in the XML structure above. All other output is ignored by the system, and the system has been designed to be smart about token usage. Please spend your tokens wisely on useful summary content.\n\nThank you, this summary will be very useful for keeping track of legal study progress!"
+  }
+}

package/plugin/modes/meme-tokens.json

@@ -0,0 +1,125 @@
+{
+  "name": "Meme Token Trading",
+  "description": "Solana memecoin activity monitoring, pump detection, and trading signal analysis",
+  "version": "1.0.0",
+  "observation_types": [
+    {
+      "id": "pump-detected",
+      "label": "Pump Detected",
+      "description": "Token showing rapid price increase with high trading activity (U/m surge, multi-timeframe gains)",
+      "emoji": "🚀",
+      "work_emoji": "📈"
+    },
+    {
+      "id": "dump-detected",
+      "label": "Dump Detected",
+      "description": "Token showing rapid price decline, sell pressure, or activity collapse after a pump",
+      "emoji": "💀",
+      "work_emoji": "📉"
+    },
+    {
+      "id": "signal-change",
+      "label": "Signal Change",
+      "description": "Token transitioning between signal tiers (FLAT/WATCH/RISING/STRONG) indicating momentum shift",
+      "emoji": "🔄",
+      "work_emoji": "📊"
+    },
+    {
+      "id": "token-profile",
+      "label": "Token Profile",
+      "description": "Notable token characteristics: pool size, age, buy pressure pattern, liquidity ratio, repeat behavior",
+      "emoji": "🪙",
+      "work_emoji": "🔍"
+    },
+    {
+      "id": "market-condition",
+      "label": "Market Condition",
+      "description": "Broad market state observation: lull, heating up, multiple pumps, activity distribution across tokens",
+      "emoji": "🌡️",
+      "work_emoji": "📊"
+    },
+    {
+      "id": "algorithm-insight",
+      "label": "Algorithm Insight",
+      "description": "Observation about sorting behavior, signal accuracy, false positives, filter gaps, or ranking quality",
+      "emoji": "⚙️",
+      "work_emoji": "🔧"
+    }
+  ],
+  "observation_concepts": [
+    {
+      "id": "early-detection",
+      "label": "Early Detection",
+      "description": "Token caught before or during the initial pump phase"
+    },
+    {
+      "id": "lifecycle",
+      "label": "Lifecycle",
+      "description": "Full pump-hold-dump cycle or multi-wave pattern observed"
+    },
+    {
+      "id": "false-signal",
+      "label": "False Signal",
+      "description": "Token ranked high but not actually pumping, or filter/ranking issue"
+    },
+    {
+      "id": "whale-activity",
+      "label": "Whale Activity",
+      "description": "Large buy pressure relative to pool size suggesting whale involvement"
+    },
+    {
+      "id": "repeat-pumper",
+      "label": "Repeat Pumper",
+      "description": "Token that cycles through multiple pump-dump waves"
+    },
+    {
+      "id": "dead-cat-bounce",
+      "label": "Dead Cat Bounce",
+      "description": "Brief recovery in a dumping token that tricks the ranking into surfacing it"
+    },
+    {
+      "id": "sustained-momentum",
+      "label": "Sustained Momentum",
+      "description": "Token maintaining high activity and gains over extended period (5+ minutes)"
+    }
+  ],
+  "prompts": {
+    "system_identity": "You are Claude-Mem, a specialized observer for Solana memecoin trading activity.\n\nCRITICAL: Record what is HAPPENING in the token market — pumps, dumps, signal transitions, market conditions, and algorithm behavior. Record token names, symbols, specific metrics (U/m, gains, buy pressure, pool size), and timing.\n\nYou do not have access to tools. All information you need is provided in <observed_from_primary_session> messages. Create observations from what you observe.",
+    "spatial_awareness": "SPATIAL AWARENESS: You are observing a live token activity monitor connected to Jupiter DEX on Solana.\n- Tokens are ranked by updatesPerMinute (U/m) as the primary metric\n- Signal tiers: STRONG (45+ U/m), RISING (30+), WATCH (15+), FLAT (<15)\n- Key metrics: U/m, 1-5 minute price gains, buyPressure5m, liquidity pool size, token age\n- The sorting algorithm prioritizes activity (U/m) over price gains\n- Staleness decay: tokens with no updates for 5+ seconds get linearly decayed to 0 U/m over 10 seconds",
+    "observer_role": "Your job is to monitor meme token trading activity happening RIGHT NOW, creating observations about pumps, dumps, market conditions, and algorithm behavior. You are tracking the HOT POTATO GAME — which tokens have the most trading activity and whether that activity leads to real price movement.",
+    "recording_focus": "WHAT TO RECORD\n--------------\nFocus on trading signals and market behavior:\n- Pump detection: token symbol, U/m, signal tier, price gains across timeframes, buy pressure, pool size\n- Dump detection: activity collapse, negative gains, sell pressure\n- Signal transitions: FLAT→WATCH→RISING→STRONG or reverse\n- Multi-wave pumps: tokens that pump, die, then pump again\n- Market conditions: how many STRONG/RISING tokens, overall activity level\n- Algorithm quality: false positives, tokens that shouldn't be ranked high, filter gaps\n- Buy pressure ratios: buyPressure5m relative to pool liquidity (high ratio = potential whale)\n\nALWAYS INCLUDE SPECIFIC NUMBERS:\n- U/m value and signal tier\n- Price gains (1m%, 2m%, 3m%, 4m%, 5m%)\n- Buy pressure dollar amount\n- Pool liquidity\n- Token age and discovery time\n\n✅ GOOD EXAMPLES:\n- \"MEMEMAN hit 58 U/m STRONG with +82.3% 3m gain, $2.5K buy pressure on $7K pool, discovered 5 minutes ago\"\n- \"Market in deep lull: no STRONG/RISING tokens, all FLAT at 1-9 U/m, only noise-level shuffling\"\n- \"思念熊 appeared for 8th time — repeat pumper cycling FLAT→WATCH→RISING then collapsing within 3 checks\"\n\n❌ BAD EXAMPLES:\n- \"Observed token activity and recorded findings\"\n- \"Monitored market conditions and logged results\"",
+    "skip_guidance": "WHEN TO SKIP\n------------\nSkip these:\n- Routine checks with no notable changes from previous observation\n- Tokens at 1-2 U/m with 0% gains (background noise)\n- Repeat observations of the same token at the same signal tier with no meaningful metric change\n- Code file reads or edits (these are algorithm changes, not token observations)\n- **No output necessary if skipping.**",
+    "type_guidance": "**type**: MUST be EXACTLY one of these 6 options (no other values allowed):\n      - pump-detected: rapid price increase with high trading activity\n      - dump-detected: rapid price decline, sell pressure, or activity collapse\n      - signal-change: token transitioning between signal tiers (FLAT/WATCH/RISING/STRONG)\n      - token-profile: notable token characteristics, patterns, or repeat behavior\n      - market-condition: broad market state (lull, heating up, multiple pumps)\n      - algorithm-insight: observation about sorting behavior, ranking quality, or filter gaps",
+    "concept_guidance": "**concepts**: 2-5 knowledge-type categories. MUST use ONLY these exact keywords:\n      - early-detection: token caught before or during initial pump\n      - lifecycle: full pump-hold-dump cycle or multi-wave pattern\n      - false-signal: token ranked high but not actually pumping\n      - whale-activity: large buy pressure relative to pool size\n      - repeat-pumper: token cycling through multiple pump-dump waves\n      - dead-cat-bounce: brief recovery tricking the ranking\n      - sustained-momentum: high activity and gains over 5+ minutes\n\n    IMPORTANT: Do NOT include the observation type as a concept.\n    Types and concepts are separate dimensions.",
+    "field_guidance": "**facts**: Concise, self-contained statements about token activity\nEach fact is ONE piece of information\n      No pronouns - each fact must stand alone\n      ALWAYS include: token symbol, U/m, signal tier, specific gain percentages, buy pressure, pool size\n      Include timing: when discovered, how long at current tier, which check number\n\n**files**: Leave empty for token observations (no files involved)",
+    "output_format_header": "OUTPUT FORMAT\n-------------\nOutput observations using this XML structure:",
+    "format_examples": "**Token Observation Examples:**\n\n<observation>\n  <type>pump-detected</type>\n  <title>SIMULAT Reaches RISING at 36 U/m With +45.5% 3m Gain</title>\n  <subtitle>6-day-old token building sustained momentum over 5 consecutive checks since discovery at 6 U/m</subtitle>\n  <facts>\n    <fact>SIMULAT reached 36 U/m RISING signal tier at 10:33 PM</fact>\n    <fact>SIMULAT price gains: +15.3% 1m, +33.9% 2m, +45.5% 3m</fact>\n    <fact>SIMULAT buy pressure $4.8K on $4K pool (1.2:1 pressure-to-pool ratio)</fact>\n    <fact>SIMULAT first detected at 6 U/m FLAT, promoted through WATCH to RISING over 4 minutes</fact>\n  </facts>\n  <narrative>SIMULAT demonstrated the ideal early-detection pattern for the activity-first algorithm. First appearing at 6 U/m with +15% 1m gain, it steadily built activity through WATCH to RISING over 4 minutes. The 1.2:1 buy-pressure-to-pool ratio suggests concentrated buying interest. This token was surfaced 4 minutes before its biggest price move.</narrative>\n  <concepts><concept>early-detection</concept><concept>sustained-momentum</concept></concepts>\n  <files></files>\n</observation>",
+    "footer": "IMPORTANT! DO NOT do any work right now other than generating OBSERVATIONS from the token monitoring data.\n\nNever reference yourself or your own actions. Focus on what is happening in the market. Include specific numbers — U/m, gains, buy pressure, pool size — in every observation. Token observations without specific metrics are useless.\n\nThese observations help us understand which tokens pump, how the algorithm detects them, and what patterns emerge over time. Thank you!",
+
+    "xml_title_placeholder": "[Token Symbol + Key Metric Change, e.g. 'MEMEMAN Hits 58 U/m STRONG With +82% 3m Gain']",
+    "xml_subtitle_placeholder": "[One sentence with timing and context (max 24 words)]",
+    "xml_fact_placeholder": "[Token symbol + specific metric: U/m value, signal tier, gain %, buy pressure $, pool size $]",
+    "xml_narrative_placeholder": "[**narrative**: What happened, how fast, what the metrics say about the move, and what it means for the algorithm's detection quality]",
+    "xml_concept_placeholder": "[early-detection | lifecycle | false-signal | whale-activity | repeat-pumper | dead-cat-bounce | sustained-momentum]",
+    "xml_file_placeholder": "",
+
+    "xml_summary_request_placeholder": "[Short title: time range + key market events, e.g. '10:18-10:48 PM — MEMEMAN triple pump, SIMULAT +85% slow build']",
+    "xml_summary_investigated_placeholder": "[What tokens were tracked? How many checks performed? Total updates processed?]",
+    "xml_summary_learned_placeholder": "[What patterns emerged? Which token archetypes appeared? How did the algorithm perform?]",
+    "xml_summary_completed_placeholder": "[How long monitored? Key pumps detected? Algorithm changes deployed?]",
+    "xml_summary_next_steps_placeholder": "[What to watch for next? Any algorithm improvements identified?]",
+    "xml_summary_notes_placeholder": "[Market conditions, unusual patterns, algorithm edge cases observed]",
+
+    "header_memory_start": "TOKEN MONITORING START\n=======================",
+    "header_memory_continued": "TOKEN MONITORING CONTINUED\n===========================",
+    "header_summary_checkpoint": "MARKET SUMMARY CHECKPOINT\n===========================",
+
+    "continuation_greeting": "Hello memory agent, you are continuing to observe live meme token trading activity.",
+    "continuation_instruction": "IMPORTANT: Continue generating observations from token monitoring data using the XML structure below. Focus on NEW pumps, dumps, signal changes, and market shifts since your last observation.",
+
+    "summary_instruction": "Write a market summary covering: tokens that pumped, tokens that dumped, market conditions (hot vs lull periods), algorithm performance, and any patterns observed. Include specific metrics for the most notable tokens. This is a checkpoint — the monitoring session is ongoing.",
+    "summary_context_label": "Token Monitoring Data:",
+    "summary_format_instruction": "Respond in this XML format:",
+    "summary_footer": "IMPORTANT! DO NOT do any work right now other than generating this MARKET SUMMARY.\n\nNever reference yourself or your own actions. Focus on what happened in the token market. Include specific numbers. Thank you!"
+  }
+}

package/plugin/package.json

@@ -0,0 +1,45 @@
+{
+  "name": "opencode-mem-plugin",
+  "version": "13.10.2",
+  "private": true,
+  "description": "Runtime dependencies for opencode-mem bundled hooks",
+  "type": "module",
+  "dependencies": {
+    "zod": "^4.4.3",
+    "tree-sitter-cli": "^0.26.5",
+    "tree-sitter-c": "^0.24.1",
+    "tree-sitter-cpp": "^0.23.4",
+    "tree-sitter-go": "^0.25.0",
+    "tree-sitter-java": "^0.23.5",
+    "tree-sitter-javascript": "^0.25.0",
+    "tree-sitter-python": "^0.25.0",
+    "tree-sitter-ruby": "^0.23.1",
+    "tree-sitter-rust": "^0.24.0",
+    "tree-sitter-typescript": "^0.23.2",
+    "tree-sitter-kotlin": "^0.3.8",
+    "tree-sitter-swift": "^0.7.1",
+    "tree-sitter-php": "^0.24.2",
+    "@tree-sitter-grammars/tree-sitter-lua": "^0.4.1",
+    "tree-sitter-scala": "^0.24.0",
+    "tree-sitter-bash": "^0.25.1",
+    "tree-sitter-haskell": "^0.23.1",
+    "@tree-sitter-grammars/tree-sitter-zig": "^1.1.2",
+    "tree-sitter-css": "^0.25.0",
+    "tree-sitter-scss": "^1.0.0",
+    "@tree-sitter-grammars/tree-sitter-toml": "^0.7.0",
+    "@tree-sitter-grammars/tree-sitter-yaml": "^0.7.1",
+    "@derekstride/tree-sitter-sql": "^0.3.11",
+    "@tree-sitter-grammars/tree-sitter-markdown": "^0.3.2",
+    "shell-quote": "^1.8.3"
+  },
+  "overrides": {
+    "tree-sitter": "^0.25.0"
+  },
+  "trustedDependencies": [
+    "tree-sitter-cli"
+  ],
+  "engines": {
+    "node": ">=20.12.0",
+    "bun": ">=1.0.0"
+  }
+}

package/plugin/scripts/bun-runner.js

@@ -0,0 +1,238 @@
+#!/usr/bin/env node
+import { spawnSync, spawn } from 'child_process';
+import { existsSync, readFileSync, mkdirSync, appendFileSync, writeFileSync } from 'fs';
+import { join, dirname, resolve } from 'path';
+import { homedir } from 'os';
+import { fileURLToPath } from 'url';
+
+const IS_WINDOWS = process.platform === 'win32';
+
+const __bun_runner_dirname = dirname(fileURLToPath(import.meta.url));
+const RESOLVED_PLUGIN_ROOT = process.env.CLAUDE_PLUGIN_ROOT || resolve(__bun_runner_dirname, '..');
+
+function fixBrokenScriptPath(argPath) {
+  if (argPath.startsWith('/scripts/') && !existsSync(argPath)) {
+    const fixedPath = join(RESOLVED_PLUGIN_ROOT, argPath);
+    if (existsSync(fixedPath)) {
+      return fixedPath;
+    }
+  }
+  return argPath;
+}
+
+function findBun() {
+  const pathCheck = IS_WINDOWS
+    ? spawnSync('where', ['bun'], {
+        encoding: 'utf-8',
+        stdio: ['pipe', 'pipe', 'pipe'],
+        windowsHide: true
+      })
+    : spawnSync('which', ['bun'], {
+        encoding: 'utf-8',
+        stdio: ['pipe', 'pipe', 'pipe']
+      });
+
+  if (pathCheck.status === 0 && pathCheck.stdout.trim()) {
+    if (IS_WINDOWS) {
+      const bunCmdPath = pathCheck.stdout.split('\n').find(line => line.trim().endsWith('bun.cmd'));
+      if (bunCmdPath) {
+        return bunCmdPath.trim();
+      }
+    }
+    return 'bun'; 
+  }
+
+  const bunPaths = IS_WINDOWS
+    ? [join(homedir(), '.bun', 'bin', 'bun.exe')]
+    : [
+        join(homedir(), '.bun', 'bin', 'bun'),
+        '/usr/local/bin/bun',
+        '/opt/homebrew/bin/bun',
+        '/home/linuxbrew/.linuxbrew/bin/bun'
+      ];
+
+  for (const bunPath of bunPaths) {
+    if (existsSync(bunPath)) {
+      return bunPath;
+    }
+  }
+
+  return null;
+}
+
+function isPluginDisabledInClaudeSettings() {
+  try {
+    const configDir = process.env.CLAUDE_CONFIG_DIR || join(homedir(), '.claude');
+    const settingsPath = join(configDir, 'settings.json');
+    if (!existsSync(settingsPath)) return false;
+    const settings = JSON.parse(readFileSync(settingsPath, 'utf-8'));
+    // No optional chaining (?.) here: this launcher must parse on the oldest
+    // Node that any host might invoke it with. Some Claude Code installs run
+    // hooks under a bundled pre-ES2020 Node whose ESM loader throws
+    // "SyntaxError: Unexpected token '.'" on `?.` (issue #2791).
+    return Boolean(
+      settings &&
+      settings.enabledPlugins &&
+      settings.enabledPlugins['opencode-mem@thedotmack'] === false
+    );
+  } catch {
+    return false;
+  }
+}
+
+if (isPluginDisabledInClaudeSettings()) {
+  process.exit(0);
+}
+
+const args = process.argv.slice(2);
+
+if (args.length === 0) {
+  console.error('Usage: node bun-runner.js <script> [args...]');
+  process.exit(1);
+}
+
+args[0] = fixBrokenScriptPath(args[0]);
+
+const bunPath = findBun();
+
+if (!bunPath) {
+  console.error('Error: Bun not found. Please install Bun: https://bun.sh');
+  console.error('After installation, restart your terminal.');
+  process.exit(1);
+}
+
+function collectStdin() {
+  return new Promise((resolve) => {
+    if (process.stdin.isTTY) {
+      resolve(null);
+      return;
+    }
+
+    const chunks = [];
+    process.stdin.on('data', (chunk) => chunks.push(chunk));
+    process.stdin.on('end', () => {
+      resolve(chunks.length > 0 ? Buffer.concat(chunks) : null);
+    });
+    process.stdin.on('error', () => {
+      resolve(null);
+    });
+
+    setTimeout(() => {
+      process.stdin.removeAllListeners();
+      process.stdin.pause();
+      resolve(chunks.length > 0 ? Buffer.concat(chunks) : null);
+    }, 5000);
+  });
+}
+
+const stdinData = await collectStdin();
+
+const spawnOptions = {
+  stdio: ['pipe', 'inherit', 'inherit'],
+  windowsHide: true,
+  env: process.env
+};
+
+let spawnCmd = bunPath;
+let spawnArgs = args;
+
+if (IS_WINDOWS) {
+  const quote = (s) => `"${String(s).replace(/"/g, '\\"')}"`;
+  spawnOptions.shell = true;
+  spawnCmd = [bunPath, ...args].map(quote).join(' ');
+  spawnArgs = [];
+}
+
+const child = spawn(spawnCmd, spawnArgs, spawnOptions);
+
+if (child.stdin) {
+  if (stdinData && stdinData.length > 0) {
+    child.stdin.write(stdinData);
+    child.stdin.end();
+  } else {
+    // Lifecycle subcommands (start, stop, restart, status) never consume stdin —
+    // they manage the worker daemon, not hook payloads.  Killing the child here
+    // prevents the daemon from starting/stopping on platforms where Claude Code
+    // doesn't pipe a payload for SessionStart (e.g. Windows CC ≤ 2.1.145).
+    const lifecycleCommands = ['start', 'stop', 'restart', 'status'];
+    const isLifecycle = lifecycleCommands.some(cmd => args.includes(cmd));
+
+    if (isLifecycle) {
+      // Lifecycle commands don't need stdin — close pipe and let child run.
+      try { child.stdin.end(); } catch {}
+    } else {
+      // Issue #2188: empty/missing stdin previously masked by `|| '{}'` fallback,
+      // which silently hid WSL bash failures (e.g. hooks invoked under a broken
+      // shell that never piped a payload). Surface the failure mode instead.
+      const dataDir = process.env.OPENCODE_MEM_DATA_DIR || join(homedir(), '.opencode-mem');
+      const payloadType = stdinData === null
+        ? 'null (no data event or stream error)'
+        : stdinData === undefined
+          ? 'undefined'
+          : Buffer.isBuffer(stdinData) && stdinData.length === 0
+            ? 'empty Buffer (zero bytes received)'
+            : `unexpected (${typeof stdinData})`;
+      const payloadByteLength = (stdinData && typeof stdinData.length === 'number')
+        ? stdinData.length
+        : 0;
+      const diagnostic = [
+        `[bun-runner] empty stdin payload received — issue #2188`,
+        `  script: ${args[0]}`,
+        `  payload byte length: ${payloadByteLength}`,
+        `  payload type: ${payloadType}`,
+        `  platform: ${process.platform}`,
+        `  shell: ${process.env.SHELL || 'n/a'}`,
+        `  stdin TTY: ${process.stdin.isTTY === true ? 'true' : process.stdin.isTTY === false ? 'false' : 'undefined'}`,
+        `  timestamp: ${new Date().toISOString()}`,
+        `  CLAUDE_PLUGIN_ROOT: ${RESOLVED_PLUGIN_ROOT}`,
+      ].join('\n');
+
+      // IO discipline (see src/shared/hook-io.ts intent vocabulary):
+      // - this stderr write is a USER_HINT (Claude Code surfaces it inline).
+      // - the CAPTURE_BROKEN marker file below is a DIAGNOSTIC durable signal for
+      //   the next session-start hint.
+      // - exit 0 below is the EXIT_SIGNAL per CLAUDE.md (Windows Terminal tab
+      //   management); the marker file, not the exit code, is the durable failure
+      //   signal. bun-runner runs in its own node process BEFORE hookCommand's
+      //   stderr buffer is installed, so this write is never swallowed.
+
+      // Write to stderr so Claude Code surfaces the diagnostic.
+      console.error(diagnostic);
+
+      // Persist diagnostic to the runner-errors log and drop a CAPTURE_BROKEN marker
+      // file so the next session-start hint can surface the failure. We exit 0 to
+      // honor the project's exit-code strategy (worker/hook errors exit 0 to
+      // prevent Windows Terminal tab pileup) — the marker file is the durable
+      // signal that something is wrong, not the exit code.
+      try {
+        const logsDir = join(dataDir, 'logs');
+        mkdirSync(logsDir, { recursive: true });
+        appendFileSync(join(logsDir, 'runner-errors.log'), diagnostic + '\n\n');
+        mkdirSync(dataDir, { recursive: true });
+        writeFileSync(join(dataDir, 'CAPTURE_BROKEN'), diagnostic + '\n');
+      } catch (writeErr) {
+        console.error(`[bun-runner] failed to persist diagnostic: ${writeErr && writeErr.message ? writeErr.message : writeErr}`);
+      }
+
+      try { child.stdin.end(); } catch {}
+      try { child.kill(); } catch {}
+      process.exit(0);
+    }
+  }
+}
+
+child.on('error', (err) => {
+  // EXCEPTION to CLAUDE.md exit-0-on-error: Bun-not-found is a user environment
+  // problem, not a hook execution failure. Surfacing exit 1 here forces Claude
+  // Code to display the stderr message rather than silently retrying. This runs
+  // before any hook handler, so the exit-0 tab-management rationale doesn't apply.
+  console.error(`Failed to start Bun: ${err.message}`);
+  process.exit(1);
+});
+
+child.on('close', (code, signal) => {
+  if ((signal || code > 128) && args.includes('start')) {
+    process.exit(0);
+  }
+  process.exit(code || 0);
+});