purecontext-mcp 1.1.1 → 1.1.2

package/docs/dev/PHASE8_TASKS.md

@@ -1,299 +0,0 @@
-# Phase 8 — Task Breakdown
-
-**Goal**: Implement a token savings tracker that measures and reports how many tokens PureContext saves compared to reading raw files. This provides tangible value metrics for users and enables cost-aware decision-making.
-
-**Scope rationale**: Token efficiency is the core value proposition of PureContext — agents retrieve precisely the code they need instead of entire files. Phase 8 makes this value visible and measurable. The implementation mirrors jCodeMunch's approach (which has proven effective in production) but is adapted for PureContext's TypeScript architecture and SQLite storage.
-
-**Approach**: Tasks are sequenced to build the foundation first (storage and estimation), then integrate tracking into each tool, and finally add reporting capabilities.
-
----
-
-## Task 70: Token Tracker Core
-
-Implement the core token tracking infrastructure: persistent storage, estimation logic, and cost calculations.
-
-**Deliverables:**
-
-- `src/core/token-tracker.ts`
-  - `BYTES_PER_TOKEN = 4` — rough but consistent approximation (cl100k_base encoding)
-  - `estimateSavings(rawBytes: number, responseBytes: number): number`
-    - Returns `Math.max(0, Math.floor((rawBytes - responseBytes) / BYTES_PER_TOKEN))`
-    - Never returns negative values
-  - `recordSavings(tokensSaved: number): number`
-    - Adds to the running total
-    - Returns the new cumulative total
-    - Uses an in-memory accumulator with periodic disk flush (every 5 calls)
-  - `getTotalSaved(): number`
-    - Returns current cumulative total without modifying it
-  - `costAvoided(tokensSaved: number, totalTokensSaved: number): CostEstimates`
-    - Returns cost estimates based on model pricing tiers:
-      ```typescript
-      interface CostEstimates {
-        cost_avoided: Record<string, number>;      // This call
-        total_cost_avoided: Record<string, number>; // Cumulative
-      }
-      ```
-    - Pricing tiers (USD per million input tokens):
-      - `claude_opus_4`: $15.00
-      - `claude_sonnet_4`: $3.00
-      - `claude_haiku_4`: $0.80
-      - `gpt4o`: $2.50
-      - `gpt4o_mini`: $0.15
-    - Values rounded to 4 decimal places
-
-- `src/core/db/savings-store.ts`
-  - Storage file: `~/.purecontext/_savings.json`
-  - Schema:
-    ```json
-    {
-      "total_tokens_saved": 123456,
-      "anon_id": "uuid-v4",
-      "last_updated": "2026-04-14T10:30:00Z"
-    }
-    ```
-  - `loadSavings(): SavingsData`
-  - `saveSavings(data: SavingsData): void`
-  - File created on first save if it doesn't exist
-  - Uses atomic write (write to temp file, then rename)
-
-- In-memory state management:
-  - `_State` class holds:
-    - `total: number` — cumulative total (disk + unflushed)
-    - `unflushed: number` — delta not yet written to disk
-    - `callCount: number` — calls since last flush
-    - `loaded: boolean` — whether disk state has been loaded
-  - Lazy loading: disk state loaded on first `recordSavings()` or `getTotalSaved()` call
-  - Flush triggers:
-    - Every 5 calls (`FLUSH_INTERVAL = 5`)
-    - On process exit (`process.on('exit')`)
-    - On SIGTERM/SIGINT (graceful shutdown)
-
-**Key technical notes:**
-- The in-memory accumulator avoids disk I/O on every tool call — critical for performance
-- SIGTERM handling is important because MCP servers are commonly killed via pipe close
-- The `anon_id` field is reserved for optional future telemetry (not implemented in Phase 8)
-- Token estimation is deliberately simple (bytes/4) — matches jCodeMunch and is consistent
-
-**Verify:** Call `recordSavings(1000)` five times. Verify file is created after fifth call. Kill process with SIGTERM, restart, verify total persists. Verify `costAvoided()` returns correct USD values for various token counts.
-
-**Tests:** `estimateSavings`: raw > response (positive), raw < response (zero, not negative), raw == response (zero). `recordSavings`: accumulation, flush trigger at interval. `costAvoided`: verify arithmetic for each pricing tier. Persistence: write, kill process, reload, verify total.
-
----
-
-## Task 71: Integrate Token Tracking into Retrieval Tools
-
-Add token savings tracking to all tools that retrieve symbol or file content.
-
-**Deliverables:**
-
-- Update `src/server/tools/get-symbol-source.ts`:
-  - Before returning response:
-    1. Calculate `rawBytes`: file size of the source file (from `files` table or `fs.statSync`)
-    2. Calculate `responseBytes`: `symbol.endByte - symbol.startByte`
-    3. Call `estimateSavings(rawBytes, responseBytes)`
-    4. Call `recordSavings(tokensSaved)`
-    5. Add to response `_meta`:
-       ```json
-       {
-         "tokens_saved": 1234,
-         "total_tokens_saved": 56789,
-         "cost_avoided": { "claude_opus_4": 0.0185, ... },
-         "total_cost_avoided": { "claude_opus_4": 0.8518, ... }
-       }
-       ```
-
-- Update `src/server/tools/search-symbols.ts`:
-  - For each returned symbol:
-    - Accumulate `rawBytes` from unique files containing results
-    - Accumulate `responseBytes` from symbol byte lengths
-  - Calculate aggregate savings across all results
-  - Add `_meta` fields as above
-
-- Update `src/server/tools/get-file-outline.ts`:
-  - `rawBytes`: full file size
-  - `responseBytes`: sum of all symbol signatures + metadata (not full source)
-  - Lower savings ratio expected (outlines are compact)
-
-- Update `src/server/tools/get-context-bundle.ts`:
-  - `rawBytes`: sum of all files that would need to be read for full context
-  - `responseBytes`: actual bundle size (symbol + imports)
-
-- Update `src/server/tools/find-importers.ts` and `src/server/tools/get-blast-radius.ts`:
-  - `rawBytes`: sum of all files in the traversal
-  - `responseBytes`: actual response JSON size
-
-**Key technical notes:**
-- File size lookup should use cached values from the `files` table when available
-- For multi-symbol responses, deduplicate file sizes (same file counted once even if multiple symbols from it)
-- `responseBytes` calculation varies by tool — some return source, some return metadata only
-
-**Verify:** Call `get-symbol-source` → verify `_meta.tokens_saved` is positive and plausible. Call `search-symbols` with 5 results → verify aggregate savings. Verify `total_tokens_saved` increases across multiple calls.
-
-**Tests:** Per-tool: mock file sizes and symbol ranges, verify correct savings calculation. Multi-symbol deduplication: two symbols from same file, file size counted once. Cumulative total: multiple tool calls, verify running total increases.
-
----
-
-## Task 72: Token Savings Statistics Tool
-
-Add a dedicated tool for querying token savings statistics.
-
-**Deliverables:**
-
-- `src/server/tools/get-savings-stats.ts`
-  - Tool name: `get-savings-stats`
-  - Input schema:
-    ```json
-    {
-      "reset": { "type": "boolean", "default": false, "description": "Reset the counter to zero" }
-    }
-    ```
-  - Output:
-    ```json
-    {
-      "total_tokens_saved": 123456,
-      "equivalent_context_windows": {
-        "claude_200k": 0.62,
-        "gpt4_128k": 0.96
-      },
-      "total_cost_avoided": {
-        "claude_opus_4": 1.8518,
-        "claude_sonnet_4": 0.3704,
-        "claude_haiku_4": 0.0988,
-        "gpt4o": 0.3086,
-        "gpt4o_mini": 0.0185
-      },
-      "session_start": "2026-04-14T08:00:00Z",
-      "_meta": {
-        "powered_by": "PureContext MCP"
-      }
-    }
-    ```
-  - `equivalent_context_windows`: tokens saved divided by model context window sizes
-    - Claude 200k: 200,000 tokens
-    - GPT-4 128k: 128,000 tokens
-  - If `reset: true`: clear the counter, return `{ "reset": true, "previous_total": 123456 }`
-  - Register in `src/server/mcp-server.ts`
-
-- Update `src/core/token-tracker.ts`:
-  - Add `resetSavings(): number`
-    - Returns the previous total
-    - Resets in-memory and disk state to zero
-  - Add `getSessionStart(): Date`
-    - Returns timestamp when the current session started (first `recordSavings()` call)
-    - Stored in `_savings.json` as `session_start`
-
-**Key technical notes:**
-- The reset functionality is useful for starting fresh tracking sessions
-- Context window equivalents give users an intuitive sense of scale
-- Session start timestamp helps contextualize the savings (per-session vs all-time)
-
-**Verify:** After multiple tool calls, run `get-savings-stats` → verify total matches accumulated savings. Run with `reset: true` → verify counter resets. Make more calls → verify new accumulation starts from zero.
-
-**Tests:** Stats retrieval: mock accumulated total, verify output fields. Reset: verify previous total returned, verify new calls start from zero. Context window calculations: verify arithmetic.
-
----
-
-## Task 73: Response Envelope Enhancement
-
-Standardize the `_meta` envelope across all tools to include consistent token tracking fields.
-
-**Deliverables:**
-
-- `src/server/tools/_meta.ts`
-  - `buildMeta(options: MetaOptions): MetaEnvelope`
-    ```typescript
-    interface MetaOptions {
-      timingMs: number;
-      rawBytes?: number;
-      responseBytes?: number;
-      // ... other tool-specific fields
-    }
-
-    interface MetaEnvelope {
-      timing_ms: number;
-      tokens_saved?: number;
-      total_tokens_saved?: number;
-      cost_avoided?: Record<string, number>;
-      total_cost_avoided?: Record<string, number>;
-      powered_by: string;
-    }
-    ```
-  - Automatically calculates and records savings when `rawBytes` and `responseBytes` are provided
-  - Adds `powered_by: 'PureContext MCP'` to every response
-
-- Update all tool handlers to use `buildMeta()`:
-  - `get-symbol-source.ts`
-  - `search-symbols.ts`
-  - `get-file-outline.ts`
-  - `get-repo-outline.ts`
-  - `get-context-bundle.ts`
-  - `find-importers.ts`
-  - `get-blast-radius.ts`
-  - `search-text.ts`
-  - `get-file-tree.ts`
-  - `index-folder.ts` (no savings — indexing generates, doesn't retrieve)
-  - `list-repos.ts` (no savings — metadata only)
-
-- Tools that don't retrieve content (indexing, listing) should still use `buildMeta()` for consistent `timing_ms` and `powered_by` fields, but omit savings fields.
-
-**Key technical notes:**
-- Centralizing meta construction ensures consistency and reduces duplication
-- The `powered_by` field provides attribution in tool responses
-- Savings fields are optional — tools that don't retrieve content omit them
-
-**Verify:** Run each tool, verify all responses have consistent `_meta` structure. Verify retrieval tools include savings fields. Verify non-retrieval tools omit savings but include timing.
-
-**Tests:** `buildMeta` with savings: verify all fields present. `buildMeta` without savings: verify savings fields absent. Verify `powered_by` always present.
-
----
-
-## Task 74: Phase 8 Integration Tests
-
-Validate the complete token tracking pipeline end-to-end.
-
-**Deliverables:**
-
-- Integration tests `test/integration/phase8.test.ts`:
-  1. Index a fixture project, call `get-symbol-source` for a symbol → verify `tokens_saved > 0`
-  2. Verify `tokens_saved` calculation: `(fileSize - symbolByteLength) / 4` matches returned value
-  3. Call `search-symbols`, retrieve 5 results → verify aggregate savings across results
-  4. Call `get-file-outline` → verify savings reflect outline vs full file
-  5. Make 10 tool calls, call `get-savings-stats` → verify `total_tokens_saved` equals sum of individual calls
-  6. Call `get-savings-stats` with `reset: true` → verify reset works
-  7. Kill process (SIGTERM simulation), restart, verify savings persisted
-  8. Verify `cost_avoided` arithmetic: `tokens_saved * (rate / 1_000_000)` for each tier
-  9. Verify `equivalent_context_windows` arithmetic
-  10. Full suite regression: all Phase 1–7 tests still green
-
-- Performance verification:
-  - Token tracking overhead: < 1ms per tool call
-  - Disk flush: < 5ms (atomic write to small JSON file)
-  - Memory overhead: < 1KB for in-memory state
-
-**Verify:** `npm run test` passes entirely — all Phase 1–8 tests green. Token tracking adds negligible overhead to tool response times.
-
----
-
-## Order of Execution
-
-```
-Task 70: Token tracker core                ███░░░░░░░ Foundation
-Task 71: Integrate into retrieval tools    ██████░░░░ Integration
-Task 72: Savings statistics tool           ████████░░ Tool
-Task 73: Response envelope enhancement     █████████░ Standardization
-Task 74: Integration tests                 ██████████ Polish
-```
-
-Tasks proceed in order: core infrastructure (70) must be complete before integration (71), which must be complete before the stats tool (72). Task 73 can begin after Task 71 is complete. Task 74 validates everything.
-
----
-
-## Post-Phase 8: What Comes Next
-
-Phase 8 establishes token efficiency as a measurable, visible feature. Future phases continue expanding PureContext capabilities:
-
-- **Phase 9**: Additional language handlers (Elixir, Haskell, Scala, R)
-- **Phase 10**: Additional framework adapters (Spring, Hibernate, SQLAlchemy, Django ORM, Rust/Java web frameworks)
-- **Phase 11**: Semantic search (HNSW) for repos with > 50k symbols
-- **Phase 12**: Rate limiting and multi-tenant auth for hosted deployments
-- **Phase 13**: Web UI for exploring the symbol graph visually

package/docs/dev/PHASE9_TASKS.md

@@ -1,320 +0,0 @@
-# Phase 9 — Task Breakdown
-
-**Goal**: Expand language coverage to Elixir, Haskell, Scala, and R — completing PureContext's coverage of popular functional and statistical languages. Each language has a distinct syntax and paradigm, requiring careful handler implementation.
-
-**Scope rationale**: These four languages represent important niches: Elixir (Erlang VM, Phoenix framework), Haskell (pure functional, type theory), Scala (JVM functional-OOP hybrid, big data), and R (statistical computing, data science). Adding them broadens PureContext's applicability to functional programming and data science teams.
-
-**Approach**: Tasks are sequenced by complexity: Elixir and Scala have more familiar syntax, while Haskell's type system and R's syntax require more care. Each handler is independent and can be developed in parallel.
-
----
-
-## Task 75: Elixir Language Handler
-
-Add Elixir as a new language handler. Elixir's macro system and module-based architecture map cleanly to PureContext's symbol model.
-
-**Deliverables:**
-
-- Download and bundle `grammars/tree-sitter-elixir.wasm`
-  - Source: `tree-sitter-elixir` npm package
-  - Build: `npx tree-sitter build-wasm node_modules/tree-sitter-elixir`
-
-- `src/handlers/elixir.ts` — implements `LanguageHandler`
-  - `extensions()`: `['.ex', '.exs']`
-  - `grammarPath()`: path to `tree-sitter-elixir.wasm`
-  - `extractSymbols(tree, source)`:
-    - `call` with identifier `defmodule` → kind `'class'` (modules as classes)
-    - `call` with identifier `def` → kind `'function'` (public function)
-    - `call` with identifier `defp` → skip (private function)
-    - `call` with identifier `defmacro` → kind `'function'` with `frameworkMeta.elixir_macro: true`
-    - `call` with identifier `defmacrop` → skip (private macro)
-    - `call` with identifier `defstruct` → kind `'type'`
-    - `call` with identifier `defprotocol` → kind `'interface'`
-    - `call` with identifier `defimpl` → kind `'class'` with `frameworkMeta.elixir_impl: true`
-    - `@callback` attribute → kind `'method'` (behaviour callback)
-    - `@type` attribute → kind `'type'`
-    - `@spec` attribute → capture as signature for the following function
-    - Module attributes with `@moduledoc` or `@doc` → capture as docstring
-  - `extractImports(tree, source)`:
-    - `alias` directive: `alias Foo.Bar` → specifier = `Foo.Bar`
-    - `import` directive: `import Foo.Bar` → specifier = `Foo.Bar`
-    - `use` directive: `use GenServer` → specifier = `GenServer`
-    - `require` directive: `require Logger` → specifier = `Logger`
-    - `resolvedPath`: `null` (Elixir module resolution is external)
-    - `isTypeOnly`: `false`
-  - `extractDocstring(node)`:
-    - Look for `@doc` attribute preceding function definition
-    - Look for `@moduledoc` attribute at module start
-    - Strip heredoc syntax (`"""`) and leading whitespace
-
-**Signature building:**
-- Modules: `defmodule ModuleName`
-- Functions: `def name(params) :: return_type` (from `@spec` if present)
-- Functions without spec: `def name(params)` (with arity)
-- Macros: `defmacro name(params)`
-- Protocols: `defprotocol Name`
-- Structs: `defstruct [:field1, :field2, ...]`
-- Keep signatures under 120 chars
-
-**Key technical notes:**
-- Elixir's `defmodule` creates nested scopes — qualify function names with module path
-- Pattern matching in function heads creates multiple function clauses — emit one symbol per head, not per clause
-- Guards (`when guard`) should be included in the signature
-- Elixir's `@spec` type annotations provide rich signature information
-- `.ex` files are compiled code; `.exs` files are scripts (both indexed)
-
-**Verify:** Index `test/fixtures/elixir-project/`. Verify modules, public functions, macros, protocols, and structs extracted. Verify private functions (`defp`) are skipped. Verify `@doc` captured as docstring.
-
-**Tests:** `defmodule`, `def` (public), `defp` (skipped), `defmacro`, `defstruct`, `defprotocol`, `defimpl`, `alias/import/use/require`, `@doc` docstring, function with `@spec`, function with guards.
-
----
-
-## Task 76: Haskell Language Handler
-
-Add Haskell as a new language handler. Haskell's pure functional paradigm and advanced type system require special attention to type signatures and typeclass instances.
-
-**Deliverables:**
-
-- Download and bundle `grammars/tree-sitter-haskell.wasm`
-  - Source: `tree-sitter-haskell` npm package
-  - Build: `npx tree-sitter build-wasm node_modules/tree-sitter-haskell`
-  - Note: Haskell grammar is complex; verify parsing of common constructs before proceeding
-
-- `src/handlers/haskell.ts` — implements `LanguageHandler`
-  - `extensions()`: `['.hs', '.lhs']`
-  - `grammarPath()`: path to `tree-sitter-haskell.wasm`
-  - `extractSymbols(tree, source)`:
-    - `function` node (top-level binding) → kind `'function'`
-    - `signature` node (type signature) → associate with following function
-    - `type_synonym` (`type X = Y`) → kind `'type'`
-    - `newtype` declaration → kind `'type'`
-    - `data` declaration → kind `'class'` (algebraic data type)
-    - `class` declaration (typeclass) → kind `'interface'`
-    - `instance` declaration → kind `'class'` with `frameworkMeta.haskell_instance: true`
-    - Data constructors within `data` → kind `'const'`
-    - Record fields within `data` → kind `'const'`
-    - Pattern bindings (`x = value`) → kind `'const'`
-    - Skip functions/bindings in `where` clauses (local scope)
-  - `extractImports(tree, source)`:
-    - `import` declaration: `import Data.List`, `import qualified Data.Map as M`
-    - `importedNames`: extract from `import Data.List (sort, nub)`
-    - `isTypeOnly`: `false` (Haskell doesn't distinguish)
-    - Handle `qualified`, `hiding`, and `as` modifiers
-  - `extractDocstring(node)`:
-    - Haddock documentation: `-- |` or `{- | ... -}` preceding declarations
-    - Also `-- ^` for argument documentation
-    - Strip comment markers and leading whitespace
-
-**Signature building:**
-- Functions with signature: `functionName :: Type -> Type -> ReturnType`
-- Functions without signature: `functionName arg1 arg2 = ...` (pattern from definition)
-- Data types: `data TypeName = Constructor1 | Constructor2`
-- Newtypes: `newtype Name = Name WrappedType`
-- Type synonyms: `type Name = ExistingType`
-- Typeclasses: `class ClassName a where`
-- Instances: `instance ClassName Type where`
-- Keep signatures under 120 chars; truncate complex types
-
-**Key technical notes:**
-- Haskell type signatures are separate from function definitions — correlate by name
-- Multiple equations for the same function (pattern matching) → emit one symbol, use first equation's position
-- Typeclass instances are important for navigation — include the type being instanced
-- Literate Haskell (`.lhs`) uses `>` prefix for code lines — strip before parsing
-- GADTs and type families are advanced features — basic extraction sufficient for Phase 9
-
-**Verify:** Index `test/fixtures/haskell-project/`. Verify functions with type signatures extracted. Verify `data`, `newtype`, `type` declarations. Verify typeclass and instances. Verify Haddock comments captured.
-
-**Tests:** Function with signature, function without signature, `data` with constructors, `newtype`, `type` synonym, `class` declaration, `instance` declaration, `import` qualified, Haddock `-- |` comment, `.lhs` literate file.
-
----
-
-## Task 77: Scala Language Handler
-
-Add Scala as a new language handler. Scala's hybrid OOP-FP paradigm on the JVM makes it popular for big data (Spark) and backend services.
-
-**Deliverables:**
-
-- Download and bundle `grammars/tree-sitter-scala.wasm`
-  - Source: `tree-sitter-scala` npm package
-  - Build: `npx tree-sitter build-wasm node_modules/tree-sitter-scala`
-
-- `src/handlers/scala.ts` — implements `LanguageHandler`
-  - `extensions()`: `['.scala', '.sc']`
-  - `grammarPath()`: path to `tree-sitter-scala.wasm`
-  - `extractSymbols(tree, source)`:
-    - `class_definition` → kind `'class'`
-    - `trait_definition` → kind `'interface'`
-    - `object_definition` → kind `'class'` with `frameworkMeta.scala_object: true`
-    - `case_class_definition` → kind `'class'` with `frameworkMeta.scala_case_class: true`
-    - `function_definition` (top-level or in object) → kind `'function'`
-    - `function_definition` in class/trait → kind `'method'`
-    - `val_definition` at top-level or in object → kind `'const'`
-    - `type_definition` → kind `'type'`
-    - `enum_definition` (Scala 3) → kind `'enum'`
-    - `given_definition` (Scala 3 implicits) → kind `'const'` with `frameworkMeta.scala_given: true`
-    - `extension_definition` (Scala 3) → kind `'class'` with `frameworkMeta.scala_extension: true`
-    - Skip `private` and `protected` without `[package]` qualifier
-  - `extractImports(tree, source)`:
-    - `import_declaration`: `import scala.collection.mutable._`
-    - Handle Scala's `{ A, B => C }` renaming syntax
-    - `isTypeOnly`: `false`
-  - `extractDocstring(node)`:
-    - Scaladoc: `/** ... */` preceding declarations
-    - Strip `*` prefixes and `@param`, `@return` tags for summary
-
-**Signature building:**
-- Functions: `def name(params: Types): ReturnType`
-- Classes: `class Name(params) extends Parent with Trait`
-- Case classes: `case class Name(field: Type, ...)`
-- Objects: `object Name extends Trait`
-- Traits: `trait Name extends Parent`
-- Types: `type Name = Alias` or `type Name[A] <: Upper`
-- Implicit/given: `given name: Type = ...`
-- Keep signatures under 120 chars
-
-**Key technical notes:**
-- Scala 2 and Scala 3 syntax differ significantly — handle both
-- `object` declarations are singletons, not classes — special metadata
-- Case classes are immutable data containers — primary constructor in signature
-- Scala's implicit parameters and givens are important for API understanding
-- Companion objects (same name as class) are common — don't deduplicate
-
-**Verify:** Index `test/fixtures/scala-project/`. Verify classes, traits, objects, case classes extracted. Verify methods distinguished from functions. Verify Scala 3 `enum`, `given`, `extension` extracted.
-
-**Tests:** `class`, `trait`, `object`, `case class`, `def` method, `def` function, `val`, `type`, `enum` (Scala 3), `given` (Scala 3), `extension` (Scala 3), `import` with renaming, Scaladoc comment, `private` method (skipped).
-
----
-
-## Task 78: R Language Handler
-
-Add R as a new language handler. R's syntax for statistical computing is unique but maps to the symbol model with appropriate handling.
-
-**Deliverables:**
-
-- Download and bundle `grammars/tree-sitter-r.wasm`
-  - Source: `tree-sitter-r` npm package
-  - Build: `npx tree-sitter build-wasm node_modules/tree-sitter-r`
-
-- `src/handlers/r.ts` — implements `LanguageHandler`
-  - `extensions()`: `['.r', '.R', '.Rmd']` (note: R is case-sensitive on some systems)
-  - `grammarPath()`: path to `tree-sitter-r.wasm`
-  - `extractSymbols(tree, source)`:
-    - `left_assignment` where RHS is `function(...)` → kind `'function'`
-      - Pattern: `name <- function(args) { ... }`
-    - `right_assignment` where LHS is `function(...)` → kind `'function'`
-      - Pattern: `function(args) { ... } -> name`
-    - `equals_assignment` where RHS is `function(...)` → kind `'function'`
-      - Pattern: `name = function(args) { ... }`
-    - `left_assignment` / `equals_assignment` with non-function RHS → kind `'const'`
-    - S3 method: function named `generic.class` → kind `'method'`
-    - S4 class: `setClass("ClassName", ...)` call → kind `'class'`
-    - S4 method: `setMethod("generic", ...)` call → kind `'method'`
-    - R6 class: `R6Class("ClassName", ...)` call → kind `'class'`
-    - Skip local function assignments (inside other functions)
-  - `extractImports(tree, source)`:
-    - `library(package)` and `require(package)` calls → specifier = package name
-    - `import::from(package, func1, func2)` → specifier = package, importedNames = [func1, func2]
-    - `::` namespace access in code (e.g., `dplyr::filter`) → log but don't emit import record
-    - `source("file.R")` → specifier = file path (local file import)
-  - `extractDocstring(node)`:
-    - Roxygen2 comments: `#'` prefix lines preceding function
-    - Strip `#' ` prefix, capture `@title`, `@description`, and first paragraph
-
-**Signature building:**
-- Functions: `name <- function(arg1, arg2 = default)` (preserve defaults)
-- S3 methods: `generic.class <- function(x, ...)`
-- S4 classes: `setClass("ClassName", slots = c(...))`
-- Constants: `NAME <- value` (truncate value if long)
-- Keep signatures under 120 chars
-
-**Key technical notes:**
-- R uses `<-` for assignment more than `=` (convention)
-- Function names with `.` are S3 methods if they match `generic.class` pattern
-- R's lazy evaluation means default argument expressions can be complex
-- `.Rmd` files are R Markdown — extract R code chunks only
-- R packages use NAMESPACE files for exports — out of scope for handler, extract all top-level
-
-**Verify:** Index `test/fixtures/r-project/`. Verify functions with `<-`, `=`, and `->` assignment extracted. Verify S3 methods detected. Verify `library()` imports captured. Verify Roxygen2 comments captured.
-
-**Tests:** `<-` function, `=` function, `->` function (rare but valid), constant assignment, S3 method (`print.myclass`), `library()` import, `require()` import, Roxygen2 `#'` comment, nested function (skipped), `.Rmd` code chunk.
-
----
-
-## Task 79: Phase 9 Test Fixtures and Integration Tests
-
-Validate all four new language handlers end-to-end.
-
-**Deliverables:**
-
-- `test/fixtures/elixir-project/` — representative Elixir project:
-  - `lib/my_app.ex` — main module with functions
-  - `lib/my_app/user.ex` — struct definition
-  - `lib/my_app/repo.ex` — behaviour and callbacks
-  - `lib/my_app/macros.ex` — macro definitions
-  - `test/my_app_test.exs` — test file
-  - `mix.exs` — project config
-
-- `test/fixtures/haskell-project/` — representative Haskell project:
-  - `src/Main.hs` — main module with functions and types
-  - `src/Types.hs` — data types and newtypes
-  - `src/Typeclass.hs` — typeclass definition and instances
-  - `app/Main.hs` — executable entry point
-  - `stack.yaml` or `cabal.project` — project config
-
-- `test/fixtures/scala-project/` — representative Scala project:
-  - `src/main/scala/Main.scala` — object with main method
-  - `src/main/scala/models/User.scala` — case class
-  - `src/main/scala/services/UserService.scala` — class with methods
-  - `src/main/scala/traits/Repository.scala` — trait definition
-  - `build.sbt` — project config
-
-- `test/fixtures/r-project/` — representative R project:
-  - `R/functions.R` — function definitions
-  - `R/classes.R` — S3/S4/R6 classes
-  - `R/utils.R` — utility functions with Roxygen2 docs
-  - `inst/examples/example.R` — example script
-  - `DESCRIPTION` — package config
-
-- Integration tests `test/integration/phase9.test.ts`:
-  1. Elixir: `defmodule` extracted as class
-  2. Elixir: `def` extracted, `defp` skipped
-  3. Elixir: `@doc` captured as docstring
-  4. Elixir: `alias`, `import`, `use` captured as imports
-  5. Haskell: function with type signature extracted
-  6. Haskell: `data` type with constructors
-  7. Haskell: `class` and `instance` declarations
-  8. Haskell: Haddock `-- |` captured
-  9. Scala: `class`, `object`, `trait` extracted
-  10. Scala: `case class` with scala_case_class metadata
-  11. Scala: Scala 3 `enum` and `given` (if grammar supports)
-  12. R: function with `<-` assignment
-  13. R: S3 method detection (`print.myclass`)
-  14. R: `library()` captured as import
-  15. R: Roxygen2 `#'` captured
-  16. Full suite regression: all Phase 1–8 tests still green
-
-**Verify:** `npm run test` passes entirely — all Phase 1–9 tests green. Verify token tracking works correctly for new language handlers.
-
----
-
-## Order of Execution
-
-```
-Task 75: Elixir language handler           ██░░░░░░░░ Languages
-Task 76: Haskell language handler          ████░░░░░░ Languages
-Task 77: Scala language handler            ██████░░░░ Languages
-Task 78: R language handler                ████████░░ Languages
-Task 79: Fixtures + integration tests      ██████████ Polish
-```
-
-Tasks 75–78 are fully independent and can be developed in parallel. Task 79 validates everything once all handlers are complete.
-
----
-
-## Post-Phase 9: What Comes Next
-
-Phase 9 completes PureContext's language expansion to 18 languages. Future phases add framework adapters and advanced features:
-
-- **Phase 10**: Additional framework adapters (Spring, Hibernate, SQLAlchemy, Django ORM, Axum, Actix-web, Rocket, Spring Boot, Micronaut, Quarkus)
-- **Phase 11**: Semantic search (HNSW) for repos with > 50k symbols
-- **Phase 12**: Rate limiting and multi-tenant auth for hosted deployments
-- **Phase 13**: Web UI for exploring the symbol graph visually