diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 5d70d495..3da14c7b 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -37,6 +37,9 @@ jobs:
- name: Install TypeScript dependencies
run: pnpm install --frozen-lockfile
+ - name: Run TypeScript dead-code checks
+ run: pnpm run dead-code
+
- name: Run TypeScript checks
run: pnpm run check
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 8908b532..167681a6 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -33,6 +33,19 @@ repos:
name: ruff format (python)
files: ^python/
+ - repo: local
+ hooks:
+ - id: biome-dead-code
+ name: biome dead-code check
+ entry: pnpm exec biome ci . --formatter-enabled=false --assist-enabled=false
+ language: system
+ pass_filenames: false
+ - id: knip-dead-code
+ name: knip dead-code check
+ entry: pnpm exec knip --reporter compact
+ language: system
+ pass_filenames: false
+
- repo: https://github.com/Yelp/detect-secrets
rev: v1.5.0
hooks:
diff --git a/AGENTS.md b/AGENTS.md
index 2e5a684a..4a235864 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -24,6 +24,9 @@ database migrations, ORPC contracts, or `python-service/` layout exist here.
- **MUST**: Keep package/public API changes intentional. Do not add compatibility
wrappers for old KTX names unless the user explicitly asks for a migration
bridge.
+- **MUST**: Treat KTX as having no public users unless the user says otherwise.
+ Legacy support is not necessary by default; prefer clean breaking changes over
+ compatibility shims, migration bridges, or preserved stale behavior.
### Absolute Prohibitions
@@ -86,6 +89,7 @@ pnpm run build
pnpm run type-check
pnpm run test
pnpm run check
+pnpm run dead-code
pnpm --filter @ktx/cli run smoke
pnpm --filter './packages/*' run build
pnpm --filter './packages/*' run test
@@ -127,6 +131,7 @@ shared contracts or package exports are affected.
- Build/export changes: `pnpm run build`
- Workspace scripts: `node --test scripts/*.test.mjs` or the specific script
test file
+- TypeScript dead-code tooling/config changes: `pnpm run dead-code`
- Python semantic layer: `uv run pytest python/ktx-sl/tests -q`
- Python daemon: `uv run pytest python/ktx-daemon/tests -q`
- Python files: also run `uv run pre-commit run --files [FILES]` when
@@ -156,6 +161,23 @@ pnpm run test 2>&1 | tee /tmp/ktx-test-output.log
- Do not manually edit generated or built output under `dist/`; edit source and
rebuild.
+### Dead TypeScript Code Checks
+
+KTX uses Biome for local unused-code linting and Knip for workspace graph
+analysis. These checks are intentionally part of CI and pre-commit because the
+normal development workflow is agent-based.
+
+- Run `pnpm run dead-code` after TypeScript changes.
+- Treat Knip findings as investigation prompts, not automatic deletion orders.
+- Remove private dead code when you confirm there are no imports, dynamic
+ references, generated references, or tests that still need it.
+- Preserve public package exports unless the task explicitly includes API
+ pruning.
+- Add narrow `knip.json` ignores only for intentional dynamic or public cases.
+ Do not add broad package-level ignores to silence unrelated findings.
+- Update `knip.json` when adding dynamic entrypoints, generated files, package
+ exports, CLI bins, or framework files that Knip cannot infer.
+
### CLI Standards
- Use Commander for CLI command trees, arguments, options, help text, custom
diff --git a/README.md b/README.md
index cfabfbcc..563525e5 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,7 @@ reviewable project files that agents can use while planning, querying, and
updating analytics work.
A KTX project is a directory of plain files — YAML semantic sources, Markdown
-knowledge pages, and SQLite state — that you commit to git and review in PRs,
+wiki pages, and SQLite state — that you commit to git and review in PRs,
just like dbt models.
## Who KTX is for
@@ -105,7 +105,7 @@ my-project/
│ ├── orders.yaml # Semantic source definitions
│ ├── customers.yaml
│ └── order_items.yaml
-├── knowledge/
+├── wiki/
│ ├── global/
│ │ ├── revenue.md # Business definitions and rules
│ │ └── segment-classification.md
@@ -118,7 +118,7 @@ my-project/
└── db.sqlite # Local state (git-ignored)
```
-Semantic sources and knowledge pages are committed to git. The `.ktx/` directory
+Semantic sources and wiki pages are committed to git. The `.ktx/` directory
holds ephemeral state and is git-ignored — delete it and KTX rebuilds on the
next run.
@@ -130,9 +130,7 @@ Scan artifacts are written under
```bash
SCAN_OUTPUT="$(ktx scan warehouse --project-dir "$PROJECT_DIR")"
printf '%s\n' "$SCAN_OUTPUT"
-SCAN_RUN_ID="$(printf '%s\n' "$SCAN_OUTPUT" | awk '/^Run: / { print $2 }')"
-ktx scan status --project-dir "$PROJECT_DIR" "$SCAN_RUN_ID"
-ktx scan report --project-dir "$PROJECT_DIR" "$SCAN_RUN_ID"
+ktx status --project-dir "$PROJECT_DIR"
```
For non-SQLite drivers, prefer credential references such as `--url env:NAME`
@@ -147,16 +145,13 @@ version, and is managed by `ktx dev runtime` commands.
KTX requires `uv` on `PATH` to create the managed runtime. Install `uv` with
your system package manager or the official installer before running Python-
backed KTX commands. KTX doesn't download `uv` automatically; run
-`ktx dev runtime doctor` if runtime installation fails:
+`ktx dev runtime status` if runtime installation fails:
```bash
ktx dev runtime install --yes
ktx dev runtime status
-ktx dev runtime doctor
ktx dev runtime start
ktx dev runtime stop
-ktx dev runtime prune --dry-run
-ktx dev runtime prune --yes
```
The release artifact manifest contains the public npm tarball and the bundled `kaelio-ktx`
@@ -223,7 +218,7 @@ KTX provider. Enable it with an environment flag when running an LLM-backed
command:
```bash
-KTX_AI_DEVTOOLS_ENABLED=true ktx dev ingest run \
+KTX_AI_DEVTOOLS_ENABLED=true ktx ingest run \
--connection-id warehouse \
--adapter metabase
```
diff --git a/biome.json b/biome.json
new file mode 100644
index 00000000..35c6d596
--- /dev/null
+++ b/biome.json
@@ -0,0 +1,36 @@
+{
+ "$schema": "https://biomejs.dev/schemas/2.4.15/schema.json",
+ "assist": {
+ "enabled": false
+ },
+ "formatter": {
+ "enabled": false
+ },
+ "files": {
+ "includes": [
+ "scripts/**/*.mjs",
+ "packages/**/*.ts",
+ "packages/**/*.tsx",
+ "docs-site/**/*.ts",
+ "docs-site/**/*.tsx",
+ "docs-site/**/*.mjs",
+ "!**/dist/**",
+ "!**/coverage/**",
+ "!**/.next/**",
+ "!**/node_modules/**",
+ "!**/*.gen.ts",
+ "!**/*.generated.ts"
+ ]
+ },
+ "linter": {
+ "enabled": true,
+ "rules": {
+ "recommended": false,
+ "correctness": {
+ "noUnusedImports": "error",
+ "noUnusedVariables": "error",
+ "noUnusedPrivateClassMembers": "error"
+ }
+ }
+ }
+}
diff --git a/docs-site/components/terminal-preview.tsx b/docs-site/components/terminal-preview.tsx
index a1f950c8..d430c4ac 100644
--- a/docs-site/components/terminal-preview.tsx
+++ b/docs-site/components/terminal-preview.tsx
@@ -47,7 +47,7 @@ export function TerminalPreview() {
diff --git a/docs-site/content/docs/ai-resources/agent-quickstart.mdx b/docs-site/content/docs/ai-resources/agent-quickstart.mdx
index 40983224..6fd6e5ac 100644
--- a/docs-site/content/docs/ai-resources/agent-quickstart.mdx
+++ b/docs-site/content/docs/ai-resources/agent-quickstart.mdx
@@ -22,7 +22,7 @@ Agents should start with the smallest source that answers the task:
| How to check project readiness | [ktx status](/docs/cli-reference/ktx-status) | [Quickstart](/docs/getting-started/quickstart) |
| How context gets built | [Building Context](/docs/guides/building-context) | [ktx ingest](/docs/cli-reference/ktx-ingest) |
| How semantic YAML works | [Writing Context](/docs/guides/writing-context) | [ktx sl](/docs/cli-reference/ktx-sl) |
-| How machine-readable CLI output is shaped | [ktx agent](/docs/cli-reference/ktx-agent) | [Markdown Access](/docs/ai-resources/markdown-access) |
+| How machine-readable CLI output is shaped | [ktx sl](/docs/cli-reference/ktx-sl) | [ktx wiki](/docs/cli-reference/ktx-wiki) |
## Operating workflow
diff --git a/docs-site/content/docs/ai-resources/markdown-access.mdx b/docs-site/content/docs/ai-resources/markdown-access.mdx
index c363a215..12bb7456 100644
--- a/docs-site/content/docs/ai-resources/markdown-access.mdx
+++ b/docs-site/content/docs/ai-resources/markdown-access.mdx
@@ -31,7 +31,8 @@ Every docs page has a Markdown route:
```text
https://docs.kaelio.com/ktx/docs/getting-started/quickstart.md
-https://docs.kaelio.com/ktx/docs/cli-reference/ktx-agent.md
+https://docs.kaelio.com/ktx/docs/cli-reference/ktx-sl.md
+https://docs.kaelio.com/ktx/docs/cli-reference/ktx-wiki.md
https://docs.kaelio.com/ktx/docs/guides/building-context.md
```
diff --git a/docs-site/content/docs/cli-reference/ktx-agent.mdx b/docs-site/content/docs/cli-reference/ktx-agent.mdx
deleted file mode 100644
index cdc4ceac..00000000
--- a/docs-site/content/docs/cli-reference/ktx-agent.mdx
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: "ktx agent"
-description: "Machine-readable commands for coding agents."
----
-
-Hidden commands that provide machine-readable JSON output for coding agents. These are the commands that agent integrations (Claude Code, Cursor, Codex, OpenCode) call under the hood — you typically won't use them directly.
-
-All `ktx agent` subcommands require `--json` and produce structured JSON output on stdout.
-
-## Command signature
-
-```bash
-ktx agent --json [options]
-```
-
-## Subcommands
-
-| Subcommand | Description |
-|-----------|-------------|
-| `tools` | Print available agent-facing KTX tools |
-| `context` | Print project context for agent planning |
-| `sl list` | List semantic-layer sources |
-| `sl read ` | Read one semantic-layer source |
-| `sl query` | Run a semantic-layer query from a JSON file |
-| `wiki search ` | Search KTX wiki pages |
-| `wiki read ` | Read one KTX wiki page |
-| `sql execute` | Execute read-only SQL with a row limit |
-
-## Options
-
-### `agent tools`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-
-### `agent context`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-
-### `agent sl list`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-| `--connection-id ` | Filter by connection id | — |
-| `--query ` | Search source names and descriptions | — |
-
-### `agent sl read`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-| `--connection-id ` | Connection id containing the source | — |
-
-### `agent sl query`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-| `--connection-id ` | Connection id for execution (required) | — |
-| `--query-file ` | JSON semantic-layer query file (required) | — |
-| `--execute` | Execute the compiled query against the connection | `false` |
-| `--max-rows ` | Maximum rows to return when executing (1-1000) | — |
-
-### `agent wiki search`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-| `--limit ` | Maximum search results | `10` |
-
-### `agent wiki read`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-
-### `agent sql execute`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output (required) | — |
-| `--connection-id ` | Connection id for execution (required) | — |
-| `--sql-file ` | SQL file to execute (required) | — |
-| `--max-rows ` | Maximum rows to return, 1-1000 (required) | — |
-
-## Examples
-
-```bash
-# List available tools
-ktx agent tools --json
-
-# Get project context for planning
-ktx agent context --json
-
-# List semantic sources
-ktx agent sl list --json
-
-# Search semantic sources by name
-ktx agent sl list --json --query "revenue"
-
-# Read a semantic source
-ktx agent sl read orders --json --connection-id my-warehouse
-
-# Run a semantic-layer query from a file
-ktx agent sl query --json \
- --connection-id my-warehouse \
- --query-file /tmp/query.json \
- --execute \
- --max-rows 100
-
-# Search wiki pages
-ktx agent wiki search "churn definition" --json
-
-# Read a specific wiki page
-ktx agent wiki read page-abc123 --json
-
-# Execute read-only SQL
-ktx agent sql execute --json \
- --connection-id my-warehouse \
- --sql-file /tmp/query.sql \
- --max-rows 500
-```
-
-## Output
-
-Every `ktx agent` command writes JSON to stdout and diagnostic text to stderr. Agents should parse stdout as JSON and treat a non-zero exit code as a failed tool call.
-
-```json
-{
- "ok": true,
- "data": {
- "type": "agent-response"
- }
-}
-```
-
-## Common errors
-
-| Error | Cause | Recovery |
-|-------|-------|----------|
-| Missing JSON output | `--json` was omitted | Re-run the same subcommand with `--json` |
-| Unknown connection id | The requested connection is not configured in `ktx.yaml` | Call `ktx agent context --json` or `ktx connection list` to discover valid ids |
-| Query file cannot be read | `--query-file` points to a missing or invalid JSON file | Write the query payload to a real file and pass its absolute path |
-| SQL execution rejected | SQL is not read-only or `--max-rows` is missing | Use semantic-layer queries first; for direct SQL, pass read-only SQL and an explicit row limit |
diff --git a/docs-site/content/docs/cli-reference/ktx-connection.mdx b/docs-site/content/docs/cli-reference/ktx-connection.mdx
index 31a79736..0cec3eae 100644
--- a/docs-site/content/docs/cli-reference/ktx-connection.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-connection.mdx
@@ -1,9 +1,11 @@
---
title: "ktx connection"
-description: "Add, list, test, and map data sources."
+description: "List and test configured data sources."
---
-Manage database and source connections in your KTX project. Connections define how KTX reaches your data warehouse, BI tools, and context sources.
+Inspect configured connections in your KTX project. Connections define how KTX
+reaches your data warehouse, BI tools, and context sources. Use `ktx setup` to
+add, remove, or reconfigure connections.
## Command signature
@@ -17,96 +19,23 @@ ktx connection [options]
|-----------|-------------|
| `list` | List configured connections |
| `test ` | Test a configured connection |
-| `add ` | Add or replace a configured connection |
-| `remove ` | Remove a configured connection from `ktx.yaml` |
-| `map ` | Refresh and validate BI-to-warehouse mappings |
-| `mapping list ` | List Metabase database mappings |
-| `mapping set ` | Set a Metabase or Looker warehouse mapping |
-| `mapping apply-bulk ` | Apply mappings from JSON |
-| `mapping set-sync-enabled ` | Enable or disable sync for one Metabase database |
-| `mapping sync-state get ` | Read sync-state selection |
-| `mapping sync-state set ` | Write sync-state selection |
-| `mapping refresh ` | Refresh Metabase database mappings |
-| `mapping validate ` | Validate Metabase database mappings |
-| `mapping clear [dbId]` | Clear Metabase database mappings |
-| `metabase setup` | Guided setup for a Metabase connection |
-| `notion pick ` | Pick Notion root pages for a configured Notion connection |
## Options
-### `connection add`
+The `connection` command has command-level options for listing and testing
+existing connections.
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--url ` | Connection URL, `env:NAME`, or `file:/path` reference | — |
-| `--schema ` | Schema to include; repeatable | — |
-| `--readonly` | Mark the connection as read-only | `false` |
-| `--force` | Replace an existing connection | `false` |
-| `--allow-literal-credentials` | Allow writing a literal credential URL to `ktx.yaml` | `false` |
-
-#### Notion-specific options for `connection add`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--token-env ` | Environment variable containing Notion auth token | — |
-| `--token-file ` | File containing Notion auth token | — |
-| `--crawl-mode ` | Notion crawl mode (`all_accessible` or `selected_roots`) | `selected_roots` |
-| `--root-page-id ` | Root page to crawl; repeatable | — |
-| `--root-database-id ` | Root database to crawl; repeatable | — |
-| `--root-data-source-id ` | Root data source to crawl; repeatable | — |
-| `--max-pages ` | Maximum pages per run | — |
-| `--max-knowledge-creates ` | Maximum knowledge creates per run | — |
-| `--max-knowledge-updates ` | Maximum knowledge updates per run | — |
-
-### `connection remove`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--force` | Remove without prompting | `false` |
-| `--no-input` | Disable interactive terminal input | — |
-
-### `connection map`
+### `connection list`
| Flag | Description | Default |
|------|-------------|---------|
| `--json` | Print JSON output | `false` |
-### `connection mapping` subcommands
-
-| Flag | Subcommand | Description | Default |
-|------|-----------|-------------|---------|
-| `--json` | `list`, `sync-state get` | Print JSON output | `false` |
-| `--file ` | `apply-bulk` | JSON mapping file (required) | — |
-| `--enabled ` | `set-sync-enabled` | `true` or `false` (required) | — |
-| `--mode ` | `sync-state set` | `ALL`, `ONLY`, or `EXCEPT` (required) | — |
-| `--collections ` | `sync-state set` | Comma-separated collection ids | — |
-| `--items ` | `sync-state set` | Comma-separated item ids | — |
-| `--tag-names ` | `sync-state set` | Comma-separated tag names | — |
-| `--auto-accept` | `refresh` | Accept refresh changes without prompting | `false` |
-
-### `connection metabase setup`
+### `connection test`
| Flag | Description | Default |
|------|-------------|---------|
-| `--id ` | KTX connection id to write | — |
-| `--url ` | Metabase API URL | — |
-| `--api-key ` | Metabase API key | — |
-| `--mint-api-key` | Mint a Metabase API key with credentials | `false` |
-| `--username ` | Metabase admin username for API-key minting | — |
-| `--password ` | Metabase admin password for API-key minting | — |
-| `--map ` | Assign a Metabase database id to a warehouse connection; repeatable | — |
-| `--sync ` | Enable sync for a discovered database; repeatable | — |
-| `--sync-mode ` | Metabase sync selection mode (`ALL`, `ONLY`, or `EXCEPT`) | `ALL` |
-| `--run-ingest` | Run ingest after setup | `false` |
-| `--yes` | Confirm and apply setup changes without prompting | `false` |
-| `--no-input` | Disable interactive terminal input | — |
-
-### `connection notion pick`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--no-input` | Disable interactive terminal input | — |
-| `--root-page-id ` | Root page UUID to crawl; repeatable (required with `--no-input`) | — |
+| `--json` | Print JSON output | `false` |
## Examples
@@ -114,43 +43,20 @@ ktx connection [options]
# List all configured connections
ktx connection list
-# Add a Postgres connection using an environment variable
-ktx connection add postgres my-warehouse --url "env:DATABASE_URL"
-
-# Add a Postgres connection with specific schemas
-ktx connection add postgres analytics --url "env:PG_URL" --schema public --schema analytics
-
-# Add a read-only Snowflake connection
-ktx connection add snowflake sf-prod --url "env:SNOWFLAKE_URL" --readonly
-
# Test a connection
ktx connection test my-warehouse
-
-# Remove a connection
-ktx connection remove old-warehouse
-
-# Add a Notion source connection
-ktx connection add notion my-notion \
- --token-env NOTION_TOKEN \
- --crawl-mode selected_roots \
- --root-page-id abc123def456...
-
-# Run guided Metabase setup
-ktx connection metabase setup --url https://metabase.example.com
-
-# Map a BI database to a warehouse connection
-ktx connection mapping set metabase-prod databaseMappings 1=my-warehouse
-
-# Refresh Metabase mappings
-ktx connection mapping refresh metabase-prod --auto-accept
-
-# Pick Notion root pages interactively
-ktx connection notion pick my-notion
```
+## Setup-managed connections
+
+Run `ktx setup` when you need to add or reconfigure a connection. Interactive
+setup includes the rich Notion page picker for selected root pages and the
+Metabase mapping prompts for BI-to-warehouse mappings.
+
## Output
-Interactive commands render prompts and status text. Commands with `--json` return machine-readable JSON suitable for scripts and agents.
+Commands with `--json` return machine-readable JSON suitable for scripts and
+agents.
```json
{
@@ -168,7 +74,6 @@ Interactive commands render prompts and status text. Commands with `--json` retu
| Error | Cause | Recovery |
|-------|-------|----------|
-| Connection test fails | Credentials, network access, database, warehouse, or schema is invalid | Verify the same URL with the database's native client, then rerun `ktx connection add ... --force` |
-| Literal credentials rejected | KTX avoids writing raw secrets to `ktx.yaml` by default | Use `env:NAME` or `file:/path/to/secret`; use `--allow-literal-credentials` only for local throwaway projects |
-| Mapping validation fails | BI database mappings do not point at valid warehouse connections | Run `ktx connection mapping refresh --auto-accept`, then set invalid mappings explicitly |
-| Notion pick cannot run non-interactively | `--no-input` was used without root page or database ids | Pass `--root-page-id`, `--root-database-id`, or `--root-data-source-id` with `--no-input` |
+| Connection test fails | Credentials, network access, database, warehouse, or schema is invalid | Verify the same URL with the database's native client, then rerun `ktx setup` and reconfigure the connection |
+| Mapping validation fails during setup | BI database mappings do not point at valid warehouse connections | Rerun `ktx setup` and update the source mapping selections |
+| Notion page picker cannot run | The terminal is non-interactive or Notion discovery failed | Rerun interactive `ktx setup`, or use non-interactive setup flags with explicit root page ids |
diff --git a/docs-site/content/docs/cli-reference/ktx-dev.mdx b/docs-site/content/docs/cli-reference/ktx-dev.mdx
index 82ba9acb..e00a4585 100644
--- a/docs-site/content/docs/cli-reference/ktx-dev.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-dev.mdx
@@ -1,9 +1,9 @@
---
title: "ktx dev"
-description: "Low-level diagnostics, scans, adapter commands, and mapping tools."
+description: "Low-level project initialization and runtime management."
---
-Hidden commands for low-level project management, diagnostics, direct adapter control, and shell completion. Most users interact with these through higher-level commands like [`ktx ingest`](/docs/cli-reference/ktx-ingest) and [`ktx setup`](/docs/cli-reference/ktx-setup), but `ktx dev` provides direct access when you need fine-grained control.
+`ktx dev` contains development-only project initialization and managed runtime commands. Scan and ingest commands live at the root as [`ktx scan`](/docs/cli-reference/ktx-scan) and [`ktx ingest`](/docs/cli-reference/ktx-ingest).
## Command signature
@@ -16,145 +16,42 @@ ktx dev [options]
| Subcommand | Description |
|-----------|-------------|
| `init [directory]` | Initialize a Git-backed KTX project directory |
-| `runtime` | Install, inspect, and prune the KTX-managed Python runtime |
-| `scan` | Run or inspect standalone connection scans |
-| `ingest run` | Run local ingest for one configured connection and source adapter |
-| `ingest status [runId]` | Print status for a stored local ingest run |
-| `ingest watch [runId]` | Open a stored ingest visual report |
-| `ingest replay ` | Replay a stored ingest run through memory-flow output |
-| `mapping` | Manage Metabase warehouse mappings (same as `ktx connection mapping`) |
-| `completion zsh` | Generate zsh completion script |
+| `runtime` | Install, start, stop, and inspect the KTX-managed Python runtime |
-## Options
-
-### `dev init`
+## `dev init`
| Flag | Description | Default |
|------|-------------|---------|
| `--name ` | Project name written to `ktx.yaml` | — |
| `--force` | Rewrite `ktx.yaml` and scaffold files in an existing project | `false` |
-### `dev runtime`
+## `dev runtime`
+
+`ktx dev runtime` supports `install`, `start`, `stop`, and `status`.
| Flag | Description | Default |
|------|-------------|---------|
| `--feature ` | Runtime feature level for `install` and `start` (`core` or `local-embeddings`) | `core` |
-| `--json` | Print JSON output | `false` |
-| `--yes` | Confirm runtime install or prune actions where supported | `false` |
+| `--json` | Print JSON output for `status` | `false` |
+| `--yes` | Confirm runtime install actions where supported | `false` |
| `--force` | Reinstall or restart where supported | `false` |
-### `dev scan`
-
-See [`ktx scan`](/docs/cli-reference/ktx-scan) for the full scan command reference.
-
-### `dev ingest run`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--connection-id ` | KTX connection id (required) | — |
-| `--adapter ` | Ingest source adapter name (required) | — |
-| `--source-dir ` | Directory containing source files | — |
-| `--database-introspection-url ` | Daemon URL for live-database introspection | — |
-| `--debug-llm-request-file ` | Write sanitized LLM request structure to a JSONL file | — |
-| `--plain` | Print plain text output | `false` |
-| `--json` | Print JSON output | `false` |
-| `--viz` | Render memory-flow TUI output | `false` |
-| `--no-input` | Disable interactive terminal input for visualization | — |
-
-### `dev ingest status`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--report-file ` | Bundle ingest report JSON file to render | — |
-| `--plain` | Print plain text output | `false` |
-| `--json` | Print JSON output | `false` |
-| `--viz` | Render memory-flow TUI output | `false` |
-| `--no-input` | Disable interactive terminal input for visualization | — |
-
-### `dev ingest watch`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--report-file ` | Bundle ingest report JSON file to render | — |
-| `--plain` | Print plain text output | `false` |
-| `--json` | Print JSON output | `false` |
-| `--viz` | Render memory-flow TUI output (the default unless `--plain` or `--json` is set) | `true` |
-| `--no-input` | Disable interactive terminal input for visualization | — |
-
-### `dev ingest replay`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--report-file ` | Bundle ingest report JSON file to render | — |
-| `--plain` | Print plain text output | `false` |
-| `--json` | Print JSON output | `false` |
-| `--viz` | Render memory-flow TUI output | `false` |
-| `--no-input` | Disable interactive terminal input for visualization | — |
-
-### `dev completion zsh`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--install` | Install zsh completion into `~/.zfunc` and update `~/.zshrc` | `false` |
-
## Examples
```bash
-# Initialize a new KTX project
ktx dev init
-
-# Initialize in a specific directory with a project name
ktx dev init ./my-project --name "Analytics Context"
-
-# Re-initialize an existing project
ktx dev init --force
-# Check managed Python runtime readiness
-ktx dev runtime doctor
-
-# Start the managed Python daemon
+ktx dev runtime install --yes
+ktx dev runtime status
ktx dev runtime start
-
-# Run a low-level ingest with a specific adapter
-ktx dev ingest run --connection-id my-dbt --adapter dbt
-
-# Run ingest from a specific source directory
-ktx dev ingest run \
- --connection-id my-dbt \
- --adapter dbt \
- --source-dir ./dbt-project
-
-# View ingest status with the visual TUI
-ktx dev ingest watch run-abc123
-
-# Replay a stored ingest session
-ktx dev ingest replay run-abc123
-
-# View ingest status from a report file
-ktx dev ingest status --report-file /tmp/ingest-report.json
-
-# Generate zsh completions
-ktx dev completion zsh
-
-# Install zsh completions
-ktx dev completion zsh --install
+ktx dev runtime stop
```
-## Output
-
-`ktx dev` commands are diagnostic and may print plain text, JSON, or visual reports depending on the selected flags.
-
-| Mode | How to request it | Use case |
-|------|-------------------|----------|
-| Plain text | `--plain` or default diagnostic output | Human-readable terminal inspection |
-| JSON | `--json` | Agent parsing and automation |
-| Visual report | `--viz` | Interactive memory-flow and ingest debugging |
-
## Common errors
| Error | Cause | Recovery |
|-------|-------|----------|
-| Doctor reports missing runtime pieces | Packages, Python environment, or linked CLI are not ready | Run `pnpm install`, `pnpm run setup:dev`, and `uv sync --all-groups` |
-| Ingest run cannot find adapter | `--adapter` does not match a supported source adapter | Use configured source names from `ktx.yaml` or run higher-level `ktx ingest` |
-| Replay/report file cannot be read | The report path is wrong or the run id is not stored locally | Run `ktx dev ingest status --json` to discover stored run ids and report files |
-| Visual output fails in CI | TUI rendering requires an interactive terminal | Use `--plain --no-input` or `--json --no-input` |
+| Runtime status reports missing pieces | Packages, Python environment, or linked CLI are not ready | Run `pnpm install`, `pnpm run setup:dev`, `uv sync --all-groups`, then `ktx dev runtime status` |
+| Runtime daemon does not start | The managed Python runtime is missing or stale | Run `ktx dev runtime install --yes`, then `ktx dev runtime start` |
diff --git a/docs-site/content/docs/cli-reference/ktx-ingest.mdx b/docs-site/content/docs/cli-reference/ktx-ingest.mdx
index 8ce9d9a5..e1c0e339 100644
--- a/docs-site/content/docs/cli-reference/ktx-ingest.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-ingest.mdx
@@ -1,14 +1,13 @@
---
title: "ktx ingest"
-description: "Build and refresh context from configured sources."
+description: "Run and inspect local ingest memory-flow output."
---
-Ingest context from your configured sources — dbt, Looker, Metabase, MetricFlow, LookML, or Notion. The ingest process extracts metadata from your tools, then uses an LLM agent to reconcile it with existing context, writing semantic sources and knowledge pages to your project.
+`ktx ingest` runs adapter-level local ingest and renders stored ingest reports.
## Command signature
```bash
-ktx ingest [connectionId] [options]
ktx ingest [options]
```
@@ -16,80 +15,59 @@ ktx ingest [options]
| Subcommand | Description |
|-----------|-------------|
-| `status [runId]` | Print status for the latest or selected public ingest run |
-| `watch [runId]` | Open the latest or selected public ingest visual report |
+| `run` | Run local ingest for one configured connection and source adapter |
+| `status [runId]` | Print status for the latest or selected stored local ingest run or report file |
+| `watch [runId]` | Open the latest or selected stored ingest visual report |
+| `replay ` | Replay a stored ingest run or bundle report through memory-flow output |
-## Options
-
-### `ingest` (run)
+## `ingest run`
| Flag | Description | Default |
|------|-------------|---------|
-| `--all` | Ingest every eligible configured source | `false` |
+| `--connection-id ` | KTX connection id | Required |
+| `--adapter ` | Ingest source adapter name | Required |
+| `--source-dir ` | Directory containing source files | — |
+| `--database-introspection-url ` | Daemon URL for live-database introspection | — |
+| `--debug-llm-request-file ` | Write sanitized LLM request structure to a JSONL file | — |
+| `--plain` | Print plain text output | `true` |
| `--json` | Print JSON output | `false` |
-| `--no-input` | Disable interactive terminal input | — |
+| `--viz` | Render memory-flow TUI output | `false` |
+| `--yes` | Install the managed Python runtime without prompting when required | `false` |
+| `--no-input` | Disable interactive terminal input for visualization and runtime installation | — |
-### `ingest status`
+## `ingest status`, `watch`, and `replay`
| Flag | Description | Default |
|------|-------------|---------|
+| `--report-file ` | Bundle ingest report JSON file to render | — |
+| `--plain` | Print plain text output | `true` for `status` and `replay` |
| `--json` | Print JSON output | `false` |
-| `--no-input` | Disable interactive terminal input | — |
-
-### `ingest watch`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print JSON output instead of the visual report | `false` |
-| `--no-input` | Disable interactive terminal input | — |
+| `--viz` | Render memory-flow TUI output | `true` for `watch` |
+| `--no-input` | Disable interactive terminal input for visualization | — |
## Examples
```bash
-# Ingest from a specific connection
-ktx ingest my-dbt-source
+ktx ingest run --connection-id my-dbt-source --adapter dbt
+ktx ingest run --connection-id prod-metabase --adapter metabase --yes
-# Ingest from all eligible sources
-ktx ingest --all
-
-# Check the status of the latest ingest
ktx ingest status
-
-# Check the status of a specific ingest run
ktx ingest status run-abc123
-
-# Watch the latest ingest report
-ktx ingest watch
-
-# Get ingest status as JSON
ktx ingest status --json
-```
-## Low-level ingest commands
+ktx ingest watch
+ktx ingest watch run-abc123
-For adapter-level control, use `ktx dev ingest`. See [`ktx dev`](/docs/cli-reference/ktx-dev) for the full low-level ingest surface including `run`, `status`, `watch`, and `replay` with output mode options (`--plain`, `--json`, `--viz`).
-
-## Output
-
-Ingest run commands print progress and create a stored ingest report. `ktx ingest status --json` returns the run state, adapter, connection, and summary information.
-
-```json
-{
- "runId": "ingest-local-abc123",
- "status": "completed",
- "connectionId": "dbt-main",
- "summary": {
- "semanticSourcesChanged": 4,
- "knowledgePagesChanged": 2
- }
-}
+ktx ingest replay run-abc123
+ktx ingest replay run-abc123 --viz
+ktx ingest replay run-abc123 --report-file /tmp/ingest-report.json
```
## Common errors
| Error | Cause | Recovery |
|-------|-------|----------|
-| No eligible sources | `ktx.yaml` has no configured context source for ingest | Add a source with `ktx setup` or `ktx connection add`, then rerun ingest |
| Ingest needs credentials | The source adapter requires API or git access | Configure the referenced environment variable or secret file |
-| Latest run not found | No ingest run has been started in this project | Run `ktx ingest ` or `ktx ingest --all` first |
+| Ingest run cannot find adapter | `--adapter` does not match a supported source adapter | Use a configured adapter such as `dbt`, `metabase`, `looker`, `lookml`, `notion`, or `live-database` |
+| Latest run not found | No ingest run has been started in this project | Run `ktx ingest run --connection-id --adapter ` first |
| Report watch fails in a non-interactive shell | Visual report needs a terminal | Use `ktx ingest status --json` for agent and CI workflows |
diff --git a/docs-site/content/docs/cli-reference/ktx-scan.mdx b/docs-site/content/docs/cli-reference/ktx-scan.mdx
index 0c37eccb..2f73ed99 100644
--- a/docs-site/content/docs/cli-reference/ktx-scan.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-scan.mdx
@@ -1,163 +1,39 @@
---
title: "ktx scan"
-description: "Run or inspect database scans."
+description: "Run standalone database scans."
---
-Discover your database schema — tables, columns, types, constraints, and relationships. Scanning is the first step in building context: KTX needs to understand your warehouse structure before it can build semantic sources.
-
-Scan commands live under `ktx dev scan`. See also the [Building Context](/docs/guides/building-context) guide for a walkthrough.
+Discover a configured database connection's schema, including tables, columns, types, constraints, and optional relationship signals.
## Command signature
```bash
-ktx dev scan [options]
-ktx dev scan [options]
+ktx scan [options]
```
-## Subcommands
-
-| Subcommand | Description |
-|-----------|-------------|
-| `status ` | Print status for a local scan run |
-| `report ` | Print a local scan report |
-| `relationships ` | Print relationship artifacts for a local scan run |
-| `relationship-apply ` | Apply accepted relationship review decisions as manual manifest joins |
-| `relationship-feedback` | Export persisted relationship review decisions as calibration labels |
-| `relationship-calibration` | Summarize relationship feedback labels against current score thresholds |
-| `relationship-thresholds` | Evaluate relationship feedback labels for offline threshold advice |
-
## Options
-### `scan` (run)
-
| Flag | Description | Default |
|------|-------------|---------|
| `--mode ` | Scan mode: `structural`, `enriched`, or `relationships` | `structural` |
| `--dry-run` | Run without writing scan results | `false` |
| `--database-introspection-url ` | Daemon URL for live-database introspection | — |
-
-### `scan report`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--json` | Print the raw scan report JSON | `false` |
-
-### `scan relationships`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--status ` | Filter by status: `accepted`, `review`, `rejected`, `skipped`, or `all` | `review` |
-| `--limit ` | Maximum relationships to print per status | `25` |
-| `--accept ` | Record an accepted decision for a relationship candidate | — |
-| `--reject ` | Record a rejected decision for a relationship candidate | — |
-| `--note ` | Attach a note when recording a relationship review decision | — |
-| `--reviewer ` | Reviewer name for a relationship review decision | — |
-| `--json` | Print relationship artifacts as JSON | `false` |
-
-### `scan relationship-apply`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--all-accepted` | Apply all accepted relationship review decisions for the scan run | `false` |
-| `--candidate ` | Apply one accepted relationship review decision; repeatable | — |
-| `--dry-run` | Preview relationships that would be written without rewriting manifest shards | `false` |
-| `--json` | Print the apply result as JSON | `false` |
-
-### `scan relationship-feedback`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--connection ` | Only export labels for one KTX connection | — |
-| `--decision ` | Filter: `accepted`, `rejected`, or `all` | `all` |
-| `--json` | Print the export as JSON | `false` |
-| `--jsonl` | Print labels as newline-delimited JSON | `false` |
-
-### `scan relationship-calibration`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--connection ` | Only calibrate labels for one KTX connection | — |
-| `--decision ` | Filter: `accepted`, `rejected`, or `all` | `all` |
-| `--accept-threshold ` | Score threshold treated as predicted accepted (0–1) | `0.85` |
-| `--review-threshold ` | Score threshold treated as predicted review (0–1) | `0.55` |
-| `--json` | Print the calibration report as JSON | `false` |
-
-### `scan relationship-thresholds`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--connection ` | Only evaluate labels for one KTX connection | — |
-| `--min-total-labels ` | Minimum scored labels before advice can be ready | `20` |
-| `--min-accepted-labels ` | Minimum accepted labels before advice can be ready | `5` |
-| `--min-rejected-labels ` | Minimum rejected labels before advice can be ready | `5` |
-| `--json` | Print the threshold advice report as JSON | `false` |
+| `--yes` | Install the managed Python runtime without prompting when required | `false` |
+| `--no-input` | Disable interactive managed runtime installation | — |
## Examples
```bash
-# Run a structural scan of a connection
-ktx dev scan my-warehouse
-
-# Run a scan with LLM enrichment
-ktx dev scan my-warehouse --mode enriched
-
-# Run a scan with relationship detection
-ktx dev scan my-warehouse --mode relationships
-
-# Dry-run a scan (don't write results)
-ktx dev scan my-warehouse --dry-run
-
-# Check the status of a scan run
-ktx dev scan status run-abc123
-
-# View the scan report
-ktx dev scan report run-abc123
-
-# View scan report as JSON
-ktx dev scan report run-abc123 --json
-
-# List relationship candidates pending review
-ktx dev scan relationships run-abc123
-
-# List all relationships regardless of status
-ktx dev scan relationships run-abc123 --status all
-
-# Accept a relationship candidate
-ktx dev scan relationships run-abc123 --accept candidate-xyz
-
-# Reject a relationship candidate with a note
-ktx dev scan relationships run-abc123 --reject candidate-xyz --note "false positive"
-
-# Apply all accepted relationships to the manifest
-ktx dev scan relationship-apply run-abc123 --all-accepted
-
-# Preview what would be applied
-ktx dev scan relationship-apply run-abc123 --all-accepted --dry-run
-
-# Export relationship feedback as calibration labels
-ktx dev scan relationship-feedback --json
-
-# Calibrate relationship detection thresholds
-ktx dev scan relationship-calibration --accept-threshold 0.9 --review-threshold 0.6
-
-# Get threshold advice based on review decisions
-ktx dev scan relationship-thresholds
+ktx scan my-warehouse
+ktx scan my-warehouse --mode enriched
+ktx scan my-warehouse --mode relationships
+ktx scan my-warehouse --dry-run
+ktx scan my-warehouse --database-introspection-url http://127.0.0.1:8765
```
## Output
-Scan commands write scan artifacts under the KTX project directory and print status or report summaries. Use `--json` on report and relationship commands when an agent needs structured output.
-
-```json
-{
- "runId": "scan-local-abc123",
- "status": "completed",
- "mode": "structural",
- "changes": {
- "tablesAdded": 42
- }
-}
-```
+`ktx scan` prints a human summary and writes scan artifacts under the KTX project directory unless `--dry-run` is set. Use `ktx status` after a scan to inspect project readiness and next setup work.
## Common errors
@@ -165,5 +41,4 @@ Scan commands write scan artifacts under the KTX project directory and print sta
|-------|-------|----------|
| Scan cannot connect | Connection credentials or network access are invalid | Run `ktx connection test ` and update the connection before scanning |
| Enriched scan cannot describe columns | LLM credentials are missing or invalid | Complete LLM setup with `ktx setup` before enriched scans |
-| Relationship apply writes nothing | No accepted candidates match the provided run id or candidate ids | Inspect `ktx dev scan relationships --status accepted` first |
-| Calibration is not ready | Too few reviewed relationship labels exist | Review and accept/reject more candidates, then rerun calibration |
+| Relationship scan has limited evidence | The connector cannot provide optional validation or statistics | Re-run with a connector that supports the missing capability, or treat relationship output as lower-confidence context |
diff --git a/docs-site/content/docs/cli-reference/ktx-sl.mdx b/docs-site/content/docs/cli-reference/ktx-sl.mdx
index 4ec7bdd1..b3e5305f 100644
--- a/docs-site/content/docs/cli-reference/ktx-sl.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-sl.mdx
@@ -1,6 +1,6 @@
---
title: "ktx sl"
-description: "List, read, validate, query, or write semantic-layer sources."
+description: "List, search, validate, or query semantic-layer sources."
---
Interact with your project's semantic layer. Semantic sources are YAML definitions that describe your tables, columns, measures, joins, and grain — the vocabulary agents use to generate correct SQL.
@@ -16,9 +16,8 @@ ktx sl [options]
| Subcommand | Description |
|-----------|-------------|
| `list` | List semantic-layer sources |
-| `read ` | Read a semantic-layer source |
+| `search ` | Search semantic-layer sources |
| `validate ` | Validate a semantic-layer source against the database schema |
-| `write ` | Write a semantic-layer source |
| `query` | Compile or execute a semantic-layer query |
## Options
@@ -31,11 +30,14 @@ ktx sl [options]
| `--output ` | Output mode: `pretty` (default in TTY), `plain` (TSV), or `json` | `pretty` |
| `--json` | Shortcut for `--output=json` (overrides `--output`) | `false` |
-### `sl read`
+### `sl search`
| Flag | Description | Default |
|------|-------------|---------|
-| `--connection-id ` | KTX connection id (required) | — |
+| `--connection-id ` | Filter by KTX connection id | — |
+| `--limit ` | Maximum search results | — |
+| `--output ` | Output mode: `pretty` (default in TTY), `plain` (TSV), or `json` | `pretty` |
+| `--json` | Shortcut for `--output=json` (overrides `--output`) | `false` |
### `sl validate`
@@ -43,18 +45,12 @@ ktx sl [options]
|------|-------------|---------|
| `--connection-id ` | KTX connection id (required) | — |
-### `sl write`
-
-| Flag | Description | Default |
-|------|-------------|---------|
-| `--connection-id ` | KTX connection id (required) | — |
-| `--yaml ` | Semantic-layer source YAML content (required) | — |
-
### `sl query`
| Flag | Description | Default |
|------|-------------|---------|
| `--connection-id ` | KTX connection id | — |
+| `--query-file ` | JSON semantic-layer query file | — |
| `--measure ` | Measure to query; repeatable (at least one required) | — |
| `--dimension ` | Dimension to include; repeatable | — |
| `--filter ` | Filter expression; repeatable | — |
@@ -78,15 +74,12 @@ ktx sl list --connection-id my-warehouse
# List sources as JSON
ktx sl list --json
-# Read a source definition
-ktx sl read orders --connection-id my-warehouse
+# Search sources as JSON
+ktx sl search "revenue" --json
# Validate a source against the live schema
ktx sl validate orders --connection-id my-warehouse
-# Write a new source from YAML
-ktx sl write customers --connection-id my-warehouse --yaml "$(cat sources/customers.yaml)"
-
# Compile a query and view the generated SQL
ktx sl query \
--connection-id my-warehouse \
@@ -119,6 +112,13 @@ ktx sl query \
--dimension orders.created_date \
--execute \
--max-rows 1000
+
+# Execute a query from a JSON file
+ktx sl query \
+ --connection-id my-warehouse \
+ --query-file query.json \
+ --execute \
+ --max-rows 100
```
## Output
@@ -143,5 +143,5 @@ Semantic-layer commands return human-readable output by default. Use `--json` or
|-------|-------|----------|
| Source not found | Source name or connection id is wrong | Run `ktx sl list --json` and retry with an exact source name and connection id |
| Validation fails | YAML references missing columns, invalid joins, or invalid SQL expressions | Fix the source YAML and rerun `ktx sl validate` |
-| Query compile fails | Measure, dimension, filter, or segment name is invalid | Read the source with `ktx sl read`, then retry using declared fields |
+| Query compile fails | Measure, dimension, filter, or segment name is invalid | Search sources with `ktx sl search`, inspect the source YAML in your project files, then retry using declared fields |
| Execution returns too many rows | `--max-rows` is missing or too high | Add `--max-rows` with a bounded value before executing |
diff --git a/docs-site/content/docs/cli-reference/ktx-wiki.mdx b/docs-site/content/docs/cli-reference/ktx-wiki.mdx
index a709ac07..1d57a93f 100644
--- a/docs-site/content/docs/cli-reference/ktx-wiki.mdx
+++ b/docs-site/content/docs/cli-reference/ktx-wiki.mdx
@@ -1,9 +1,9 @@
---
title: "ktx wiki"
-description: "List, read, search, or write knowledge pages."
+description: "List, read, search, or write wiki pages."
---
-Manage knowledge pages in your KTX project. Knowledge pages are Markdown documents that capture business definitions, rules, and gotchas. Agents search them for context when answering questions about your data.
+Manage wiki pages in your KTX project. Wiki pages are Markdown documents that capture business definitions, rules, and gotchas. Agents search them for context when answering questions about your data.
## Command signature
@@ -26,19 +26,23 @@ ktx wiki [options]
| Flag | Description | Default |
|------|-------------|---------|
+| `--json` | Print JSON output | `false` |
| `--user-id ` | Local user id | `local` |
### `wiki read`
| Flag | Description | Default |
|------|-------------|---------|
+| `--json` | Print JSON output | `false` |
| `--user-id ` | Local user id | `local` |
### `wiki search`
| Flag | Description | Default |
|------|-------------|---------|
+| `--json` | Print JSON output | `false` |
| `--user-id ` | Local user id | `local` |
+| `--limit ` | Maximum search results | — |
### `wiki write`
@@ -58,18 +62,27 @@ ktx wiki [options]
# List all wiki pages
ktx wiki list
+# List all wiki pages as JSON
+ktx wiki list --json
+
# Read a specific wiki page
ktx wiki read revenue-definitions
+# Read a specific wiki page as JSON
+ktx wiki read revenue-definitions --json
+
# Search wiki pages
ktx wiki search "monthly recurring revenue"
-# Write a global knowledge page
+# Search wiki pages as JSON
+ktx wiki search "monthly recurring revenue" --json --limit 10
+
+# Write a global wiki page
ktx wiki write revenue-definitions \
--summary "Canonical revenue metric definitions" \
--content "## MRR\nMonthly Recurring Revenue is calculated as..."
-# Write a user-scoped knowledge page
+# Write a user-scoped wiki page
ktx wiki write my-notes \
--scope user \
--summary "Personal analysis notes" \
@@ -93,17 +106,20 @@ ktx wiki write data-freshness \
## Output
-Wiki commands print local knowledge pages and search results. Agents should search first, then read the most relevant page by key.
+Wiki commands print local wiki pages and search results. Agents should search first, then read the most relevant page by key.
```json
{
- "results": [
- {
- "key": "revenue-definitions",
- "summary": "Canonical revenue metric definitions",
- "score": 0.92
- }
- ]
+ "kind": "list",
+ "data": {
+ "items": [
+ {
+ "key": "revenue-definitions",
+ "summary": "Canonical revenue metric definitions",
+ "score": 0.92
+ }
+ ]
+ }
}
```
diff --git a/docs-site/content/docs/cli-reference/meta.json b/docs-site/content/docs/cli-reference/meta.json
index a5d7a95f..bed3f98c 100644
--- a/docs-site/content/docs/cli-reference/meta.json
+++ b/docs-site/content/docs/cli-reference/meta.json
@@ -9,7 +9,6 @@
"ktx-sl",
"ktx-wiki",
"ktx-status",
- "ktx-agent",
"ktx-dev"
]
}
diff --git a/docs-site/content/docs/concepts/context-as-code.mdx b/docs-site/content/docs/concepts/context-as-code.mdx
index e40665ec..51141b85 100644
--- a/docs-site/content/docs/concepts/context-as-code.mdx
+++ b/docs-site/content/docs/concepts/context-as-code.mdx
@@ -7,9 +7,9 @@ description: Treat analytics context like code — version it, review it, merge
dbt proved that analytics transformations belong in version control. Before dbt, SQL lived in BI tools, scheduling systems, and spreadsheets — scattered, unreviewed, impossible to audit. "Analytics as code" changed that: put your models in git, review them in PRs, deploy them by merging.
-KTX applies the same principle to analytics context. Metric definitions, business rules, join relationships, knowledge pages — these are artifacts that determine whether an agent produces correct results. They change over time. They need review. They need history. They need to be treated like code.
+KTX applies the same principle to analytics context. Metric definitions, business rules, join relationships, wiki pages — these are artifacts that determine whether an agent produces correct results. They change over time. They need review. They need history. They need to be treated like code.
-A KTX project is a git repository. Semantic sources are YAML files. Knowledge pages are Markdown files. Changes are commits. Updates are pull requests. Deployment is a merge. The entire lifecycle of your analytics context follows the same workflow your team already uses for dbt models, application code, and infrastructure.
+A KTX project is a git repository. Semantic sources are YAML files. Wiki pages are Markdown files. Changes are commits. Updates are pull requests. Deployment is a merge. The entire lifecycle of your analytics context follows the same workflow your team already uses for dbt models, application code, and infrastructure.
## Auto-ingestion
@@ -19,9 +19,9 @@ An ingestion run works like this:
1. **Adapters extract metadata.** Each configured source — dbt, LookML, Metabase, MetricFlow, Notion, or your live database — provides structured metadata about models, metrics, dimensions, questions, and documentation.
-2. **The LLM agent reconciles.** KTX doesn't blindly overwrite existing context. An LLM agent compares incoming metadata against your current semantic sources and knowledge pages. It decides what to create, what to update, and what to leave alone. If your dbt project added a new model, the agent writes a new semantic source. If a Metabase question references a metric you've already defined, the agent skips the duplicate.
+2. **The LLM agent reconciles.** KTX doesn't blindly overwrite existing context. An LLM agent compares incoming metadata against your current semantic sources and wiki pages. It decides what to create, what to update, and what to leave alone. If your dbt project added a new model, the agent writes a new semantic source. If a Metabase question references a metric you've already defined, the agent skips the duplicate.
-3. **Files are written.** New and updated YAML sources and Markdown knowledge pages are written to the project directory. Every decision is recorded in the session transcript.
+3. **Files are written.** New and updated YAML sources and Markdown wiki pages are written to the project directory. Every decision is recorded in the session transcript.
This reconciliation step is what separates auto-ingestion from a simple sync. A naive import would overwrite your hand-tuned metric definitions every time dbt's manifest changes. KTX's agent-driven approach merges intelligently: it respects your edits, fills gaps, and flags conflicts for human review.
@@ -43,7 +43,7 @@ dbt / Looker / Metabase / Notion
|
| + 3 new sources
| ~ 2 updated joins
- | + 1 knowledge page
+ | + 1 wiki page
v
open PR
|
@@ -57,9 +57,9 @@ dbt / Looker / Metabase / Notion
agents see updated context
```
-A typical branch shows a semantic diff: "this ingest added 3 new sources from dbt, updated 2 join definitions based on schema changes, and created 1 knowledge page from a Notion doc." Analytics engineers review the diff, verify that the new sources look correct, and merge.
+A typical branch shows a semantic diff: "this ingest added 3 new sources from dbt, updated 2 join definitions based on schema changes, and created 1 wiki page from a Notion doc." Analytics engineers review the diff, verify that the new sources look correct, and merge.
-Teams usually run this on demand while setting up a source, then schedule it once the source is stable. A cron job or CI schedule can run `ktx ingest --all --no-input` overnight on an ingest branch so the latest dbt manifests, BI metadata, and documentation updates are ready for review each morning.
+Teams usually run this on demand while setting up a source, then schedule it once the source is stable. A cron job or CI schedule can run `ktx ingest run --connection-id --adapter --no-input` overnight on an ingest branch so the latest dbt manifests, BI metadata, and documentation updates are ready for review each morning.
Once merged, agents querying through the KTX CLI see the updated context immediately. No deployment step, no cache invalidation, no restart. The files are the source of truth, and agents read them on every request.
@@ -69,9 +69,9 @@ This workflow gives you the same review guarantees you have for dbt models. No s
Context improves over time through two feedback channels.
-**Analyst corrections.** When an analytics engineer spots something wrong — a measure formula that doesn't match the business definition, a join that should be `many_to_one` instead of `one_to_many`, a knowledge page that's out of date — they edit the YAML or Markdown directly and commit. These corrections become part of the project's git history, and the next ingestion run respects them. If you manually fix a measure definition, KTX won't overwrite it on the next ingest.
+**Analyst corrections.** When an analytics engineer spots something wrong — a measure formula that doesn't match the business definition, a join that should be `many_to_one` instead of `one_to_many`, a wiki page that's out of date — they edit the YAML or Markdown directly and commit. These corrections become part of the project's git history, and the next ingestion run respects them. If you manually fix a measure definition, KTX won't overwrite it on the next ingest.
-**Agent feedback.** When an agent queries the semantic layer and gets unexpected results — a query that returns no rows because of a bad filter, a join path that produces duplicated results — it can flag the issue. These signals feed back into the context: knowledge pages can note known data quality issues, and source definitions can be tightened with better filters, join paths, or grain declarations.
+**Agent feedback.** When an agent queries the semantic layer and gets unexpected results — a query that returns no rows because of a bad filter, a join path that produces duplicated results — it can flag the issue. These signals feed back into the context: wiki pages can note known data quality issues, and source definitions can be tightened with better filters, join paths, or grain declarations.
Each of these channels makes the next ingestion cycle better. Analyst corrections teach the system what your team considers authoritative. Agent feedback surfaces gaps in coverage. Context is not a static artifact — it's a living system that converges toward accuracy with every iteration.
diff --git a/docs-site/content/docs/concepts/the-context-layer.mdx b/docs-site/content/docs/concepts/the-context-layer.mdx
index 70480f48..d9021a8e 100644
--- a/docs-site/content/docs/concepts/the-context-layer.mdx
+++ b/docs-site/content/docs/concepts/the-context-layer.mdx
@@ -30,7 +30,7 @@ A context layer is the infrastructure that gives agents the business knowledge t
KTX organizes context into four pillars:
- Semantic sources
-- Knowledge pages
+- Wiki pages
- Scan artifacts
- Provenance
@@ -67,7 +67,7 @@ measures:
expr: count(id)
```
-**Knowledge pages** are Markdown documents that capture business definitions, rules, and operating context — the kind of context that doesn't fit in a schema definition. Pages have structured frontmatter (summary, tags, semantic layer references) and free-form content. Agents search them when they need to understand why a metric works a certain way, not just how to compute it.
+**Wiki pages** are Markdown documents that capture business definitions, rules, and operating context — the kind of context that doesn't fit in a schema definition. Pages have structured frontmatter (summary, tags, semantic layer references) and free-form content. Agents search them when they need to understand why a metric works a certain way, not just how to compute it.
```markdown
---
@@ -97,13 +97,13 @@ Together, these four pillars give agents enough context to produce analytics art
## How KTX compares
-KTX is a context layer with an agent-native semantic layer at its core. MetricFlow, Cube, and Malloy model metrics, dimensions, joins, and generated SQL. KTX covers that semantic-layer work, then adds the context agents need to use and maintain it: knowledge pages, schema scans, provenance, ingestion, validation, and agent-facing CLI commands.
+KTX is a context layer with an agent-native semantic layer at its core. MetricFlow, Cube, and Malloy model metrics, dimensions, joins, and generated SQL. KTX covers that semantic-layer work, then adds the context agents need to use and maintain it: wiki pages, schema scans, provenance, ingestion, validation, and agent-facing CLI commands.
The workflow is the difference. Traditional semantic layers are powerful, but they are usually built and maintained through manual modeling work, product-specific runtimes, or language-specific workflows. They are not agent-native by default, which makes them harder for agents to inspect, edit, validate, and review in a tight loop. KTX is designed for agents that need to read context, change semantic files, inspect generated SQL, and leave a reviewable git diff.
| | KTX semantic layer | MetricFlow | Cube | Malloy |
|---|---|---|---|---|
-| **Model surface** | Plain YAML sources plus Markdown knowledge pages | YAML semantic models and metrics in a dbt project | YAML or JavaScript cubes, views, access policies, and pre-aggregations | `.malloy` models, query pipelines, notebooks, and annotations |
+| **Model surface** | Plain YAML sources plus Markdown wiki pages | YAML semantic models and metrics in a dbt project | YAML or JavaScript cubes, views, access policies, and pre-aggregations | `.malloy` models, query pipelines, notebooks, and annotations |
| **What it models** | Sources, columns, measures, segments, joins, grain, filters, default time dimensions, and context references | Semantic models, entities, dimensions, measures, metrics, time grains, and metric types | Cubes, views, measures, dimensions, segments, joins, hierarchies, policies, and rollups | Sources, joins, dimensions, measures, calculations, nested results, and query pipelines |
| **Agent edit loop** | First-class. Agents can patch small files, save imperfect drafts, run validation, query through the CLI, inspect SQL, and refine in the same workflow | Possible, but the interface is a dbt/metric workflow rather than an agent context workflow | Possible through code-first models and platform APIs, but changes are tied to runtime deployment and governance concerns | Possible, but agents must operate in Malloy's language and compiler model |
| **Fan-out safety** | Explicit `grain` plus relationship metadata. KTX detects `one_to_many` fan-out, identifies chasm traps, pre-aggregates independent fact measures into CTEs, and rejects unsafe filters | Dataflow query planning for metric requests, multi-hop joins, metric time, and metric types | Runtime planner, modeled joins, primary keys, views, multi-fact views, and pre-aggregations | Symmetric aggregates and path-based aggregation in the language |
@@ -111,7 +111,7 @@ The workflow is the difference. Traditional semantic layers are powerful, but th
| **Context around semantics** | Built in: wiki pages, scan artifacts, relationship inference, ingest transcripts, replay, and agent-facing CLI commands | Primarily metric and dbt project context | Descriptions and `meta.ai_context` inside the semantic model, plus platform agent features | Annotations/tags can carry metadata; surrounding context depends on the application |
| **Best fit** | Agents maintaining analytics code, metrics, joins, SQL, docs, and semantic definitions | Teams standardizing metrics inside dbt workflows | Production semantic APIs, BI integrations, access control, caching, and concurrency | Expressive modeling and exploratory analysis above SQL |
-If you do not have a semantic layer, KTX can build an agent-native one from your database schema and enrich it with generated descriptions and knowledge pages. If you already use MetricFlow or LookML, KTX ingests from those tools and merges their context into KTX's files. You can keep your existing BI or metric-serving system while using KTX as the semantic and contextual surface agents work against.
+If you do not have a semantic layer, KTX can build an agent-native one from your database schema and enrich it with generated descriptions and wiki pages. If you already use MetricFlow or LookML, KTX ingests from those tools and merges their context into KTX's files. You can keep your existing BI or metric-serving system while using KTX as the semantic and contextual surface agents work against.
## The plain-files philosophy
@@ -125,7 +125,7 @@ my-project/
│ ├── orders.yaml # Semantic source definitions
│ ├── customers.yaml
│ └── order_items.yaml
-├── knowledge/
+├── wiki/
│ ├── global/
│ │ ├── revenue.md # Business definitions and rules
│ │ └── segment-classification.md
@@ -140,7 +140,7 @@ my-project/
└── cache/ # Runtime cache (git-ignored)
```
-Semantic sources and knowledge pages are committed to git. The SQLite database holds ephemeral state — scan results, embedding indexes, session logs — and is git-ignored. If you delete it, KTX rebuilds it on the next run.
+Semantic sources and wiki pages are committed to git. The SQLite database holds ephemeral state — scan results, embedding indexes, session logs — and is git-ignored. If you delete it, KTX rebuilds it on the next run.
This means your analytics context travels with your code. You can fork it, branch it, review it in a PR, and merge it with the same tools you use for dbt models. There's no sync problem between a remote server and your local state. There's no migration to run. The files are the source of truth.
diff --git a/docs-site/content/docs/getting-started/introduction.mdx b/docs-site/content/docs/getting-started/introduction.mdx
index a9d98d3e..70ca9a84 100644
--- a/docs-site/content/docs/getting-started/introduction.mdx
+++ b/docs-site/content/docs/getting-started/introduction.mdx
@@ -88,5 +88,5 @@ Works with PostgreSQL, Snowflake, BigQuery, ClickHouse, MySQL, and SQL Server.
| Set up a new KTX project | [Quickstart](/docs/getting-started/quickstart) |
| Explain what problem KTX solves | [The Context Layer](/docs/concepts/the-context-layer) |
| Scan a database and ingest metadata | [Building Context](/docs/guides/building-context) |
-| Edit semantic sources or knowledge pages | [Writing Context](/docs/guides/writing-context) |
+| Edit semantic sources or wiki pages | [Writing Context](/docs/guides/writing-context) |
| Look up exact command flags | [CLI Reference](/docs/cli-reference/ktx-setup) |
diff --git a/docs-site/content/docs/getting-started/quickstart.mdx b/docs-site/content/docs/getting-started/quickstart.mdx
index ece3ceac..7aba00fd 100644
--- a/docs-site/content/docs/getting-started/quickstart.mdx
+++ b/docs-site/content/docs/getting-started/quickstart.mdx
@@ -146,7 +146,7 @@ This is where KTX does the heavy lifting. It runs an enriched scan of your datab
│ ○ Leave context unbuilt and exit setup
```
-The build scans each primary source with LLM enrichment, detects table relationships, and runs ingestion agents that reconcile metadata from your context sources into semantic-layer YAML files and knowledge pages.
+The build scans each primary source with LLM enrichment, detects table relationships, and runs ingestion agents that reconcile metadata from your context sources into semantic-layer YAML files and wiki pages.
For a small database (under 50 tables), this takes a few minutes. Larger warehouses can take longer. You can press d to detach and let it run in the background:
@@ -208,10 +208,10 @@ KTX writes project state as plain files so agents can inspect and edit changes i
|------|------------|---------|
| `ktx.yaml` | `ktx setup` | Main project configuration: connections, LLM settings, embeddings, and context sources |
| `.ktx/secrets/*` | `ktx setup` when file-backed secrets are selected | Local secret files referenced from `ktx.yaml`; do not commit these |
-| `semantic-layer//*.yaml` | context build, ingestion, or `ktx sl write` | Semantic source definitions agents use for SQL generation |
-| `knowledge/global/*.md` | ingestion or `ktx wiki write --scope global` | Shared business context and metric definitions |
-| `knowledge/user//*.md` | `ktx wiki write --scope user` | User-scoped notes for one agent/user context |
-| `.claude/skills/ktx/SKILL.md`, `.agents/skills/ktx/SKILL.md` | CLI-mode agent integration setup | Agent instructions for calling `ktx agent` commands |
+| `semantic-layer//*.yaml` | context build, ingestion, or direct file edits | Semantic source definitions agents use for SQL generation |
+| `wiki/global/*.md` | ingestion, memory capture, `ktx wiki write --scope global`, or direct file edits | Shared business context and metric definitions |
+| `wiki/user//*.md` | memory capture, `ktx wiki write --scope user`, or direct file edits | User-scoped notes for one agent/user context |
+| `.claude/skills/ktx/SKILL.md`, `.agents/skills/ktx/SKILL.md` | CLI-mode agent integration setup | Agent instructions for calling public `ktx` commands |
## Verify it worked
@@ -239,14 +239,14 @@ Agent integration ready: yes (claude-code:project)
| `ktx: command not found` | The KTX package is not installed globally, or the shell cannot find the global binary | Run `npm install -g @kaelio/ktx` and open a new shell |
| LLM health check fails | Missing, invalid, or unauthorized Anthropic API key | Export `ANTHROPIC_API_KEY` or rerun `ktx setup` and choose the file-backed secret option |
| OpenAI embedding check fails | `OPENAI_API_KEY` is missing when OpenAI embeddings are selected | Export `OPENAI_API_KEY`, or rerun setup and choose local sentence-transformers embeddings |
-| Local embeddings hang or fail | The managed Python runtime cannot start or the local model runtime is unavailable | Install `uv`, run `ktx dev runtime doctor`, then run `ktx dev runtime install --feature local-embeddings --yes` and rerun setup |
-| Database connection test fails | Credentials, network access, warehouse, database, or schema value is wrong | Test the same URL with the database's native client, then rerun `ktx connection add ... --force` or rerun setup |
+| Local embeddings hang or fail | The managed Python runtime cannot start or the local model runtime is unavailable | Install `uv`, run `ktx dev runtime status`, then run `ktx dev runtime install --feature local-embeddings --yes` and rerun setup |
+| Database connection test fails | Credentials, network access, warehouse, database, or schema value is wrong | Test the same URL with the database's native client, then rerun `ktx setup` and reconfigure the connection |
| `KTX context built: no` in `ktx status` | Setup saved configuration but did not build context | Run `ktx setup` and choose to build context now |
| Agent integration is incomplete | Setup skipped the agents step or the target was not installed | Run `ktx setup --agents --target codex --project` using the target you need |
## Next steps
- **Build more context** — learn about [scanning](/docs/guides/building-context), relationship detection, and ingestion workflows in the Building Context guide.
-- **Refine your semantic layer** — the [Writing Context](/docs/guides/writing-context) guide covers source YAML, measures, joins, and knowledge pages.
+- **Refine your semantic layer** — the [Writing Context](/docs/guides/writing-context) guide covers source YAML, measures, joins, and wiki pages.
- **Understand the architecture** — read [The Context Layer](/docs/concepts/the-context-layer) to learn why a context layer is more than a semantic layer.
- **Connect more agents** — see the [Agent Clients](/docs/integrations/agent-clients) integration page for per-tool setup details.
diff --git a/docs-site/content/docs/guides/building-context.mdx b/docs-site/content/docs/guides/building-context.mdx
index 31d55bac..c3821a52 100644
--- a/docs-site/content/docs/guides/building-context.mdx
+++ b/docs-site/content/docs/guides/building-context.mdx
@@ -12,7 +12,7 @@ Scanning connects to your database and extracts structural metadata. KTX stores
### Running a scan
```bash
-ktx dev scan
+ktx scan
```
This runs a structural scan by default. You can control what the scan does with the `--mode` flag:
@@ -25,25 +25,18 @@ This runs a structural scan by default. You can control what the scan does with
```bash
# Scan with relationship detection
-ktx dev scan my-postgres --mode relationships
+ktx scan my-postgres --mode relationships
# Preview without writing results
-ktx dev scan my-postgres --dry-run
+ktx scan my-postgres --dry-run
```
-### Checking scan status
+### Checking scan results
-Every scan produces a run ID. Use it to check progress or review results:
+Every scan prints a summary and writes local artifacts. Use `ktx status` after a scan to review project readiness and follow-up setup work:
```bash
-# Check status of a scan run
-ktx dev scan status
-
-# Print the full scan report
-ktx dev scan report
-
-# Get the report as JSON for scripting
-ktx dev scan report --json
+ktx status
```
### Relationship detection
@@ -56,53 +49,11 @@ Many databases lack declared foreign keys. KTX infers relationships by scoring c
| 0.55 – 0.84 | `review` | Plausible — needs human review |
| < 0.55 | `rejected` | Low confidence — not applied |
-After a relationship scan, review the candidates:
-
-```bash
-# Show candidates pending review (default)
-ktx dev scan relationships
-
-# Show all candidates regardless of status
-ktx dev scan relationships --status all
-
-# Accept a specific candidate
-ktx dev scan relationships --accept
-
-# Reject a candidate with a note
-ktx dev scan relationships --reject --note "These columns share a name but are unrelated"
-```
-
-Once you've reviewed candidates, apply the accepted ones as joins in your semantic layer:
-
-```bash
-# Apply all accepted relationships
-ktx dev scan relationship-apply --all-accepted
-
-# Preview what would be applied
-ktx dev scan relationship-apply --all-accepted --dry-run
-
-# Apply a specific candidate
-ktx dev scan relationship-apply --candidate
-```
-
-### Calibrating thresholds
-
-As you review more relationships, KTX can evaluate whether the default thresholds (0.85 accept, 0.55 review) are optimal for your schema:
-
-```bash
-# See how your feedback aligns with current thresholds
-ktx dev scan relationship-calibration --connection my-postgres
-
-# Get threshold recommendations (needs 20+ labels, 5+ accepted, 5+ rejected)
-ktx dev scan relationship-thresholds --connection my-postgres
-
-# Export your review decisions as calibration labels
-ktx dev scan relationship-feedback --connection my-postgres
-```
+Relationship scans run with `ktx scan --mode relationships`. This command only executes the scan; relationship review and calibration subcommands are not part of the current CLI surface.
## Ingestion
-Ingestion pulls semantic context from your existing analytics tools — dbt projects, Looker models, Metabase questions, and more — and writes it into your KTX project as semantic sources and knowledge pages.
+Ingestion pulls semantic context from your existing analytics tools — dbt projects, Looker models, Metabase questions, and more — and writes it into your KTX project as semantic sources and wiki pages.
### How it works
@@ -110,24 +61,12 @@ Each ingest run follows this flow:
1. An **adapter** extracts metadata from your tool (dbt manifest, LookML files, Metabase API, etc.)
2. An **LLM agent** reconciles the extracted metadata with your existing context — it merges intelligently rather than overwriting
-3. **Semantic sources** (YAML) and **knowledge pages** (Markdown) are written to your project directory
+3. **Semantic sources** (YAML) and **wiki pages** (Markdown) are written to your project directory
### Running an ingest
```bash
-# Ingest one configured context source
-ktx ingest my-dbt-source
-
-# Ingest every configured context source
-ktx ingest --all
-```
-
-The public `ktx ingest` command uses the source configuration in `ktx.yaml`, including the source `driver` and any adapter-specific paths or credentials.
-
-For adapter-level debugging, use the low-level `ktx dev ingest run` command:
-
-```bash
-ktx dev ingest run --connection-id my-dbt-source --adapter dbt
+ktx ingest run --connection-id my-dbt-source --adapter dbt
```
Useful low-level flags:
@@ -152,7 +91,7 @@ ktx ingest status
ktx ingest watch
# Replay a past ingest run
-ktx dev ingest replay
+ktx ingest replay
```
The `watch` command opens an interactive TUI that shows the memory-flow output — every tool call, LLM decision, and artifact written during the ingest.
@@ -174,7 +113,7 @@ See [Context Sources](/docs/integrations/context-sources) for adapter-specific s
### What gets generated
-A typical dbt ingest produces semantic sources and knowledge pages in your project:
+A typical dbt ingest produces semantic sources and wiki pages in your project:
**Semantic source** (`semantic-layer/my-postgres/orders.yaml`):
@@ -210,7 +149,7 @@ joins:
relationship: many_to_one
```
-**Knowledge page** (`knowledge/global/order-status-definitions.md`):
+**Wiki page** (`wiki/global/order-status-definitions.md`):
```markdown
---
@@ -235,7 +174,7 @@ Orders in "pending" status for more than 48 hours are flagged for review.
Every ingest session records a full transcript — tool calls, LLM responses, and write decisions. You can replay any session to debug why a source was written a certain way:
```bash
-ktx dev ingest replay --viz
+ktx ingest replay --viz
```
This opens the same TUI view as the original run, letting you step through the agent's reasoning.
diff --git a/docs-site/content/docs/guides/serving-agents.mdx b/docs-site/content/docs/guides/serving-agents.mdx
index 4285611b..4a93ae43 100644
--- a/docs-site/content/docs/guides/serving-agents.mdx
+++ b/docs-site/content/docs/guides/serving-agents.mdx
@@ -3,61 +3,44 @@ title: Serving Agents
description: Expose your context to Claude Code, Cursor, Codex, and other coding agents.
---
-Once you've built and refined your context, the final step is exposing it to
-coding agents. KTX provides machine-readable CLI commands for direct terminal
-access from Claude Code, Cursor, Codex, OpenCode, and custom agent workflows.
+Once you've built and refined your context, expose it to coding agents through
+the public KTX CLI. Claude Code, Cursor, Codex, OpenCode, and custom agent
+workflows can call the same commands you use at a terminal.
## CLI Commands
-KTX provides a set of machine-readable commands under `ktx agent`. These return
-JSON output designed for programmatic consumption.
+KTX public commands support JSON output for the context reads that agents use
+most often. Use `--project-dir` when the agent is not already running inside the
+KTX project directory.
### Available commands
```bash
-# List available tools and their descriptions
-ktx agent tools --json
-
-# Get project context for planning
-ktx agent context --json
+# Check setup and context readiness
+ktx status --json
```
**Semantic layer:**
```bash
# List sources
-ktx agent sl list --json
-ktx agent sl list --json --connection-id my-postgres
-
-# Read a source
-ktx agent sl read orders --json --connection-id my-postgres
+ktx sl list --json
+ktx sl list --json --connection-id my-postgres
+ktx sl search "revenue" --json
# Run a query from a JSON file
-ktx agent sl query --json \
+ktx sl query --json \
--connection-id my-postgres \
--query-file query.json \
--execute \
--max-rows 100
```
-**Knowledge:**
+**Wiki:**
```bash
-# Search knowledge pages
-ktx agent wiki search "revenue recognition" --json --limit 10
-
-# Read a specific page
-ktx agent wiki read order-status-definitions --json
-```
-
-**SQL execution:**
-
-```bash
-# Execute read-only SQL with a row limit
-ktx agent sql execute --json \
- --connection-id my-postgres \
- --sql-file query.sql \
- --max-rows 500
+# Search wiki pages
+ktx wiki search "revenue recognition" --json --limit 10
```
## Setting Up Your Agent
@@ -73,4 +56,4 @@ configuration. For manual setup or per-tool details, see the
[Agent Clients](/docs/integrations/agent-clients) integration page.
After configuration, the agent can immediately call KTX commands to list
-sources, search knowledge, and query your semantic layer.
+sources, search wiki pages, and query your semantic layer.
diff --git a/docs-site/content/docs/guides/writing-context.mdx b/docs-site/content/docs/guides/writing-context.mdx
index 3f0e3fbd..b6ca3597 100644
--- a/docs-site/content/docs/guides/writing-context.mdx
+++ b/docs-site/content/docs/guides/writing-context.mdx
@@ -1,20 +1,20 @@
---
title: Writing Context
-description: Write and refine semantic sources and knowledge pages.
+description: Write and refine semantic sources and wiki pages.
---
-After building context through scanning and ingestion, you'll want to refine it — edit semantic sources to match your business logic, add knowledge pages that capture tribal knowledge, and query your data through the semantic layer to verify everything works.
+After building context through scanning and ingestion, you'll want to refine it — edit semantic sources to match your business logic, add wiki pages that capture tribal knowledge, and query your data through the semantic layer to verify everything works.
## Agent workflow summary
Agents should refine context in this order:
1. `ktx sl list --json` — discover available sources and connection ids.
-2. `ktx sl read --connection-id ` — inspect the current YAML.
-3. Edit the source YAML directly or use `ktx sl write`.
+2. `ktx sl search --json` — find source candidates for a concept.
+3. Edit the source YAML directly in `semantic-layer//`.
4. `ktx sl validate --connection-id ` — verify columns, joins, and table references.
5. `ktx sl query ... --format sql` — compile a representative query without executing it.
-6. `ktx wiki search ...` and `ktx wiki write ...` — add business context that does not belong in schema YAML.
+6. `ktx wiki search ...` — check business context captured by ingest or memory.
## Semantic Sources
@@ -33,13 +33,14 @@ ktx sl list --connection-id my-postgres
ktx sl list --json
```
-### Reading a source
+### Searching sources
```bash
-ktx sl read orders --connection-id my-postgres
+ktx sl search "revenue" --connection-id my-postgres --json
```
-This prints the full YAML definition for the source.
+Search returns ranked source summaries. To inspect or edit a source, open the
+YAML file under `semantic-layer//`.
### The source schema
@@ -147,25 +148,10 @@ Column visibility controls what agents see:
| `internal` | Available for joins and measures but not shown to agents |
| `hidden` | Excluded entirely — useful for ETL columns |
-### Writing a source
+### Editing a source
-```bash
-ktx sl write orders --connection-id my-postgres --yaml '
-name: orders
-table: public.orders
-grain: [order_id]
-columns:
- - name: order_id
- type: string
- - name: total_amount
- type: number
-measures:
- - name: total_revenue
- expr: SUM(total_amount)
-'
-```
-
-You can also edit source files directly — they live at `semantic-layer//.yaml` in your project directory.
+Edit source files directly. They live at
+`semantic-layer//.yaml` in your project directory.
### Validating sources
@@ -225,28 +211,27 @@ The query planner is grain-aware — it understands the cardinality of joins and
### Workflow: edit and validate a source
-1. `ktx sl read orders --connection-id my-postgres > /tmp/orders.yaml` — capture the current definition.
-2. Edit `/tmp/orders.yaml` to add columns, measures, joins, or descriptions.
-3. `ktx sl write orders --connection-id my-postgres --yaml "$(cat /tmp/orders.yaml)"` — write the updated source.
-4. `ktx sl validate orders --connection-id my-postgres` — check the definition against the live schema.
-5. `ktx sl query --connection-id my-postgres --measure total_revenue --dimension order_date --format sql` — compile a representative query.
+1. Open `semantic-layer/my-postgres/orders.yaml`.
+2. Edit the file to add columns, measures, joins, or descriptions.
+3. `ktx sl validate orders --connection-id my-postgres` — check the definition against the live schema.
+4. `ktx sl query --connection-id my-postgres --measure total_revenue --dimension order_date --format sql` — compile a representative query.
If validation fails, fix the YAML before asking an agent to use the source. Common validation failures are missing columns, invalid join targets, and measure expressions that reference fields outside the source.
-## Knowledge Pages
+## Wiki Pages
-Knowledge pages are Markdown files that capture business context — definitions, rules, gotchas, and anything an agent needs to understand beyond what the schema tells it.
+Wiki pages are Markdown files that capture business context — definitions, rules, gotchas, and anything an agent needs to understand beyond what the schema tells it.
### What they are
-When an agent asks "what counts as an active user?" or "why do revenue numbers differ between the dashboard and the SQL query?", the answer isn't in the schema. It's tribal knowledge that lives in Slack threads, Notion pages, or someone's head. Knowledge pages make that context searchable and available to agents.
+When an agent asks "what counts as an active user?" or "why do revenue numbers differ between the dashboard and the SQL query?", the answer isn't in the schema. It's tribal knowledge that lives in Slack threads, Notion pages, or someone's head. Wiki pages make that context searchable and available to agents.
### Organization
-Knowledge pages are organized by scope:
+Wiki pages are organized by scope:
```
-knowledge/
+wiki/
├── global/ # Cross-cutting definitions
│ ├── order-status-definitions.md
│ ├── revenue-recognition-rules.md
@@ -260,42 +245,17 @@ knowledge/
- **Global pages** apply across all connections — business definitions, metric standards, company terminology.
- **User-scoped pages** are private to a user ID — personal notes, local gotchas, or context you do not want shared globally.
-### Writing pages
+### Editing pages
-```bash
-ktx wiki write order-status-definitions \
- --scope global \
- --summary "Business definitions for order status values" \
- --content "## Order Statuses
+Create and edit wiki pages directly as Markdown files in the `wiki/`
+directory, or with `ktx wiki write`. Ingest and memory capture also create
+these pages automatically.
-- **pending**: Order placed but not yet processed
-- **confirmed**: Payment received, awaiting fulfillment
-- **shipped**: Order dispatched to carrier
-- **delivered**: Order received by customer
-- **cancelled**: Order cancelled before shipment
-
-Orders in pending status for more than 48 hours are flagged for review." \
- --tag orders \
- --tag definitions \
- --sl-ref orders
-```
-
-Write flags:
-
-| Flag | Description |
-|------|-------------|
-| `--scope ` | `global` (default) or `user` |
-| `--summary ` | Short description for search results (required) |
-| `--content ` | Full Markdown content (required) |
-| `--tag ` | Categorization tag (repeatable) |
-| `--ref ` | Reference to external resources (repeatable) |
-| `--sl-ref ` | Link to a semantic source (repeatable) |
-
-Knowledge page fields:
+Wiki page fields:
| Field | Required | Description |
|-------|----------|-------------|
-| Key | Yes | Stable page identifier passed to `ktx wiki read` |
+| Key | Yes | Stable page identifier used as the Markdown filename |
| Summary | Yes | Short text shown in search results |
| Content | Yes | Full Markdown business context |
| Scope | No | `global` for shared context or `user` for user-scoped notes |
@@ -303,20 +263,12 @@ Knowledge page fields:
| External refs | No | Links or identifiers for source-of-truth systems |
| Semantic-layer refs | No | Source names the page explains or constrains |
-You can also create and edit knowledge pages directly as Markdown files in the `knowledge/` directory.
-
### Listing pages
```bash
ktx wiki list
```
-### Reading a page
-
-```bash
-ktx wiki read order-status-definitions
-```
-
### Searching
```bash
@@ -328,9 +280,9 @@ Search uses both full-text matching and semantic similarity — it finds relevan
### Workflow: add searchable business context
1. Search first: `ktx wiki search "order status definitions"`.
-2. If no page already covers the rule, write a page with `ktx wiki write`.
-3. Include a concise `--summary`; agents see this before loading full content.
-4. Add `--tag` values for the business area and `--sl-ref` values for related semantic sources.
+2. If no page already covers the rule, create or edit a Markdown file under `wiki/global/`.
+3. Include concise frontmatter; agents see the summary before loading full content.
+4. Add `tags` values for the business area and `sl_refs` values for related semantic sources.
5. Search again with the user's likely wording to confirm the page is discoverable.
## Common errors
@@ -339,6 +291,6 @@ Search uses both full-text matching and semantic similarity — it finds relevan
|------------------|--------------|----------|
| `ktx sl validate` reports a missing column | YAML references a column that is absent from the scanned table | Run a fresh scan or update the YAML to match the warehouse schema |
| Query compilation double-counts a measure | Join relationship or grain is missing or wrong | Add `grain` and explicit `relationship` values, then validate and recompile |
-| Agent cannot find a metric | Measure name or description does not match business terminology | Add a measure description and a knowledge page with common synonyms |
-| Knowledge search misses a page | Summary and tags do not include likely user wording | Rewrite the summary and add relevant tags, then search again |
-| `ktx sl write` changes are hard to review | Large YAML was passed inline | Edit the source file directly or write from a temporary file, then review the git diff |
+| Agent cannot find a metric | Measure name or description does not match business terminology | Add a measure description and a wiki page with common synonyms |
+| Wiki search misses a page | Summary and tags do not include likely user wording | Rewrite the summary and add relevant tags, then search again |
+| Semantic-layer changes are hard to review | The YAML edit is too large or unfocused | Split the change into smaller source-file edits, then review the git diff |
diff --git a/docs-site/content/docs/integrations/agent-clients.mdx b/docs-site/content/docs/integrations/agent-clients.mdx
index 1c105e1f..95786f52 100644
--- a/docs-site/content/docs/integrations/agent-clients.mdx
+++ b/docs-site/content/docs/integrations/agent-clients.mdx
@@ -3,7 +3,9 @@ title: Agent Clients
description: Set up KTX with Claude Code, Cursor, Codex, and OpenCode.
---
-KTX integrates with coding agents through CLI skills and command files. These files teach agents to call `ktx agent ...` commands directly from the terminal for semantic-layer context, wiki knowledge, and safe SQL execution.
+KTX integrates with coding agents through CLI skills and command files. These
+files teach agents to call public `ktx` commands directly from the terminal for
+semantic-layer context and wiki knowledge.
Run `ktx setup` and select your agent targets, or configure manually using the snippets below.
@@ -26,17 +28,15 @@ Create `.claude/skills/ktx/SKILL.md`:
```markdown title=".claude/skills/ktx/SKILL.md"
---
name: ktx
-description: Use local KTX semantic context, wiki knowledge, and safe SQL execution for this project.
+description: Use local KTX semantic context and wiki knowledge for this project.
---
Available commands:
-- `ktx agent context --json --project-dir /path/to/project`
-- `ktx agent sl list --json --project-dir /path/to/project`
-- `ktx agent sl read '' --json --project-dir /path/to/project`
-- `ktx agent sl query --json --project-dir /path/to/project --connection-id '' --query-file '' --execute --max-rows 100`
-- `ktx agent wiki search '' --json --project-dir /path/to/project`
-- `ktx agent wiki read '' --json --project-dir /path/to/project`
-- `ktx agent sql execute --json --project-dir /path/to/project --connection-id '' --sql-file '' --max-rows 100`
+- `ktx status --json --project-dir /path/to/project`
+- `ktx sl list --json --project-dir /path/to/project`
+- `ktx sl search '' --json --project-dir /path/to/project --connection-id ''`
+- `ktx sl query --json --project-dir /path/to/project --connection-id '' --query-file '' --execute --max-rows 100`
+- `ktx wiki search '' --json --project-dir /path/to/project --limit 10`
```
### Workflow tips
@@ -123,22 +123,17 @@ All supported agent clients call the same KTX CLI commands:
| Command | Description |
|---------|-------------|
-| `ktx agent context --json` | Return a compact project context summary |
-| `ktx agent tools --json` | List available agent-facing commands |
-| `ktx agent wiki search --json` | Search knowledge pages |
-| `ktx agent wiki read --json` | Read a knowledge page |
-| `ktx agent wiki write --json` | Write or update a knowledge page |
-| `ktx agent sl list --json` | List semantic layer sources |
-| `ktx agent sl read --json` | Read a semantic source definition |
-| `ktx agent sl write --json` | Write or update a semantic source |
-| `ktx agent sl validate --json` | Validate semantic source definitions |
-| `ktx agent sl query --json` | Execute a semantic layer query when semantic compute is configured |
-| `ktx agent sql execute --json` | Execute read-only SQL with an explicit row limit |
+| `ktx status --json` | Return project setup and context readiness |
+| `ktx wiki search --json` | Search wiki pages |
+| `ktx wiki read --json` | Read a wiki page |
+| `ktx wiki write ` | Write or update a wiki page |
+| `ktx sl list --json` | List semantic-layer sources |
+| `ktx sl search --json` | Search semantic-layer sources |
+| `ktx sl validate --connection-id ` | Validate semantic source definitions |
+| `ktx sl query --json` | Execute a semantic-layer query when semantic compute is configured |
### Security constraints
-- SQL execution is always read-only.
-- Agent SQL execution requires an explicit `--max-rows` limit from 1 to 1000.
- Secrets and credentials are never exposed in command output.
- Commands resolve the project from `--project-dir`, `KTX_PROJECT_DIR`, or the nearest `ktx.yaml`.
diff --git a/docs-site/content/docs/integrations/context-sources.mdx b/docs-site/content/docs/integrations/context-sources.mdx
index 02554e08..5b85bff2 100644
--- a/docs-site/content/docs/integrations/context-sources.mdx
+++ b/docs-site/content/docs/integrations/context-sources.mdx
@@ -13,9 +13,9 @@ Agents should configure and ingest context sources in this order:
1. Add the context source connection in `ktx.yaml` or with `ktx setup`.
2. Store tokens as `env:NAME` or `file:/path/to/secret`.
-3. Run `ktx ingest ` for one source or `ktx ingest --all`.
+3. Run `ktx ingest run --connection-id --adapter ` for one source or `ktx ingest run --connection-id --adapter `.
4. Check progress with `ktx ingest status --json`.
-5. Review generated `semantic-layer/` YAML and `knowledge/` Markdown files in git.
+5. Review generated `semantic-layer/` YAML and `wiki/` Markdown files in git.
6. Validate changed semantic sources with `ktx sl validate`.
## Shared source fields
@@ -233,7 +233,7 @@ Generate an API key in Metabase: **Admin > Settings > Authentication > API Keys*
### What gets ingested
- Semantic sources generated from SQL queries in questions
-- Knowledge pages for dashboards (purpose, key metrics, relationships)
+- Wiki pages for dashboards (purpose, key metrics, relationships)
- Work units per dashboard and per question
### Warehouse mapping
@@ -290,7 +290,7 @@ Generate API credentials in Looker: **Admin > Users > Edit > API Keys**.
### What gets ingested
- Semantic sources from explore field definitions
-- Knowledge pages for dashboards (purpose, audience, key metrics)
+- Wiki pages for dashboards (purpose, audience, key metrics)
- Triage signals for automated content classification
- Work units per explore and per dashboard
@@ -310,11 +310,11 @@ Find Looker connection names in **Admin > Database > Connections**.
## Notion
-Ingests pages and databases from a Notion workspace as knowledge pages. Useful for capturing business definitions, data dictionaries, and team documentation that agents need for context.
+Ingests pages and databases from a Notion workspace as wiki pages. Useful for capturing business definitions, data dictionaries, and team documentation that agents need for context.
### What it provides
-- Knowledge pages synthesized from Notion content
+- Wiki pages synthesized from Notion content
- Page hierarchy and relationships
- Database schemas (when Notion databases describe data sources)
- Semantic clustering for organized ingestion
@@ -364,7 +364,7 @@ Create an integration at [notion.so/my-integrations](https://www.notion.so/my-in
### What gets ingested
-- Knowledge pages synthesized from Notion content (not raw copies)
+- Wiki pages synthesized from Notion content (not raw copies)
- Domain context extracted and organized by topic
- Triage signals for classifying page relevance
- Work units clustered by semantic similarity for efficient processing
@@ -381,6 +381,6 @@ Create an integration at [notion.so/my-integrations](https://www.notion.so/my-in
|------------------|--------------|----------|
| Adapter cannot read source files | `source_dir`, `repo_url`, `branch`, or `path` is wrong | Verify the path locally or clone the repo manually with the same credentials |
| Private repo/API authentication fails | Token env var or secret file is missing | Export the env var or update `auth_token_ref` to a readable file |
-| Ingest creates duplicate context | Existing source names or knowledge pages do not match imported terminology | Review the diff, rename duplicates, and add knowledge pages with canonical names |
+| Ingest creates duplicate context | Existing source names or wiki pages do not match imported terminology | Review the diff, rename duplicates, and add wiki pages with canonical names |
| Notion ingest skips pages | Integration lacks access or root ids are missing | Share pages with the Notion integration and set `root_page_ids` or use `all_accessible` carefully |
| Generated semantic sources fail validation | Tool metadata does not match the live warehouse schema | Map BI/source databases to primary warehouse connections and rerun validation |
diff --git a/docs-site/content/docs/integrations/primary-sources.mdx b/docs-site/content/docs/integrations/primary-sources.mdx
index 49200d47..94dc4e44 100644
--- a/docs-site/content/docs/integrations/primary-sources.mdx
+++ b/docs-site/content/docs/integrations/primary-sources.mdx
@@ -511,4 +511,4 @@ No authentication required — SQLite is file-based. The file must be readable b
| Scan returns no tables | Schema/database/project filter is wrong or the user lacks metadata permissions | Verify the schema list and grant metadata read permissions |
| Historic SQL is empty | Query history extension or warehouse history view is unavailable | Enable the warehouse-specific history feature, then rerun scan or setup |
| Column statistics are missing | Connector cannot access stats tables or the warehouse does not expose them | Grant stats permissions where supported; otherwise rely on structural scan output |
-| SQL execution fails through agents | Connection is missing, unreachable, or query execution is disabled | Run `ktx connection test ` and check the agent command flags |
+| Semantic query execution fails | Connection is missing, unreachable, or query execution is disabled | Run `ktx connection test ` and check the `ktx sl query` flags |
diff --git a/docs-site/lib/llm-docs.ts b/docs-site/lib/llm-docs.ts
index 9d9b5c74..cbf9ba9e 100644
--- a/docs-site/lib/llm-docs.ts
+++ b/docs-site/lib/llm-docs.ts
@@ -47,7 +47,7 @@ export function buildLlmsTxt() {
> Agent-native context layer for analytics engineering and database agents.
-KTX provides semantic-layer files, warehouse scans, knowledge pages, provenance, and agent-facing tools that help coding agents answer analytics questions without inventing metrics or joins.
+KTX provides semantic-layer files, warehouse scans, wiki pages, provenance, and agent-facing tools that help coding agents answer analytics questions without inventing metrics or joins.
## Agent Entry Points
@@ -60,21 +60,21 @@ ${link("/docs/ai-resources/agent-instructions", "Agent Instructions", "Suggested
${link("/docs/getting-started/introduction", "Introduction", "What KTX is and who it is for")}
${link("/docs/getting-started/quickstart", "Quickstart", "Set up KTX and build your first context")}
-${link("/docs/guides/writing-context", "Writing Context", "Write semantic sources and knowledge pages")}
+${link("/docs/guides/writing-context", "Writing Context", "Write semantic sources and wiki pages")}
## Machine-Readable Documentation
- [Full documentation](${absoluteUrl("/llms-full.txt")}): All docs pages in one plain-text markdown response
- [Markdown access guide](${absoluteUrl("/docs/ai-resources/markdown-access.md")}): How to fetch llms.txt, llms-full.txt, and per-page Markdown
- [Quickstart markdown](${absoluteUrl("/docs/getting-started/quickstart.md")}): Human setup walkthrough
-- [Agent CLI markdown](${absoluteUrl("/docs/cli-reference/ktx-agent.md")}): Machine-readable agent commands
+- [Semantic-layer CLI markdown](${absoluteUrl("/docs/cli-reference/ktx-sl.md")}): Semantic-layer commands and JSON output
+- [Wiki CLI markdown](${absoluteUrl("/docs/cli-reference/ktx-wiki.md")}): Wiki page commands and JSON output
## CLI Reference
${link("/docs/cli-reference/ktx-setup", "ktx setup", "Interactive project setup")}
-${link("/docs/cli-reference/ktx-agent", "ktx agent", "Machine-readable commands for coding agents")}
${link("/docs/cli-reference/ktx-sl", "ktx sl", "Semantic-layer commands")}
-${link("/docs/cli-reference/ktx-wiki", "ktx wiki", "Knowledge page commands")}
+${link("/docs/cli-reference/ktx-wiki", "ktx wiki", "Wiki page commands")}
${link("/docs/cli-reference/ktx-connection", "ktx connection", "Connection management commands")}
## Integrations
diff --git a/docs/superpowers/plans/2026-05-12-notion-warehouse-verification-gap-closure.md b/docs/superpowers/plans/2026-05-12-notion-warehouse-verification-gap-closure.md
new file mode 100644
index 00000000..3cfdc843
--- /dev/null
+++ b/docs/superpowers/plans/2026-05-12-notion-warehouse-verification-gap-closure.md
@@ -0,0 +1,785 @@
+# Notion Warehouse Verification Gap Closure Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Close the remaining v1 gaps that prevent ingest agents, especially
+Notion WorkUnits, from reliably verifying warehouse table and column
+identifiers before writing wiki or semantic-layer output.
+
+**Architecture:** Keep the existing warehouse verification tool module and
+runner wiring. Add Notion target-warehouse scoping through the local adapter
+factory, make the active WorkUnit prompt name the shipped tools, enforce
+`allowedConnectionNames` in `discover_data`, and teach `entity_details` to
+resolve and reject column-level display targets.
+
+**Tech Stack:** TypeScript, Node 22, Vitest, AI SDK v6 tools, Zod, KTX local
+ingest adapters, KTX file store.
+
+---
+
+## Audit summary
+
+The previous implementation plan landed the main tool module and prompt
+protocol, but four v1-blocking gaps remain:
+
+- Notion ingest sessions still allow only the Notion connection unless a
+ specific adapter supplies target IDs. `NotionSourceAdapter` does not supply
+ target warehouse IDs, so the original Notion hallucination case cannot use
+ `entity_details` or raw-schema `discover_data` for the warehouse connection.
+- The active WorkUnit framing prompt still tells agents to call
+ `wiki_sl_search` and `sl_describe_table`, which are not shipped KTX tools.
+- `discover_data` accepts an explicit out-of-scope `connectionName` and still
+ searches raw schema for that connection.
+- `entity_details({ targets: [{ display: "schema.table.column" }] })` does not
+ resolve column display strings and does not fail explicit missing-column
+ targets.
+
+Non-blocking gaps remain out of scope for this plan:
+
+- Full DDL-style `entity_details` formatting with FK and profile summaries.
+- AST-backed SQL read-only validation for data-modifying CTEs.
+- Search over `enrichment/descriptions.json` for generated descriptions.
+- Lexicographic latest-sync edge cases for non-timestamp sync IDs.
+- Hard write-time validation in `wiki_write` and `emit_unmapped_fallback`.
+
+## File structure
+
+Modify these files:
+
+- `packages/context/src/ingest/adapters/notion/notion.adapter.ts`: add
+ configured target warehouse IDs and implement `listTargetConnectionIds()`.
+- `packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`: cover
+ Notion target connection ID fan-out.
+- `packages/context/src/ingest/local-adapters.ts`: pass primary warehouse IDs
+ into `NotionSourceAdapter`.
+- `packages/context/src/ingest/local-adapters.test.ts`: cover local Notion
+ adapter target IDs.
+- `packages/context/src/ingest/adapters/notion/chunk.ts`: update Notion
+ WorkUnit notes to prefer the warehouse verification tools.
+- `packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`: update
+ Notion note expectations.
+- `packages/context/prompts/memory_agent_bundle_ingest_work_unit.md`: replace
+ stale tool names in the active WorkUnit prompt.
+- `packages/context/src/ingest/ingest-prompts.test.ts`: guard the WorkUnit
+ prompt against stale tool names.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`:
+ refuse explicit out-of-scope connection names.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`:
+ cover `discover_data` scoping.
+- `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`:
+ add column-aware display-target resolution.
+- `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`:
+ cover column display resolution.
+- `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`:
+ use column-aware resolution and report missing columns.
+- `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts`:
+ cover column display and missing-column behavior.
+
+### Task 1: Give Notion ingest access to target warehouses
+
+**Files:**
+- Modify: `packages/context/src/ingest/adapters/notion/notion.adapter.ts`
+- Modify: `packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`
+- Modify: `packages/context/src/ingest/local-adapters.ts`
+- Modify: `packages/context/src/ingest/local-adapters.test.ts`
+
+- [ ] **Step 1: Write the failing Notion adapter test**
+
+Add this test inside `describe('NotionSourceAdapter', ...)` in
+`packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`:
+
+```ts
+it('returns configured target warehouse connection ids', async () => {
+ const adapter = new NotionSourceAdapter({
+ targetConnectionIds: ['warehouse', 'warehouse', 'analytics'],
+ });
+
+ await expect(adapter.listTargetConnectionIds?.(stagedDir)).resolves.toEqual([
+ 'analytics',
+ 'warehouse',
+ ]);
+});
+```
+
+- [ ] **Step 2: Run the failing Notion adapter test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/adapters/notion/notion.adapter.test.ts -t "target warehouse connection ids"
+```
+
+Expected: FAIL because `NotionSourceAdapterDeps` has no
+`targetConnectionIds` option and `NotionSourceAdapter` does not implement
+`listTargetConnectionIds()`.
+
+- [ ] **Step 3: Implement Notion target connection IDs**
+
+Modify `packages/context/src/ingest/adapters/notion/notion.adapter.ts`:
+
+```ts
+export interface NotionSourceAdapterDeps {
+ onPullSucceeded?: (ctx: NotionPullSucceededContext) => Promise;
+ logger?: NotionFetchLogger;
+ targetConnectionIds?: string[];
+}
+
+function uniqueSorted(values: readonly string[] | undefined): string[] {
+ return [...new Set(values ?? [])].sort((left, right) =>
+ left.localeCompare(right),
+ );
+}
+```
+
+Add this method to `NotionSourceAdapter`:
+
+```ts
+ async listTargetConnectionIds(_stagedDir: string): Promise {
+ return uniqueSorted(this.deps.targetConnectionIds);
+ }
+```
+
+- [ ] **Step 4: Pass primary warehouses into the local Notion adapter**
+
+Modify the Notion adapter construction in
+`packages/context/src/ingest/local-adapters.ts`:
+
+```ts
+ new NotionSourceAdapter({
+ targetConnectionIds: primaryWarehouseConnectionIds(project),
+ ...(options.logger ? { logger: options.logger } : {}),
+ }),
+```
+
+- [ ] **Step 5: Write the local adapter fan-out test**
+
+Add this test to `packages/context/src/ingest/local-adapters.test.ts`:
+
+```ts
+it('passes primary warehouse connection ids to the local Notion adapter', async () => {
+ const adapters = createDefaultLocalIngestAdapters(
+ projectWithConnections({
+ notion: {
+ driver: 'notion',
+ auth_token: 'secret',
+ crawl_mode: 'selected_roots',
+ root_page_ids: ['page-1'],
+ },
+ warehouse: {
+ driver: 'postgres',
+ url: 'postgresql://readonly@db.example.test/analytics',
+ },
+ docs: {
+ driver: 'dbt',
+ source_dir: './dbt',
+ },
+ } as never),
+ );
+
+ const notion = adapters.find((adapter) => adapter.source === 'notion');
+
+ await expect(notion?.listTargetConnectionIds?.('/tmp/staged-notion')).resolves.toEqual([
+ 'warehouse',
+ ]);
+});
+```
+
+- [ ] **Step 6: Run the Notion target tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/adapters/notion/notion.adapter.test.ts -t "target warehouse connection ids" \
+ src/ingest/local-adapters.test.ts -t "local Notion adapter"
+```
+
+Expected: PASS.
+
+- [ ] **Step 7: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/adapters/notion/notion.adapter.ts \
+ packages/context/src/ingest/adapters/notion/notion.adapter.test.ts \
+ packages/context/src/ingest/local-adapters.ts \
+ packages/context/src/ingest/local-adapters.test.ts
+git commit -m "fix(context): expose target warehouses to Notion ingest"
+```
+
+### Task 2: Remove stale tool names from active ingest prompts
+
+**Files:**
+- Modify: `packages/context/prompts/memory_agent_bundle_ingest_work_unit.md`
+- Modify: `packages/context/src/ingest/ingest-prompts.test.ts`
+- Modify: `packages/context/src/ingest/adapters/notion/chunk.ts`
+- Modify: `packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`
+
+- [ ] **Step 1: Add failing prompt guards**
+
+Add this test to `packages/context/src/ingest/ingest-prompts.test.ts`:
+
+```ts
+it('uses shipped warehouse verification tools in the WorkUnit prompt', async () => {
+ const prompt = await readFile(
+ new URL('../../prompts/memory_agent_bundle_ingest_work_unit.md', import.meta.url),
+ 'utf-8',
+ );
+
+ expect(prompt).toContain('discover_data');
+ expect(prompt).toContain('entity_details');
+ expect(prompt).not.toContain('wiki_sl_search');
+ expect(prompt).not.toContain('sl_describe_table');
+});
+```
+
+- [ ] **Step 2: Run the failing prompt guard**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/ingest-prompts.test.ts -t "warehouse verification tools"
+```
+
+Expected: FAIL because the WorkUnit prompt still contains `wiki_sl_search` and
+`sl_describe_table`.
+
+- [ ] **Step 3: Update the WorkUnit framing prompt**
+
+In `packages/context/prompts/memory_agent_bundle_ingest_work_unit.md`, replace
+the first `` paragraph with:
+
+```md
+You are processing ONE WorkUnit of a multi-file ingest bundle. The WorkUnit gives you a slice of raw source files (LookML views, dbt/MetricFlow YAMLs, Metabase card JSONs, Notion pages, or similar) and you must translate that slice into KTX semantic-layer sources and/or knowledge wiki pages, in one pass. Prior WorkUnits in this same job may have already written SL sources and wiki pages; their writes are visible on the working branch and discoverable with `discover_data`.
+```
+
+In workflow step 2, replace the final sentence with:
+
+```md
+The triage skill tells you how to react when `discover_data` reveals that a prior WU already wrote something overlapping.
+```
+
+In workflow step 4, replace the sentence that starts
+`For each raw file:` with:
+
+```md
+4. For each raw file: call `read_raw_file` (or `read_raw_span` for slicing large files) to load content. Before writing a new SL source or wiki page, call `discover_data` for each candidate source, table, metric, or topic name to find prior-WU writes, existing wiki pages, SL sources, and raw warehouse matches; apply `ingest_triage` when you hit one, and apply any matching canonical pin before deciding whether to edit, rename, or skip.
+```
+
+In the `` block, replace the physical-column rule with:
+
+```md
+- Do not invent physical column names or grain keys. For table-backed SL sources, every `columns:`, `grain:`, `joins:`, `segments:`, and `measures[].expr` column must come from raw-file column declarations or warehouse-backed discovery (`discover_data`, `sl_discover`, `entity_details`). If column names are not confirmed, capture the business context in wiki instead of writing a full SL source.
+```
+
+- [ ] **Step 4: Update Notion WorkUnit notes**
+
+In `packages/context/src/ingest/adapters/notion/chunk.ts`, replace
+`NOTION_SL_WRITE_GUIDANCE` with:
+
+```ts
+const NOTION_SL_WRITE_GUIDANCE =
+ 'Write wiki entries with wiki_write. Wiki keys must be flat slugs like orbit-company-overview, not orbit/company-overview. Search existing wiki pages, SL sources, and raw warehouse schema for the same tables or sl_refs with discover_data before creating a new page. Only write or edit SL sources after discover_data plus sl_discover/sl_read_source or entity_details confirms a mapped non-Notion target source; if no mapped target exists, emit_unmapped_fallback and keep the fact wiki-only. Notion dataSourceCount counts Notion databases/data sources only, not warehouse/dbt mappings. If a warehouse/dbt connection exists but the named table or source is absent, use reason no_physical_table rather than no_connection_mapping. Do not create SL sources under the Notion connection just because a page mentions a warehouse table.';
+```
+
+In the `reconcileNotes` array in the same file, replace:
+
+```ts
+ 'Notion dataSourceCount is Notion-only; use sl_discover for warehouse/dbt mapping decisions.',
+```
+
+with:
+
+```ts
+ 'Notion dataSourceCount is Notion-only; use discover_data/entity_details for warehouse/dbt mapping decisions.',
+```
+
+- [ ] **Step 5: Update Notion note expectations**
+
+In `packages/context/src/ingest/adapters/notion/notion.adapter.test.ts`,
+update the note expectations in `it('chunks changed Notion pages...')`:
+
+```ts
+expect(result.workUnits[0].notes).toContain('discover_data');
+expect(result.workUnits[0].notes).toContain('entity_details');
+```
+
+Update the exact `reconcileNotes` expectation to:
+
+```ts
+expect(result.reconcileNotes).toEqual([
+ 'Notion maxKnowledgeCreatesPerRun=25',
+ 'Notion maxKnowledgeUpdatesPerRun=20',
+ 'Notion dataSourceCount is Notion-only; use discover_data/entity_details for warehouse/dbt mapping decisions.',
+ 'Reconcile Notion wiki pages sharing tables/sl_refs before creating distinct artifacts.',
+]);
+```
+
+- [ ] **Step 6: Run prompt and Notion note tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/ingest-prompts.test.ts \
+ src/ingest/adapters/notion/notion.adapter.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 7: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/prompts/memory_agent_bundle_ingest_work_unit.md \
+ packages/context/src/ingest/ingest-prompts.test.ts \
+ packages/context/src/ingest/adapters/notion/chunk.ts \
+ packages/context/src/ingest/adapters/notion/notion.adapter.test.ts
+git commit -m "fix(context): update ingest prompts for warehouse verification tools"
+```
+
+### Task 3: Enforce allowed connection scope in discover_data
+
+**Files:**
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`
+
+- [ ] **Step 1: Write the failing scoping test**
+
+Add this test to
+`packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`:
+
+```ts
+it('refuses explicit out-of-scope connection names', async () => {
+ const result = await tool.call({ query: 'orders', connectionName: 'billing' }, context);
+
+ expect(result.markdown).toContain('Connection "billing" is not available to this ingest stage.');
+ expect(result.structured).toEqual({ wiki: null, sl: null, raw: null });
+ expect(wikiSearchTool.call).not.toHaveBeenCalled();
+ expect(slDiscoverTool.call).not.toHaveBeenCalled();
+ expect(catalog.searchByName).not.toHaveBeenCalled();
+});
+```
+
+- [ ] **Step 2: Run the failing scoping test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts -t "out-of-scope"
+```
+
+Expected: FAIL because `discover_data` currently searches raw schema for an
+explicit `connectionName` even when it is not in `allowedConnectionNames`.
+
+- [ ] **Step 3: Add the scope guard**
+
+In
+`packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`,
+add this helper near `totalSources()`:
+
+```ts
+function allowedConnectionNames(context: ToolContext): ReadonlySet | null {
+ return context.session?.allowedConnectionNames ?? null;
+}
+```
+
+At the top of `DiscoverDataTool.call()`, before the `sourceName` branch and
+before calling any child tool, add:
+
+```ts
+ const allowed = allowedConnectionNames(context);
+ if (input.connectionName && allowed && !allowed.has(input.connectionName)) {
+ return {
+ markdown: `Connection "${input.connectionName}" is not available to this ingest stage.`,
+ structured: { wiki: null, sl: null, raw: null },
+ };
+ }
+```
+
+Then replace the raw connection-list construction with:
+
+```ts
+ const connections = input.connectionName ? [input.connectionName] : [...(allowed ?? [])].sort();
+```
+
+- [ ] **Step 4: Run discover_data tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+git commit -m "fix(context): scope raw schema discovery to allowed connections"
+```
+
+### Task 4: Fix column-level entity_details verification
+
+**Files:**
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts`
+
+- [ ] **Step 1: Write failing catalog column-target tests**
+
+First update `seedLiveDatabaseScan()` in that test file so BigQuery tables have
+a project/catalog. Replace the repeated inline table refs with:
+
+```ts
+const tableRef = {
+ catalog: driver === 'bigquery' ? 'analytics' : null,
+ db: driver === 'sqlite' ? null : 'public',
+ name: 'orders',
+};
+```
+
+Use `tableRef.catalog`, `tableRef.db`, and `tableRef.name` for the seeded
+table and profile table references.
+
+Then add these tests to
+`packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`:
+
+```ts
+it('resolves postgres column display strings without treating the column as a table', async () => {
+ await seedLiveDatabaseScan();
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.resolveDisplayTarget('warehouse', 'public.orders.status')).resolves.toMatchObject({
+ resolved: { catalog: null, db: 'public', name: 'orders', column: 'status' },
+ candidates: [],
+ dialect: 'postgres',
+ });
+});
+
+it('resolves BigQuery column display strings with four parts', async () => {
+ await seedLiveDatabaseScan('warehouse', 'sync-bigquery', 'bigquery');
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.resolveDisplayTarget('warehouse', 'analytics.public.orders.status')).resolves.toMatchObject({
+ resolved: { catalog: 'analytics', db: 'public', name: 'orders', column: 'status' },
+ candidates: [],
+ dialect: 'bigquery',
+ });
+});
+```
+
+- [ ] **Step 2: Run the failing catalog tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts -t "column display"
+```
+
+Expected: FAIL because `resolveDisplayTarget()` does not exist.
+
+- [ ] **Step 3: Implement column-aware display resolution**
+
+In
+`packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`,
+add this exported interface near `RawSchemaHit`:
+
+```ts
+export interface DisplayTargetResolution {
+ resolved: (KtxTableRef & { column?: string }) | null;
+ candidates: KtxTableRef[];
+ dialect: string;
+}
+```
+
+Add these helpers near `parseDisplay()`:
+
+```ts
+function expectedDisplayPartCount(driver: CatalogDriver): number {
+ if (driver === 'sqlite' || driver === 'sqlite3') {
+ return 1;
+ }
+ if (driver === 'bigquery' || driver === 'snowflake' || driver === 'sqlserver') {
+ return 3;
+ }
+ return 2;
+}
+
+function parseColumnDisplay(driver: CatalogDriver, display: string): (KtxTableRef & { column: string }) | null {
+ const parts = splitDisplay(display);
+ const tablePartCount = expectedDisplayPartCount(driver);
+ if (parts.length !== tablePartCount + 1) {
+ return null;
+ }
+ const column = parts.at(-1);
+ if (!column) {
+ return null;
+ }
+ const table = parseDisplay(driver, parts.slice(0, -1).join('.'));
+ return table ? { ...table, column } : null;
+}
+```
+
+Add this method to `WarehouseCatalogService` after `resolveDisplay()`:
+
+```ts
+ async resolveDisplayTarget(connectionName: string, display: string): Promise {
+ const catalog = await this.loadCatalog(connectionName);
+ if (!catalog) {
+ return { resolved: null, candidates: [], dialect: 'unknown' };
+ }
+
+ const dialect = getDialectForDriver(catalog.driver).type;
+ const tableResolution = await this.resolveDisplay(connectionName, display);
+ if (tableResolution.resolved) {
+ return tableResolution;
+ }
+
+ const parsedColumn = parseColumnDisplay(catalog.driver, display);
+ if (!parsedColumn) {
+ return { resolved: null, candidates: bestCandidates(catalog.tables, display), dialect };
+ }
+
+ const table = catalog.tables.find((candidate) => refsEqual(candidate, parsedColumn));
+ if (!table) {
+ return { resolved: null, candidates: bestCandidates(catalog.tables, display), dialect };
+ }
+
+ return {
+ resolved: {
+ catalog: table.catalog,
+ db: table.db,
+ name: table.name,
+ column: parsedColumn.column,
+ },
+ candidates: [],
+ dialect,
+ };
+ }
+```
+
+- [ ] **Step 4: Write failing entity_details column tests**
+
+Add these tests to
+`packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts`:
+
+```ts
+it('resolves display targets that include a column name', async () => {
+ const result = await tool.call(
+ { connectionName: 'warehouse', targets: [{ display: 'public.orders.status' }] },
+ context,
+ );
+
+ expect(result.markdown).toContain('### public.orders');
+ expect(result.markdown).toContain('- status (text, nullable=false)');
+ expect(result.markdown).not.toContain('- id (integer');
+ expect(result.structured.resolved).toHaveLength(1);
+ expect(result.structured.resolved[0]?.columns.map((column) => column.name)).toEqual(['status']);
+});
+
+it('reports missing explicit columns instead of returning an empty column list', async () => {
+ const result = await tool.call(
+ { connectionName: 'warehouse', targets: [{ display: 'public.orders.plan_tier' }] },
+ context,
+ );
+
+ expect(result.markdown).toContain('Column not found in scan: public.orders.plan_tier');
+ expect(result.markdown).toContain('Available columns: id, status');
+ expect(result.structured.resolved).toHaveLength(0);
+ expect(result.structured.missing).toHaveLength(1);
+});
+```
+
+- [ ] **Step 5: Run the failing entity_details tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/entity-details.tool.test.ts -t "column"
+```
+
+Expected: FAIL because display column targets are treated as table names and
+missing columns are not reported.
+
+- [ ] **Step 6: Use column-aware resolution in entity_details**
+
+In
+`packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`,
+add this helper near `appendTableMarkdown()`:
+
+```ts
+function findColumn(detail: TableDetail, columnName: string): TableDetail['columns'][number] | null {
+ const normalized = columnName.toLowerCase();
+ return detail.columns.find((column) => column.name.toLowerCase() === normalized) ?? null;
+}
+```
+
+Replace the display resolution block inside the `for (const target of
+input.targets)` loop with:
+
+```ts
+ const resolution =
+ 'display' in target
+ ? await catalog.resolveDisplayTarget(input.connectionName, target.display)
+ : {
+ resolved: { catalog: target.catalog, db: target.db, name: target.name, column: target.column },
+ candidates: [],
+ dialect: '',
+ };
+```
+
+After `const detail = await catalog.getTable(...)`, replace the existing
+`resolved.push(detail); appendTableMarkdown(...)` lines with:
+
+```ts
+ const requestedColumn = resolution.resolved.column;
+ if (requestedColumn) {
+ const column = findColumn(detail, requestedColumn);
+ if (!column) {
+ missing.push({
+ target,
+ candidates: [{ catalog: detail.catalog, db: detail.db, name: detail.name }],
+ });
+ parts.push(`Column not found in scan: ${detail.display}.${requestedColumn}`);
+ parts.push(`Available columns: ${detail.columns.map((candidate) => candidate.name).join(', ')}`);
+ continue;
+ }
+ const scopedDetail = { ...detail, columns: [column] };
+ resolved.push(scopedDetail);
+ appendTableMarkdown(parts, scopedDetail, column.name);
+ continue;
+ }
+
+ resolved.push(detail);
+ appendTableMarkdown(parts, detail);
+```
+
+- [ ] **Step 7: Run warehouse verification tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts \
+ src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 8: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts \
+ packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+git commit -m "fix(context): verify warehouse column display targets"
+```
+
+### Task 5: Verify the v1 gap closure
+
+**Files:**
+- Verify all files changed by Tasks 1-4.
+
+- [ ] **Step 1: Run focused tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/adapters/notion/notion.adapter.test.ts \
+ src/ingest/local-adapters.test.ts \
+ src/ingest/ingest-prompts.test.ts \
+ src/ingest/tools/warehouse-verification/discover-data.tool.test.ts \
+ src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts \
+ src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 2: Run package type-check**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context run type-check
+```
+
+Expected: PASS.
+
+- [ ] **Step 3: Run package tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context run test
+```
+
+Expected: PASS.
+
+- [ ] **Step 4: Run pre-commit on changed files when configured**
+
+Run:
+
+```bash
+uv run pre-commit run --files \
+ packages/context/src/ingest/adapters/notion/notion.adapter.ts \
+ packages/context/src/ingest/adapters/notion/notion.adapter.test.ts \
+ packages/context/src/ingest/local-adapters.ts \
+ packages/context/src/ingest/local-adapters.test.ts \
+ packages/context/src/ingest/adapters/notion/chunk.ts \
+ packages/context/prompts/memory_agent_bundle_ingest_work_unit.md \
+ packages/context/src/ingest/ingest-prompts.test.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts \
+ packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+```
+
+Expected: PASS. If the repo has no pre-commit config or the local `uv` version
+cannot satisfy the project pin, record the exact error and rely on focused
+tests plus type-check.
+
+- [ ] **Step 5: Inspect final git status**
+
+Run:
+
+```bash
+git status --short
+```
+
+Expected: only intentional files are modified. Commit any formatter-driven
+changes with:
+
+```bash
+git add packages/context
+git commit -m "chore(context): verify warehouse verification v1 gaps"
+```
+
+## Self-review checklist
+
+- Spec coverage: this plan closes the remaining v1 paths for Notion warehouse
+ verification, active WorkUnit prompt correctness, raw discovery scoping, and
+ column-level identifier verification.
+- Placeholder scan: no task relies on future-work markers, unnamed edge-case
+ handling, or cross-task shorthand.
+- Type consistency: `discover_data` continues to use `connectionName`,
+ `sl_discover` still receives `connectionId` internally, and
+ `resolveDisplayTarget()` returns the same table identity plus optional
+ `column`.
diff --git a/docs/superpowers/plans/2026-05-12-warehouse-verification-final-v1-closure.md b/docs/superpowers/plans/2026-05-12-warehouse-verification-final-v1-closure.md
new file mode 100644
index 00000000..f48fea36
--- /dev/null
+++ b/docs/superpowers/plans/2026-05-12-warehouse-verification-final-v1-closure.md
@@ -0,0 +1,957 @@
+# Warehouse Verification Final V1 Closure Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Close the remaining v1 gaps that still prevent ingest agents from
+reliably following warehouse verification results through to `entity_details`
+and `sql_execution`.
+
+**Architecture:** Keep the existing warehouse verification module and runner
+session scoping. Add connection names to raw discovery hits, expose primary
+warehouse targets from the remaining source adapters, and make local ingest
+SQL probes use the same scan connector read-only execution path as schema scan.
+
+**Tech Stack:** TypeScript, Node 22, Vitest, AI SDK v6 tools, Zod, KTX local
+ingest runtime, KTX scan connectors.
+
+---
+
+## Audit summary
+
+The first two implementation plans landed the warehouse verification tools,
+prompt protocol, Notion warehouse scoping, and stale prompt-name cleanup. The
+focused audit on May 12, 2026, found three remaining v1-blocking gaps:
+
+- `discover_data` searches multiple allowed raw warehouse scans, but raw hits do
+ not carry or render `connectionName`. The tool tells the agent to call
+ `entity_details({connectionName, targets: [...]})`, then omits the required
+ `connectionName` from the follow-up evidence.
+- Local LookML and MetricFlow adapters do not expose primary warehouse target
+ IDs. The runner only adds adapter-provided targets to `allowedConnectionNames`,
+ so those WorkUnits cannot use raw warehouse verification unless their source
+ connection is itself the warehouse.
+- `sql_execution` calls the local ingest connection catalog, but the catalog
+ either has no query executor in normal CLI ingest or calls an injected
+ executor without `projectDir` and connection config. The default local query
+ executor cannot dispatch without that config.
+
+Non-blocking gaps remain out of scope for this v1 plan:
+
+- Full DDL-style `entity_details` formatting with FK profile summaries.
+- AST-backed SQL read-only validation for data-modifying CTE bodies.
+- Search over generated `enrichment/descriptions.json`.
+- Lexicographic latest-sync edge cases for non-timestamp sync IDs.
+- Hard write-time validation in `wiki_write` and `emit_unmapped_fallback`.
+
+## File structure
+
+Modify these files:
+
+- `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`:
+ add `connectionName` to raw schema hit records.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`:
+ render raw hit connection names and preserve them in structured output.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`:
+ cover multi-connection raw discovery follow-up data.
+- `packages/context/src/ingest/adapters/lookml/lookml.adapter.ts`:
+ accept and return configured target warehouse connection IDs.
+- `packages/context/src/ingest/adapters/lookml/lookml.adapter.test.ts`:
+ cover LookML target warehouse IDs.
+- `packages/context/src/ingest/adapters/metricflow/metricflow.adapter.ts`:
+ accept and return configured target warehouse connection IDs.
+- `packages/context/src/ingest/adapters/metricflow/metricflow.adapter.test.ts`:
+ cover MetricFlow target warehouse IDs.
+- `packages/context/src/ingest/local-adapters.ts`:
+ pass primary warehouse IDs into LookML and MetricFlow adapters.
+- `packages/context/src/ingest/local-adapters.test.ts`:
+ cover local adapter warehouse target fan-out.
+- `packages/context/src/ingest/local-bundle-runtime.ts`:
+ pass full project connection config to local ingest query executors.
+- `packages/context/src/ingest/local-bundle-runtime.test.ts`:
+ cover the local ingest query executor call shape.
+- `packages/context/src/ingest/local-ingest.ts`:
+ use the shared query executor port type.
+- `packages/context/src/mcp/local-project-ports.ts`:
+ no behavior change expected, but type-checks against the updated local ingest
+ query executor type.
+- `packages/cli/src/ingest.ts`:
+ provide a read-only scan-connector-backed query executor for normal local
+ ingest runs.
+
+Create these files:
+
+- `packages/cli/src/ingest-query-executor.ts`: CLI query executor that adapts
+ scan connectors' `executeReadOnly()` method to `KtxSqlQueryExecutorPort`.
+- `packages/cli/src/ingest-query-executor.test.ts`: unit coverage for the CLI
+ ingest query executor.
+
+### Task 1: Preserve raw discovery connection names
+
+**Files:**
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`
+- Modify: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`
+
+- [ ] **Step 1: Write the failing multi-connection discovery test**
+
+Add this test to
+`packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`:
+
+```ts
+ it('includes connectionName on raw schema hits so entity_details can follow up', async () => {
+ const multiConnectionContext: ToolContext = {
+ ...context,
+ session: { allowedConnectionNames: new Set(['warehouse', 'analytics']) } as any,
+ };
+ catalog.searchByName.mockImplementation(async (connectionName: string, query: string) => [
+ {
+ kind: 'table',
+ connectionName,
+ ref: { catalog: null, db: 'public', name: `${connectionName}_${query}` },
+ display: `public.${connectionName}_${query}`,
+ matchedOn: 'name',
+ },
+ ]);
+
+ const result = await tool.call({ query: 'orders', limit: 10 }, multiConnectionContext);
+
+ expect(catalog.searchByName).toHaveBeenCalledWith('analytics', 'orders', 10);
+ expect(catalog.searchByName).toHaveBeenCalledWith('warehouse', 'orders', 10);
+ expect(result.markdown).toContain('connectionName=analytics');
+ expect(result.markdown).toContain('connectionName=warehouse');
+ expect(result.markdown).toContain(
+ 'entity_details({connectionName: "analytics", targets: [{display: "public.analytics_orders"}]})',
+ );
+ expect(result.structured.raw?.hits.map((hit) => hit.connectionName)).toEqual([
+ 'analytics',
+ 'warehouse',
+ ]);
+ });
+```
+
+- [ ] **Step 2: Run the failing discovery test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts -t "connectionName on raw schema hits"
+```
+
+Expected: FAIL because `RawSchemaHit` has no `connectionName` property and the
+markdown only renders the display string.
+
+- [ ] **Step 3: Add `connectionName` to raw schema hits**
+
+Modify the raw hit type and hit construction in
+`packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`:
+
+```ts
+export type RawSchemaHit =
+ | {
+ kind: 'table';
+ connectionName: string;
+ ref: KtxTableRef;
+ display: string;
+ matchedOn: 'name' | 'db' | 'comment' | 'description';
+ }
+ | {
+ kind: 'column';
+ connectionName: string;
+ ref: KtxTableRef & { column: string };
+ display: string;
+ matchedOn: 'name' | 'comment' | 'description';
+ };
+```
+
+In the table hit block, add `connectionName`:
+
+```ts
+ hits.push({
+ kind: 'table',
+ connectionName,
+ ref: { catalog: table.catalog, db: table.db, name: table.name },
+ display: formatDisplay(catalog.driver, table),
+ matchedOn: tableMatch,
+ });
+```
+
+In the column hit block, add `connectionName`:
+
+```ts
+ hits.push({
+ kind: 'column',
+ connectionName,
+ ref: { catalog: table.catalog, db: table.db, name: table.name, column: column.name },
+ display: `${formatDisplay(catalog.driver, table)}.${column.name}`,
+ matchedOn: columnMatch,
+ });
+```
+
+- [ ] **Step 4: Render follow-up-ready raw hits**
+
+Modify the raw schema markdown in
+`packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`:
+
+```ts
+ parts.push('## Raw Warehouse Schema', '> use `entity_details({connectionName, targets: [{display}]})` for full DDL + sample values');
+ parts.push(
+ rawHits
+ .slice(0, limit)
+ .map(
+ (hit) =>
+ `- ${hit.kind}: ${hit.display} [connectionName=${hit.connectionName}] (matched on ${hit.matchedOn}) — ` +
+ `follow up with \`entity_details({connectionName: "${hit.connectionName}", targets: [{display: "${hit.display}"}]})\``,
+ )
+ .join('\n'),
+ );
+```
+
+- [ ] **Step 5: Run the discovery test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 6: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+git commit -m "fix(context): include raw discovery connection names"
+```
+
+### Task 2: Expose LookML and MetricFlow warehouse targets
+
+**Files:**
+- Modify: `packages/context/src/ingest/adapters/lookml/lookml.adapter.ts`
+- Modify: `packages/context/src/ingest/adapters/lookml/lookml.adapter.test.ts`
+- Modify: `packages/context/src/ingest/adapters/metricflow/metricflow.adapter.ts`
+- Modify: `packages/context/src/ingest/adapters/metricflow/metricflow.adapter.test.ts`
+- Modify: `packages/context/src/ingest/local-adapters.ts`
+- Modify: `packages/context/src/ingest/local-adapters.test.ts`
+
+- [ ] **Step 1: Write failing adapter target tests**
+
+Add this test to
+`packages/context/src/ingest/adapters/lookml/lookml.adapter.test.ts`:
+
+```ts
+ it('returns configured target warehouse connection ids', async () => {
+ const adapter = new LookmlSourceAdapter({
+ homeDir: join(tmpRoot, 'home'),
+ targetConnectionIds: ['warehouse', 'analytics', 'warehouse'],
+ });
+
+ await expect(adapter.listTargetConnectionIds?.(join(tmpRoot, 'staged'))).resolves.toEqual([
+ 'analytics',
+ 'warehouse',
+ ]);
+ });
+```
+
+Add this test to
+`packages/context/src/ingest/adapters/metricflow/metricflow.adapter.test.ts`:
+
+```ts
+ it('returns configured target warehouse connection ids', async () => {
+ const metricflow = new MetricflowSourceAdapter({
+ homeDir: join(tmpRoot, 'cache-home'),
+ targetConnectionIds: ['warehouse', 'analytics', 'warehouse'],
+ });
+
+ await expect(metricflow.listTargetConnectionIds?.(stagedDir)).resolves.toEqual([
+ 'analytics',
+ 'warehouse',
+ ]);
+ });
+```
+
+- [ ] **Step 2: Run the failing adapter tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/adapters/lookml/lookml.adapter.test.ts -t "target warehouse connection ids" \
+ src/ingest/adapters/metricflow/metricflow.adapter.test.ts -t "target warehouse connection ids"
+```
+
+Expected: FAIL because neither adapter accepts `targetConnectionIds` or
+implements `listTargetConnectionIds()`.
+
+- [ ] **Step 3: Implement target ID support in LookML**
+
+Modify `packages/context/src/ingest/adapters/lookml/lookml.adapter.ts`:
+
+```ts
+export interface LookmlSourceAdapterDeps {
+ homeDir: string;
+ targetConnectionIds?: string[];
+}
+
+function uniqueSorted(values: readonly string[] | undefined): string[] {
+ return [...new Set(values ?? [])].sort((left, right) => left.localeCompare(right));
+}
+```
+
+Add this method to `LookmlSourceAdapter`:
+
+```ts
+ async listTargetConnectionIds(_stagedDir: string): Promise {
+ return uniqueSorted(this.deps.targetConnectionIds);
+ }
+```
+
+- [ ] **Step 4: Implement target ID support in MetricFlow**
+
+Modify `packages/context/src/ingest/adapters/metricflow/metricflow.adapter.ts`:
+
+```ts
+export interface MetricflowSourceAdapterDeps {
+ homeDir: string;
+ targetConnectionIds?: string[];
+}
+
+function uniqueSorted(values: readonly string[] | undefined): string[] {
+ return [...new Set(values ?? [])].sort((left, right) => left.localeCompare(right));
+}
+```
+
+Add this method to `MetricflowSourceAdapter`:
+
+```ts
+ async listTargetConnectionIds(_stagedDir: string): Promise {
+ return uniqueSorted(this.deps.targetConnectionIds);
+ }
+```
+
+- [ ] **Step 5: Pass primary warehouses from the local adapter factory**
+
+Modify the LookML and MetricFlow adapter construction in
+`packages/context/src/ingest/local-adapters.ts`:
+
+```ts
+ new LookmlSourceAdapter({
+ homeDir: join(project.projectDir, '.ktx/cache'),
+ targetConnectionIds: primaryWarehouseConnectionIds(project),
+ }),
+```
+
+```ts
+ new MetricflowSourceAdapter({
+ homeDir: join(project.projectDir, '.ktx/cache'),
+ targetConnectionIds: primaryWarehouseConnectionIds(project),
+ }),
+```
+
+- [ ] **Step 6: Write the local adapter fan-out test**
+
+Add this test to `packages/context/src/ingest/local-adapters.test.ts`:
+
+```ts
+ it('passes primary warehouse connection ids to local LookML and MetricFlow adapters', async () => {
+ const adapters = createDefaultLocalIngestAdapters(
+ projectWithConnections({
+ warehouse: {
+ driver: 'postgres',
+ url: 'postgresql://readonly@db.example.test/analytics',
+ },
+ lookml_docs: {
+ driver: 'lookml',
+ lookml: {
+ repoUrl: 'https://github.com/acme/lookml.git',
+ },
+ },
+ metrics_repo: {
+ driver: 'metricflow',
+ metricflow: {
+ repoUrl: 'https://github.com/acme/metrics.git',
+ },
+ },
+ } as never),
+ );
+
+ const lookml = adapters.find((adapter) => adapter.source === 'lookml');
+ const metricflow = adapters.find((adapter) => adapter.source === 'metricflow');
+
+ await expect(lookml?.listTargetConnectionIds?.('/tmp/staged-lookml')).resolves.toEqual([
+ 'warehouse',
+ ]);
+ await expect(metricflow?.listTargetConnectionIds?.('/tmp/staged-metricflow')).resolves.toEqual([
+ 'warehouse',
+ ]);
+ });
+```
+
+- [ ] **Step 7: Run the target fan-out tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/adapters/lookml/lookml.adapter.test.ts \
+ src/ingest/adapters/metricflow/metricflow.adapter.test.ts \
+ src/ingest/local-adapters.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 8: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/adapters/lookml/lookml.adapter.ts \
+ packages/context/src/ingest/adapters/lookml/lookml.adapter.test.ts \
+ packages/context/src/ingest/adapters/metricflow/metricflow.adapter.ts \
+ packages/context/src/ingest/adapters/metricflow/metricflow.adapter.test.ts \
+ packages/context/src/ingest/local-adapters.ts \
+ packages/context/src/ingest/local-adapters.test.ts
+git commit -m "fix(context): expose warehouse targets for LookML and MetricFlow"
+```
+
+### Task 3: Pass full connection config to local ingest SQL execution
+
+**Files:**
+- Modify: `packages/context/src/ingest/local-bundle-runtime.ts`
+- Modify: `packages/context/src/ingest/local-bundle-runtime.test.ts`
+- Modify: `packages/context/src/ingest/local-ingest.ts`
+
+- [ ] **Step 1: Write the failing local connection catalog test**
+
+In `packages/context/src/ingest/local-bundle-runtime.test.ts`, change the
+Vitest import to include `vi`:
+
+```ts
+import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
+```
+
+Extend `RuntimeWithConnectionDeps`:
+
+```ts
+type RuntimeWithConnectionDeps = {
+ deps: {
+ connections: {
+ listEnabledConnections(ids: string[]): Promise>;
+ getConnectionById(connectionId: string): Promise<{ id: string; name: string; connectionType: string } | null>;
+ executeQuery(connectionId: string, sql: string): Promise;
+ };
+ };
+};
+```
+
+Add this test:
+
+```ts
+ it('passes project connection config to local ingest query executors', async () => {
+ const agentRunner = new AgentRunnerService({ llmProvider: { getModel: () => ({}) as never } as any });
+ const queryExecutor = {
+ execute: vi.fn(async () => ({
+ headers: ['answer'],
+ rows: [[1]],
+ totalRows: 1,
+ command: 'SELECT',
+ rowCount: 1,
+ })),
+ };
+
+ const runtime = createLocalBundleIngestRuntime({
+ project,
+ adapters: [new FakeSourceAdapter()],
+ agentRunner,
+ queryExecutor,
+ });
+ const connections = (runtime.runner as unknown as RuntimeWithConnectionDeps).deps.connections;
+
+ await expect(connections.executeQuery('warehouse', 'select 1')).resolves.toMatchObject({
+ headers: ['answer'],
+ });
+ expect(queryExecutor.execute).toHaveBeenCalledWith({
+ connectionId: 'warehouse',
+ projectDir: project.projectDir,
+ connection: project.config.connections.warehouse,
+ sql: 'select 1',
+ });
+ });
+```
+
+- [ ] **Step 2: Run the failing local runtime test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/local-bundle-runtime.test.ts -t "project connection config"
+```
+
+Expected: FAIL because `LocalConnectionCatalog.executeQuery()` only passes
+`connectionId` and `sql`.
+
+- [ ] **Step 3: Update local ingest query executor types**
+
+In `packages/context/src/ingest/local-bundle-runtime.ts`, import the shared
+query executor type:
+
+```ts
+import { localConnectionInfoFromConfig, type KtxSqlQueryExecutorPort } from '../connections/index.js';
+```
+
+Change `CreateLocalBundleIngestRuntimeOptions.queryExecutor` to:
+
+```ts
+ queryExecutor?: KtxSqlQueryExecutorPort;
+```
+
+Change `LocalConnectionCatalog` to store that type:
+
+```ts
+class LocalConnectionCatalog implements SlConnectionCatalogPort {
+ constructor(
+ private readonly project: KtxLocalProject,
+ private readonly queryExecutor?: KtxSqlQueryExecutorPort,
+ ) {}
+```
+
+Change `executeQuery()`:
+
+```ts
+ async executeQuery(connectionId: string, sql: string): Promise {
+ if (!this.queryExecutor) {
+ throw new Error('Local ingest has no query executor configured');
+ }
+ return this.queryExecutor.execute({
+ connectionId,
+ projectDir: this.project.projectDir,
+ connection: this.project.config.connections[connectionId],
+ sql,
+ });
+ }
+```
+
+In `packages/context/src/ingest/local-ingest.ts`, replace the local query
+executor object type with the shared port:
+
+```ts
+import type { KtxSqlQueryExecutorPort } from '../connections/index.js';
+```
+
+```ts
+ queryExecutor?: KtxSqlQueryExecutorPort;
+```
+
+- [ ] **Step 4: Run the local runtime test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/local-bundle-runtime.test.ts -t "project connection config"
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/context/src/ingest/local-bundle-runtime.ts \
+ packages/context/src/ingest/local-bundle-runtime.test.ts \
+ packages/context/src/ingest/local-ingest.ts
+git commit -m "fix(context): pass connection config to ingest query executors"
+```
+
+### Task 4: Supply a scan-connector query executor to CLI ingest
+
+**Files:**
+- Create: `packages/cli/src/ingest-query-executor.ts`
+- Create: `packages/cli/src/ingest-query-executor.test.ts`
+- Modify: `packages/cli/src/ingest.ts`
+
+- [ ] **Step 1: Write the CLI query executor tests**
+
+Create `packages/cli/src/ingest-query-executor.test.ts`:
+
+```ts
+import type { KtxLocalProject } from '@ktx/context/project';
+import { createKtxConnectorCapabilities, type KtxScanConnector } from '@ktx/context/scan';
+import { describe, expect, it, vi } from 'vitest';
+import { createKtxCliIngestQueryExecutor } from './ingest-query-executor.js';
+
+function project(): KtxLocalProject {
+ return {
+ projectDir: '/tmp/ktx-query-project',
+ config: {
+ project: 'warehouse',
+ connections: {
+ warehouse: { driver: 'postgres', url: 'postgresql://readonly@example.test/db' },
+ },
+ },
+ } as unknown as KtxLocalProject;
+}
+
+function connector(overrides: Partial = {}): KtxScanConnector {
+ return {
+ id: 'warehouse',
+ driver: 'postgres',
+ capabilities: createKtxConnectorCapabilities({ readOnlySql: true }),
+ async introspect() {
+ throw new Error('introspect is not used by this test');
+ },
+ executeReadOnly: vi.fn(async () => ({
+ headers: ['answer'],
+ rows: [[1]],
+ totalRows: 1,
+ rowCount: 1,
+ })),
+ cleanup: vi.fn(async () => {}),
+ ...overrides,
+ };
+}
+
+describe('createKtxCliIngestQueryExecutor', () => {
+ it('executes read-only SQL through the scan connector and cleans it up', async () => {
+ const scanConnector = connector();
+ const createConnector = vi.fn(async () => scanConnector);
+ const executor = createKtxCliIngestQueryExecutor(project(), { createConnector });
+
+ await expect(
+ executor.execute({
+ connectionId: 'warehouse',
+ connection: { driver: 'postgres', url: 'postgresql://readonly@example.test/db' },
+ projectDir: '/tmp/ktx-query-project',
+ sql: 'select 1',
+ maxRows: 5,
+ }),
+ ).resolves.toMatchObject({
+ headers: ['answer'],
+ rows: [[1]],
+ totalRows: 1,
+ command: 'SELECT',
+ rowCount: 1,
+ });
+
+ expect(createConnector).toHaveBeenCalledWith(project(), 'warehouse');
+ expect(scanConnector.executeReadOnly).toHaveBeenCalledWith(
+ { connectionId: 'warehouse', sql: 'select 1', maxRows: 5 },
+ { runId: 'ingest-sql-execution' },
+ );
+ expect(scanConnector.cleanup).toHaveBeenCalledTimes(1);
+ });
+
+ it('rejects connectors without read-only SQL support', async () => {
+ const scanConnector = connector({
+ capabilities: createKtxConnectorCapabilities({ readOnlySql: false }),
+ executeReadOnly: undefined,
+ });
+ const executor = createKtxCliIngestQueryExecutor(project(), {
+ createConnector: vi.fn(async () => scanConnector),
+ });
+
+ await expect(
+ executor.execute({
+ connectionId: 'warehouse',
+ connection: { driver: 'postgres' },
+ projectDir: '/tmp/ktx-query-project',
+ sql: 'select 1',
+ }),
+ ).rejects.toThrow('Connection "warehouse" driver "postgres" does not support read-only SQL execution.');
+ expect(scanConnector.cleanup).toHaveBeenCalledTimes(1);
+ });
+});
+```
+
+- [ ] **Step 2: Run the failing CLI query executor test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/cli exec vitest run src/ingest-query-executor.test.ts
+```
+
+Expected: FAIL because `ingest-query-executor.ts` does not exist.
+
+- [ ] **Step 3: Add the scan-connector-backed query executor**
+
+Create `packages/cli/src/ingest-query-executor.ts`:
+
+```ts
+import type { KtxSqlQueryExecutionInput, KtxSqlQueryExecutorPort } from '@ktx/context/connections';
+import type { KtxLocalProject } from '@ktx/context/project';
+import type { KtxScanConnector, KtxScanContext } from '@ktx/context/scan';
+import { createKtxCliScanConnector } from './local-scan-connectors.js';
+
+type CreateConnector = typeof createKtxCliScanConnector;
+
+export interface KtxCliIngestQueryExecutorDeps {
+ createConnector?: CreateConnector;
+}
+
+async function cleanupConnector(connector: KtxScanConnector | null): Promise {
+ await connector?.cleanup?.();
+}
+
+export function createKtxCliIngestQueryExecutor(
+ project: KtxLocalProject,
+ deps: KtxCliIngestQueryExecutorDeps = {},
+): KtxSqlQueryExecutorPort {
+ const createConnector = deps.createConnector ?? createKtxCliScanConnector;
+ return {
+ async execute(input: KtxSqlQueryExecutionInput) {
+ let connector: KtxScanConnector | null = null;
+ try {
+ connector = await createConnector(project, input.connectionId);
+ if (!connector.capabilities.readOnlySql || !connector.executeReadOnly) {
+ throw new Error(
+ `Connection "${input.connectionId}" driver "${connector.driver}" does not support read-only SQL execution.`,
+ );
+ }
+
+ const ctx: KtxScanContext = { runId: 'ingest-sql-execution' };
+ const result = await connector.executeReadOnly(
+ { connectionId: input.connectionId, sql: input.sql, maxRows: input.maxRows },
+ ctx,
+ );
+ return {
+ headers: result.headers,
+ rows: result.rows,
+ totalRows: result.totalRows,
+ command: 'SELECT',
+ rowCount: result.rowCount,
+ };
+ } finally {
+ await cleanupConnector(connector);
+ }
+ },
+ };
+}
+```
+
+- [ ] **Step 4: Wire the CLI executor into local ingest runs**
+
+In `packages/cli/src/ingest.ts`, import the executor and type:
+
+```ts
+import type { KtxSqlQueryExecutorPort } from '@ktx/context/connections';
+import type { KtxLocalProject } from '@ktx/context/project';
+import { createKtxCliIngestQueryExecutor } from './ingest-query-executor.js';
+```
+
+Extend `KtxIngestDeps`:
+
+```ts
+ createQueryExecutor?: (project: KtxLocalProject) => KtxSqlQueryExecutorPort;
+```
+
+Inside the `args.command === 'run'` branch, after `localIngestOptions` is
+defined, add:
+
+```ts
+ const queryExecutor =
+ localIngestOptions.queryExecutor ??
+ (deps.createQueryExecutor ?? createKtxCliIngestQueryExecutor)(project);
+```
+
+Pass `queryExecutor` to both local ingest execution paths. In the Metabase
+fan-out call:
+
+```ts
+ ...localIngestOptions,
+ queryExecutor,
+ trigger: 'manual_resync',
+```
+
+In the normal local ingest call:
+
+```ts
+ ...localIngestOptions,
+ queryExecutor,
+ pullConfigOptions: adapterOptions,
+```
+
+- [ ] **Step 5: Add CLI wiring coverage**
+
+Add this test to `packages/cli/src/ingest.test.ts`:
+
+```ts
+ it('supplies a scan-connector query executor to local ingest runs', async () => {
+ const io = makeIo();
+ const projectDir = join(tempDir, 'query-executor-project');
+ await writeWarehouseConfig(projectDir);
+ const queryExecutor = {
+ execute: vi.fn(async () => ({
+ headers: [],
+ rows: [],
+ totalRows: 0,
+ command: 'SELECT',
+ rowCount: 0,
+ })),
+ };
+ const runLocalIngest = vi.fn(async (input: RunLocalIngestOptions): Promise =>
+ completedLocalBundleRun(input, 'query-executor-run'),
+ );
+
+ await expect(
+ runKtxIngest(
+ {
+ command: 'run',
+ projectDir,
+ connectionId: 'warehouse',
+ adapter: 'fake',
+ outputMode: 'json',
+ },
+ io.io,
+ {
+ runLocalIngest,
+ createAdapters: () => [],
+ createQueryExecutor: () => queryExecutor,
+ },
+ ),
+ ).resolves.toBe(0);
+
+ expect(runLocalIngest).toHaveBeenCalledWith(expect.objectContaining({ queryExecutor }));
+ });
+```
+
+- [ ] **Step 6: Run CLI query executor tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/cli exec vitest run src/ingest-query-executor.test.ts src/ingest.test.ts -t "query executor"
+```
+
+Expected: PASS.
+
+- [ ] **Step 7: Commit**
+
+Run:
+
+```bash
+git add \
+ packages/cli/src/ingest-query-executor.ts \
+ packages/cli/src/ingest-query-executor.test.ts \
+ packages/cli/src/ingest.ts \
+ packages/cli/src/ingest.test.ts
+git commit -m "fix(cli): enable read-only SQL probes for local ingest"
+```
+
+### Task 5: Final verification
+
+**Files:**
+- Verify: all files changed by Tasks 1-4.
+
+- [ ] **Step 1: Run focused context tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run \
+ src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts \
+ src/ingest/tools/warehouse-verification/entity-details.tool.test.ts \
+ src/ingest/tools/warehouse-verification/discover-data.tool.test.ts \
+ src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts \
+ src/ingest/local-bundle-runtime.test.ts \
+ src/ingest/local-adapters.test.ts \
+ src/ingest/adapters/lookml/lookml.adapter.test.ts \
+ src/ingest/adapters/metricflow/metricflow.adapter.test.ts \
+ src/ingest/ingest-bundle.runner.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 2: Run focused CLI tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/cli exec vitest run src/ingest-query-executor.test.ts src/ingest.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 3: Run type checks**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context run type-check
+pnpm --filter @ktx/cli run type-check
+```
+
+Expected: both commands pass.
+
+- [ ] **Step 4: Run pre-commit on changed files if configured**
+
+Run:
+
+```bash
+uv run pre-commit run --files \
+ packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts \
+ packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts \
+ packages/context/src/ingest/adapters/lookml/lookml.adapter.ts \
+ packages/context/src/ingest/adapters/lookml/lookml.adapter.test.ts \
+ packages/context/src/ingest/adapters/metricflow/metricflow.adapter.ts \
+ packages/context/src/ingest/adapters/metricflow/metricflow.adapter.test.ts \
+ packages/context/src/ingest/local-adapters.ts \
+ packages/context/src/ingest/local-adapters.test.ts \
+ packages/context/src/ingest/local-bundle-runtime.ts \
+ packages/context/src/ingest/local-bundle-runtime.test.ts \
+ packages/context/src/ingest/local-ingest.ts \
+ packages/cli/src/ingest-query-executor.ts \
+ packages/cli/src/ingest-query-executor.test.ts \
+ packages/cli/src/ingest.ts \
+ packages/cli/src/ingest.test.ts \
+ docs/superpowers/plans/2026-05-12-warehouse-verification-final-v1-closure.md
+```
+
+Expected: PASS. If the repository has no pre-commit config or the local `uv`
+version cannot satisfy the configured toolchain, record the exact error and use
+the focused test and type-check results as the closest verification.
+
+- [ ] **Step 5: Commit final verification fixes if any were needed**
+
+If verification required edits, run:
+
+```bash
+git add
+git commit -m "test: cover warehouse verification v1 closure"
+```
+
+If verification required no edits, do not create an empty commit.
+
+## Self-review
+
+Spec coverage:
+
+- Raw warehouse discovery still covers wiki, semantic-layer, and raw schema
+ results, and now raw hits include the connection name needed by the required
+ `entity_details` follow-up.
+- Every local synthesis adapter with an external source connection now has a
+ path to target warehouse IDs: dbt and Notion already had it, Looker resolves
+ staged mappings, Metabase fan-out runs under target warehouse IDs, and this
+ plan adds LookML and MetricFlow.
+- `sql_execution` remains scoped by `allowedConnectionNames`, retains the
+ read-only SQL wrapper, and gains a normal local ingest execution backend.
+
+Placeholder scan:
+
+- This plan contains no deferred implementation placeholders.
+- Every code-changing step includes the exact test or implementation snippet to
+ add.
+
+Type consistency:
+
+- `connectionName` is added to `RawSchemaHit` and used by `DiscoverDataTool`.
+- `targetConnectionIds` and `listTargetConnectionIds()` match the existing dbt
+ and Notion adapter pattern.
+- Local ingest uses `KtxSqlQueryExecutorPort` consistently from CLI to context.
diff --git a/docs/superpowers/plans/2026-05-12-warehouse-verification-tools.md b/docs/superpowers/plans/2026-05-12-warehouse-verification-tools.md
new file mode 100644
index 00000000..42bb7f44
--- /dev/null
+++ b/docs/superpowers/plans/2026-05-12-warehouse-verification-tools.md
@@ -0,0 +1,1617 @@
+# Warehouse Verification Tools Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Add synthesis-time warehouse verification tools so ingest agents can verify raw warehouse tables, columns, and sample values before writing wiki pages, SL sources, `tables:` frontmatter, `sl_refs`, or unmapped fallback records.
+
+**Architecture:** Add a raw scan catalog service over `raw-sources//live-database//`, three BaseTool-backed ingest tools, and runner/tool-session scoping for allowed warehouse connections. Register the tools in the local ingest toolset so both WorkUnit and reconcile stages receive them through the existing `toAiSdkTools()` path.
+
+**Tech Stack:** TypeScript, Node 22, Vitest, AI SDK v6 tools, Zod, KTX file store, KTX semantic layer and wiki tools.
+
+---
+
+## Audit summary
+
+The current repo has the original spec file only; no matching plan or implementation exists under `docs/superpowers/plans`. The following v1-blocking gaps remain:
+
+- `packages/context/src/connections/dialects.ts` does not exist.
+- `packages/context/src/ingest/tools/warehouse-verification/` does not exist.
+- `entity_details`, `sql_execution`, and `discover_data` are not available to ingest WU or reconcile toolsets.
+- `ToolSession` does not carry the ingest stage's allowed warehouse connection IDs.
+- Prompt updates are absent from the 11 writer skills named in the spec.
+- Cleanup strings remain: `orbit_analytics.customer`, `wiki_sl_search`, and `sl_describe_table`.
+- Prompt-bundling and warehouse-tool tests are absent.
+
+Non-blocking gaps remain out of scope for this plan:
+
+- Hard write-time validation in `wiki_write` and `emit_unmapped_fallback`.
+- `dictionary_search`.
+- `semantic_query` in synthesis toolsets.
+- A raw-schema FTS index.
+- A UUID identity layer for tables and columns.
+
+One repo-specific adjustment is required: do not import `@ktx/connector-*`
+dialect classes into `@ktx/context`, because every connector package already
+depends on `@ktx/context`. Add a minimal context-local dialect dispatch instead.
+
+## File structure
+
+Create these files:
+
+- `packages/context/src/connections/dialects.ts`: Context-local driver dispatch for identifier quoting and display formatting.
+- `packages/context/src/connections/dialects.test.ts`: Driver dispatch and display-format tests.
+- `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`: Reads the latest live-database scan, resolves display identifiers, and searches table and column metadata.
+- `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`: Fixture-backed catalog tests.
+- `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`: `entity_details` ingest tool.
+- `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts`: Tool contract tests.
+- `packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.ts`: `sql_execution` ingest tool.
+- `packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts`: Read-only SQL and output tests.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`: `discover_data` ingest tool composing wiki, SL, and raw-schema search.
+- `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`: Discovery composition tests.
+- `packages/context/src/ingest/tools/warehouse-verification/index.ts`: Exports tool classes and `createWarehouseVerificationTools()`.
+- `packages/context/skills/_shared/identifier-verification.md`: Shared protocol text kept in the tree for review even though writer skills inline it.
+
+Modify these files:
+
+- `packages/context/src/connections/index.ts`: Export the dialect helper.
+- `packages/context/src/tools/tool-session.ts`: Add `allowedConnectionNames`.
+- `packages/context/src/ingest/ingest-bundle.runner.ts`: Populate `allowedConnectionNames` for WU and reconcile sessions.
+- `packages/context/src/ingest/local-bundle-runtime.ts`: Register the warehouse verification tools in `LocalIngestToolsetFactory`.
+- `packages/context/src/ingest/ingest-bundle.runner.test.ts`: Assert the runner scopes allowed warehouse connections.
+- `packages/context/src/memory/memory-runtime-assets.test.ts`: Assert writer skills contain the protocol and banned strings are gone.
+- `packages/context/src/ingest/ingest-runtime-assets.test.ts`: Assert ingest skill packaging includes the protocol.
+- `packages/context/src/ingest/tools/emit-unmapped-fallback.tool.ts`: Replace the fictional table example.
+- `packages/context/src/sl/tools/sl-warehouse-validation.ts`: Replace the stale `sl_describe_table` hint.
+- `packages/context/skills/*/SKILL.md`: Inline protocol updates for the writer skills listed in the spec.
+
+### Task 1: Add context-local dialect dispatch
+
+**Files:**
+- Create: `packages/context/src/connections/dialects.ts`
+- Create: `packages/context/src/connections/dialects.test.ts`
+- Modify: `packages/context/src/connections/index.ts`
+
+- [ ] **Step 1: Write the failing dialect tests**
+
+Create `packages/context/src/connections/dialects.test.ts`:
+
+```ts
+import { describe, expect, it } from 'vitest';
+import { getDialectForDriver } from './dialects.js';
+
+describe('getDialectForDriver', () => {
+ it.each([
+ ['postgres', '"public"."orders"'],
+ ['postgresql', '"public"."orders"'],
+ ['mysql', '`public`.`orders`'],
+ ['clickhouse', '`public`.`orders`'],
+ ['sqlite', '"orders"'],
+ ['snowflake', '"analytics"."public"."orders"'],
+ ['bigquery', '`analytics`.`public`.`orders`'],
+ ['sqlserver', '[analytics].[public].[orders]'],
+ ] as const)('formats table names for %s', (driver, expected) => {
+ const dialect = getDialectForDriver(driver);
+ expect(
+ dialect.formatTableName({
+ catalog: driver === 'snowflake' || driver === 'bigquery' || driver === 'sqlserver' ? 'analytics' : null,
+ db: driver === 'sqlite' ? null : 'public',
+ name: 'orders',
+ }),
+ ).toBe(expected);
+ });
+
+ it('throws with a supported-driver list for unknown drivers', () => {
+ expect(() => getDialectForDriver('oracle')).toThrow(
+ 'Unsupported warehouse driver "oracle". Supported drivers: bigquery, clickhouse, mysql, postgres, postgresql, sqlite, sqlite3, snowflake, sqlserver',
+ );
+ });
+});
+```
+
+- [ ] **Step 2: Run the failing test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/connections/dialects.test.ts
+```
+
+Expected: FAIL because `./dialects.js` does not exist.
+
+- [ ] **Step 3: Add the minimal dialect implementation**
+
+Create `packages/context/src/connections/dialects.ts`:
+
+```ts
+import type { KtxSchemaDimensionType, KtxTableRef } from '../scan/types.js';
+
+export type SupportedDriver =
+ | 'postgres'
+ | 'postgresql'
+ | 'mysql'
+ | 'sqlserver'
+ | 'snowflake'
+ | 'bigquery'
+ | 'clickhouse'
+ | 'sqlite'
+ | 'sqlite3';
+
+export interface KtxDialect {
+ readonly type: SupportedDriver;
+ quoteIdentifier(identifier: string): string;
+ formatTableName(table: KtxTableRef): string;
+ mapToDimensionType(nativeType: string): KtxSchemaDimensionType;
+}
+
+const supportedDrivers: SupportedDriver[] = [
+ 'bigquery',
+ 'clickhouse',
+ 'mysql',
+ 'postgres',
+ 'postgresql',
+ 'sqlite',
+ 'sqlite3',
+ 'snowflake',
+ 'sqlserver',
+];
+
+function doubleQuoted(identifier: string): string {
+ return `"${identifier.replace(/"/g, '""')}"`;
+}
+
+function backtickQuoted(identifier: string): string {
+ return `\`${identifier.replace(/`/g, '``')}\``;
+}
+
+function bigQueryQuoted(identifier: string): string {
+ return `\`${identifier.replace(/`/g, '\\`')}\``;
+}
+
+function bracketQuoted(identifier: string): string {
+ return `[${identifier.replace(/\]/g, ']]')}]`;
+}
+
+function inferDimensionType(nativeType: string): KtxSchemaDimensionType {
+ const normalized = nativeType.toLowerCase().trim();
+ if (normalized.includes('date') || normalized.includes('time')) {
+ return 'time';
+ }
+ if (
+ normalized.includes('int') ||
+ normalized.includes('num') ||
+ normalized.includes('dec') ||
+ normalized.includes('float') ||
+ normalized.includes('double') ||
+ normalized.includes('real')
+ ) {
+ return 'number';
+ }
+ if (normalized.includes('bool') || normalized === 'bit') {
+ return 'boolean';
+ }
+ return 'string';
+}
+
+function formatWithParts(table: KtxTableRef, quote: (identifier: string) => string, sqlite = false): string {
+ const parts = sqlite ? [table.name] : [table.catalog, table.db, table.name].filter((part): part is string => !!part);
+ return parts.map(quote).join('.');
+}
+
+function createDialect(type: SupportedDriver, quote: (identifier: string) => string, sqlite = false): KtxDialect {
+ return {
+ type,
+ quoteIdentifier: quote,
+ formatTableName: (table) => formatWithParts(table, quote, sqlite),
+ mapToDimensionType: inferDimensionType,
+ };
+}
+
+const dialects: Record = {
+ postgres: createDialect('postgres', doubleQuoted),
+ postgresql: createDialect('postgresql', doubleQuoted),
+ mysql: createDialect('mysql', backtickQuoted),
+ clickhouse: createDialect('clickhouse', backtickQuoted),
+ sqlite: createDialect('sqlite', doubleQuoted, true),
+ sqlite3: createDialect('sqlite3', doubleQuoted, true),
+ snowflake: createDialect('snowflake', doubleQuoted),
+ bigquery: createDialect('bigquery', bigQueryQuoted),
+ sqlserver: createDialect('sqlserver', bracketQuoted),
+};
+
+export function getDialectForDriver(driver: string): KtxDialect {
+ const normalized = driver.toLowerCase().trim();
+ if (normalized in dialects) {
+ return dialects[normalized as SupportedDriver];
+ }
+ throw new Error(`Unsupported warehouse driver "${driver}". Supported drivers: ${supportedDrivers.join(', ')}`);
+}
+```
+
+Modify `packages/context/src/connections/index.ts`:
+
+```ts
+export type { KtxDialect, SupportedDriver } from './dialects.js';
+export { getDialectForDriver } from './dialects.js';
+```
+
+- [ ] **Step 4: Run the dialect tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/connections/dialects.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/connections/dialects.ts packages/context/src/connections/dialects.test.ts packages/context/src/connections/index.ts
+git commit -m "feat(context): add warehouse dialect dispatch"
+```
+
+### Task 2: Add the raw scan warehouse catalog service
+
+**Files:**
+- Create: `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts`
+- Create: `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`
+
+- [ ] **Step 1: Write failing catalog tests**
+
+Create `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts`:
+
+```ts
+import { mkdtemp, rm } from 'node:fs/promises';
+import { tmpdir } from 'node:os';
+import { join } from 'node:path';
+import { afterEach, beforeEach, describe, expect, it } from 'vitest';
+import { initKtxProject, type KtxLocalProject } from '../../../project/index.js';
+import { WarehouseCatalogService } from './warehouse-catalog.service.js';
+
+describe('WarehouseCatalogService', () => {
+ let tempDir: string;
+ let project: KtxLocalProject;
+
+ beforeEach(async () => {
+ tempDir = await mkdtemp(join(tmpdir(), 'ktx-warehouse-catalog-'));
+ project = await initKtxProject({ projectDir: join(tempDir, 'project'), projectName: 'warehouse' });
+ });
+
+ afterEach(async () => {
+ await rm(tempDir, { recursive: true, force: true });
+ });
+
+ async function seedLiveDatabaseScan(connectionName = 'warehouse', syncId = 'sync-2', driver = 'postgres') {
+ const root = `raw-sources/${connectionName}/live-database/${syncId}`;
+ await project.fileStore.writeFile(
+ `${root}/connection.json`,
+ JSON.stringify({ connectionId: connectionName, driver, extractedAt: '2026-05-12T00:00:00.000Z' }, null, 2),
+ 'ktx',
+ 'ktx@example.com',
+ 'seed connection',
+ );
+ await project.fileStore.writeFile(
+ `${root}/tables/orders.json`,
+ JSON.stringify(
+ {
+ catalog: null,
+ db: driver === 'sqlite' ? null : 'public',
+ name: 'orders',
+ kind: 'table',
+ comment: 'Customer orders',
+ estimatedRows: 12,
+ columns: [
+ {
+ name: 'id',
+ nativeType: 'integer',
+ normalizedType: 'integer',
+ dimensionType: 'number',
+ nullable: false,
+ primaryKey: true,
+ comment: 'Order id',
+ },
+ {
+ name: 'status',
+ nativeType: 'text',
+ normalizedType: 'text',
+ dimensionType: 'string',
+ nullable: false,
+ primaryKey: false,
+ comment: 'Order status',
+ },
+ ],
+ foreignKeys: [],
+ },
+ null,
+ 2,
+ ),
+ 'ktx',
+ 'ktx@example.com',
+ 'seed orders',
+ );
+ await project.fileStore.writeFile(
+ `${root}/enrichment/relationship-profile.json`,
+ JSON.stringify(
+ {
+ connectionId: connectionName,
+ driver,
+ sqlAvailable: true,
+ queryCount: 3,
+ tables: [{ table: { catalog: null, db: driver === 'sqlite' ? null : 'public', name: 'orders' }, rowCount: 12 }],
+ columns: {
+ 'orders.status': {
+ table: { catalog: null, db: driver === 'sqlite' ? null : 'public', name: 'orders' },
+ column: 'status',
+ nativeType: 'text',
+ normalizedType: 'text',
+ rowCount: 12,
+ nullCount: 0,
+ distinctCount: 2,
+ uniquenessRatio: 0.1667,
+ nullRate: 0,
+ sampleValues: ['paid', 'refunded'],
+ minTextLength: 4,
+ maxTextLength: 8,
+ },
+ },
+ warnings: [],
+ },
+ null,
+ 2,
+ ),
+ 'ktx',
+ 'ktx@example.com',
+ 'seed profile',
+ );
+ }
+
+ it('finds the latest sync and merges table schema with relationship profile values', async () => {
+ await seedLiveDatabaseScan('warehouse', 'sync-1');
+ await seedLiveDatabaseScan('warehouse', 'sync-2');
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.getLatestSyncId('warehouse')).resolves.toBe('sync-2');
+ const detail = await catalog.getTable({ connectionName: 'warehouse', catalog: null, db: 'public', name: 'orders' });
+
+ expect(detail).toMatchObject({
+ connectionName: 'warehouse',
+ display: 'public.orders',
+ rowCount: 12,
+ columns: [
+ { name: 'id', nativeType: 'integer', primaryKey: true },
+ { name: 'status', nativeType: 'text', sampleValues: ['paid', 'refunded'], distinctCount: 2 },
+ ],
+ });
+ });
+
+ it('returns scanAvailable=false when no live-database scan exists', async () => {
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+ await expect(catalog.getTable({ connectionName: 'missing', catalog: null, db: 'public', name: 'orders' })).resolves.toBeNull();
+ await expect(catalog.hasScan('missing')).resolves.toBe(false);
+ });
+
+ it('resolves postgres display strings and returns closest candidates for missing tables', async () => {
+ await seedLiveDatabaseScan();
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.resolveDisplay('warehouse', 'public.orders')).resolves.toMatchObject({
+ resolved: { catalog: null, db: 'public', name: 'orders' },
+ candidates: [],
+ dialect: 'postgres',
+ });
+ await expect(catalog.resolveDisplay('warehouse', 'public.orderz')).resolves.toMatchObject({
+ resolved: null,
+ candidates: [{ name: 'orders' }],
+ });
+ });
+
+ it('treats two-part BigQuery identifiers as ambiguous instead of guessing', async () => {
+ await seedLiveDatabaseScan('warehouse', 'sync-bigquery', 'bigquery');
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.resolveDisplay('warehouse', 'public.orders')).resolves.toMatchObject({
+ resolved: null,
+ dialect: 'bigquery',
+ });
+ });
+
+ it('searches table names, column names, comments, and descriptions', async () => {
+ await seedLiveDatabaseScan();
+ const catalog = new WarehouseCatalogService({ fileStore: project.fileStore });
+
+ await expect(catalog.searchByName('warehouse', 'status', 10)).resolves.toEqual(
+ expect.arrayContaining([
+ expect.objectContaining({
+ kind: 'column',
+ ref: expect.objectContaining({ db: 'public', name: 'orders', column: 'status' }),
+ matchedOn: 'name',
+ }),
+ ]),
+ );
+ });
+});
+```
+
+- [ ] **Step 2: Run the failing catalog tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts
+```
+
+Expected: FAIL because the service file does not exist.
+
+- [ ] **Step 3: Add the catalog service**
+
+Create `packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts` with these exported shapes and behavior:
+
+```ts
+import type { KtxFileStorePort } from '../../../core/index.js';
+import { getDialectForDriver } from '../../../connections/index.js';
+import type { KtxConnectionDriver, KtxSchemaColumn, KtxSchemaForeignKey, KtxSchemaTable, KtxTableRef } from '../../../scan/types.js';
+
+export interface WarehouseCatalogServiceDeps {
+ fileStore: KtxFileStorePort;
+}
+
+export interface WarehouseColumnDetail extends KtxSchemaColumn {
+ descriptions: Record;
+ rowCount: number | null;
+ nullCount: number | null;
+ distinctCount: number | null;
+ nullRate: number | null;
+ sampleValues: string[];
+}
+
+export interface TableDetail {
+ connectionName: string;
+ catalog: string | null;
+ db: string | null;
+ name: string;
+ display: string;
+ kind: string;
+ comment: string | null;
+ description: string | null;
+ rowCount: number | null;
+ columns: WarehouseColumnDetail[];
+ foreignKeys: KtxSchemaForeignKey[];
+}
+
+export type RawSchemaHit =
+ | { kind: 'table'; ref: KtxTableRef; display: string; matchedOn: 'name' | 'db' | 'comment' | 'description' }
+ | { kind: 'column'; ref: KtxTableRef & { column: string }; display: string; matchedOn: 'name' | 'comment' | 'description' };
+
+interface ConnectionArtifact {
+ driver?: KtxConnectionDriver;
+}
+
+interface RelationshipProfileColumn {
+ table?: KtxTableRef;
+ column?: string;
+ rowCount?: number;
+ nullCount?: number;
+ distinctCount?: number;
+ nullRate?: number;
+ sampleValues?: unknown[];
+}
+
+interface RelationshipProfileArtifact {
+ driver?: KtxConnectionDriver;
+ tables?: Array<{ table?: KtxTableRef; rowCount?: number }>;
+ columns?: Record;
+}
+
+interface ConnectionCatalog {
+ connectionName: string;
+ syncId: string;
+ driver: KtxConnectionDriver;
+ tables: KtxSchemaTable[];
+ profile: RelationshipProfileArtifact | null;
+}
+```
+
+The implementation must:
+
+- Use `fileStore.listFiles("raw-sources//live-database")` and choose the lexicographically latest path ending in `/connection.json`.
+- Read every JSON file under `/tables/` rather than reconstructing a path from the table ref. This supports encoded and simple table filenames already present in tests.
+- Parse display strings by driver:
+ - Postgres, MySQL, and ClickHouse: `schema.table`.
+ - SQL Server, Snowflake, and BigQuery: `catalog.schema.table`.
+ - SQLite: `table`.
+ - For BigQuery, a two-part display must return `resolved: null` and candidate matches.
+- Match table refs case-insensitively, while preserving stored casing in outputs.
+- Merge relationship-profile fields by `(catalog, db, name, column)`, with fallback matching on `table.name + "." + column`.
+- Cache a loaded connection catalog per `connectionName` within the service instance.
+- Return `null` from `getTable()` when the scan is absent or the table ref is not found.
+
+Use these method signatures:
+
+```ts
+export class WarehouseCatalogService {
+ constructor(private readonly deps: WarehouseCatalogServiceDeps) {}
+
+ async hasScan(connectionName: string): Promise;
+ async getLatestSyncId(connectionName: string): Promise;
+ async listTables(connectionName: string): Promise;
+ async getTable(ref: { connectionName: string } & KtxTableRef): Promise;
+ async resolveDisplay(connectionName: string, display: string): Promise<{
+ resolved: KtxTableRef | null;
+ candidates: KtxTableRef[];
+ dialect: string;
+ }>;
+ async searchByName(connectionName: string, query: string, limit: number): Promise;
+}
+```
+
+- [ ] **Step 4: Run the catalog tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.ts packages/context/src/ingest/tools/warehouse-verification/warehouse-catalog.service.test.ts
+git commit -m "feat(context): read warehouse scan catalog"
+```
+
+### Task 3: Add `entity_details`
+
+**Files:**
+- Create: `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`
+- Create: `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts`
+
+- [ ] **Step 1: Write failing `entity_details` tests**
+
+Create tests that instantiate the tool with a seeded `WarehouseCatalogService` and a `ToolContext` whose session has `allowedConnectionNames: new Set(['warehouse'])`. Test these cases:
+
+```ts
+it('returns scoped table detail for a display target', async () => {
+ const result = await tool.call(
+ { connectionName: 'warehouse', targets: [{ display: 'public.orders' }] },
+ context,
+ );
+ expect(result.markdown).toContain('### public.orders');
+ expect(result.markdown).toContain('- status (text, nullable=false)');
+ expect(result.markdown).toContain('sample: ["paid","refunded"]');
+ expect(result.structured.scanAvailable).toBe(true);
+ expect(result.structured.resolved).toHaveLength(1);
+});
+
+it('returns a no-scan state distinct from not found', async () => {
+ const result = await tool.call(
+ { connectionName: 'empty', targets: [{ display: 'public.orders' }] },
+ { ...context, session: { ...context.session!, allowedConnectionNames: new Set(['empty']) } },
+ );
+ expect(result.markdown).toContain('No live-database scan available for connection "empty"; run `ktx scan` first.');
+ expect(result.structured.scanAvailable).toBe(false);
+});
+
+it('refuses out-of-scope connections', async () => {
+ const result = await tool.call(
+ { connectionName: 'billing', targets: [{ display: 'public.orders' }] },
+ context,
+ );
+ expect(result.markdown).toContain('Connection "billing" is not available to this ingest stage.');
+ expect(result.structured.scanAvailable).toBe(false);
+});
+```
+
+- [ ] **Step 2: Run the failing tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+```
+
+Expected: FAIL because the tool file does not exist.
+
+- [ ] **Step 3: Implement the tool**
+
+Create `packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts`:
+
+```ts
+import { z } from 'zod';
+import { BaseTool, type ToolContext, type ToolOutput } from '../../../tools/index.js';
+import type { KtxTableRef } from '../../../scan/types.js';
+import { WarehouseCatalogService, type TableDetail } from './warehouse-catalog.service.js';
+
+const targetSchema = z.union([
+ z.object({ display: z.string().min(1) }),
+ z.object({
+ catalog: z.string().nullable(),
+ db: z.string().nullable(),
+ name: z.string().min(1),
+ column: z.string().optional(),
+ }),
+]);
+
+const entityDetailsInputSchema = z.object({
+ connectionName: z.string().regex(/^[a-zA-Z0-9][a-zA-Z0-9_-]*$/),
+ targets: z.array(targetSchema).min(1).max(50),
+});
+
+type EntityDetailsInput = z.infer;
+
+export interface EntityDetailsStructured {
+ resolved: TableDetail[];
+ missing: Array<{ target: unknown; candidates: KtxTableRef[] }>;
+ scanAvailable: boolean;
+}
+
+function allowedConnectionNames(context: ToolContext): ReadonlySet | null {
+ return context.session?.allowedConnectionNames ?? null;
+}
+
+function sampleText(values: string[]): string {
+ return values.length > 0 ? ` - sample: ${JSON.stringify(values.slice(0, 10))}` : '';
+}
+
+function appendTableMarkdown(parts: string[], detail: TableDetail, columnName?: string): void {
+ const columns = columnName ? detail.columns.filter((column) => column.name === columnName) : detail.columns;
+ parts.push(`### ${detail.display}`);
+ parts.push(`Type: ${detail.kind} | Native columns: ${detail.columns.length}`);
+ if (detail.description || detail.comment) {
+ parts.push(`Description: ${detail.description ?? detail.comment}`);
+ }
+ parts.push('', 'Columns:');
+ for (const column of columns) {
+ const pk = column.primaryKey ? ', PK' : '';
+ parts.push(`- ${column.name} (${column.nativeType}, nullable=${column.nullable}${pk})${sampleText(column.sampleValues)}`);
+ }
+ parts.push('');
+}
+
+export class EntityDetailsTool extends BaseTool {
+ readonly name = 'entity_details';
+
+ constructor(private readonly catalogFactory: (context: ToolContext) => WarehouseCatalogService) {
+ super();
+ }
+
+ get description(): string {
+ return 'Verify warehouse tables and columns from the latest live-database scan before writing them into wiki or semantic-layer output.';
+ }
+
+ get inputSchema() {
+ return entityDetailsInputSchema;
+ }
+
+ async call(input: EntityDetailsInput, context: ToolContext): Promise> {
+ const allowed = allowedConnectionNames(context);
+ if (allowed && !allowed.has(input.connectionName)) {
+ return {
+ markdown: `Connection "${input.connectionName}" is not available to this ingest stage.`,
+ structured: { resolved: [], missing: [], scanAvailable: false },
+ };
+ }
+
+ const catalog = this.catalogFactory(context);
+ const scanAvailable = await catalog.hasScan(input.connectionName);
+ if (!scanAvailable) {
+ return {
+ markdown: `No live-database scan available for connection "${input.connectionName}"; run \`ktx scan\` first.`,
+ structured: { resolved: [], missing: [], scanAvailable: false },
+ };
+ }
+
+ const parts: string[] = [];
+ const resolved: TableDetail[] = [];
+ const missing: EntityDetailsStructured['missing'] = [];
+
+ for (const target of input.targets) {
+ const resolution =
+ 'display' in target
+ ? await catalog.resolveDisplay(input.connectionName, target.display)
+ : { resolved: { catalog: target.catalog, db: target.db, name: target.name }, candidates: [], dialect: '' };
+ if (!resolution.resolved) {
+ missing.push({ target, candidates: resolution.candidates });
+ parts.push(`Not found in scan: ${'display' in target ? target.display : target.name}`);
+ if (resolution.candidates.length > 0) {
+ parts.push(`Closest matches: ${resolution.candidates.map((candidate) => candidate.name).join(', ')}`);
+ }
+ continue;
+ }
+ const detail = await catalog.getTable({ connectionName: input.connectionName, ...resolution.resolved });
+ if (!detail) {
+ missing.push({ target, candidates: resolution.candidates });
+ continue;
+ }
+ resolved.push(detail);
+ appendTableMarkdown(parts, detail, 'column' in target ? target.column : undefined);
+ }
+
+ return {
+ markdown: parts.join('\n').trim(),
+ structured: { resolved, missing, scanAvailable: true },
+ };
+ }
+}
+```
+
+- [ ] **Step 4: Run the `entity_details` tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.ts packages/context/src/ingest/tools/warehouse-verification/entity-details.tool.test.ts
+git commit -m "feat(context): add entity details verification tool"
+```
+
+### Task 4: Add `sql_execution`
+
+**Files:**
+- Create: `packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.ts`
+- Create: `packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts`
+
+- [ ] **Step 1: Write failing `sql_execution` tests**
+
+Create tests for:
+
+```ts
+it('wraps read-only SQL with a capped row limit', async () => {
+ connections.executeQuery.mockResolvedValue({ headers: ['status'], rows: [['paid']], totalRows: 1 });
+ const result = await tool.call(
+ { connectionName: 'warehouse', sql: 'select status from public.orders', rowLimit: 5 },
+ context,
+ );
+ expect(connections.executeQuery).toHaveBeenCalledWith(
+ 'warehouse',
+ 'select * from (select status from public.orders) as ktx_query_result limit 5',
+ );
+ expect(result.markdown).toContain('| status |');
+ expect(result.structured.wrappedSql).toContain('limit 5');
+});
+
+it.each(['insert into x values (1)', 'drop table x', 'vacuum'])('rejects mutating SQL: %s', async (sql) => {
+ const result = await tool.call({ connectionName: 'warehouse', sql }, context);
+ expect(result.markdown).toContain('Only read-only SELECT/WITH queries can be executed locally.');
+ expect(connections.executeQuery).not.toHaveBeenCalled();
+});
+
+it('surfaces connector errors verbatim', async () => {
+ connections.executeQuery.mockRejectedValue(new Error('relation "orbit_analytics.customer" does not exist'));
+ const result = await tool.call(
+ { connectionName: 'warehouse', sql: 'select 1 from orbit_analytics.customer', rowLimit: 1 },
+ context,
+ );
+ expect(result.markdown).toContain('relation "orbit_analytics.customer" does not exist');
+ expect(result.structured.error).toContain('relation "orbit_analytics.customer" does not exist');
+});
+```
+
+- [ ] **Step 2: Run the failing tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts
+```
+
+Expected: FAIL because the tool file does not exist.
+
+- [ ] **Step 3: Implement the tool**
+
+Create `packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.ts`:
+
+```ts
+import { z } from 'zod';
+import { assertReadOnlySql, limitSqlForExecution } from '../../../connections/index.js';
+import type { SlConnectionCatalogPort } from '../../../sl/index.js';
+import { BaseTool, type ToolContext, type ToolOutput } from '../../../tools/index.js';
+
+const sqlExecutionInputSchema = z.object({
+ connectionName: z.string().regex(/^[a-zA-Z0-9][a-zA-Z0-9_-]*$/),
+ sql: z.string().min(1),
+ rowLimit: z.number().int().positive().max(1000).optional().default(100),
+});
+
+type SqlExecutionInput = z.infer;
+
+export interface SqlExecutionStructured {
+ headers: string[];
+ rows: unknown[][];
+ rowCount: number;
+ truncated: boolean;
+ sql: string;
+ wrappedSql: string;
+ error?: string;
+}
+
+function markdownTable(headers: string[], rows: unknown[][], totalRows: number): string {
+ if (headers.length === 0) {
+ return rows.length === 0 ? 'Query returned no rows.' : JSON.stringify(rows.slice(0, 20));
+ }
+ const visible = rows.slice(0, 20);
+ const lines = [
+ `| ${headers.join(' | ')} |`,
+ `| ${headers.map(() => '---').join(' | ')} |`,
+ ...visible.map((row) => `| ${row.map((value) => String(value ?? '')).join(' | ')} |`),
+ ];
+ if (totalRows > visible.length) {
+ lines.push(`... +${totalRows - visible.length} more rows`);
+ }
+ return lines.join('\n');
+}
+
+export class SqlExecutionTool extends BaseTool {
+ readonly name = 'sql_execution';
+
+ constructor(private readonly connections: SlConnectionCatalogPort) {
+ super();
+ }
+
+ get description(): string {
+ return 'Run a single read-only SELECT or WITH probe against an allowed warehouse connection and return a capped markdown table or the warehouse error.';
+ }
+
+ get inputSchema() {
+ return sqlExecutionInputSchema;
+ }
+
+ async call(input: SqlExecutionInput, context: ToolContext): Promise> {
+ const allowed = context.session?.allowedConnectionNames;
+ if (allowed && !allowed.has(input.connectionName)) {
+ return {
+ markdown: `Connection "${input.connectionName}" is not available to this ingest stage.`,
+ structured: { headers: [], rows: [], rowCount: 0, truncated: false, sql: input.sql, wrappedSql: '', error: 'connection_not_allowed' },
+ };
+ }
+
+ let sql: string;
+ let wrappedSql: string;
+ try {
+ sql = assertReadOnlySql(input.sql);
+ wrappedSql = limitSqlForExecution(sql, input.rowLimit);
+ } catch (error) {
+ const message = error instanceof Error ? error.message : String(error);
+ return {
+ markdown: message,
+ structured: { headers: [], rows: [], rowCount: 0, truncated: false, sql: input.sql, wrappedSql: '', error: message },
+ };
+ }
+
+ try {
+ const result = await this.connections.executeQuery(input.connectionName, wrappedSql);
+ const headers = result.headers ?? [];
+ const rows = result.rows ?? [];
+ const rowCount = result.totalRows ?? rows.length;
+ return {
+ markdown: markdownTable(headers, rows, rowCount),
+ structured: { headers, rows, rowCount, truncated: rowCount > rows.length, sql, wrappedSql },
+ };
+ } catch (error) {
+ const message = error instanceof Error ? error.message : String(error);
+ return {
+ markdown: `SQL execution failed: ${message}`,
+ structured: { headers: [], rows: [], rowCount: 0, truncated: false, sql, wrappedSql, error: message },
+ };
+ }
+ }
+}
+```
+
+- [ ] **Step 4: Run the `sql_execution` tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.ts packages/context/src/ingest/tools/warehouse-verification/sql-execution.tool.test.ts
+git commit -m "feat(context): add ingest SQL verification tool"
+```
+
+### Task 5: Add `discover_data`
+
+**Files:**
+- Create: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`
+- Create: `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts`
+- Create: `packages/context/src/ingest/tools/warehouse-verification/index.ts`
+
+- [ ] **Step 1: Write failing `discover_data` tests**
+
+Create tests with fake `wikiSearchTool.call`, `slDiscoverTool.call`, and `WarehouseCatalogService.searchByName`. Cover:
+
+```ts
+it('groups wiki, semantic layer, and raw schema hits with routing hints', async () => {
+ const result = await tool.call({ query: 'orders', connectionName: 'warehouse', limit: 5 }, context);
+ expect(result.markdown).toContain('## Wiki Pages');
+ expect(result.markdown).toContain('use `wiki_read(blockKey)` for full content');
+ expect(result.markdown).toContain('## Semantic Layer Sources');
+ expect(result.markdown).toContain('use `sl_read_source(sourceName)` for the YAML');
+ expect(result.markdown).toContain('## Raw Warehouse Schema');
+ expect(result.markdown).toContain('use `entity_details({connectionName, targets: [{display}]})`');
+ expect(result.structured.raw?.hits).toHaveLength(1);
+});
+
+it('delegates sourceName inspect mode to sl_discover only', async () => {
+ const result = await tool.call({ sourceName: 'orders', connectionName: 'warehouse' }, context);
+ expect(slDiscoverTool.call).toHaveBeenCalledWith({ sourceName: 'orders', connectionId: 'warehouse' }, context);
+ expect(wikiSearchTool.call).not.toHaveBeenCalled();
+ expect(catalog.searchByName).not.toHaveBeenCalled();
+ expect(result.markdown).toContain('source detail');
+});
+
+it('returns the empty-state message when all sections are empty', async () => {
+ const result = await tool.call({ query: 'customer source', connectionName: 'warehouse' }, emptyContext);
+ expect(result.markdown).toContain('No matches for "customer source" across wiki, semantic layer, or raw warehouse schema.');
+});
+```
+
+- [ ] **Step 2: Run the failing tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+```
+
+Expected: FAIL because the tool file does not exist.
+
+- [ ] **Step 3: Implement the tool and index export**
+
+Create `packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts`:
+
+```ts
+import { z } from 'zod';
+import type { BaseTool, ToolContext, ToolOutput } from '../../../tools/index.js';
+import { BaseTool as ToolBase } from '../../../tools/index.js';
+import { WarehouseCatalogService, type RawSchemaHit } from './warehouse-catalog.service.js';
+
+const discoverDataInputSchema = z.object({
+ query: z.string().optional(),
+ connectionName: z.string().regex(/^[a-zA-Z0-9][a-zA-Z0-9_-]*$/).optional(),
+ limit: z.number().int().positive().max(50).optional().default(10),
+ sourceName: z.string().optional(),
+});
+
+type DiscoverDataInput = z.infer;
+
+export interface DiscoverDataStructured {
+ wiki: unknown | null;
+ sl: unknown | null;
+ raw: { hits: RawSchemaHit[] } | null;
+}
+
+interface DiscoverDataDeps {
+ wikiSearchTool: BaseTool;
+ slDiscoverTool: BaseTool;
+ catalogFactory: (context: ToolContext) => WarehouseCatalogService;
+}
+
+export class DiscoverDataTool extends ToolBase {
+ readonly name = 'discover_data';
+
+ constructor(private readonly deps: DiscoverDataDeps) {
+ super();
+ }
+
+ get description(): string {
+ return 'Discover existing wiki pages, semantic layer sources, and raw warehouse schema hits before writing ingest output.';
+ }
+
+ get inputSchema() {
+ return discoverDataInputSchema;
+ }
+
+ async call(input: DiscoverDataInput, context: ToolContext): Promise> {
+ if (input.sourceName) {
+ const sl = await this.deps.slDiscoverTool.call(
+ { sourceName: input.sourceName, connectionId: input.connectionName },
+ context,
+ );
+ return { markdown: sl.markdown, structured: { wiki: null, sl: sl.structured, raw: null } };
+ }
+
+ const query = input.query?.trim() || '';
+ const limit = input.limit ?? 10;
+ const parts: string[] = [];
+ let wiki: unknown | null = null;
+ let sl: unknown | null = null;
+ let raw: DiscoverDataStructured['raw'] = null;
+
+ if (query) {
+ const wikiResult = await this.deps.wikiSearchTool.call({ query, limit }, context);
+ if (wikiResult.structured?.totalFound > 0) {
+ parts.push('## Wiki Pages', '> use `wiki_read(blockKey)` for full content', wikiResult.markdown, '');
+ wiki = wikiResult.structured;
+ }
+ }
+
+ const slResult = await this.deps.slDiscoverTool.call(
+ { query: query || undefined, connectionId: input.connectionName },
+ context,
+ );
+ if (slResult.structured?.totalSources > 0) {
+ parts.push('## Semantic Layer Sources', '> use `sl_read_source(sourceName)` for the YAML, or `entity_details` for warehouse-shape details', slResult.markdown, '');
+ sl = slResult.structured;
+ }
+
+ const catalog = this.deps.catalogFactory(context);
+ const connections = input.connectionName
+ ? [input.connectionName]
+ : [...(context.session?.allowedConnectionNames ?? [])].sort();
+ const rawHits: RawSchemaHit[] = [];
+ for (const connectionName of connections) {
+ rawHits.push(...(await catalog.searchByName(connectionName, query, limit)));
+ }
+ if (rawHits.length > 0) {
+ parts.push('## Raw Warehouse Schema', '> use `entity_details({connectionName, targets: [{display}]})` for full DDL + sample values');
+ parts.push(
+ rawHits
+ .slice(0, limit)
+ .map((hit) => `- ${hit.kind}: ${hit.display} (matched on ${hit.matchedOn})`)
+ .join('\n'),
+ );
+ raw = { hits: rawHits.slice(0, limit) };
+ }
+
+ if (parts.length === 0) {
+ return {
+ markdown: `No matches for "${query}" across wiki, semantic layer, or raw warehouse schema. Try broader terms; this concept may not exist yet.`,
+ structured: { wiki, sl, raw },
+ };
+ }
+
+ return { markdown: parts.join('\n'), structured: { wiki, sl, raw } };
+ }
+}
+```
+
+Create `packages/context/src/ingest/tools/warehouse-verification/index.ts`:
+
+```ts
+import type { BaseTool, ToolContext } from '../../../tools/index.js';
+import type { KtxFileStorePort } from '../../../core/index.js';
+import type { SlConnectionCatalogPort } from '../../../sl/index.js';
+import { DiscoverDataTool } from './discover-data.tool.js';
+import { EntityDetailsTool } from './entity-details.tool.js';
+import { SqlExecutionTool } from './sql-execution.tool.js';
+import { WarehouseCatalogService } from './warehouse-catalog.service.js';
+
+export { DiscoverDataTool } from './discover-data.tool.js';
+export { EntityDetailsTool } from './entity-details.tool.js';
+export { SqlExecutionTool } from './sql-execution.tool.js';
+export { WarehouseCatalogService } from './warehouse-catalog.service.js';
+export type { TableDetail, WarehouseColumnDetail, RawSchemaHit } from './warehouse-catalog.service.js';
+
+export function createWarehouseVerificationTools(deps: {
+ connections: SlConnectionCatalogPort;
+ fallbackFileStore: KtxFileStorePort;
+ wikiSearchTool: BaseTool;
+ slDiscoverTool: BaseTool;
+}): BaseTool[] {
+ const catalogFactory = (context: ToolContext) =>
+ new WarehouseCatalogService({
+ fileStore: context.session?.configService ?? deps.fallbackFileStore,
+ });
+ return [
+ new EntityDetailsTool(catalogFactory),
+ new SqlExecutionTool(deps.connections),
+ new DiscoverDataTool({
+ wikiSearchTool: deps.wikiSearchTool,
+ slDiscoverTool: deps.slDiscoverTool,
+ catalogFactory,
+ }),
+ ];
+}
+```
+
+- [ ] **Step 4: Run the `discover_data` tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/tools/warehouse-verification/discover-data.tool.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 5: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.ts packages/context/src/ingest/tools/warehouse-verification/discover-data.tool.test.ts packages/context/src/ingest/tools/warehouse-verification/index.ts
+git commit -m "feat(context): add raw warehouse discovery tool"
+```
+
+### Task 6: Wire tools into ingest sessions
+
+**Files:**
+- Modify: `packages/context/src/tools/tool-session.ts`
+- Modify: `packages/context/src/ingest/ingest-bundle.runner.ts`
+- Modify: `packages/context/src/ingest/local-bundle-runtime.ts`
+- Modify: `packages/context/src/ingest/ingest-bundle.runner.test.ts`
+
+- [ ] **Step 1: Write failing scoping test**
+
+Add to `packages/context/src/ingest/ingest-bundle.runner.test.ts`:
+
+```ts
+it('threads target warehouse connection names into WorkUnit and reconcile tool sessions', async () => {
+ const deps = makeDeps();
+ const sessions: any[] = [];
+ deps.adapter.listTargetConnectionIds = vi.fn().mockResolvedValue(['warehouse']);
+ deps.toolsetFactory.createIngestWuToolset.mockImplementation((toolSession: any) => {
+ sessions.push(toolSession);
+ return {
+ toAiSdkTools: vi.fn().mockReturnValue({}),
+ getAllTools: vi.fn().mockReturnValue([]),
+ getToolNames: vi.fn().mockReturnValue([]),
+ };
+ });
+ deps.agentRunner.runLoop.mockResolvedValue({ stopReason: 'natural' });
+
+ const runner = buildRunner(deps);
+ (runner as any).stageRawFilesStage1 = vi.fn().mockResolvedValue({
+ currentHashes: new Map([['a.yml', 'h1']]),
+ rawDirInWorktree: 'raw-sources/notion/fake/s',
+ });
+ (runner as any).resolveStagedDir = vi.fn().mockResolvedValue('/tmp/stage/upload-x');
+
+ await runner.run({
+ jobId: 'j1',
+ connectionId: 'notion',
+ sourceKey: 'fake',
+ trigger: 'upload',
+ bundleRef: { kind: 'upload', uploadId: 'upload-x' },
+ });
+
+ expect([...sessions[0].allowedConnectionNames].sort()).toEqual(['notion', 'warehouse']);
+});
+```
+
+- [ ] **Step 2: Run the failing runner test**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/ingest-bundle.runner.test.ts -t "threads target warehouse connection names"
+```
+
+Expected: FAIL because `allowedConnectionNames` is absent.
+
+- [ ] **Step 3: Thread allowed connection names**
+
+Modify `packages/context/src/tools/tool-session.ts`:
+
+```ts
+ allowedRawPaths?: ReadonlySet;
+ allowedConnectionNames?: ReadonlySet;
+ semanticLayerService: SemanticLayerService;
+```
+
+Modify WU session creation in `packages/context/src/ingest/ingest-bundle.runner.ts`:
+
+```ts
+ allowedRawPaths: new Set(wu.rawFiles),
+ allowedConnectionNames: new Set(slConnectionIds),
+ semanticLayerService: scopedSemanticLayerService,
+```
+
+Modify reconcile session creation in the same file:
+
+```ts
+ allowedRawPaths: reconciliationAllowedRawPaths,
+ allowedConnectionNames: new Set(slConnectionIds),
+ semanticLayerService: rcScopedSl,
+```
+
+- [ ] **Step 4: Register the tools in the local ingest toolset**
+
+Modify `packages/context/src/ingest/local-bundle-runtime.ts`:
+
+```ts
+import {
+ createWarehouseVerificationTools,
+} from './tools/warehouse-verification/index.js';
+```
+
+Refactor the existing inline wiki and SL tool instances in `LocalIngestToolsetFactory` so `wikiSearchTool` and `slDiscoverTool` are named constants, then add the warehouse tools:
+
+```ts
+ const wikiSearchTool = new WikiSearchTool({
+ search: async (input) => {
+ const results = await searchLocalKnowledgePages(deps.project, {
+ userId: input.userId,
+ query: input.query,
+ limit: input.limit,
+ embeddingService: deps.embedding,
+ });
+ return {
+ results: results.slice(0, input.limit).map((result) => ({
+ key: result.key,
+ path: result.path,
+ summary: result.summary,
+ score: result.score,
+ matchReasons: result.matchReasons,
+ lanes: result.lanes,
+ })),
+ totalFound: results.length,
+ };
+ },
+ });
+ const slDiscoverTool = new SlDiscoverTool(slDeps, { maxSources: 25, minRrfScore: 0, maxDetailedSources: 5 });
+ const warehouseVerificationTools = createWarehouseVerificationTools({
+ connections: deps.connections,
+ fallbackFileStore: deps.project.fileStore,
+ wikiSearchTool,
+ slDiscoverTool,
+ });
+
+ this.baseTools = [
+ new WikiReadTool(deps.wikiService, deps.knowledgeIndex),
+ wikiSearchTool,
+ new WikiListTagsTool(deps.wikiService, deps.knowledgeIndex),
+ new WikiWriteTool(deps.wikiService, deps.knowledgeIndex, deps.knowledgeEvents),
+ new WikiRemoveTool(deps.wikiService, deps.knowledgeIndex, deps.knowledgeEvents),
+ slDiscoverTool,
+ new SlEditSourceTool(slDeps),
+ new SlReadSourceTool(slDeps),
+ new SlWriteSourceTool(slDeps),
+ new SlValidateTool(slDeps),
+ new SlRollbackTool(deps.slSourcesRepository, deps.connections, 0),
+ ...warehouseVerificationTools,
+ ];
+```
+
+- [ ] **Step 5: Run integration and toolset tests**
+
+Run:
+
+```bash
+pnpm --filter @ktx/context exec vitest run src/ingest/ingest-bundle.runner.test.ts -t "threads target warehouse connection names"
+pnpm --filter @ktx/context exec vitest run src/ingest/local-bundle-runtime.test.ts
+```
+
+Expected: PASS.
+
+- [ ] **Step 6: Commit**
+
+Run:
+
+```bash
+git add packages/context/src/tools/tool-session.ts packages/context/src/ingest/ingest-bundle.runner.ts packages/context/src/ingest/local-bundle-runtime.ts packages/context/src/ingest/ingest-bundle.runner.test.ts
+git commit -m "feat(context): expose warehouse verification tools to ingest"
+```
+
+### Task 7: Update writer prompts and cleanup stale references
+
+**Files:**
+- Create: `packages/context/skills/_shared/identifier-verification.md`
+- Modify: `packages/context/skills/notion_synthesize/SKILL.md`
+- Modify: `packages/context/skills/dbt_ingest/SKILL.md`
+- Modify: `packages/context/skills/lookml_ingest/SKILL.md`
+- Modify: `packages/context/skills/looker_ingest/SKILL.md`
+- Modify: `packages/context/skills/metabase_ingest/SKILL.md`
+- Modify: `packages/context/skills/metricflow_ingest/SKILL.md`
+- Modify: `packages/context/skills/live_database_ingest/SKILL.md`
+- Modify: `packages/context/skills/historic_sql_table_digest/SKILL.md`
+- Modify: `packages/context/skills/historic_sql_patterns/SKILL.md`
+- Modify: `packages/context/skills/knowledge_capture/SKILL.md`
+- Modify: `packages/context/skills/sl_capture/SKILL.md`
+- Modify: `packages/context/skills/sl/SKILL.md`
+- Modify: `packages/context/src/ingest/tools/emit-unmapped-fallback.tool.ts`
+- Modify: `packages/context/src/sl/tools/sl-warehouse-validation.ts`
+
+- [ ] **Step 1: Add the shared protocol file**
+
+Create `packages/context/skills/_shared/identifier-verification.md`:
+
+```md
+## Identifier Verification Protocol
+
+Before writing a wiki page or SL source on any topic:
+
+1. `discover_data({query: ""})` - 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({connectionName, targets: [{display: ""}]})` -
+ 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:
+ `SELECT DISTINCT
FROM LIMIT 50`.
+4. If the candidate identifier still does not resolve, do one of:
+ - Use `sql_execution` with `SELECT 1 FROM LIMIT 0`. If it errors, the
+ identifier is fictional.
+ - Wrap the identifier in `[unverified - from ]` 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 `