purecontext-mcp 1.1.8 → 1.2.0

package/VISUALIZING-CODE.md

@@ -0,0 +1,199 @@
+# Visualizing Code Structure
+
+Reading code is one way to understand structure. Seeing it is faster.
+
+PureContext can generate diagrams of your codebase — import graphs, call graphs, class hierarchies, and dependency matrices — directly from the indexed symbol data. The output is Mermaid or DOT format: Mermaid renders natively in GitHub, VS Code, Claude, and most documentation tools; DOT feeds Graphviz.
+
+---
+
+## Import graphs: understanding module structure at a glance
+
+The most common architectural question is also the simplest: *what imports what?*
+
+**Scenario:** You're about to refactor the authentication module. Before you touch anything, you want to see how the auth files relate to each other and what the rest of the codebase is connected to.
+
+> "Generate a diagram of the import relationships in src/auth/."
+
+```
+render_import_graph(repoId, filePath: "src/auth/", maxNodes: 20) →
+
+  ```mermaid
+  graph TD
+    subgraph auth
+      A[auth.ts] --> B[validator.ts]
+      A --> C[session.ts]
+      B --> D[crypto.ts]
+      C --> E[db/session-store.ts]
+    end
+    F[api/routes/login.ts] --> A
+    G[api/middleware/auth-guard.ts] --> A
+    H[workers/session-cleanup.ts] --> C
+  ```
+```
+
+Paste this into any Mermaid renderer and you see the auth module's external surface immediately: two API files import the main `auth.ts`, one worker imports `session.ts` directly. The validator and session modules are internal to auth.
+
+**Whole-repo import graph (scoped to top-level directories):**
+
+```
+render_diagram(repoId, type: "module", maxNodes: 15, maxDepth: 2) →
+  [diagram showing how src/api, src/core, src/db, src/workers relate]
+```
+
+Use `maxNodes` to keep the diagram readable. A 300-file codebase doesn't need 300 nodes — 15–30 representative files gives you the architectural skeleton.
+
+---
+
+## Call graphs: tracing execution paths visually
+
+A call graph shows the actual runtime flow: when function A runs, what does it call, and what do those call?
+
+**Scenario:** You're debugging an intermittent timeout. Requests to `/api/orders` are slow. You want to see the full execution path visually.
+
+> "Draw the call graph for the processOrder function, 3 levels deep."
+
+```
+render_call_graph(repoId, symbolId: "processOrder-id", direction: "callees", maxDepth: 3) →
+
+  ```mermaid
+  flowchart TD
+    ROOT["processOrder()"]:::root
+    ROOT --> A["validateCart()"]
+    ROOT --> B["calculateTax()"]
+    ROOT --> C["chargePayment()"]
+    A --> D["checkInventory()"]
+    A --> E["applyDiscounts()"]
+    B --> F["fetchTaxRates()"]
+    C --> G["callPaymentGateway()"]
+    C -.->|cyclic| C
+    classDef root fill:#f0a500
+  ```
+```
+
+The orange root node is `processOrder`. The dashed self-arrow on `chargePayment` — marked `cyclic` — indicates a retry loop. `callPaymentGateway` is the leaf that makes the external call. That's your timeout candidate.
+
+**Bidirectional view — callers and callees:**
+
+```
+render_call_graph(repoId, symbolId: "sendEmail-id", direction: "both") →
+  [callers above the root, callees below]
+```
+
+---
+
+## Class hierarchy diagrams: visualizing inheritance
+
+For codebases with significant inheritance — frameworks, plugin systems, ORM models — seeing the hierarchy visually is far faster than tracing it through source files.
+
+**Scenario:** You're onboarding a new developer to the project. They need to understand the controller hierarchy before they can write a new endpoint.
+
+> "Generate a class diagram of the controller hierarchy."
+
+```
+render_class_hierarchy(repoId, symbolId: "BaseController-id", direction: "descendants") →
+
+  ```mermaid
+  classDiagram
+    BaseController <|-- AuthenticatedController
+    BaseController <|-- PublicController
+    AuthenticatedController <|-- UserController
+    AuthenticatedController <|-- AdminController
+    AuthenticatedController <|-- ApiController
+    ApiController <|-- RestApiController
+    ApiController <|-- GraphQLController
+    PublicController <|-- LandingController
+  ```
+```
+
+This goes straight into the architecture documentation. The diagram is generated from the live code — not hand-drawn — so it's always accurate.
+
+---
+
+## Dependency matrices: finding coupling hotspots
+
+A dependency matrix shows the same information as an import graph but in table form. It's better for spotting dense coupling between specific files.
+
+**Scenario:** You have a suspicion that certain modules in `src/core/` are too tightly coupled to each other. You want to see the exact coupling pattern.
+
+> "Show me the dependency matrix for the 8 most coupled files in src/core/."
+
+```
+render_dep_matrix(repoId, filePath: "src/core/", topN: 8) →
+
+               auth  billing  events  models  session  utils  crypto  db
+  auth            —       1       0       1        1      1       1    1
+  billing         0       —       1       1        0      1       0    1
+  events          1       1       —       0        1      1       0    0
+  models          0       0       0       —        0      0       0    1
+  session         1       0       1       1        —      1       0    1
+  utils           0       0       0       0        0      —       0    0
+  crypto          0       0       0       0        0      1       —    0
+  db              0       0       0       0        0      0       0    —
+```
+
+Cell `[row][col] = 1` means the row file imports the column file. You can immediately see that `auth`, `events`, and `session` form a triangle of mutual imports — a strong signal of circular dependency. `utils` imports nothing (it's a pure leaf), confirming it's safe to change. `models` only imports `db` — appropriately isolated.
+
+---
+
+## Architecture snapshots: tracking structural change over time
+
+The tools above show you the current state. Architecture snapshots let you compare state across time — before and after a refactoring, between a feature branch and main.
+
+**Scenario:** Your team spent three weeks breaking circular dependencies and reducing coupling. You want to prove the improvement with data.
+
+> "Create a snapshot of the architecture before we start the refactoring sprint."
+
+```
+get_architecture_snapshot(repoId, action: "create", label: "before-dec-sprint") →
+  { snapshotId: "snap_a1b2c3", label: "before-dec-sprint", createdAt: "..." }
+```
+
+[Three weeks and a re-index later]
+
+> "Create another snapshot and compare it to the one from before the sprint."
+
+```
+get_architecture_snapshot(repoId, action: "create", label: "after-dec-sprint") →
+  { snapshotId: "snap_d4e5f6" }
+
+get_architecture_snapshot(repoId, action: "diff",
+  snapshotId: "snap_a1b2c3", compareId: "snap_d4e5f6") →
+
+  Structural change (after vs before):
+
+  fileCount:      +12         (12 new files created during extraction)
+  symbolCount:    +34         (more focused, smaller functions)
+  edgeCount:      -41         (fewer total imports — less coupling)
+  cycleCount:     -7          (7 circular deps eliminated)
+  avgCoupling:    3.4 → 2.1  (modules are less interconnected)
+  avgComplexity:  4.8 → 3.9  (simpler on average)
+```
+
+Fewer edges, fewer cycles, lower coupling, lower complexity. This is the before-and-after you show in the sprint retrospective.
+
+**Use snapshots for PR review too:**
+
+```
+1. Index main → get_architecture_snapshot(action: "create", label: "main")
+2. Index feature branch → get_architecture_snapshot(action: "create", label: "pr-42")
+3. diff the two snapshots to see the structural impact of the PR
+```
+
+---
+
+## Choosing the right diagram
+
+| Question | Tool |
+|----------|------|
+| How are the files in this directory connected? | `render_import_graph` |
+| What does this function call at runtime? | `render_call_graph` |
+| What extends/implements this class? | `render_class_hierarchy` |
+| Which files are most tightly coupled? | `render_dep_matrix` |
+| I want a single diagram — call, class, or module | `render_diagram` (general-purpose) |
+| Did this PR improve or worsen the architecture? | `get_architecture_snapshot` + diff |
+
+All tools support `format: "dot"` if you prefer Graphviz output for more powerful layout options.
+
+---
+
+→ Reference: [MCP Tools Reference](docs/06-tools-reference.md) — `render_diagram`, `render_call_graph`, `render_import_graph`, `render_class_hierarchy`, `render_dep_matrix`, `get_architecture_snapshot`

package/WORKFLOW-TECH-DEBT.md

@@ -0,0 +1,286 @@
+# Workflow: Running a Tech Debt Review Sprint
+
+**Scenario:** It's the start of a new quarter. Your team has been shipping features for six months and the codebase has drifted. You have two weeks set aside for a technical debt sprint. You need to figure out what to work on, prioritize it, execute it safely, and prove the improvement.
+
+This workflow shows how PureContext turns a vague "debt sprint" into a structured, measurable campaign.
+
+---
+
+## Phase 1: Assess — what are we dealing with?
+
+Before writing any code, get a complete picture of the codebase's health.
+
+**You:** "Before we start the sprint, give me a full health assessment of the codebase."
+
+**Claude** runs `health_radar`:
+
+```
+Health Radar — before Q2 sprint
+
+complexity       58   ██████████░░░░░░░░░░  Warning
+coupling         44   ████████░░░░░░░░░░░░  Poor
+maintainability  71   ██████████████░░░░░░  Fair
+documentation    31   ██████░░░░░░░░░░░░░░  Poor
+stability        62   ████████████░░░░░░░░  Fair
+
+Overall Health:  53   Grade: D
+```
+
+Not good. Coupling and documentation are the weakest axes. Complexity is borderline. Now get the details.
+
+**You:** "Generate a full debt report. I want to know which files to focus on."
+
+**Claude** runs `get_debt_report(topN: 10)`:
+
+```
+Technical Debt Report
+
+Overall Debt Score: 49/100   Grade: C-
+
+Structural Debt:  68  ← worst category
+  3 circular dependencies
+  14 files with fan-out > 10
+  2 god classes (UserManager.ts, helpers.ts)
+
+Complexity Debt:  55
+  18 functions with cyclomatic > 8
+  4 functions > 20 complexity
+
+Maintainability:  41
+  2 god classes
+  29 dead exports
+  81 undocumented exported symbols
+
+Volatility:  44
+  6 high-churn files with complexity > 8 (highest risk)
+
+Top Debt Files:
+
+  1. src/legacy/UserManager.ts       score: 91
+  2. src/utils/helpers.ts            score: 79
+  3. src/core/auth.ts                score: 68  ← highest churn + cycles
+  4. src/api/routes/legacy.ts        score: 61
+  5. src/billing/processor.ts        score: 58
+```
+
+**Snapshot the state before you start:**
+
+```
+get_architecture_snapshot(repoId, action: "create", label: "before-Q2-sprint")
+→ snapshotId: "snap_before"
+```
+
+You'll diff against this at the end to prove the improvement.
+
+---
+
+## Phase 2: Understand — cycles, coupling, relationships
+
+Before breaking cycles and reducing coupling, understand the exact structure.
+
+**You:** "Find all circular dependencies. Show me the cycles involving our core modules."
+
+```
+find_cycles(repoId, filePath: "src/core/") →
+
+  Cycle 1 (ERROR — tight 2-node):
+    src/core/auth.ts ↔ src/core/session.ts
+
+  Cycle 2 (ERROR — tight 3-node):
+    src/core/billing.ts → src/utils/currency.ts → src/core/billing.ts
+
+  Cycle 3 (WARNING):
+    src/core/events.ts → src/handlers/payment.ts → src/core/billing.ts
+    → src/core/events.ts
+```
+
+Three cycles. Two errors — these are the structural problems that make the core modules hard to test independently.
+
+**You:** "Show me the coupling map for the most coupled files."
+
+```
+get_coupling_map(repoId, topN: 8) →
+
+  src/utils/helpers.ts         instability: 0.06   (42 files depend on it)
+  src/core/auth.ts             instability: 0.24   (28 files depend on it)
+  src/models/user.ts           instability: 0.19   (31 files depend on it)
+  ...
+```
+
+`helpers.ts` is the most dangerous file to change — 42 files depend on it. It's also identified as a god class in the debt report. It's the highest-priority structural target.
+
+**You:** "Before I split helpers.ts, show me its class hierarchy and who implements its exported interfaces."
+
+```
+get_class_hierarchy(symbolId: "BaseHelper-id", direction: "descendants") →
+  [hierarchy showing no subclasses — it's not a class hierarchy issue, it's a module cohesion issue]
+
+get_coupling_map(repoId, filePath: "src/utils/helpers.ts", direction: "efferent") →
+  [shows helpers.ts imports from: lodash, moment, crypto, db/queries ← 4 completely unrelated domains]
+```
+
+The helper file mixes formatting, crypto, date handling, and database utilities in one place. The plan: split it into `src/format/`, `src/crypto/`, `src/date/`, `src/db/utils/`.
+
+---
+
+## Phase 3: Plan — sequence the work safely
+
+Before executing, get a sequenced plan for each major change.
+
+**You:** "Give me a refactoring plan for splitting helpers.ts into focused modules."
+
+```
+plan_refactoring(repoId, goal: "extract-module", filePath: "src/utils/helpers.ts") →
+
+  Goal: extract-module
+  Estimated files affected: 42
+  Risk: HIGH (42 files import this — proceed carefully)
+
+  Recommended steps:
+
+  1. [LOW RISK] Create new module files
+     src/format/currency.ts  — move formatCurrency, formatPrice, formatPercent
+     src/date/utils.ts       — move formatDate, parseDate, addDays
+     src/crypto/utils.ts     — move hashToken, compareHash, generateSecret
+     src/db/helpers.ts       — move buildQuery, sanitizeSql
+
+  2. [MEDIUM RISK] Update leaf importers (files with few other importers)
+     12 test files — update imports one by one, run tests after each
+     8 utility consumers — update in batches of 2-3
+
+  3. [HIGH RISK] Update hub importers (files imported by many others)
+     src/core/auth.ts (imported by 28 files) — update last
+     src/api/middleware/auth.ts (imported by 14 files) — update last
+
+  4. [FINAL] Deprecate src/utils/helpers.ts
+     Add re-exports for backward compatibility
+     Schedule removal in next major release
+
+  Warnings:
+    - Do not remove helpers.ts immediately — it takes 42 files off the air simultaneously
+    - Use re-exports during a transition period to avoid breaking the team's in-progress work
+```
+
+---
+
+## Phase 4: Execute — safely, one step at a time
+
+For each specific change, check safety before you start.
+
+**Breaking the billing ↔ currency cycle:**
+
+**You:** "Before I break the circular dependency between billing.ts and currency.ts, show me the exact imports causing the cycle."
+
+```
+find_cycles(repoId, filePath: "src/core/billing.ts") →
+
+  Cycle:
+    src/core/billing.ts:3   import { formatCurrency } from '../utils/currency'
+    src/utils/currency.ts:7  import { DEFAULT_CURRENCY } from '../core/billing'
+```
+
+`billing.ts` imports `formatCurrency` from currency. `currency.ts` imports `DEFAULT_CURRENCY` from billing. The fix: move `DEFAULT_CURRENCY` to a `constants.ts` file that both can import without creating a cycle.
+
+**Renaming a function as part of the cleanup:**
+
+**You:** "I'm renaming formatCurrency to formatMoney as part of the extraction. Is that safe?"
+
+```
+check_rename_safe(repoId, symbolId: "formatCurrency-id", newName: "formatMoney") →
+
+  safe: true  — 23 files affected, all call sites and imports
+  No string-literal references. No name conflicts.
+```
+
+Safe. Proceed.
+
+**Deleting dead exports found by the debt report:**
+
+**You:** "The debt report listed 29 dead exports. Confirm that the top 5 are safe to delete."
+
+```
+check_delete_safe(repoId, symbolId: "LegacyTokenParser-id") → safe: true
+check_delete_safe(repoId, symbolId: "OldSessionFormat-id")   → safe: true
+check_delete_safe(repoId, symbolId: "validateBasicAuth-id")  → safe: true
+check_delete_safe(repoId, symbolId: "generateJWT-id")        →
+  safe: false — 1 live reference in src/integrations/legacy-sso.ts:45
+check_delete_safe(repoId, symbolId: "parseQueryString-id")   → safe: true
+```
+
+Four of five are clean deletes. `generateJWT` has one live reference in the legacy SSO integration — update that first, then delete.
+
+---
+
+## Phase 5: Verify — did it work?
+
+After two weeks of work, measure the improvement.
+
+**You:** "Re-index and generate a new health radar. How did we do?"
+
+```
+health_radar(repoId) →
+
+  Health Radar — after Q2 sprint
+
+  complexity       65   ████████████░░░░░░░░  Fair    (was: 58 ▲ +7)
+  coupling         61   ████████████░░░░░░░░  Fair    (was: 44 ▲ +17)
+  maintainability  79   ███████████████░░░░░  Good    (was: 71 ▲ +8)
+  documentation    52   ██████████░░░░░░░░░░  Warning (was: 31 ▲ +21)
+  stability        67   █████████████░░░░░░░  Fair    (was: 62 ▲ +5)
+
+  Overall Health:  65   Grade: C+   (was: D)
+```
+
+Every axis improved. Documentation saw the biggest gain — from a nearly failing 31 to 52. Coupling improved by 17 points. Overall grade went from D to C+.
+
+**Compare the architecture snapshots:**
+
+```
+get_architecture_snapshot(repoId, action: "diff",
+  snapshotId: "snap_before", compareId: "snap_after") →
+
+  fileCount:     +8     (helpers.ts split into 4 focused modules + 4 new test files)
+  symbolCount:   -12    (29 dead exports removed, net negative after new code)
+  edgeCount:     -34    (fewer total imports — better modularization)
+  cycleCount:    -3     (3 circular deps eliminated)
+  avgCoupling:   4.2 → 2.8  (-1.4 — significantly less coupled)
+  avgComplexity: 5.1 → 4.3  (-0.8 — lower average complexity)
+```
+
+Concrete structural improvement. Three cycles eliminated. Coupling down 33%.
+
+**Run the debt report to verify the top files improved:**
+
+```
+get_debt_report(repoId, topN: 5) →
+
+  Overall Debt Score: 31/100   Grade: B-   (was: 49/100)
+
+  src/legacy/UserManager.ts  score: 67  (was: 91 ▼ -24)
+  src/utils/format/currency.ts  score: 12  (was: 79 as helpers.ts ▼ -67 — split completed)
+  src/core/auth.ts  score: 44  (was: 68 ▼ -24)
+  src/api/routes/legacy.ts  score: 58  (was: 61 ▼ -3)
+  src/billing/processor.ts  score: 55  (was: 58 ▼ -3)
+```
+
+The dramatic improvement in `helpers.ts` (79 → 12 average across the split modules) shows the extraction was the right call. `UserManager.ts` dropped 24 points from the class extraction. The sprint achieved its goals.
+
+---
+
+## What made this sprint effective
+
+**Measured before and after.** Snapshots gave concrete proof of improvement — not just "we refactored things" but "+17 coupling score, 3 cycles eliminated."
+
+**Prioritized by impact, not feeling.** The debt report ranked files objectively. `UserManager.ts` and `helpers.ts` were the right targets because the data said so — not intuition.
+
+**Checked safety before every change.** `check_rename_safe`, `check_delete_safe`, and `check_move_safe` prevented breaking changes. The one "not safe" flag on `generateJWT` caught a real dependency that would have caused a production regression.
+
+**Understood structure before touching code.** `find_cycles` showed the exact imports causing each cycle. `get_coupling_map` showed why `helpers.ts` was so dangerous to change. The actual edits were straightforward once the structure was understood.
+
+---
+
+→ See also:  
+→ [Code Health & Architecture Analysis](CODE-HEALTH.md) — quality metrics and anti-pattern detection  
+→ [Health Dashboards & Debt Reporting](HEALTH-DASHBOARDS.md) — health_radar, diff_health_radar, get_debt_report  
+→ [Refactoring Safely](REFACTORING-SAFELY.md) — pre-flight checks before any structural change  
+→ [Understanding Relationships](UNDERSTANDING-RELATIONSHIPS.md) — cycles, coupling, and call hierarchies

package/dist/core/db/dep-store.d.ts

@@ -10,6 +10,81 @@ export declare function getForwardDeps(db: Database.Database, repoId: string, so
 export declare function getReverseDeps(db: Database.Database, repoId: string, targetFile: string, tenantId?: string): DepEdge[];
 /** Distinct file paths that import `targetFile`. */
 export declare function getImportersOf(db: Database.Database, repoId: string, targetFile: string, tenantId?: string): string[];
+export interface CouplingRow {
+    filePath: string;
+    efferentCoupling: number;
+    afferentCoupling: number;
+    instability: number;
+    efferentDeps: string[];
+    afferentDeps: string[];
+}
+/**
+ * Build a per-file coupling map from dep_edges.
+ *
+ * All edges in dep_edges are internal (external npm imports are dropped at
+ * graph-build time), so no external-package filtering is needed.
+ *
+ * When `filePath` is provided only that file's row is returned.
+ */
+export declare function getCouplingMap(db: Database.Database, repoId: string, filePath?: string): CouplingRow[];
+/**
+ * Find all class/interface symbols whose signature contains `extends TargetName`.
+ * Used for building the descendant tree in get_class_hierarchy.
+ *
+ * The LIKE query is an over-approximation; callers should post-filter with a
+ * word-boundary regex when exact matching is needed.
+ */
+export declare function findClassesExtending(db: Database.Database, repoId: string, targetName: string): ImplementorRow[];
+/**
+ * Find a class or interface symbol by exact name.
+ * Returns the first match (expected to be unique per name+kind in a repo).
+ */
+export declare function findClassOrInterfaceByName(db: Database.Database, repoId: string, name: string): ImplementorRow | null;
+export interface ImplementorRow {
+    id: string;
+    name: string;
+    kind: string;
+    filePath: string;
+    startByte: number;
+    endByte: number;
+    signature: string;
+    summary: string;
+}
+/**
+ * Find all class / interface symbols in the repo whose signature contains
+ * `implements {targetName}` or `extends {targetName}`.
+ *
+ * Two passes are used:
+ *  1. Name-based: LIKE query on signature (fast, covers most cases).
+ *  2. Import-based: check files that import the interface's file — any class
+ *     there that matches is also included (catches cases where the LIKE
+ *     didn't fire because the signature was truncated).
+ *
+ * When `includeAbstract` is false, classes with `abstract` in their signature
+ * are excluded. The `limit` is applied after both passes are merged.
+ */
+export declare function findClassImplementations(db: Database.Database, repoId: string, targetName: string, targetFilePath: string, includeAbstract: boolean, limit: number): ImplementorRow[];
+/**
+ * Return the method name stems (the part after the dot) for all method symbols
+ * belonging to a given class in the symbol index.
+ *
+ * e.g. `JwtAuthProvider.authenticate` → `'authenticate'`
+ *
+ * Note: interface methods are NOT indexed as separate symbols by the TypeScript
+ * handler. Use `extractInterfaceMethodNames` for interface method extraction.
+ */
+export declare function getMethodNamesForSymbol(db: Database.Database, repoId: string, ownerName: string, filePath: string): string[];
+/**
+ * Extract method/property names from an interface or abstract class body by
+ * scanning the raw file content between the symbol's byte offsets.
+ *
+ * Used for `missingMethods` computation when interface methods are not indexed
+ * as separate symbol rows.
+ *
+ * Strategy: scan lines within the byte range for `identifier(` patterns,
+ * skipping the declaration line itself and accessor keywords.
+ */
+export declare function extractInterfaceMethodNames(fileContent: Buffer, startByte: number, endByte: number): string[];
 /**
  * Returns exported symbols whose file is never imported by any other file in
  * the repo. Phase 1: file-level dead code detection.

package/dist/core/db/dep-store.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"dep-store.d.ts","sourceRoot":"","sources":["../../../src/core/db/dep-store.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,QAAQ,MAAM,gBAAgB,CAAC;AAC3C,OAAO,KAAK,EAAE,OAAO,EAAE,YAAY,EAAc,MAAM,aAAa,CAAC;AA4DrE,wBAAgB,WAAW,CACzB,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,KAAK,EAAE,OAAO,EAAE,EAChB,QAAQ,SAAU,GACjB,IAAI,CAkCN;AAED,wBAAgB,iBAAiB,CAC/B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,MAAM,GACf,IAAI,CAIN;AAED,uCAAuC;AACvC,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAaX;AAED,2EAA2E;AAC3E,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAeX;AAED,0EAA0E;AAC1E,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAeX;AAED,oDAAoD;AACpD,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,MAAM,EAAE,CAeV;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAC7B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,CAAC,EAAE,MAAM,GAChB,YAAY,EAAE,CAmChB"}
+{"version":3,"file":"dep-store.d.ts","sourceRoot":"","sources":["../../../src/core/db/dep-store.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,QAAQ,MAAM,gBAAgB,CAAC;AAC3C,OAAO,KAAK,EAAE,OAAO,EAAE,YAAY,EAAc,MAAM,aAAa,CAAC;AA4DrE,wBAAgB,WAAW,CACzB,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,KAAK,EAAE,OAAO,EAAE,EAChB,QAAQ,SAAU,GACjB,IAAI,CAkCN;AAED,wBAAgB,iBAAiB,CAC/B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,MAAM,GACf,IAAI,CAIN;AAED,uCAAuC;AACvC,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAaX;AAED,2EAA2E;AAC3E,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAeX;AAED,0EAA0E;AAC1E,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,OAAO,EAAE,CAeX;AAED,oDAAoD;AACpD,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,QAAQ,CAAC,EAAE,MAAM,GAChB,MAAM,EAAE,CAeV;AAID,MAAM,WAAW,WAAW;IAC1B,QAAQ,EAAE,MAAM,CAAC;IACjB,gBAAgB,EAAE,MAAM,CAAC;IACzB,gBAAgB,EAAE,MAAM,CAAC;IACzB,WAAW,EAAE,MAAM,CAAC;IACpB,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB,YAAY,EAAE,MAAM,EAAE,CAAC;CACxB;AAED;;;;;;;GAOG;AACH,wBAAgB,cAAc,CAC5B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,CAAC,EAAE,MAAM,GAChB,WAAW,EAAE,CA4Ff;AAID;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CAClC,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,GACjB,cAAc,EAAE,CAiClB;AAED;;;GAGG;AACH,wBAAgB,0BAA0B,CACxC,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,IAAI,EAAE,MAAM,GACX,cAAc,GAAG,IAAI,CAgCvB;AAID,MAAM,WAAW,cAAc;IAC7B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;IAChB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;CACjB;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,wBAAwB,CACtC,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,cAAc,EAAE,MAAM,EACtB,eAAe,EAAE,OAAO,EACxB,KAAK,EAAE,MAAM,GACZ,cAAc,EAAE,CA2ElB;AAED;;;;;;;;GAQG;AACH,wBAAgB,uBAAuB,CACrC,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,SAAS,EAAE,MAAM,EACjB,QAAQ,EAAE,MAAM,GACf,MAAM,EAAE,CASV;AAED;;;;;;;;;GASG;AACH,wBAAgB,2BAA2B,CACzC,WAAW,EAAE,MAAM,EACnB,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,MAAM,GACd,MAAM,EAAE,CAkCV;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAC7B,EAAE,EAAE,QAAQ,CAAC,QAAQ,EACrB,MAAM,EAAE,MAAM,EACd,QAAQ,CAAC,EAAE,MAAM,GAChB,YAAY,EAAE,CAmChB"}