Feature Map Maintenance
You are maintaining /feature-map.json — the canonical information architecture for LangWatch. Every platform feature is defined here with its surfaces (how it's accessed) and sync state (how code and platform relate). All implementations (sidebar, docs, skills, MCP tools) derive from this map.
/FEATURE_MAP.md is the human-readable companion — a coverage table derived from the JSON. Keep it in sync when you edit the JSON. Use the underscore form (FEATURE_MAP.md), matching GitHub's convention for uppercase root files like CODE_OF_CONDUCT.md and PULL_REQUEST_TEMPLATE.md. Never create a hyphenated FEATURE-MAP.md variant.
Information Architecture
The hierarchy represents the product's mental model, not the code structure:
observability/ — Tracing, Analytics, User Events, Annotations
evaluations/ — Experiments, Online Evaluation (includes guardrails via code)
agent-simulations/ — Scenarios, Runs
prompt-management/ — Prompts, Prompt Playground
library/ — Agents, Workflows, Evaluators, Datasets
settings/ — Model Providers
Key Design Decisions
- No "integrations" category — SDKs/frameworks enable features, they aren't features themselves. Each feature declares its own SDK surface.
- Library contains reusable components (evaluators, datasets, agents, workflows) — NOT "platform" catch-all.
- Annotations live in Observability (they annotate traces).
- Guardrails = online-evaluation accessed via code (
as_guardrail=True), not a separate concept.
- Evaluators and Datasets are in Library, not Evaluations — they're shared components used by experiments, online evaluation, and simulations.
The Surfaces Model
Each feature has two main access paths:
code — developer writes files in their project (SDK, CLI, skill)
platform — no-code via UI or MCP tools (UI route, MCP tool, platform skill)
Plus cross-cutting:
api — REST/Hono API endpoint namespace (used by both code and platform)
docs — canonical documentation URL
Fields point to namespaces, not individual methods. E.g., "python": "langwatch.experiment" means the whole experiment module, not just init().
The Sync Model
How code and platform relate for each feature:
| sync value |
meaning |
example |
null |
separate or one-mode only |
annotations (platform only) |
"bidirectional" |
code ↔ platform, synced |
prompts (via prompt sync) |
"code-to-platform" |
code generates, platform displays |
tracing, experiments |
"platform-to-code" |
platform configures, code consumes |
— (none currently) |
plannedSync captures known future intent (e.g., scenarios will become "bidirectional").
Where to Find Things in the Codebase
API Endpoints
- Hono routes (current):
platform/app/src/app/api/ — each [[...route]]/app.ts is a Hono app
- traces:
platform/app/src/app/api/traces/[[...route]]/app.ts
- scenarios:
platform/app/src/app/api/scenarios/[[...route]]/app.ts
- prompts:
platform/app/src/app/api/prompts/[[...route]]/app.ts
- evaluators:
platform/app/src/app/api/evaluators/[[...route]]/app.ts
- datasets:
platform/app/src/app/api/dataset/[[...route]]/
- analytics:
platform/app/src/app/api/analytics/
- model-providers:
platform/app/src/app/api/model-providers/[[...route]]/
- Legacy Next.js routes (being migrated):
platform/app/src/pages/api/
- tRPC routers:
platform/app/src/server/api/routers/ registered in platform/app/src/server/api/root.ts
Platform UI
- Route definitions:
platform/app/src/utils/routes.ts — projectRoutes object has every page route
- Sidebar menu:
platform/app/src/components/MainMenu.tsx — sections: Observe, Evaluate, Library
- Feature icons:
platform/app/src/utils/featureIcons.ts
MCP Tools
- All tools:
mcp/typescript/src/index.ts — every server.tool() call
- Tool handlers:
mcp/typescript/src/tools/*.ts
- Currently 21 tools: 2 docs, 1 discovery, 3 observability, 4 prompt, 5 scenario, 4 evaluator, 2 model-provider
CLI Commands
- Entry point:
sdks/typescript/src/cli/index.ts
- Command implementations:
sdks/typescript/src/cli/commands/
- Currently:
login + prompt subcommands (init, create, add, remove, list, sync, pull, push)
SDKs
- Python:
sdks/python/src/langwatch/__init__.py (top-level exports), modules: experiment, evaluation, dataset, evaluators, prompts, dspy
- TypeScript:
sdks/typescript/src/index.ts — LangWatch class with .prompts, .experiments, .evaluations, .evaluators, .datasets, .traces
- Scenario SDK (separate):
@langwatch/scenario (TS) / langwatch-scenario (Python)
Skills (external, for users)
- Location:
skills/*/SKILL.md
- Feature skills: tracing, evaluations, scenarios, prompts (each handles both code and platform approaches)
- Meta skills: level-up (orchestrates all feature skills)
- Cross-cutting: analytics
Documentation
- LangWatch docs: served via
fetch_langwatch_docs MCP tool, index at https://langwatch.ai/docs/llms.txt
- Scenario docs: served via
fetch_scenario_docs MCP tool, index at https://langwatch.ai/scenario/llms.txt
How to Update the Feature Map
When a new API endpoint is added
- Read
feature-map.json
- Find the feature entry by
id
- Update
surfaces.api with the route namespace
- If it's a new feature, create a new entry under the right category
When a new MCP tool is added
- Verify the tool exists in
mcp/typescript/src/index.ts
- Add the tool name to
surfaces.platform.mcp array
When a new skill is created
- Verify the skill exists in
skills/{name}/SKILL.md
- Add to
surfaces.code.skill (for code-path skills) or surfaces.platform.skill (for platform-path skills)
When a new CLI command is added
- Verify it exists in
sdks/typescript/src/cli/commands/
- Add to
surfaces.code.cli array
When SDK surface changes
- Update
surfaces.code.sdk with the namespace
When sync capability changes
- Move value from
plannedSync to sync
- Or set new
plannedSync for future plans
When a completely new feature is added
- Decide which category it belongs to based on the hierarchy rules above
- Create a new entry with all known surfaces
- Set
sync appropriately
- Consider: does it need a skill? A docs page? MCP tool?
Validation
After any change, verify:
- Every
api value corresponds to a route in platform/app/src/app/api/ or platform/app/src/pages/api/
- Every
mcp tool name appears in mcp/typescript/src/index.ts
- Every
skill name has a skills/{name}/SKILL.md
- Every
cli command exists in sdks/typescript/src/cli/
- Every
ui route exists in platform/app/src/utils/routes.ts
- No aspirational entries (use
plannedSync for future intent)
Task
$ARGUMENTS
1---2name: feature-map3description: Maintain the canonical LangWatch feature map (/feature-map.json). Use when adding features, APIs, MCP tools, CLI commands, or skills — to update the central registry and keep surfaces in sync.4---56# Feature Map Maintenance78You are maintaining `/feature-map.json` — the **canonical information architecture** for LangWatch. Every platform feature is defined here with its **surfaces** (how it's accessed) and **sync** state (how code and platform relate). All implementations (sidebar, docs, skills, MCP tools) derive from this map.910`/FEATURE_MAP.md` is the human-readable companion — a coverage table derived from the JSON. Keep it in sync when you edit the JSON. Use the **underscore** form (`FEATURE_MAP.md`), matching GitHub's convention for uppercase root files like `CODE_OF_CONDUCT.md` and `PULL_REQUEST_TEMPLATE.md`. Never create a hyphenated `FEATURE-MAP.md` variant.1112## Information Architecture1314The hierarchy represents the product's mental model, not the code structure:1516```17observability/ — Tracing, Analytics, User Events, Annotations18evaluations/ — Experiments, Online Evaluation (includes guardrails via code)19agent-simulations/ — Scenarios, Runs20prompt-management/ — Prompts, Prompt Playground21library/ — Agents, Workflows, Evaluators, Datasets22settings/ — Model Providers23```2425### Key Design Decisions26271. **No "integrations" category** — SDKs/frameworks enable features, they aren't features themselves. Each feature declares its own SDK surface.282. **Library** contains reusable components (evaluators, datasets, agents, workflows) — NOT "platform" catch-all.293. **Annotations** live in Observability (they annotate traces).304. **Guardrails** = online-evaluation accessed via code (`as_guardrail=True`), not a separate concept.315. **Evaluators** and **Datasets** are in Library, not Evaluations — they're shared components used by experiments, online evaluation, and simulations.3233### The Surfaces Model3435Each feature has two main access paths:3637- **`code`** — developer writes files in their project (SDK, CLI, skill)38- **`platform`** — no-code via UI or MCP tools (UI route, MCP tool, platform skill)3940Plus cross-cutting:41- **`api`** — REST/Hono API endpoint namespace (used by both code and platform)42- **`docs`** — canonical documentation URL4344Fields point to **namespaces**, not individual methods. E.g., `"python": "langwatch.experiment"` means the whole experiment module, not just `init()`.4546### The Sync Model4748How code and platform relate for each feature:4950| sync value | meaning | example |51|---|---|---|52| `null` | separate or one-mode only | annotations (platform only) |53| `"bidirectional"` | code ↔ platform, synced | prompts (via `prompt sync`) |54| `"code-to-platform"` | code generates, platform displays | tracing, experiments |55| `"platform-to-code"` | platform configures, code consumes | — (none currently) |5657`plannedSync` captures known future intent (e.g., scenarios will become `"bidirectional"`).5859## Where to Find Things in the Codebase6061### API Endpoints62- **Hono routes** (current): `platform/app/src/app/api/` — each `[[...route]]/app.ts` is a Hono app63 - traces: `platform/app/src/app/api/traces/[[...route]]/app.ts`64 - scenarios: `platform/app/src/app/api/scenarios/[[...route]]/app.ts`65 - prompts: `platform/app/src/app/api/prompts/[[...route]]/app.ts`66 - evaluators: `platform/app/src/app/api/evaluators/[[...route]]/app.ts`67 - datasets: `platform/app/src/app/api/dataset/[[...route]]/`68 - analytics: `platform/app/src/app/api/analytics/`69 - model-providers: `platform/app/src/app/api/model-providers/[[...route]]/`70- **Legacy Next.js routes** (being migrated): `platform/app/src/pages/api/`71- **tRPC routers**: `platform/app/src/server/api/routers/` registered in `platform/app/src/server/api/root.ts`7273### Platform UI74- **Route definitions**: `platform/app/src/utils/routes.ts` — `projectRoutes` object has every page route75- **Sidebar menu**: `platform/app/src/components/MainMenu.tsx` — sections: Observe, Evaluate, Library76- **Feature icons**: `platform/app/src/utils/featureIcons.ts`7778### MCP Tools79- **All tools**: `mcp/typescript/src/index.ts` — every `server.tool()` call80- **Tool handlers**: `mcp/typescript/src/tools/*.ts`81- Currently 21 tools: 2 docs, 1 discovery, 3 observability, 4 prompt, 5 scenario, 4 evaluator, 2 model-provider8283### CLI Commands84- **Entry point**: `sdks/typescript/src/cli/index.ts`85- **Command implementations**: `sdks/typescript/src/cli/commands/`86- Currently: `login` + `prompt` subcommands (init, create, add, remove, list, sync, pull, push)8788### SDKs89- **Python**: `sdks/python/src/langwatch/__init__.py` (top-level exports), modules: `experiment`, `evaluation`, `dataset`, `evaluators`, `prompts`, `dspy`90- **TypeScript**: `sdks/typescript/src/index.ts` — `LangWatch` class with `.prompts`, `.experiments`, `.evaluations`, `.evaluators`, `.datasets`, `.traces`91- **Scenario SDK** (separate): `@langwatch/scenario` (TS) / `langwatch-scenario` (Python)9293### Skills (external, for users)94- **Location**: `skills/*/SKILL.md`95- **Feature skills**: tracing, evaluations, scenarios, prompts (each handles both code and platform approaches)96- **Meta skills**: level-up (orchestrates all feature skills)97- **Cross-cutting**: analytics9899### Documentation100- **LangWatch docs**: served via `fetch_langwatch_docs` MCP tool, index at `https://langwatch.ai/docs/llms.txt`101- **Scenario docs**: served via `fetch_scenario_docs` MCP tool, index at `https://langwatch.ai/scenario/llms.txt`102103## How to Update the Feature Map104105### When a new API endpoint is added1061. Read `feature-map.json`1072. Find the feature entry by `id`1083. Update `surfaces.api` with the route namespace1094. If it's a new feature, create a new entry under the right category110111### When a new MCP tool is added1121. Verify the tool exists in `mcp/typescript/src/index.ts`1132. Add the tool name to `surfaces.platform.mcp` array114115### When a new skill is created1161. Verify the skill exists in `skills/{name}/SKILL.md`1172. Add to `surfaces.code.skill` (for code-path skills) or `surfaces.platform.skill` (for platform-path skills)118119### When a new CLI command is added1201. Verify it exists in `sdks/typescript/src/cli/commands/`1212. Add to `surfaces.code.cli` array122123### When SDK surface changes1241. Update `surfaces.code.sdk` with the namespace125126### When sync capability changes1271. Move value from `plannedSync` to `sync`1282. Or set new `plannedSync` for future plans129130### When a completely new feature is added1311. Decide which category it belongs to based on the hierarchy rules above1322. Create a new entry with all known surfaces1333. Set `sync` appropriately1344. Consider: does it need a skill? A docs page? MCP tool?135136## Validation137138After any change, verify:139- Every `api` value corresponds to a route in `platform/app/src/app/api/` or `platform/app/src/pages/api/`140- Every `mcp` tool name appears in `mcp/typescript/src/index.ts`141- Every `skill` name has a `skills/{name}/SKILL.md`142- Every `cli` command exists in `sdks/typescript/src/cli/`143- Every `ui` route exists in `platform/app/src/utils/routes.ts`144- No aspirational entries (use `plannedSync` for future intent)145146## Task147148$ARGUMENTS