chore: Add .sdk_metadata.json for sdk-meta catalog

[jsonbailey]

Why

The sdk-meta repo builds LaunchDarkly's SDK catalog by crawling every repo with the launchdarkly-sdk topic and reading its .sdk_metadata.json. This repo has never had one, so none of its packages appear in names.json, types.json, features.json, or repos.json.

That matters now: #43 landed the $ld:ai:sdk:info event, so every package reports its own name and version. Without catalog entries those reported names cannot be resolved to an SDK, and adoption shows as raw package strings.

Opening as a draft — the type question below is worth settling first.

What

One new file, no source changes. Eight entries, one per reporting package, because these publish and version independently and the point of the per-package event is measuring them separately.

packages/ai-otel is excluded — it contains no code, does not depend on @launchdarkly/ai-server, and so cannot self-report. An entry would never resolve.

Feature assignment

Not copied between entries — each was derived from what the package actually implements.

entries	features	why
core (js-ai-server, js-ai-node)	all five	the core surface: config for both modes, graph, judges, tracking
*-messages (×3)	aiCompletionConfig	each registers a single ("<provider>", "messages") handler
*-agents (×3)	aiAgentConfig, aiAgentGraph, aiTrackMetrics	each registers ("<provider>", "agent"), ships its own graph wrapper and native-graph converter, and emits its own $ld:ai:* metrics

Dispatch is by (provider, mode) tuple and there are only two modes, so a messages-mode package cannot serve an agent config at all. Confirmed by negative evidence too: the three *-messages packages contain zero references to graph or .track( anywhere in their sources.

aiAgentGraph on the agents packages is a real per-package implementation in each case, not a repeated claim — each ships its own graph entry point and its own converter into that provider's native agent tree.

Everything is 0.1.x, so all introduced values are "0.1", verified against tags rather than defaulted.

Notes

Two types are used. The two core packages (js-ai-server, js-ai-node) are typed ai — they are the AI SDK itself. The six provider integrations are typed ai-provider, a new value added in launchdarkly/sdk-meta#614.

That PR must merge first. sdk_types.type is a foreign key into sdk_type_info, so if this merges before the vocabulary exists the next crawl fails with FOREIGN KEY constraint failed.

Ids are prefixed (js-ai-openai-agents) because the sibling python-ai-sdk repo has packages with identical directory names. Catalog ids are a primary key, so unprefixed ids would collide and break the crawl.

aiSdkNames carries the value each package reports as aiSdkName. Single-element arrays throughout — git history confirms no package has ever reported a different name.

No userAgents or wrapperNames. These wrap a caller-supplied client, open no connections of their own, and set no wrapper name. Reporting via a custom event instead is exactly why the aiSdkNames field exists.

No release or EOL data yet. sdk-meta drops all 0.x versions from release data, so these appear in the catalog with names, types, and features but no version history until 1.0.

Effect

The packages appear in the catalog on the next crawl, and reported (aiSdkName, aiSdkLanguage) pairs resolve to them.

---

Note

Overview
Adds .sdk_metadata.json so this repo is included in LaunchDarkly’s sdk-meta crawl and $ld:ai:sdk:info aiSdkName values can resolve to catalog SDKs instead of raw package strings.

The file defines eight independently versioned entries (core @launchdarkly/ai-server / ai-node as type ai, plus six provider packages as ai-provider), each with path, languages, release tag-prefix, aiSdkNames, and feature flags scoped to what that package actually implements (full five features on core; aiCompletionConfig on *-messages; agent config/graph/metrics on *-agents). packages/ai-otel is intentionally omitted.

Merge ordering: catalog ingestion expects the ai-provider SDK type to exist in sdk-meta first; otherwise crawls can fail on foreign-key validation.

^{Reviewed by Cursor Bugbot for commit 50c45b1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mattrmc1]

Small aside, since this is a submodule of https://github.com/launchdarkly/ai-sdks-monorepo does there need to be a separate PR for the parent to point to the new version or is that automated?

cc @andrewklatzke

[jsonbailey]

Small aside, since this is a submodule of https://github.com/launchdarkly/ai-sdks-monorepo does there need to be a separate PR for the parent to point to the new version or is that automated?

cc @andrewklatzke

As far as I can tell, the mono repo is a manual bump to bring in the latest changes made by this repo.