@kaelio/ktx 0.4.1 → 0.6.0

package/node_modules/@ktx/context/package.json

@@ -1,122 +0,0 @@
-{
-  "name": "@ktx/context",
-  "version": "0.0.0-private",
-  "private": true,
-  "type": "module",
-  "main": "dist/index.js",
-  "types": "dist/index.d.ts",
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "import": "./dist/index.js",
-      "default": "./dist/index.js"
-    },
-    "./agent": {
-      "types": "./dist/agent/index.d.ts",
-      "import": "./dist/agent/index.js",
-      "default": "./dist/agent/index.js"
-    },
-    "./core": {
-      "types": "./dist/core/index.d.ts",
-      "import": "./dist/core/index.js",
-      "default": "./dist/core/index.js"
-    },
-    "./connections": {
-      "types": "./dist/connections/index.d.ts",
-      "import": "./dist/connections/index.js",
-      "default": "./dist/connections/index.js"
-    },
-    "./daemon": {
-      "types": "./dist/daemon/index.d.ts",
-      "import": "./dist/daemon/index.js",
-      "default": "./dist/daemon/index.js"
-    },
-    "./ingest": {
-      "types": "./dist/ingest/index.d.ts",
-      "import": "./dist/ingest/index.js",
-      "default": "./dist/ingest/index.js"
-    },
-    "./ingest/memory-flow": {
-      "types": "./dist/ingest/memory-flow/index.d.ts",
-      "import": "./dist/ingest/memory-flow/index.js",
-      "default": "./dist/ingest/memory-flow/index.js"
-    },
-    "./ingest/metabase-mapping": {
-      "types": "./dist/ingest/metabase-mapping.d.ts",
-      "import": "./dist/ingest/metabase-mapping.js",
-      "default": "./dist/ingest/metabase-mapping.js"
-    },
-    "./index-sync": {
-      "types": "./dist/index-sync/index.d.ts",
-      "import": "./dist/index-sync/index.js",
-      "default": "./dist/index-sync/index.js"
-    },
-    "./scan": {
-      "types": "./dist/scan/index.d.ts",
-      "import": "./dist/scan/index.js",
-      "default": "./dist/scan/index.js"
-    },
-    "./search": {
-      "types": "./dist/search/index.d.ts",
-      "import": "./dist/search/index.js",
-      "default": "./dist/search/index.js"
-    },
-    "./sql-analysis": {
-      "types": "./dist/sql-analysis/index.d.ts",
-      "import": "./dist/sql-analysis/index.js",
-      "default": "./dist/sql-analysis/index.js"
-    },
-    "./memory": {
-      "types": "./dist/memory/index.d.ts",
-      "import": "./dist/memory/index.js",
-      "default": "./dist/memory/index.js"
-    },
-    "./mcp": {
-      "types": "./dist/mcp/index.d.ts",
-      "import": "./dist/mcp/index.js",
-      "default": "./dist/mcp/index.js"
-    },
-    "./project": {
-      "types": "./dist/project/index.d.ts",
-      "import": "./dist/project/index.js",
-      "default": "./dist/project/index.js"
-    },
-    "./prompts": {
-      "types": "./dist/prompts/index.d.ts",
-      "import": "./dist/prompts/index.js",
-      "default": "./dist/prompts/index.js"
-    },
-    "./skills": {
-      "types": "./dist/skills/index.d.ts",
-      "import": "./dist/skills/index.js",
-      "default": "./dist/skills/index.js"
-    },
-    "./sl": {
-      "types": "./dist/sl/index.d.ts",
-      "import": "./dist/sl/index.js",
-      "default": "./dist/sl/index.js"
-    },
-    "./sl/descriptions": {
-      "types": "./dist/sl/descriptions.d.ts",
-      "import": "./dist/sl/descriptions.js",
-      "default": "./dist/sl/descriptions.js"
-    },
-    "./tools": {
-      "types": "./dist/tools/index.d.ts",
-      "import": "./dist/tools/index.js",
-      "default": "./dist/tools/index.js"
-    },
-    "./wiki": {
-      "types": "./dist/wiki/index.d.ts",
-      "import": "./dist/wiki/index.js",
-      "default": "./dist/wiki/index.js"
-    },
-    "./package.json": "./package.json"
-  },
-  "files": [
-    "dist",
-    "prompts",
-    "skills"
-  ],
-  "license": "Apache-2.0"
-}

package/node_modules/@ktx/context/skills/historic_sql_patterns/SKILL.md

@@ -1,91 +0,0 @@
----
-name: historic_sql_patterns
-description: Identify recurring cross-table historic-SQL analytical intents from a bounded pattern shard and emit typed pattern evidence for deterministic wiki projection.
-callers: [memory_agent]
----
-
-# Historic SQL Patterns
-
-Use this skill when the WorkUnit raw file is a `patterns-input/part-0001.json` style shard from the `historic-sql` adapter. Older staged bundles may still provide root `patterns-input.json`; when that is the WorkUnit raw file, read it the same way.
-
-## Required Workflow
-
-1. Read the WorkUnit notes first.
-2. Find the single pattern input file listed under the WorkUnit `rawFiles` section.
-3. Call `read_raw_file` for that exact raw file path.
-4. Identify recurring analytical intents that span at least two tables and have repeated usage signal.
-5. Emit one `pattern` evidence object per durable cross-table intent by calling `emit_historic_sql_evidence`.
-6. Set each evidence object's `rawPath` to the exact raw file path read in step 3.
-7. Stop after all pattern evidence has been emitted.
-
-Every join column mentioned in pattern descriptions must be verified via
-entity_details for both sides of the join.
-
-## Identifier Verification Protocol
-
-Before writing a wiki page or SL source on any topic:
-
-1. `discover_data({query: "<topic>"})` - see what wikis, SL sources, and raw
-   tables already exist. Prefer updating existing pages over creating new ones.
-
-Before emitting any `schema.table` or `schema.table.column` into a wiki body,
-SL source, `tables:` frontmatter, `sl_refs`, or `emit_unmapped_fallback`:
-
-2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
-   confirm the identifier resolves; inspect native types, FK/PK, and
-   sampleValues.
-3. For literal values from the source, such as status codes or plan tiers,
-   check whether they appear in `entity_details` sampleValues for the relevant
-   column. If sampleValues is short or the sample may have missed real values,
-   run a `sql_execution` probe with the same warehouse connection id:
-   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
-4. If the candidate identifier still does not resolve, do one of:
-   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
-     If it errors, the identifier is fictional.
-   - Wrap the identifier in `[unverified - from <rawPath>]` in the wiki body,
-     citing the exact raw path that mentioned it.
-   - When recording `emit_unmapped_fallback` with `no_physical_table`, include
-     the failing probe error in `clarification`.
-5. Never copy `<schema>.<table>` placeholder strings from these instructions
-   into output.
-
-## Evidence Shape
-
-Each call to `emit_historic_sql_evidence` must use this shape:
-
-```json
-{
-  "kind": "pattern",
-  "rawPath": "patterns-input/part-0001.json",
-  "pattern": {
-    "slug": "order-lifecycle-analysis",
-    "title": "Order Lifecycle Analysis",
-    "narrative": "Analysts compare order statuses with customer segments to understand lifecycle movement.",
-    "definitionSql": "select o.status, count(*) from public.orders o join public.customers c on c.id = o.customer_id group by o.status",
-    "tablesInvolved": ["public.orders", "public.customers"],
-    "slRefs": ["orders", "customers"],
-    "constituentTemplateIds": ["pg:1", "pg:2"]
-  }
-}
-```
-
-The `pattern` object must match `patternOutputSchema`; multiple calls together must form `patternsArraySchema`.
-
-## Pattern Selection Rules
-
-- Prefer patterns that involve two or more tables.
-- Prefer templates with `executionsBucket` at least `10-100` and `distinctUsersBucket` above solo usage.
-- Merge templates into one pattern only when the business intent is the same.
-- Use a stable kebab-case slug based on intent, not a template id.
-- Set `definitionSql` to the clearest representative SQL from a constituent template.
-- Set `slRefs` to source names when the source name is obvious from table names; omit uncertain refs rather than guessing.
-- Treat each pattern shard independently; do not read peer shard files from `peerFileIndex`.
-
-## Boundaries
-
-- Do not call wiki_write.
-- Do not call sl_write_source.
-- Do not call sl_edit_source.
-- Do not call context_candidate_write.
-- Do not create single-table pattern pages.
-- Do not copy credentials, tokens, user emails, or unredacted literals into evidence.

package/node_modules/@ktx/context/skills/historic_sql_table_digest/SKILL.md

@@ -1,89 +0,0 @@
----
-name: historic_sql_table_digest
-description: Convert one changed historic-SQL table usage bucket into typed table usage evidence for deterministic _schema projection.
-callers: [memory_agent]
----
-
-# Historic SQL Table Digest
-
-Use this skill when the WorkUnit raw file is one `tables/<schema>.<name>.json` file from the `historic-sql` adapter.
-
-## Required Workflow
-
-1. Read the WorkUnit notes first.
-2. Call `read_raw_file` for the single `tables/<schema>.<name>.json` raw file.
-3. Read `manifest.json` only if the table JSON omits the dialect or the WorkUnit notes are unclear.
-4. Produce one concise usage narrative for this table from the staged table JSON.
-5. Call `emit_historic_sql_evidence` exactly once with `kind: "table_usage"`.
-6. Stop after the evidence tool succeeds.
-
-## Identifier Verification Protocol
-
-Before writing a wiki page or SL source on any topic:
-
-1. `discover_data({query: "<topic>"})` - see what wikis, SL sources, and raw
-   tables already exist. Prefer updating existing pages over creating new ones.
-
-Before emitting any `schema.table` or `schema.table.column` into a wiki body,
-SL source, `tables:` frontmatter, `sl_refs`, or `emit_unmapped_fallback`:
-
-2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
-   confirm the identifier resolves; inspect native types, FK/PK, and
-   sampleValues.
-3. For literal values from the source, such as status codes or plan tiers,
-   check whether they appear in `entity_details` sampleValues for the relevant
-   column. If sampleValues is short or the sample may have missed real values,
-   run a `sql_execution` probe with the same warehouse connection id:
-   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
-4. If the candidate identifier still does not resolve, do one of:
-   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
-     If it errors, the identifier is fictional.
-   - Wrap the identifier in `[unverified - from <rawPath>]` in the wiki body,
-     citing the exact raw path that mentioned it.
-   - When recording `emit_unmapped_fallback` with `no_physical_table`, include
-     the failing probe error in `clarification`.
-5. Never copy `<schema>.<table>` placeholder strings from these instructions
-   into output.
-
-## Evidence Shape
-
-Call `emit_historic_sql_evidence` with this shape:
-
-```json
-{
-  "kind": "table_usage",
-  "table": "public.orders",
-  "rawPath": "tables/public.orders.json",
-  "usage": {
-    "narrative": "Orders are repeatedly queried for paid/refunded lifecycle analysis and customer-level rollups.",
-    "frequencyTier": "high",
-    "commonFilters": ["status", "created_at"],
-    "commonGroupBys": ["status"],
-    "commonJoins": [{ "table": "public.customers", "on": ["customer_id"] }],
-    "staleSince": null
-  }
-}
-```
-
-The `usage` object must match `tableUsageOutputSchema`.
-
-## Interpretation Rules
-
-- Treat `columnsByClause.where` as common filters.
-- Treat `columnsByClause.groupBy` as common group-bys.
-- Treat `observedJoins` as common joins.
-- Use `stats.executionsBucket`, `stats.distinctUsersBucket`, and `stats.recencyBucket` to choose `frequencyTier`.
-- Use `frequencyTier: "high"` only when executions and distinct users are both broad.
-- Use `frequencyTier: "mid"` for repeated team usage that is not broad enough for high.
-- Use `frequencyTier: "low"` for low-volume but present usage.
-- Use `frequencyTier: "unused"` only when the table input explicitly says the table is stale or has no recent templates.
-- Keep `narrative` short and concrete.
-
-## Boundaries
-
-- Do not call wiki_write.
-- Do not call sl_write_source.
-- Do not call sl_edit_source.
-- Do not call context_candidate_write.
-- Do not emit more than one table usage evidence object.
-- Do not invent columns, joins, or tables that are absent from the staged JSON.

package/node_modules/@ktx/context/skills/sl/SKILL.md

@@ -1,247 +0,0 @@
----
-name: sl
-description: KTX's semantic layer - a structured catalog of sources (tables/views), measures, joins, and segments expressed as YAML. Covers the schema and how to query it via `sl_query`. Use when the task involves querying pre-defined metrics (ARR, churn, retention, LTV, MAU) or reading SL source YAML to understand the catalog. Capture is handled by the `sl_capture` skill (memory-agent only).
----
-
-# Semantic Layer
-
-KTX's semantic layer (SL) is a structured catalog. Each **source** represents a table, a SQL view, or an overlay that enriches a manifest-backed table with measures, computed columns, joins, and named segments. The catalog is the single source of truth for reusable business metrics.
-
-This skill covers two parts:
-- **Part 1** - Schema reference (what an SL source looks like).
-- **Part 2** - Querying via `sl_query`.
-
-Capture (when and how to add new patterns to the SL) is a separate concern handled by the memory-agent - see the `sl_capture` skill if you are running in capture mode. The research agent **reads** and **queries** the SL via the tools described here; it does not write to it.
-
-For capture-time identifier verification, load `sl_capture`. Synthesis writer
-skills must verify warehouse identifiers with `discover_data`,
-`entity_details`, and `sql_execution` before emitting table or column names.
-
----
-
-## Part 1 - Schema reference
-
-An SL source is a YAML file at `semantic-layer/<connectionId>/<source_name>.yaml`. There are three flavors:
-
-### Overlay sources
-
-Enrich a manifest-backed table with measures, computed columns, joins, and segments. No `table` or `sql` field. The base table's columns and grain are inherited from the manifest.
-
-```yaml
-name: fct_orders           # must match an existing manifest table
-descriptions:
-  user: "Overlay adding business measures to the orders fact table."
-measures:
-  - name: total_revenue
-    expr: sum(amount)
-    description: Total order revenue - filter by status or region at query time
-columns:                    # computed dimensions only
-  - name: is_large_order
-    type: boolean
-    expr: "amount > 1000"
-column_overrides:           # metadata patches for inherited columns
-  - name: status
-    descriptions:
-      user: "Order lifecycle status."
-segments:
-  - name: paid_non_refunded
-    expr: "is_paid = true AND is_refunded = false"
-joins:
-  - to: customers
-    on: "customer_id = customers.id"
-    relationship: many_to_one
-```
-
-Rules:
-- Do **not** repeat base-table columns, grain, `table`, or `source_type` in an overlay - those are inherited.
-- Overlay columns MUST be computed (`expr` + `type`).
-- Use `column_overrides` to add descriptions or metadata to inherited manifest columns. Do not put `type` or `expr` in `column_overrides`.
-- `exclude_columns` hides specific manifest columns; `disable_joins` suppresses specific auto-detected joins.
-
-### Standalone table sources
-
-Self-contained; own their schema. Has `source_type: table` and `table:`.
-
-```yaml
-name: account_health_scores
-source_type: table
-table: "analytics.account_health_scores"
-grain: [account_id, snapshot_date]
-columns:
-  - name: account_id
-    type: string
-  - name: snapshot_date
-    type: time
-    role: time
-  - name: health_score
-    type: number
-measures:
-  - name: avg_health_score
-    expr: avg(health_score)
-```
-
-### Standalone SQL sources
-
-Self-contained; schema derived from a SQL query. Has `source_type: sql` and `sql:`.
-
-```yaml
-name: monthly_cancellations
-source_type: sql
-sql: |
-  SELECT
-    date_trunc('month', cancelled_at) AS month,
-    customer_id,
-    plan_name,
-    mrr_amount
-  FROM subscriptions
-  WHERE status = 'cancelled'
-grain: [customer_id, month]
-columns:
-  - name: month
-    type: time
-    role: time
-  - name: customer_id
-    type: string
-  - name: plan_name
-    type: string
-  - name: mrr_amount
-    type: number
-measures:
-  - name: cancellation_count
-    expr: count(*)
-```
-
-An SQL source is a one-shot answer: the aggregation is frozen, callers cannot re-group or re-filter by columns the SQL has collapsed, and the source is disconnected from the join graph. Prefer overlays + measures over SQL sources when possible - the `sl_capture` skill covers when SQL is justified.
-
-### Columns
-
-Every standalone column requires `name` and `type`. Overlays have computed columns in `columns:` and manifest column metadata patches in `column_overrides:`.
-
-- `type`: one of `string`, `number`, `boolean`, `time`. Map LookML `date`/`datetime`/`timestamp` → `time`. Map LookML `yesno` → `boolean`.
-- `role` (optional): `time` enables time-granularity queries (month, week, day). `default` is the implicit fallback.
-- `visibility` (optional): `public`, `internal`, or `hidden`.
-- `expr` (optional for standalone, required for overlay columns): SQL expression that computes the value. Expanded by sqlglot before generating SQL, so you can reference other columns on the same source.
-
-### Grain
-
-`grain: [col_a, col_b]` - the set of columns that uniquely identify one row. The query engine uses grain to prevent fan-out in joins. Overlays inherit grain from the manifest unless they override.
-
-### Joins
-
-```yaml
-joins:
-  - to: customers                                    # target source name
-    on: "customer_id = customers.id"                 # local_col = TARGET.target_col
-    relationship: many_to_one                        # or one_to_many, one_to_one
-    alias: primary_customer                          # optional - lets you join the same target twice
-```
-
-- `on` format: `local_col = TARGET.target_col`. Always qualify the right side with the target source name.
-- `relationship` is the cardinality **from this source to the target**. Most joins are `many_to_one` (FK → PK on the parent).
-
-### Measures
-
-```yaml
-measures:
-  - name: total_arr
-    expr: sum(arr_amount)
-    description: Sum of ARR - filter by plan_name at query time
-    filter: "is_active = true"
-    segments: [paid_non_refunded]
-```
-
-- `name` (required, snake_case).
-- `expr` (required): any valid SQL aggregate - `sum(x)`, `count(*)`, `count(distinct user_id)`, `avg(score)`.
-- `description` (required on capture): what the measure computes and how to use it.
-- `filter` (optional): SQL predicate applied as a WHERE clause specific to this measure.
-- `segments` (optional): names of segments defined on the same source. The engine AND-composes each segment's `expr` into this measure's effective filter.
-
-Use `safe_divide(num, den)` for ratio measures to avoid division by zero.
-
-### Segments
-
-```yaml
-segments:
-  - name: paid_non_refunded
-    expr: "is_paid = true AND is_refunded = false"
-    description: Orders that were paid and not refunded
-```
-
-Named, reusable boolean predicates scoped to one source. Reference by bare name in a measure's `segments: []`, or by dotted form `source.segment_name` in an `sl_query`. Segments are predicates only - they are NOT selectable as dimensions. If you need to group by the predicate, add a `columns[]` entry instead.
-
-### Cross-references with the wiki
-
-The reverse edge (wiki pages that cite this source) is derived automatically from each wiki's `sl_refs:` - you don't emit anything on the SL side. Author the edge once on the wiki via `sl_refs:`; the post-write reconciler populates the knowledge↔SL index.
-
----
-
-## Part 2 - Querying via `sl_query`
-
-The `sl_query` tool generates correct SQL from a structured query. It handles joins, fan-out prevention, aggregation correctness, and filter classification automatically. Prefer it over writing raw SQL whenever the SL has the relevant sources.
-
-### When to prefer sl_query over raw SQL
-
-- A pre-defined measure already exists (`source.measure_name` appears in the catalog).
-- The question combines fields from multiple sources - the engine resolves the join path automatically.
-- The question asks for a standard metric (revenue, ARR, churn, retention, LTV, conversion, MAU, etc.) - even if no pre-defined measure exists, a runtime aggregation over a catalog column is usually correct.
-
-Use raw SQL (`sql_execution`) only when:
-- The computation requires multi-step CTEs whose intermediate grain is not a column in any source.
-- The question explicitly asks for a one-off exploration that will never be asked again.
-
-### Input shape
-
-```json
-{
-  "connectionId": "uuid-of-the-connection",
-  "measures": ["orders.total_revenue", "sum(orders.amount)"],
-  "dimensions": ["customers.segment", { "field": "orders.created_at", "granularity": "month" }],
-  "filters": ["orders.status != 'cancelled'", "orders.total_revenue > 10000"],
-  "segments": ["orders.paid_non_refunded"],
-  "order_by": [{ "field": "orders.created_at", "direction": "desc" }],
-  "limit": 1000
-}
-```
-
-- **`measures`**: mix pre-defined refs (`source.measure`) and runtime aggregations (`sum(source.column)`).
-- **`dimensions`**: column refs or `{ field, granularity }` objects for time grains (`day`, `week`, `month`, `quarter`, `year`).
-- **`filters`**: free-form SQL predicates. The engine auto-classifies each as WHERE or HAVING based on whether it references an aggregated measure.
-- **`segments`**: dotted `source.segment_name`. Each segment is AND-ed into the effective filter of every measure whose base source matches. Segments never become a global WHERE - use `filters` for cross-source predicates.
-- **`order_by`**: string or `{ field, direction }`. Direction defaults to `asc`.
-- **`limit`**: integer row cap.
-
-### Join resolution
-
-You don't specify a base table. The engine infers the set of sources needed from the fields you reference and resolves the shortest join path through the catalog's declared joins. If no path exists between two sources, the query fails with a path-not-found error - check `discover_data` or `sl_discover` to see which sources are connected.
-
-### Worked examples
-
-Cross-source query - engine resolves `account_health_scores → accounts ← opportunities` automatically:
-
-```json
-{
-  "measures": ["account_health_scores.avg_health_score"],
-  "dimensions": ["opportunities.stage"],
-  "filters": ["opportunities.stage != 'Closed Won'"]
-}
-```
-
-Monthly ARR trend with a segment:
-
-```json
-{
-  "measures": ["subscriptions.arr"],
-  "dimensions": [{ "field": "subscriptions.month", "granularity": "month" }],
-  "segments": ["subscriptions.paid_non_refunded"],
-  "order_by": [{ "field": "subscriptions.month", "direction": "asc" }]
-}
-```
-
-Multi-source with runtime aggregation:
-
-```json
-{
-  "measures": ["sum(orders.amount)", "count(support_tickets.ticket_id)"],
-  "dimensions": ["customers.segment"]
-}
-```

package/node_modules/@ktx/llm/dist/embedding-health.js

@@ -1,36 +0,0 @@
-import { createKtxEmbeddingProvider } from './embedding-provider.js';
-function redactHealthCheckMessage(message, config) {
-    const secrets = [config.openai?.apiKey].filter((value) => typeof value === 'string' && value.length > 0);
-    return secrets.reduce((current, secret) => current.split(secret).join('[redacted]'), message);
-}
-async function withTimeout(promise, timeoutMs) {
-    let timeout;
-    const timeoutPromise = new Promise((_resolve, reject) => {
-        timeout = setTimeout(() => reject(new Error(`Embedding health check timed out after ${timeoutMs}ms`)), timeoutMs);
-    });
-    try {
-        return await Promise.race([promise, timeoutPromise]);
-    }
-    finally {
-        if (timeout) {
-            clearTimeout(timeout);
-        }
-    }
-}
-export async function runKtxEmbeddingHealthCheck(config, options = {}) {
-    try {
-        const provider = createKtxEmbeddingProvider(config, options.deps);
-        const embedding = await withTimeout(provider.embed(options.text ?? 'KTX embedding health check'), options.timeoutMs ?? 15_000);
-        if (embedding.length !== config.dimensions) {
-            return {
-                ok: false,
-                message: `Embedding provider ${config.backend} returned vector with ${embedding.length} dimensions; expected ${config.dimensions}`,
-            };
-        }
-        return { ok: true };
-    }
-    catch (error) {
-        const message = error instanceof Error ? error.message : String(error);
-        return { ok: false, message: redactHealthCheckMessage(message, config) };
-    }
-}

package/node_modules/@ktx/llm/dist/embedding-health.test.d.ts

@@ -1 +0,0 @@
-export {};

package/node_modules/@ktx/llm/dist/embedding-health.test.js

@@ -1,72 +0,0 @@
-import { describe, expect, it, vi } from 'vitest';
-import { runKtxEmbeddingHealthCheck } from './embedding-health.js';
-describe('KTX embedding health check', () => {
-    it('runs a one-shot OpenAI embedding check through the configured provider', async () => {
-        const createOpenAIClient = vi.fn(() => ({
-            embeddings: {
-                create: vi.fn().mockResolvedValue({
-                    data: [{ index: 0, embedding: [0.1, 0.2, 0.3] }],
-                }),
-            },
-        }));
-        await expect(runKtxEmbeddingHealthCheck({
-            backend: 'openai',
-            model: 'text-embedding-3-small',
-            dimensions: 3,
-            openai: { apiKey: 'sk-openai-test' }, // pragma: allowlist secret
-        }, { deps: { createOpenAIClient } })).resolves.toEqual({ ok: true });
-        expect(createOpenAIClient).toHaveBeenCalledWith({ apiKey: 'sk-openai-test', baseURL: undefined }); // pragma: allowlist secret
-    });
-    it('returns failed when the provider returns the wrong dimensions', async () => {
-        const createOpenAIClient = vi.fn(() => ({
-            embeddings: {
-                create: vi.fn().mockResolvedValue({
-                    data: [{ index: 0, embedding: [0.1, 0.2] }],
-                }),
-            },
-        }));
-        await expect(runKtxEmbeddingHealthCheck({
-            backend: 'openai',
-            model: 'text-embedding-3-small',
-            dimensions: 3,
-            openai: { apiKey: 'sk-openai-test' }, // pragma: allowlist secret
-        }, { deps: { createOpenAIClient } })).resolves.toEqual({
-            ok: false,
-            message: 'Embedding provider openai returned vector with 2 dimensions; expected 3',
-        });
-    });
-    it('redacts credential values from health-check failures', async () => {
-        const createOpenAIClient = vi.fn(() => ({
-            embeddings: {
-                create: vi.fn(async () => {
-                    throw new Error('401 invalid api key sk-openai-secret');
-                }),
-            },
-        }));
-        await expect(runKtxEmbeddingHealthCheck({
-            backend: 'openai',
-            model: 'text-embedding-3-small',
-            dimensions: 3,
-            openai: { apiKey: 'sk-openai-secret' }, // pragma: allowlist secret
-        }, { deps: { createOpenAIClient } })).resolves.toEqual({
-            ok: false,
-            message: '401 invalid api key [redacted]',
-        });
-    });
-    it('returns failed when the health check times out', async () => {
-        const createOpenAIClient = vi.fn(() => ({
-            embeddings: {
-                create: vi.fn(() => new Promise(() => undefined)),
-            },
-        }));
-        await expect(runKtxEmbeddingHealthCheck({
-            backend: 'openai',
-            model: 'text-embedding-3-small',
-            dimensions: 3,
-            openai: { apiKey: 'sk-openai-test' }, // pragma: allowlist secret
-        }, { timeoutMs: 1, deps: { createOpenAIClient } })).resolves.toEqual({
-            ok: false,
-            message: 'Embedding health check timed out after 1ms',
-        });
-    });
-});

package/node_modules/@ktx/llm/dist/embedding-provider.test.d.ts

@@ -1 +0,0 @@
-export {};