@codeyam/codeyam-cli 0.1.0-staging.1669d45 → 0.1.0-staging.2a88920

package/codeyam-cli/templates/codeyam:memory.md

@@ -0,0 +1,341 @@
+---
+name: codeyam:memory
+autoApprove: true
+description: |
+  Generate and maintain Claude Rules for your codebase based on thorough analysis.
+  Use when: User wants to set up memory, claude rules, document confusing areas, 
+  or ensure Claude has proper context for working in the codebase.
+---
+
+# CodeYam Memory Assistant
+
+This skill helps you generate and maintain Claude Rules (`.claude/rules/`) that provide context-specific guidance. The goal is robust coverage of anything confusing while avoiding documentation of things Claude can intuit.
+
+## When to Use This Skill
+
+- Initial setup: User asks to "set up memory" or "generate claude rules"
+- Maintenance: After completing complex work where lessons should be preserved
+- Review: Periodically to ensure rules are accurate and up-to-date
+
+---
+
+## Phase 1: Setup (First Run Only)
+
+Check if this is the first time running memory.
+
+### 1A. Add Documentation Section to CLAUDE.md
+
+If CLAUDE.md doesn't contain a "When Confused / With Mistakes" section, add close to the top:
+
+```markdown
+## When Confused / With Mistakes: Stop. Ask. Document.
+
+- If you are not sure about something stop and ask about it.
+- If you attempt something and it goes wrong then you are confused. Stop and ask about it.
+- If the user is unable to help. Do your best to research.
+- Then document the findings!
+
+### Documenting Confusion / Mistakes
+
+It is very important to document any confusion or mistakes you encounter in Claude Rules (`.claude/rules`).
+Please see `.codeyam/rules/instructions.md` for guidance.
+
+After making any code changes please run `codeyam memory status` and follow the instructions.
+```
+
+### 1B. Verify Instructions File
+
+Check that `.codeyam/rules/instructions.md` exists (it should be created during `codeyam init`). If missing, copy it from `codeyam-cli/templates/rules-instructions.md`.
+
+### 1C. Install Pre-commit Hook
+
+Check if the project uses Husky (`.husky/` directory exists).
+
+**If using Husky**, append to `.husky/pre-commit`:
+
+```bash
+# CodeYam Memory Up-To-Date Check
+if [ -f ".codeyam/bin/memory-hook.sh" ]; then
+  .codeyam/bin/memory-hook.sh
+fi
+```
+
+**If not using Husky**, create or append to `.git/hooks/pre-commit`.
+
+Ensure `.codeyam/bin/memory-hook.sh` exists and is executable (`chmod +x`).
+
+---
+
+## Phase 2: Deep Codebase Analysis
+
+Perform thorough analysis to identify areas that may be confusing. The goal is to find everything that might trip up someone (or Claude) working in this codebase.
+
+### 2A. Analyze Git Commit Messages for Problem Signals
+
+Look for commits indicating gotchas, workarounds, or complexity:
+
+```bash
+# Find commits with problem-indicating keywords
+git log --oneline --since="6 months ago" --grep="fix" --grep="bug" --grep="workaround" --grep="hack" --grep="revert" --grep="oops" --grep="forgot" --grep="actually" --all-match | head -30
+
+# Find commits with long messages (indicate complex changes)
+git log --since="6 months ago" --format="%h %s" | awk 'length($0) > 80' | head -20
+
+# Find reverted commits
+git log --oneline --since="6 months ago" --grep="revert" -i | head -10
+```
+
+For interesting commits, examine the full message and changes:
+
+```bash
+git show <commit-hash> --stat
+git log -1 --format="%B" <commit-hash>
+```
+
+### 2B. Identify Files with High Churn or Complexity Signals
+
+```bash
+# Files changed most frequently (last 6 months)
+git log --since="6 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -30
+
+# Files with many different authors (tribal knowledge risk)
+git shortlog -sn --since="6 months ago" -- . | head -20
+
+# Files frequently modified together (hidden dependencies)
+git log --since="6 months ago" --name-only --pretty=format: | awk '/^$/{if(NR>1)print "---"}; /./{print}' | head -100
+```
+
+Look for patterns where the same 2-3 files appear together repeatedly.
+
+### 2C. Scan for Developer Notes in Code
+
+```bash
+# Find TODO, FIXME, HACK, XXX, NOTE comments
+grep -rn "TODO\|FIXME\|HACK\|XXX\|NOTE:" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.py" --include="*.rb" --include="*.go" --include="*.java" --include="*.rs" . 2>/dev/null | head -50
+
+# Find "workaround" or "hack" mentions in comments
+grep -rni "workaround\|hack\|temporary\|legacy" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.py" . 2>/dev/null | head -30
+```
+
+### 2D. Analyze Project Structure
+
+```bash
+# Get directory structure (2 levels deep)
+find . -type d -maxdepth 3 | grep -v node_modules | grep -v .git | grep -v dist | grep -v build | head -50
+
+# Find config files
+find . -name "*.config.*" -o -name "*.rc" -o -name ".env*" -o -name "tsconfig*" -o -name "package.json" 2>/dev/null | grep -v node_modules | head -30
+
+# Find test directories
+find . -type d -name "*test*" -o -type d -name "*spec*" -o -type d -name "__tests__" 2>/dev/null | grep -v node_modules | head -20
+```
+
+### 2E. Check for Environment and Configuration Complexity
+
+```bash
+# Find environment variable references
+grep -rn "process.env\|os.environ\|ENV\[" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.py" . 2>/dev/null | head -30
+
+# Find multiple config files that might conflict or confuse
+ls -la *.config.* .*.rc tsconfig*.json 2>/dev/null
+```
+
+### 2F. Review Existing Documentation
+
+Read these files if they exist:
+
+- `README.md`
+- `CLAUDE.md`
+- `CONTRIBUTING.md`
+- `docs/` directory
+- Any `*.md` files in the root
+
+Note what's already documented and what gaps exist.
+
+### 2G. Examine Import/Dependency Patterns
+
+```bash
+# Find files with many imports (high coupling)
+for f in $(find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" 2>/dev/null | grep -v node_modules | head -100); do
+  count=$(grep -c "^import\|^from\|require(" "$f" 2>/dev/null || echo 0)
+  if [ "$count" -gt 15 ]; then
+    echo "$count $f"
+  fi
+done | sort -rn | head -20
+
+# Find commonly imported local modules (core utilities)
+grep -rh "from '\.\|from \"\.\|require('\.\|require(\"\." --include="*.ts" --include="*.tsx" --include="*.js" . 2>/dev/null | sort | uniq -c | sort -rn | head -20
+```
+
+---
+
+## Phase 3: Cluster and Prioritize Findings
+
+After gathering signals, organize them by area/module:
+
+1. **Group findings by directory** - Which parts of the codebase have the most signals?
+2. **Identify themes**:
+   - Architecture patterns (how things connect)
+   - Testing complexity (special setup needed)
+   - Configuration/environment gotchas
+   - Historical workarounds still in place
+   - Non-obvious conventions
+
+3. **Score areas** - More signals = higher priority for documentation
+
+Create a mental map of:
+
+- Which directories/modules are most complex?
+- What relationships exist between different parts?
+- Where are the gotchas hiding?
+
+---
+
+## Phase 4: Ask Specific Questions
+
+Based on your analysis, ask the user specific questions about the actual findings. Reference the concrete evidence you found (file names, commit messages, code patterns) and ask about the substance.
+
+Always include "I'm not sure - please investigate" as an option so users can delegate investigation to you.
+
+### Question Format
+
+Ask about the **specific finding**, not the file generally:
+
+**For high-churn files with concerning commits:**
+
+> "ScopeDataStructure.ts has commits mentioning 'exponential blowup' and 'execution flows'. What causes this blowup? When does it happen?"
+>
+> Options: [Explain the cause] [I'm not sure - please investigate]
+
+**For files frequently modified together:**
+
+> "`src/api/auth.ts` and `src/middleware/session.ts` are modified together in 12 commits. Why do these need to change together?"
+>
+> Options: [Explain the relationship] [I'm not sure - please investigate]
+
+**For commits with workaround language:**
+
+> "Commit `abc123` says 'workaround for webpack issue'. What's the underlying issue and what's the workaround?"
+>
+> Options: [Explain] [I'm not sure - please investigate]
+
+**For multiple config files:**
+
+> "There are 3 tsconfig files. When is each one used?"
+>
+> Options: [Explain usage] [I'm not sure - please investigate]
+
+**For TODO/FIXME comments:**
+
+> "There's a FIXME in `src/parser.ts:142` about 'handle nested callbacks'. What's the issue with nested callbacks here?"
+>
+> Options: [Explain] [I'm not sure - please investigate]
+
+**For test organization:**
+
+> "Tests are split between `__tests__/` folders and colocated `*.test.ts` files. When should each approach be used?"
+>
+> Options: [Explain convention] [I'm not sure - please investigate]
+
+### Process
+
+1. Group related questions by area/module
+2. Ask 2-3 questions at a time, wait for answers
+3. If user says "I'm not sure - please investigate":
+   - Read the relevant code, commits, and context yourself
+   - Analyze the patterns and behavior
+   - Document your findings based on what you discover
+4. Move to next area after capturing answers
+
+---
+
+## Phase 5: Generate Rules
+
+For each area where you have enough information, create a rule file.
+
+### Rule File Guidelines:
+
+1. **Location mirrors code structure**
+   - Rule for `src/api/` → `.claude/rules/src/api/architecture.md`
+   - Rule for testing patterns → `.claude/rules/testing-patterns.md`
+
+2. **Paths must be specific**
+   - Good: `paths: ['src/api/**/*.ts']`
+   - Bad: `paths: ['**/*.ts']` (too broad, wastes context)
+
+3. **Content should be actionable**
+   - Focus on "how to" and "what to know"
+   - Avoid warnings unless truly critical
+   - Be concise - every word costs context
+
+4. **Timestamp must be current**
+   - Use ISO 8601 format: `2026-01-27T15:30:00Z`
+   - This enables the pre-commit hook enforcement
+
+### Rule Template:
+
+```markdown
+---
+paths:
+  - 'specific/path/**/*.ts'
+category: architecture | testing | faq
+timestamp: [CURRENT_ISO_TIMESTAMP]
+---
+
+## [Clear, Descriptive Title]
+
+[Concise explanation of what this covers]
+
+### [Section as appropriate]
+
+[Specific, actionable content]
+```
+
+---
+
+## Phase 6: Final Review
+
+After generating rules based on your analysis and user answers:
+
+1. **Present a summary** of all rules created
+2. **Ask the user:**
+
+   > "I've created rules covering [list areas]. Are there any other areas of the codebase that you know are confusing or have tribal knowledge that I might have missed?"
+
+3. **Generate any additional rules** based on their response
+
+4. **Suggest viewing rules in the dashboard:**
+
+   > "Run `codeyam` to open the dashboard and view all rules in the Rules tab."
+
+5. **Remind the user** to commit the new rules:
+   ```
+   git add .claude/rules/ .codeyam/rules/
+   git commit -m "Add rules for Claude Code (generated via /codeyam:memory)"
+   ```
+
+---
+
+## Ongoing Maintenance
+
+### When Claude Should Update Rules
+
+- After fixing a bug that revealed a gotcha
+- After making an architectural decision
+- When code patterns change
+- When asking "why does this work this way?" and learning the answer
+- When receiving clarification from the user about any confusion
+
+### Pre-commit Hook Behavior
+
+The pre-commit hook **blocks commits** when:
+
+- Code files matching a rule's `paths` are modified
+- The rule's `timestamp` is older than the code changes
+
+To proceed:
+
+1. Review the flagged rule(s)
+2. Update content if needed
+3. Update the `timestamp` to current time
+4. Stage and commit

package/codeyam-cli/templates/codeyam:new-rule.md

@@ -0,0 +1,13 @@
+---
+name: codeyam:new-rule
+autoApprove: true
+description: |
+  Create a new Claude Rule for documenting codebase patterns.
+  Use when: User wants to add documentation for a specific area of the codebase.
+---
+
+# Create New Claude Rule
+
+Read `.codeyam/rules/instructions.md` for guidance on how to create and structure a new rule.
+
+If the instructions file doesn't exist, copy it from `codeyam-cli/templates/rules-instructions.md`.

package/codeyam-cli/templates/rule-reflection-hook.py

@@ -0,0 +1,160 @@
+#!/usr/bin/env python3
+"""
+Rule reflection hook for Claude Code.
+
+Reads the session transcript to find new conversation since last check,
+then prompts Claude to consider rule updates if there was substantive content.
+"""
+
+import json
+import sys
+from pathlib import Path
+
+MIN_USER_TURNS = 5  # Fire after N user turns
+
+def main():
+    # Read hook input from stdin
+    try:
+        hook_input = json.load(sys.stdin)
+    except json.JSONDecodeError:
+        # No valid input, exit silently
+        return
+
+    session_id = hook_input.get('session_id', '')
+    transcript_path = hook_input.get('transcript_path', '')
+    stop_hook_active = hook_input.get('stop_hook_active', False)
+
+    # Prevent infinite loops - if we're already in a stop hook continuation, exit silently
+    if stop_hook_active:
+        return
+
+    if not session_id or not transcript_path:
+        return
+
+    # Marker file tracks last checked line per session
+    marker_dir = Path('/tmp/claude-rule-markers')
+    marker_dir.mkdir(exist_ok=True)
+    marker_file = marker_dir / f'{session_id}.marker'
+
+    # Read last checked line
+    last_line = 0
+    if marker_file.exists():
+        try:
+            last_line = int(marker_file.read_text().strip())
+        except (ValueError, IOError):
+            last_line = 0
+
+    # Read transcript and get new lines
+    try:
+        with open(transcript_path, 'r') as f:
+            all_lines = f.readlines()
+    except IOError:
+        return
+
+    current_line_count = len(all_lines)
+    new_lines = all_lines[last_line:]
+
+    if not new_lines:
+        return
+
+    # Count user turns and extract conversation content from new lines
+    user_turn_count = 0
+    conversation_snippets = []
+
+    for line in new_lines:
+        try:
+            obj = json.loads(line)
+            msg_type = obj.get('type')
+
+            if msg_type not in ('user', 'assistant'):
+                continue
+
+            message = obj.get('message', {})
+            content = message.get('content', '')
+            is_external_user = msg_type == 'user' and obj.get('userType') == 'external'
+
+            # Handle string content
+            if isinstance(content, str):
+                # Skip meta messages and very short content
+                if obj.get('isMeta') or len(content) < 20:
+                    continue
+                # Skip tool results (they show up as user messages)
+                if content.startswith('[{') or '<tool_result' in content:
+                    continue
+
+                # Count substantive user turns
+                if is_external_user and not content.startswith('<'):
+                    user_turn_count += 1
+
+                conversation_snippets.append({
+                    'role': message.get('role', msg_type),
+                    'content': content[:500]  # Truncate long messages
+                })
+
+            # Handle array content (tool calls, etc.)
+            elif isinstance(content, list):
+                for item in content:
+                    if isinstance(item, dict):
+                        if item.get('type') == 'text':
+                            text = item.get('text', '')
+                            if len(text) > 20:
+                                conversation_snippets.append({
+                                    'role': message.get('role', msg_type),
+                                    'content': text[:500]
+                                })
+        except (json.JSONDecodeError, KeyError):
+            continue
+
+    # Only fire after enough user turns
+    if user_turn_count < MIN_USER_TURNS:
+        return
+
+    # Update marker with current line count
+    marker_file.write_text(str(current_line_count))
+
+    # If not enough substantive conversation, exit silently
+    if len(conversation_snippets) < 3:
+        return
+
+    # Build a summary of the recent conversation for the rule check
+    summary_lines = []
+    for snippet in conversation_snippets[-15:]:  # Last 15 messages
+        role = snippet['role']
+        content = snippet['content'].replace('\n', ' ')[:300]
+        summary_lines.append(f"[{role}]: {content}")
+
+    summary = '\n'.join(summary_lines)
+
+    # Write detailed context to a file (keeps displayed output short)
+    context_file = marker_dir / f'{session_id}.context'
+    context = f"""Recent conversation to review for rule-worthy learnings:
+
+{summary}
+
+---
+Guidelines:
+- Did Claude get confused during this session in any way?
+- How exactly did it get confused and what information would have resolved that confusion. No additional detail is needed especially if it is something that Claude likely already knows.
+- Only update rules for patterns of confusion that will likely recur in future sessions.
+- Document knowledge not easily evident from code
+    - Locations of tests
+    - Commands that can be run that are relevant to the task at hand
+    - Architectural design, where to look for, fix, or add certain things
+- Do not document bugs being fixed as they will likely be resolved.
+- Issues that are abandoned as known issues can be noted.
+- Keep rules concise (<50 lines), use bullets/tables where appropriate.
+- Clean up, summarize, and delete existing rules as needed.
+- If no changes are needed, just say "No rule updates needed."
+"""
+    context_file.write_text(context)
+
+    # Output blocking decision - just trigger background agent
+    # Keep reason minimal since main agent will spawn background worker
+    output = {
+        "decision": "block",
+        "reason": f"RULE_CHECK:{context_file}"
+    }
+    print(json.dumps(output))
+
+if __name__ == '__main__':
+    main()

package/codeyam-cli/templates/rules-instructions.md

@@ -0,0 +1,93 @@
+# Claude Rules Guide
+
+Rules provide context-specific guidance when working in files matching their `paths` patterns.
+
+## Core Principles
+
+1. **One concept per rule** - Each rule should cover a single topic. If you're documenting two unrelated things, create two rules.
+2. **Paths must match content scope** - A rule about one specific file should have that file in `paths`, not a broad `**/*.ts` pattern.
+3. **Be concise** - Every word costs context. Use bullets and tables.
+
+## When to Create a New Rule
+
+Create a new rule when:
+
+- You learn something non-obvious about the codebase
+- You make a mistake and want to prevent it in the future
+- The user explains something that isn't clear from the code
+- An existing rule is covering multiple unrelated topics (split it)
+
+## Path Specificity
+
+The `paths` field controls when the rule is shown. Match the scope of your content:
+
+| Content Scope | Path Pattern            | Example                                                |
+| ------------- | ----------------------- | ------------------------------------------------------ |
+| Single file   | `'path/to/file.ts'`     | Rule about `processExpression.ts` specifically         |
+| Related files | `'path/to/feature*.ts'` | Rule about `generateExecutionFlows*.ts` files          |
+| Directory     | `'path/to/dir/**/*.ts'` | Rule about the queue system in `utils/queue/`          |
+| Cross-cutting | Multiple specific paths | Testing rule with paths to test configs and test files |
+
+**Anti-pattern**: Don't use `'**/*.ts'` for a rule about one specific feature.
+
+## File Structure
+
+Rules mirror the source code structure:
+
+| Source Location      | Rule Location                           |
+| -------------------- | --------------------------------------- |
+| `src/api/auth.ts`    | `.claude/rules/src/api/auth.md`         |
+| `src/utils/queue/**` | `.claude/rules/src/utils/queue.md`      |
+| Test configuration   | `.claude/rules/testing/jest-configs.md` |
+
+## Required Frontmatter
+
+```yaml
+---
+paths:
+  - 'specific/path/to/file.ts'
+  - 'another/specific/path/*.ts'
+category: architecture | testing | faq
+timestamp: 2026-01-30T00:00:00Z
+---
+```
+
+| Field       | Purpose                                                                                            |
+| ----------- | -------------------------------------------------------------------------------------------------- |
+| `paths`     | Glob patterns - be specific to avoid loading rules unnecessarily                                   |
+| `category`  | `architecture` (design/data flow), `testing` (test commands/patterns), `faq` (gotchas/workarounds) |
+| `timestamp` | ISO 8601 - update when rule is reviewed                                                            |
+
+## Content Guidelines
+
+### Be Actionable
+
+- Good: "Run `pnpm test:api` for API tests"
+- Bad: "Make sure to run the appropriate tests"
+
+### Focus on What, Not What Not
+
+- Good: "Auth tokens are stored in httpOnly cookies via `src/auth/cookies.ts`"
+- Bad: "WARNING: Don't store tokens in localStorage!"
+
+### Keep Rules Short
+
+- Target 30-50 lines
+- If a rule exceeds 60 lines, consider splitting it
+
+## Categories
+
+**architecture** - Design decisions, file relationships, data flow
+
+- "These three files must change together because..."
+- "Data flows from X → Y → Z"
+
+**testing** - Test commands, mock patterns, fixtures
+
+- "Run tests with: `pnpm test path/to/test.ts`"
+- "Must run `pnpm pretest` first because..."
+
+**faq** - Gotchas, workarounds, common questions
+
+- "If you see error X, it means Y"
+- "This looks wrong but is intentional because..."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codeyam/codeyam-cli",
-  "version": "0.1.0-staging.1669d45",
+  "version": "0.1.0-staging.2a88920",
   "description": "Local development CLI for CodeYam analysis",
   "type": "module",
   "bin": {
@@ -14,8 +14,8 @@
     "@anthropic-ai/sdk": "^0.71.0",
     "@aws-sdk/client-dynamodb": "^3.956.0",
     "@aws-sdk/s3-request-presigner": "^3.940.0",
-    "@aws-sdk/util-dynamodb": "^3.902.0",
-    "@modelcontextprotocol/sdk": "^1.25.2",
+    "@aws-sdk/util-dynamodb": "^3.971.0",
+    "@modelcontextprotocol/sdk": "^1.25.3",
     "@octokit/auth-app": "^8.1.0",
     "@octokit/request": "^10.0.3",
     "@octokit/rest": "^22.0.0",
@@ -27,7 +27,7 @@
     "better-sqlite3": "^12.4.1",
     "chalk": "^5.6.2",
     "chokidar": "^4.0.3",
-    "cli-spinners": "^3.3.0",
+    "cli-spinners": "^3.4.0",
     "domhandler": "^5.0.3",
     "dotenv": "^17.2.3",
     "express": "^5.2.1",
@@ -41,20 +41,23 @@
     "kysely": "^0.28.5",
     "lru-cache": "^11.2.4",
     "lucide-react": "^0.556.0",
+    "minimatch": "^10.0.1",
     "openai": "^6.16.0",
     "p-queue": "^8.1.0",
     "p-retry": "^7.1.1",
     "pg": "^8.16.3",
     "piscina": "^5.1.4",
     "pixelmatch": "^5.3.0",
-    "playwright": "^1.56.1",
+    "playwright": "1.58.0",
     "pluralize": "^8.0.0",
     "prompts": "^2.4.2",
     "react": "^19.2.3",
     "react-diff-viewer-continued": "^4.0.6",
     "react-dom": "^19.2.3",
+    "react-markdown": "^10.1.0",
     "react-resizable": "^3.0.5",
     "react-syntax-highlighter": "^15.6.1",
+    "remark-gfm": "^4.0.1",
     "sharp": "^0.34.5",
     "simple-git": "^3.28.0",
     "typescript": "^5.9.3",

package/packages/ai/index.js

@@ -26,19 +26,23 @@ export { default as describeCodeChange } from "./src/lib/describeCodeChange.js";
 export { default as validateTypeStructure } from "./src/lib/validateTypeStructure.js";
 export { default as validateDataStructure } from "./src/lib/validateDataStructure.js";
 export { default as isolateScopes } from "./src/lib/isolateScopes.js";
-export { default as analyzeScope } from "./src/lib/analyzeScope.js";
+export { default as analyzeScope, destroyWorkerPool, } from "./src/lib/analyzeScope.js";
 export { default as logOrderedMap } from "./src/lib/logOrderedMap.js";
 export { default as splitOutsideParentheses, splitOutsideParenthesesAndArrays, joinParenthesesAndArrays, functionArguments, } from "./src/lib/splitOutsideParentheses.js";
 export { cleanKnownObjectFunctionsFromMapping } from "./src/lib/dataStructure/helpers/cleanKnownObjectFunctions.js";
 export { clearAttributesFromMapping, removeDuplicateFunctionCalls, } from "./src/lib/dataStructure/helpers/cleanNonObjectFunctions.js";
 export { default as convertDotNotation } from "./src/lib/dataStructure/helpers/convertDotNotation.js";
+export { default as convertTypeAnnotationsToValues } from "./src/lib/dataStructure/helpers/convertTypeAnnotationsToValues.js";
 export { default as cleanOutBoundary } from "./src/lib/cleanOutBoundary.js";
-export { fillInDirectSchemaGapsAndUnknowns } from "./src/lib/dataStructure/helpers/fillInSchemaGapsAndUnknowns.js";
+export { fillInDirectSchemaGapsAndUnknowns, buildSchemaIndexes, } from "./src/lib/dataStructure/helpers/fillInSchemaGapsAndUnknowns.js";
 export { default as deduplicateFunctionSchemas } from "./src/lib/dataStructure/helpers/deduplicateFunctionSchemas.js";
 export { default as getConditionalUsagesFromCode } from "./src/lib/getConditionalUsagesFromCode.js";
-export { getExternalFunctionCallInfo, getFunctionSignature, getReturnValue, getUsageEquivalencies, getSourceEquivalencies, getEquivalentSignatureVariables, getConditionalUsages, getConditionalEffects, getCompoundConditionals, getChildBoundaryGatingConditions, } from "./src/lib/worker/SerializableDataStructure.js";
+export { getExternalFunctionCallInfo, getFunctionSignature, getReturnValue, getUsageEquivalencies, getSourceEquivalencies, getEquivalentSignatureVariables, getConditionalUsages, getConditionalEffects, getCompoundConditionals, getChildBoundaryGatingConditions, getJsxRenderingUsages, } from "./src/lib/worker/SerializableDataStructure.js";
 export { parseJsonSafe } from "./src/lib/parsers/parseJsonSafe.js";
 export { default as completionCall } from "./src/lib/completionCall.js";
+// NOTE: E2E data tracking utilities (e2eDataTracking.ts) are NOT exported here
+// because they use Node.js 'crypto' module which breaks browser builds.
+// Import directly from "../../packages/ai/src/lib/e2eDataTracking.js" when needed in Node.js tests.
 // Wrapper detection
 export { default as detectWrapperRequirements } from "./src/lib/wrapperDetection/detectWrapperRequirements.js";
 export { KNOWN_LIBRARY_HOOKS } from "./src/lib/wrapperDetection/knownLibraryHooks.js";