@browserstack/mcp-server 1.5.0-beta.9 → 1.5.1-beta.1

package/dist/tools/capability-registry/search.js

@@ -1,416 +0,0 @@
-/**
- * Ranking capabilities against a plain-language query.
- *
- * Ported from the Python `discover._score`, including the two properties that were each
- * fixed after a live mis-ranking:
- *
- *  * PENALTIES REORDER, THEY DO NOT EXCLUDE. `matched` is the pre-penalty term score and is
- *    what decides inclusion; `ranked` carries the preferences. Conflating them dropped 40
- *    legitimate matches outright, because a cardinality penalty took an otherwise-valid
- *    score to zero and the caller saw "no such capability".
- *  * CARDINALITY. A "list" query answered by a single-record getter sends the caller to a
- *    capability needing an id it cannot possibly have yet.
- */
-/**
- * Every non-alphanumeric character separates, `_` included.
- *
- * `_` used to be a word character, which made `test_case` a single token while every
- * haystack rendered it as "test case" — so the two could never match. That is the exact
- * string `listEntities` hands back, so a caller following the documented flow searched with
- * a term guaranteed to score zero: "list test_runs" matched 19 capabilities and put an
- * admin settings endpoint first, where "list test runs" matched 103 and put the test-runs
- * listing first.
- */
-const WORD = /[a-z0-9]+/g;
-const STOPWORDS = new Set([
-    "a",
-    "an",
-    "and",
-    "are",
-    "as",
-    "at",
-    "be",
-    "by",
-    "can",
-    "do",
-    "for",
-    "from",
-    "how",
-    "i",
-    "in",
-    "is",
-    "it",
-    "me",
-    "my",
-    "of",
-    "on",
-    "or",
-    "has",
-    "have",
-    "that",
-    "the",
-    "these",
-    "this",
-    "those",
-    "to",
-    "want",
-    "what",
-    "which",
-    "with",
-    "you",
-]);
-// Verbs that reveal what the caller means to DO. A preference, not a filter — an explicit
-// `mode` argument is the filter.
-const READ_VERBS = new Set([
-    "list",
-    "get",
-    "show",
-    "find",
-    "fetch",
-    "read",
-    "count",
-    "search",
-    "view",
-    "which",
-    "how",
-]);
-const WRITE_VERBS = new Set([
-    "create",
-    "add",
-    "update",
-    "edit",
-    "delete",
-    "remove",
-    "move",
-    "copy",
-    "archive",
-    "assign",
-    "restore",
-    "reorder",
-    "bulk",
-    "set",
-    "upload",
-    "import",
-    "clone",
-]);
-// Words that mean "give me many", which is what makes a single-record getter the wrong answer.
-const PLURAL_INTENT = new Set([
-    "list",
-    "all",
-    "every",
-    "many",
-    "count",
-    "search",
-    "find",
-    "which",
-    "each",
-]);
-/**
- * Query/haystack terms. Verbs are deliberately NOT stopwords — they carry the intent.
- *
- * camelCase is split before lowercasing, so `testRunId`, `test_run_id` and `test run id`
- * all tokenize alike.
- */
-export function terms(text) {
-    return [
-        ...(text || "")
-            .replace(/([a-z0-9])([A-Z])/g, "$1 $2")
-            .toLowerCase()
-            .matchAll(WORD),
-    ]
-        .map((match) => match[0])
-        .filter((word) => !STOPWORDS.has(word));
-}
-/**
- * A term plus its naive singular variants.
- *
- * QUERY SIDE ONLY, which is what makes this cheap and safe. Matching is one-directional
- * substring containment, so indexed `attachments` already contains a query of `attachment`;
- * only the reverse — a plural query against singular text — needs help. Stemming the
- * indexed side too would mean rewriting the product's own vocabulary to guess at English,
- * for no additional match.
- */
-export function termForms(term) {
-    const forms = [term];
-    // A stripped form must still be three characters. `has` -> `ha` matched more than half
-    // the surface as a substring and pushed a correct answer out of the top 8 entirely;
-    // short fragments are noise, not variants.
-    const add = (form) => {
-        if (form.length >= 3)
-            forms.push(form);
-    };
-    if (term.endsWith("es"))
-        add(term.slice(0, -2));
-    if (term.endsWith("s") && !term.endsWith("ss"))
-        add(term.slice(0, -1));
-    return forms;
-}
-/** A haystack as one lowercased, space-separated string, ready for containment tests. */
-function haystack(text) {
-    return terms(text).join(" ");
-}
-export function modeHint(query) {
-    const words = new Set(terms(query));
-    const wantsWrite = [...words].some((word) => WRITE_VERBS.has(word));
-    if (wantsWrite)
-        return "write";
-    const wantsRead = [...words].some((word) => READ_VERBS.has(word));
-    return wantsRead ? "read" : "";
-}
-export function wantsCollection(query) {
-    return [...(query || "").toLowerCase().matchAll(WORD)].some((match) => PLURAL_INTENT.has(match[0]));
-}
-/**
- * True when a capability answers with many records rather than one.
- *
- * Pagination is the reliable signal — a paged operation is a listing by construction. The
- * plural terminal path segment is a weaker fallback for unpaged collections. (The Python
- * side used the capability NAME here. tm now publishes one, but its verbs are not
- * consistent — the endpoint that lists folders is `get_root_folders_v1` — so the path's
- * terminal noun remains the better signal.)
- */
-export function isCollection(capability) {
-    if (capability.paginated)
-        return true;
-    const segments = capability.path
-        .split("/")
-        .filter((s) => s && !s.startsWith("{"));
-    const tail = segments[segments.length - 1] || "";
-    return tail.endsWith("s") && !tail.endsWith("ss");
-}
-/** Everything a caller might say that lives on a parameter rather than in the prose. */
-function parameterText(capability) {
-    const parts = [];
-    for (const group of [
-        capability.path_params,
-        capability.query,
-        capability.body,
-    ]) {
-        for (const param of group || []) {
-            parts.push(param.name);
-            if (param.description)
-                parts.push(param.description);
-            if (param.values)
-                parts.push(param.values.map(String).join(" "));
-        }
-    }
-    return parts.join(" ");
-}
-/**
- * Path words are the identity haystack. The published `name` is deliberately NOT scored.
- *
- * That is a measured result, not an oversight. tm now names every capability, and adding
- * the name to the ranking was tried three ways against tests/fixtures/search-eval.json,
- * which the pre-names index serves 18/18:
- *
- *   folded into this field, weight 6          17/18
- *   its own field, weights 1 / 2 / 3 / 4 / 6  17 / 17 / 17 / 17 / 16
- *   only the words the path lacks, 1..6       17 / 16 / 15 / 15 / 14
- *
- * Every variant loses, for two reasons. The nouns in a name are the route restated — the
- * name is snake-cased from the operationId, itself derived from the path — so scoring them
- * again rewards verbose names for repeating themselves: `get_test_cases_for_v1_test_run`
- * displaced `create_test_result_for_test_case` on "record a pass or fail for a test case in
- * a run", putting a read above the write that answers it. And what a name adds beyond the
- * route is mostly its verb, which tm applies inconsistently (`get_root_folders_v1` lists,
- * `list_folder_test_cases_v1` also lists), so the verb is noise as often as signal.
- *
- * The query this was meant to fix, "list all projects", only went 7 -> 4 even where it
- * helped: `projects` is in 156 of 173 paths as a scope prefix, so rarity correctly values it
- * near zero and no amount of name weighting recovers it. That one is fixed instead by the
- * terminal-segment bonus in `score`, which tells "is that thing" from "is scoped by it".
- *
- * Revisit when a product ships a consistent verb convention — then the verb becomes signal.
- */
-/**
- * The terminal path segment — the thing this endpoint is actually ABOUT.
- *
- * A REST path mixes two different things: the resources it is SCOPED BY, and the resource it
- * ADDRESSES. Only the last segment is the latter. See the bonus in `score` for why that
- * distinction matters and why it is applied flat rather than weighted.
- *
- * Trailing placeholders are skipped, so `/test-cases/{id}` is still about test cases.
- * Action tails (`close`, `edit`, `delete`) are kept rather than skipped: for "close a test
- * run" the tail IS the most specific thing the caller said.
- */
-function resourceText(capability) {
-    const segments = capability.path
-        .split("/")
-        .filter((s) => s && !s.startsWith("{") && s !== "api");
-    return (segments[segments.length - 1] || "").replace(/[-_]/g, " ");
-}
-function identityText(capability) {
-    return capability.path
-        .split("/")
-        .filter((segment) => segment && !segment.startsWith("{") && segment !== "api")
-        .join(" ")
-        .replace(/[-_]/g, " ");
-}
-/**
- * How much one term is worth, by how rare it is.
- *
- * Containment made every project-scoped endpoint match the term `project` — ~150 of tm's
- * 173 capabilities — so that word carried as much weight as `access`, which appears in
- * exactly one. Rarity is what separates them: a term matching everything scores near zero,
- * a term matching one capability scores near one.
- *
- * This is the IDF idea alone, not BM25. The term-frequency saturation and length
- * normalisation BM25 adds would rescale every score, and the mode and cardinality
- * adjustments below are absolute constants fitted against live mis-rankings. Bounding the
- * factor to 0..1 keeps those constants meaningful.
- */
-function rarity(documents, forms) {
-    let df = 0;
-    for (const text of documents) {
-        if (forms.some((form) => text.includes(form)))
-            df += 1;
-    }
-    const total = documents.length || 1;
-    return Math.log((total + 1) / (df + 1)) / Math.log(total + 1);
-}
-/**
- * Sized to sit alongside the mode (+6) and cardinality (+8) constants, not to dwarf them.
- * The pinned eval is unchanged at every value from 2 to 14 — the bonus only ever fires on
- * queries it does not cover — so this was chosen on the wider sweep: at 10, "close a test
- * run" starts pulling `close_exploratory_session` into second place on the tail match alone.
- */
-const RESOURCE_BONUS = 6;
-function score(capability, wanted, weights, aliases, hint, plural) {
-    if (wanted.length === 0)
-        return { matched: 1, ranked: 1 };
-    const haystacks = [
-        [identityText(capability), 6],
-        [capability.entity, 4],
-        [(aliases[capability.entity] || []).join(" "), 4],
-        [capability.intent || "", 2],
-        // `returns` is scored BELOW identity, not gated on it. At parity with intent it put a
-        // projects listing at #2 for "list test cases in a project" (its returns carries
-        // `test_cases_count`); gating it on an identity match instead made a field reachable
-        // only through returns unreachable, which is worse.
-        [(capability.returns || []).join(" "), 1],
-        [(capability.guidance || []).join(" "), 1],
-        // Parameter names, their descriptions, and their enum values — 330 descriptions and 34
-        // value lists that the artifact already carries and nothing was reading. The vocabulary
-        // a caller uses is often the value they mean to send: `pass` and `fail` appear nowhere
-        // else in the index, only as the `status` enum on the test-result writes.
-        [parameterText(capability), 1],
-    ];
-    // CONTAINMENT, not set membership. A query of `attachment` has to reach an endpoint whose
-    // path says `attachments`; under exact token equality it did not, and that endpoint fell
-    // out of the results entirely. A term scores its field once however many forms match.
-    let ranked = 0;
-    for (const [text, weight] of haystacks) {
-        const blob = haystack(text);
-        if (!blob)
-            continue;
-        for (let i = 0; i < wanted.length; i += 1) {
-            if (wanted[i].some((form) => blob.includes(form)))
-                ranked += weight * weights[i];
-        }
-    }
-    // PHRASE. Adjacent query terms occurring together say more than the same two words
-    // scattered: "test case" is one noun in this vocabulary, "test" and "case" separately
-    // are two of the commonest words in the index. Scored at half the field's weight and
-    // still scaled by rarity, so it sharpens an existing match rather than creating one.
-    for (const [text, weight] of haystacks) {
-        const blob = haystack(text);
-        if (!blob)
-            continue;
-        for (let i = 0; i + 1 < wanted.length; i += 1) {
-            if (blob.includes(`${wanted[i][0]} ${wanted[i + 1][0]}`)) {
-                ranked += weight * 0.5 * (weights[i] + weights[i + 1]);
-            }
-        }
-    }
-    const matched = ranked;
-    // THE ENDPOINT IS THAT THING, not merely scoped by it.
-    //
-    // A REST path mixes the resources it is SCOPED BY with the one it ADDRESSES. `projects` is
-    // in 156 of tm's 173 paths but is the terminal segment in 3, so whole-corpus rarity —
-    // correctly — values it near nothing, and every project-scoped listing scored the same as
-    // the projects listing itself. The top 8 for "list all projects" spanned 15.9 to 14.8,
-    // where +8 collection and +6 mode already account for 14: the term signal was ~1 point of
-    // noise and the right answer sat 7th.
-    //
-    // Flat, and deliberately NOT rarity-scaled. Rarity would reintroduce the same problem in
-    // reverse — a rare scope noun outranking the real target, which is exactly how a weighted
-    // version of this put `/projects/{id}/folders` above `/folder/{id}/test-cases` for "tc list
-    // for a folder". This asks one yes/no question instead: is the caller's own word the last
-    // thing in the path?
-    //
-    // Equality is against the QUERY's forms, never the haystack's — the same one-directional
-    // rule as containment. `projects` is in forms("projects"), so the projects listing hits;
-    // `folders` is not in forms("folder"), so a folder-scoped query does not drag in the
-    // folders listing.
-    const tail = terms(resourceText(capability));
-    if (tail.length &&
-        wanted.some((forms) => tail.every((word) => forms.includes(word)))) {
-        ranked += RESOURCE_BONUS;
-    }
-    if (hint && capability.mode !== hint)
-        ranked -= 20;
-    else if (hint && capability.mode === hint)
-        ranked += 6;
-    if (plural)
-        ranked += isCollection(capability) ? 8 : -8;
-    return { matched, ranked };
-}
-export function searchCapabilities(products, query, options = {}) {
-    const limit = options.limit && options.limit > 0 ? options.limit : 8;
-    // Forms are computed once per query, not per capability: 173 capabilities x 6 haystacks
-    // would otherwise rebuild the same handful of strings a thousand times.
-    const wanted = terms(query).map(termForms);
-    const hint = options.mode ? "" : modeHint(query);
-    const plural = wantsCollection(query);
-    const scored = [];
-    const searched = Object.entries(products).filter(([name]) => !options.product || name === options.product);
-    const aliasesByProduct = {};
-    for (const [name, bundle] of searched) {
-        const aliases = {};
-        for (const [entity, doc] of Object.entries(bundle.entities)) {
-            aliases[entity] = (doc.aliases || []);
-        }
-        aliasesByProduct[name] = aliases;
-    }
-    // ONE CORPUS ACROSS EVERY SEARCHED PRODUCT, not one per product.
-    //
-    // Measured per product, a term's rarity inverts across them: `load` appears in nearly
-    // every Load Testing capability, so it scored as noise there, while it appears in 16 of
-    // tm's 173 (`upload`, `download`, reached by containment), so it scored as gold there.
-    // The word that identifies a product was worth least inside it, and "list load tests"
-    // returned five tm results and no Load Testing ones at all.
-    //
-    // It is also measured against EVERY capability, not the entity- or mode-filtered subset:
-    // narrowing a search must not make a common word look rare.
-    const corpus = searched.flatMap(([name, bundle]) => bundle.capabilities.map((capability) => [
-        identityText(capability),
-        capability.entity,
-        (aliasesByProduct[name][capability.entity] || []).join(" "),
-        capability.intent || "",
-        (capability.returns || []).join(" "),
-        parameterText(capability),
-    ]
-        .map(haystack)
-        .join(" ")));
-    const weights = wanted.map((forms) => rarity(corpus, forms));
-    for (const [name, bundle] of searched) {
-        const aliases = aliasesByProduct[name];
-        for (const capability of bundle.capabilities) {
-            if (options.entity && capability.entity !== options.entity)
-                continue;
-            if (options.mode && capability.mode !== options.mode)
-                continue;
-            const { matched, ranked } = score(capability, wanted, weights, aliases, hint, plural);
-            if (matched > 0)
-                scored.push({ matched, ranked, product: name, capability });
-        }
-    }
-    scored.sort((a, b) => b.ranked - a.ranked || a.capability.path.localeCompare(b.capability.path));
-    return {
-        hits: scored
-            .slice(0, limit)
-            .map(({ product, capability }) => ({ product, capability })),
-        truncated: scored.length > limit,
-        total_matched: scored.length,
-    };
-}

package/dist/tools/capability-registry/types.d.ts

@@ -1,219 +0,0 @@
-/**
- * The shape of the index artifact, which is the contract with the export pipeline.
- *
- * The artifact is generated by the capability-registry build and transformed into its
- * released envelope by the export pipeline's merge step. It contains ONLY data that has
- * already passed that side's outbound boundary. Nothing here is parsed from an OpenAPI spec
- * at runtime: if this half parsed specs it would become the boundary, and every gate (route
- * lint, vocabulary rule, intent lint, discovery denylist) would have to be reimplemented and
- * re-tested here. Reading a pre-projected index means the internal data is not in the
- * package at all.
- *
- * ONE FILE PER PRODUCT. The released artifact is `capability/<product>.capability-index.json`,
- * with the
- * product object at the top level under its own name. The plural `products` wrapper belonged
- * to the pre-release shape and implied multi-product files that never existed.
- */
-/**
- * The envelope's format marker, for FUTURE shape changes.
- *
- * BOTH the released and the pre-release shapes claim 1, so this number cannot distinguish
- * them — `readIndexFile` shape-detects on the `products` wrapper instead. The check is still
- * worth keeping: it is what refuses a shape the generator has announced but this build does
- * not read.
- */
-export declare const SUPPORTED_SCHEMA_VERSION = 1;
-/** Envelope keys, i.e. everything at the top level that is NOT the product object. */
-export declare const ENVELOPE_KEYS: readonly ["schema_version", "version", "build_id", "harness_commit", "products"];
-export type Mode = "read" | "write" | "destructive";
-/** One parameter, under the name the OpenAPI spec itself gives it. */
-export interface WireParam {
-    name: string;
-    type: string;
-    required?: true;
-    values?: unknown[];
-    example?: unknown;
-    description?: string;
-    /** Field names/types one level inside an array item or nested object. */
-    fields?: {
-        name: string;
-        type: string;
-        required?: true;
-    }[];
-    /**
-     * Where a body field sits in the JSON, when that differs from its name. Published
-     * because the nesting is not guessable and getting it wrong fails silently — tm's folder
-     * create really wants `{folder: {name}}` while the spec's flat `{name}` is what a reader
-     * would assume.
-     */
-    json_path?: string;
-}
-/**
- * A reference into a product-level lookup table.
- *
- * Named components are stored ONCE, already dereferenced and allOf-flattened at build time,
- * so resolution is a single dict lookup rather than a recursive $ref walk at runtime.
- */
-export interface ComponentRef {
-    $response?: string;
-    $schema?: string;
-}
-/** A JSON Schema fragment, or a reference to a named one. */
-export type SchemaNode = ComponentRef & Record<string, unknown>;
-/** One declared response, or a reference to a named one. */
-export interface ResponseDoc extends ComponentRef {
-    description?: string;
-    schema?: SchemaNode;
-}
-/** A capability, keyed by the endpoint it exposes. There is deliberately no name. */
-export interface Capability {
-    /**
-     * The caller-facing handle — the snake-cased `operationId`, unique within its product.
-     *
-     * This is what `invokeCapability` takes, and what `entities[*].capabilities[]` lists. It
-     * is stable where a route is not: `/edit` becoming `/edit-v2` must not break a caller
-     * holding a handle.
-     *
-     * OPTIONAL because not every product publishes it yet — loadtesting's index carries none.
-     * For those, the endpoint remains the handle, so nothing may assume this is present.
-     */
-    name?: string;
-    method: string;
-    path: string;
-    mode: Mode;
-    entity: string;
-    path_params?: WireParam[];
-    query?: WireParam[];
-    body?: WireParam[];
-    intent?: string;
-    /**
-     * How to call the endpoint correctly.
-     *
-     * ABSENT from the released artifact — the export dropped it, and the shape-change note
-     * does not say whether that was intended. Kept optional and still scored by search so the
-     * server works either way; nothing may depend on it being present.
-     */
-    guidance?: string[];
-    /** Allowlisted row fields. Absent when `shape` is "discovered". */
-    returns?: string[];
-    /** "discovered" when the product declares no response schema for this operation. */
-    shape?: "discovered";
-    requires?: string[];
-    paginated?: boolean;
-    /** The largest page the operation declares. */
-    max_page_size?: number;
-    /**
-     * Declared responses by status code, values possibly `{$response: "Name"}` references.
-     *
-     * ADDITIVE and not yet emitted: no capability in the current export carries it. Absence
-     * means "no response schema available", never an error. Resolve with `resolveComponent`.
-     */
-    responses?: Record<string, ResponseDoc>;
-}
-export interface EntityDoc {
-    title?: string;
-    aliases?: string[];
-    id_convention?: string;
-    parents?: string[];
-    relations?: {
-        entity?: string;
-        via?: string;
-    }[];
-    [key: string]: unknown;
-}
-/**
- * Paging controls, keyed "METHOD /path".
- *
- * NOT USED BY THIS SERVER: it performs one request and returns the response, so paging
- * belongs to the caller and the page parameters are published with the endpoint's other
- * query parameters. The field is still emitted by the build, so it stays described here
- * rather than silently ignored — a consumer that DOES page can use it.
- */
-export interface PagingRule {
-    page?: string;
-    size?: string;
-    /** The largest page the operation declares. Absent when the spec states no maximum. */
-    max?: number;
-}
-/**
- * How a product wants the caller's credentials presented.
- *
- * The OpenAPI `securityScheme` vocabulary, verbatim — `type` / `in` / `name` / `scheme` —
- * because the spec already describes this and inventing a parallel taxonomy would mean
- * translating between two of them forever. ONE scheme per product, not OpenAPI's list of
- * alternatives: this server holds a username and an access key and nothing else, so
- * "the first alternative we can satisfy" only ever had one answer.
- *
- * `template` is what makes it a contract rather than a guess — a product taking
- * `{username}_{access_key}` is expressible instead of being a special case in the server.
- * It names placeholders, never values: the credential itself stays in config, and the
- * harness's `{ env: … }` value sources must NOT cross the boundary into the artifact.
- */
-export interface AuthScheme {
-    /** "apiKey" puts the rendered template in a header; "http" with scheme "basic" encodes it. */
-    type: "apiKey" | "http";
-    /** apiKey only. Header is the sole supported location — see `egress.authHeaders`. */
-    in?: "header" | "cookie" | "query";
-    /** apiKey only: the header name, e.g. "Api-Token". */
-    name?: string;
-    /** http only. */
-    scheme?: string;
-    /** Defaults to `{username}:{access_key}`. */
-    template?: string;
-}
-export interface ProductIndex {
-    summary: string;
-    /**
-     * How to authenticate to this product. Absent means the historical default: the caller's
-     * credentials as `Api-Token: {username}:{access_key}`, which is what every shipped index
-     * relies on today.
-     */
-    auth?: AuthScheme;
-    /**
-     * The single host this product is served from, when it has one.
-     *
-     * A default, not the last word: config overrides it, and for a region-sharded product
-     * (one declaring `base_urls`) account discovery outranks it and this is the fallback.
-     */
-    base_url?: string;
-    /**
-     * Candidate regional hosts, in probe order, for a product whose host depends on the
-     * ACCOUNT rather than the deployment.
-     *
-     * Declaring these makes the product region-sharded: the server asks each in turn with the
-     * caller's credentials and keeps the one that answers. A single fixed `base_url` cannot
-     * express this — it would send every account outside the default region to the wrong host,
-     * a failure invisible to anyone testing from inside that region.
-     */
-    base_urls?: string[];
-    /**
-     * The endpoint to probe the candidates with. Derived from the capabilities when absent
-     * (see `discovery.probePath`); declare it when the derived choice would be wrong.
-     */
-    probe_path?: string;
-    capabilities: Capability[];
-    entities: Record<string, EntityDoc>;
-    paging?: Record<string, PagingRule>;
-    /** Named responses, referenced as `{$response: "Name"}`. Additive; not yet emitted. */
-    responses?: Record<string, ResponseDoc>;
-    /** Named schemas, referenced as `{$schema: "Name"}`. Additive; not yet emitted. */
-    schemas?: Record<string, SchemaNode>;
-}
-/** Where one product's data came from. Logging and cache-busting only. */
-export interface Provenance {
-    /** `<commit>_<UTC timestamp>` in the released shape. */
-    build_id: string;
-    /** Dotted content-generation counter, e.g. "1.2". Absent in the pre-release shape. */
-    version?: string;
-}
-/**
- * The merged, in-memory model: every loaded file's product under its own name.
- *
- * This is the server's own structure, not the file format — one file carries one product,
- * and the registry holds all of them so a caller can search across products.
- */
-export interface RegistryIndex {
-    schema_version: number;
-    build_id: string;
-    products: Record<string, ProductIndex>;
-}

package/dist/tools/capability-registry/types.js

@@ -1,33 +0,0 @@
-/**
- * The shape of the index artifact, which is the contract with the export pipeline.
- *
- * The artifact is generated by the capability-registry build and transformed into its
- * released envelope by the export pipeline's merge step. It contains ONLY data that has
- * already passed that side's outbound boundary. Nothing here is parsed from an OpenAPI spec
- * at runtime: if this half parsed specs it would become the boundary, and every gate (route
- * lint, vocabulary rule, intent lint, discovery denylist) would have to be reimplemented and
- * re-tested here. Reading a pre-projected index means the internal data is not in the
- * package at all.
- *
- * ONE FILE PER PRODUCT. The released artifact is `capability/<product>.capability-index.json`,
- * with the
- * product object at the top level under its own name. The plural `products` wrapper belonged
- * to the pre-release shape and implied multi-product files that never existed.
- */
-/**
- * The envelope's format marker, for FUTURE shape changes.
- *
- * BOTH the released and the pre-release shapes claim 1, so this number cannot distinguish
- * them — `readIndexFile` shape-detects on the `products` wrapper instead. The check is still
- * worth keeping: it is what refuses a shape the generator has announced but this build does
- * not read.
- */
-export const SUPPORTED_SCHEMA_VERSION = 1;
-/** Envelope keys, i.e. everything at the top level that is NOT the product object. */
-export const ENVELOPE_KEYS = [
-    "schema_version",
-    "version",
-    "build_id",
-    "harness_commit",
-    "products",
-];