@skyramp/mcp 0.3.8 → 0.4.0-rc.1

package/build/recommendation/diversity.d.ts

@@ -1,47 +0,0 @@
-import { DraftedScenario } from "../types/RepositoryAnalysis.js";
-import { PriorityTier } from "../types/TestRecommendation.js";
-/**
- * Reorder a rank-ordered list so each attack-surface security_boundary scenario
- * sits immediately before the first ordinary direct-auth boundary — keeping
- * destructive sibling auth tests bundled ahead of their read counterparts.
- */
-export declare function prioritizeAttackSurfaceBundles<T extends {
-    scenario: DraftedScenario;
-}>(items: T[]): T[];
-/** The test-type inference used everywhere GENERATE slots are distributed:
- *  explicit testType, else single-step ⇒ contract, multi-step ⇒ integration
- *  (the same inference used when rendering plan items). */
-export declare function inferScenarioType(s: DraftedScenario): string;
-/** Protected items always take a GENERATE slot before any round-robin:
- *  CRITICAL-priority and attack-surface security_boundary scenarios. */
-export declare function isProtectedCandidate(priority: PriorityTier, scenario: DraftedScenario): boolean;
-/** Bucket items by type, preserving rank order within each bucket and
- *  first-appearance order across buckets (so the highest-ranked type wins
- *  round 1 of any subsequent round-robin). */
-export declare function bucketByType<T>(items: T[], typeOf: (item: T) => string): {
-    order: string[];
-    buckets: Map<string, T[]>;
-};
-/** Round-robin one item per non-empty bucket per round (skipping exhausted
- *  buckets, so their freed slots spill over to the next type) until
- *  `selected` reaches `count` or every bucket is empty. Mutates `selected`
- *  and the buckets. */
-export declare function roundRobinFill<T>(selected: T[], order: string[], buckets: Map<string, T[]>, count: number): void;
-/**
- * Select `count` items from a rank-ordered list, distributing GENERATE slots
- * EVENLY across the test types present, with spillover.
- *
- * Policy (kept identical to the multi-repo prose in testbot-prompts.ts's
- * "Cross-repo test generation" block — change both together):
- *  - Protected items first (see isProtectedCandidate) — they must stay in GENERATE.
- *  - Bucket the rest by inferred test type and round-robin (see bucketByType /
- *    roundRobinFill), preserving rank order within each bucket.
- *
- * Degenerate cases match the previous pure rank-order slice exactly: a single type
- * present, or `count >= items.length`, returns the same items in the same order —
- * so backend-only / single-type runs are unchanged (no regression).
- */
-export declare function roundRobinByType<T extends {
-    scenario: DraftedScenario;
-    priority: PriorityTier;
-}>(rankOrdered: T[], count: number): T[];

package/build/recommendation/diversity.js

@@ -1,101 +0,0 @@
-import { PriorityTier } from "../types/TestRecommendation.js";
-import { isAttackSurfaceSecurityBoundary, isOrdinaryDirectAuthBoundary, } from "../prompts/test-recommendation/recommendationShared.js";
-/**
- * Reorder a rank-ordered list so each attack-surface security_boundary scenario
- * sits immediately before the first ordinary direct-auth boundary — keeping
- * destructive sibling auth tests bundled ahead of their read counterparts.
- */
-export function prioritizeAttackSurfaceBundles(items) {
-    const reordered = [];
-    for (const item of items) {
-        if (isAttackSurfaceSecurityBoundary(item.scenario)) {
-            const firstDirectAuthIndex = reordered.findIndex((candidate) => isOrdinaryDirectAuthBoundary(candidate.scenario));
-            if (firstDirectAuthIndex >= 0) {
-                reordered.splice(firstDirectAuthIndex, 0, item);
-                continue;
-            }
-        }
-        reordered.push(item);
-    }
-    return reordered;
-}
-/** The test-type inference used everywhere GENERATE slots are distributed:
- *  explicit testType, else single-step ⇒ contract, multi-step ⇒ integration
- *  (the same inference used when rendering plan items). */
-export function inferScenarioType(s) {
-    return s.testType ?? (s.steps.length === 1 ? "contract" : "integration");
-}
-/** Protected items always take a GENERATE slot before any round-robin:
- *  CRITICAL-priority and attack-surface security_boundary scenarios. */
-export function isProtectedCandidate(priority, scenario) {
-    return (priority === PriorityTier.CRITICAL ||
-        isAttackSurfaceSecurityBoundary(scenario));
-}
-/** Bucket items by type, preserving rank order within each bucket and
- *  first-appearance order across buckets (so the highest-ranked type wins
- *  round 1 of any subsequent round-robin). */
-export function bucketByType(items, typeOf) {
-    const order = [];
-    const buckets = new Map();
-    for (const item of items) {
-        const t = typeOf(item);
-        if (!buckets.has(t)) {
-            buckets.set(t, []);
-            order.push(t);
-        }
-        buckets.get(t).push(item);
-    }
-    return { order, buckets };
-}
-/** Round-robin one item per non-empty bucket per round (skipping exhausted
- *  buckets, so their freed slots spill over to the next type) until
- *  `selected` reaches `count` or every bucket is empty. Mutates `selected`
- *  and the buckets. */
-export function roundRobinFill(selected, order, buckets, count) {
-    while (selected.length < count &&
-        order.some((t) => (buckets.get(t)?.length ?? 0) > 0)) {
-        for (const t of order) {
-            if (selected.length >= count)
-                break;
-            const bucket = buckets.get(t);
-            if (bucket && bucket.length > 0)
-                selected.push(bucket.shift());
-        }
-    }
-}
-/**
- * Select `count` items from a rank-ordered list, distributing GENERATE slots
- * EVENLY across the test types present, with spillover.
- *
- * Policy (kept identical to the multi-repo prose in testbot-prompts.ts's
- * "Cross-repo test generation" block — change both together):
- *  - Protected items first (see isProtectedCandidate) — they must stay in GENERATE.
- *  - Bucket the rest by inferred test type and round-robin (see bucketByType /
- *    roundRobinFill), preserving rank order within each bucket.
- *
- * Degenerate cases match the previous pure rank-order slice exactly: a single type
- * present, or `count >= items.length`, returns the same items in the same order —
- * so backend-only / single-type runs are unchanged (no regression).
- */
-export function roundRobinByType(rankOrdered, count) {
-    if (count <= 0)
-        return [];
-    // Everything fits → no need to bucket; identical to the old slice.
-    if (count >= rankOrdered.length)
-        return rankOrdered.slice(0, count);
-    // Protected items occupy GENERATE slots first, in rank order.
-    const selected = [];
-    const remaining = [];
-    for (const item of rankOrdered) {
-        if (selected.length < count &&
-            isProtectedCandidate(item.priority, item.scenario)) {
-            selected.push(item);
-        }
-        else {
-            remaining.push(item);
-        }
-    }
-    const { order, buckets } = bucketByType(remaining, (item) => inferScenarioType(item.scenario));
-    roundRobinFill(selected, order, buckets, count);
-    return selected;
-}

package/build/recommendation/planRanker.d.ts

@@ -1,65 +0,0 @@
-import { Candidate, BudgetContext, Demotion, SelectionResult } from "../types/Recommendation.js";
-import { ScenarioCategory } from "../types/TestRecommendation.js";
-/** Options for {@link rankCandidates}. Reserved for phase-2 tuning. */
-export interface RankOptions {
-    /**
-     * Categories that take the top carve-out tier ahead of everything else.
-     * Defaults to the `CATEGORY_PRIORITY === "CRITICAL"` categories (bug_caught and
-     * requirement_conflict — new_endpoint is MEDIUM, not carved out). The two CRITICAL
-     * categories are carved out independently, so a requirement conflict never competes
-     * with a code-review bug for one slot. Exposed so phase 2 can tune the carve-out
-     * WITHOUT reintroducing the agent's priority tag as a ranking input.
-     */
-    carveOutCategories?: ScenarioCategory[];
-    /**
-     * Raw PR diff text. When supplied, a candidate whose scenario references a
-     * method+path that appears on an actual changed diff line (`+`/`-`) floats
-     * ahead of a same-tier candidate that doesn't — e.g. the one endpoint really
-     * removed by a PR outranks other same-category "verify-removed-*" candidates
-     * for endpoints merely adjacent in the same file (SKYR-4026).
-     */
-    diffText?: string;
-}
-/** Context for {@link selectPlan}: the budget context plus the demotion channel
- *  the register-plan tool fills from discriminator verification. */
-export interface SelectPlanContext extends BudgetContext {
-    /** Demoted claims (failed discriminator verification) to surface on the result. */
-    demotions?: Demotion[];
-    /** Threaded into {@link rankCandidates} as `RankOptions.diffText`. */
-    diffText?: string;
-}
-/**
- * Rank test candidates for the register-plan checkpoint. Pure and fully
- * deterministic: the same set of candidates always yields the same order,
- * independent of input order (the final tiebreak is the stable `candidateId`).
- *
- * Ordering (highest first):
- *   1. Carve-out — CRITICAL-category scenarios (bug_caught, requirement_conflict), preserving the
- *      protected-first convention of `roundRobinByType` /
- *      `prioritizeAttackSurfaceBundles`.
- *   2. Verified discriminators — candidates whose declared discriminator survived
- *      `validateDiscriminator` (marked via `verifiedDiscriminator`) float ahead of
- *      unverified peers in the same tier.
- *   3. Diff-hunk proximity — candidates referencing a method+path that appears
- *      on an actual changed diff line float ahead of same-tier candidates that
- *      don't (SKYR-4026). Only applied when `opts.diffText` is supplied.
- *   4. `CATEGORY_PRIORITY` mapped over `scenario.category` (CRITICAL > HIGH >
- *      MEDIUM > LOW).
- *   5. Stable tiebreak on `candidateId` for determinism.
- *
- * IMPORTANT: the agent-supplied `priority` field (`scenario.priority`) is
- * DELIBERATELY IGNORED here. Round-1 experiments found it systematically
- * miscalibrated — the agent labels genuinely discriminating tests "low" and
- * generic happy-path tests "high" — so ranking on it inverts the intended order.
- * Priority in this pipeline is derived from the scenario's category and from the
- * verified discriminator, never from the agent's self-assessment.
- */
-export declare function rankCandidates(candidates: Candidate[], opts?: RankOptions): Candidate[];
-/**
- * Convenience composition: rank the candidates, split GENERATE vs ADDITIONAL via
- * the diversity-balanced budgeter, and surface the caller-supplied demotions on
- * the result. The caller (the register-plan tool) runs `validateDiscriminator`
- * first — setting `verifiedDiscriminator` on the candidates that passed and
- * passing the failed claims through `ctx.demotions`.
- */
-export declare function selectPlan(candidates: Candidate[], ctx: SelectPlanContext, opts?: RankOptions): SelectionResult;

package/build/recommendation/planRanker.js

@@ -1,83 +0,0 @@
-import { CATEGORY_PRIORITY, PriorityTier } from "../types/TestRecommendation.js";
-import { diversityBalancedBudgeter } from "./budgeters/diversityBalancedBudgeter.js";
-import { collectChangedRouteLines, findStepOnChangedRoute } from "../utils/changedRoutes.js";
-const PRIORITY_RANK = {
-    CRITICAL: 0,
-    HIGH: 1,
-    MEDIUM: 2,
-    LOW: 3,
-};
-const DEFAULT_CARVE_OUT_CATEGORIES = Object.keys(CATEGORY_PRIORITY).filter((category) => CATEGORY_PRIORITY[category] === PriorityTier.CRITICAL);
-/**
- * Rank test candidates for the register-plan checkpoint. Pure and fully
- * deterministic: the same set of candidates always yields the same order,
- * independent of input order (the final tiebreak is the stable `candidateId`).
- *
- * Ordering (highest first):
- *   1. Carve-out — CRITICAL-category scenarios (bug_caught, requirement_conflict), preserving the
- *      protected-first convention of `roundRobinByType` /
- *      `prioritizeAttackSurfaceBundles`.
- *   2. Verified discriminators — candidates whose declared discriminator survived
- *      `validateDiscriminator` (marked via `verifiedDiscriminator`) float ahead of
- *      unverified peers in the same tier.
- *   3. Diff-hunk proximity — candidates referencing a method+path that appears
- *      on an actual changed diff line float ahead of same-tier candidates that
- *      don't (SKYR-4026). Only applied when `opts.diffText` is supplied.
- *   4. `CATEGORY_PRIORITY` mapped over `scenario.category` (CRITICAL > HIGH >
- *      MEDIUM > LOW).
- *   5. Stable tiebreak on `candidateId` for determinism.
- *
- * IMPORTANT: the agent-supplied `priority` field (`scenario.priority`) is
- * DELIBERATELY IGNORED here. Round-1 experiments found it systematically
- * miscalibrated — the agent labels genuinely discriminating tests "low" and
- * generic happy-path tests "high" — so ranking on it inverts the intended order.
- * Priority in this pipeline is derived from the scenario's category and from the
- * verified discriminator, never from the agent's self-assessment.
- */
-export function rankCandidates(candidates, opts = {}) {
-    const carveOutSet = new Set(opts.carveOutCategories ?? DEFAULT_CARVE_OUT_CATEGORIES);
-    const changedRoutes = opts.diffText ? collectChangedRouteLines(opts.diffText) : [];
-    const onHunk = new Set(candidates
-        .filter((c) => scenarioOnChangedHunk(c.scenario, changedRoutes))
-        .map((c) => c.candidateId));
-    return [...candidates].sort((a, b) => compareRank(a, b, carveOutSet, onHunk));
-}
-/**
- * Convenience composition: rank the candidates, split GENERATE vs ADDITIONAL via
- * the diversity-balanced budgeter, and surface the caller-supplied demotions on
- * the result. The caller (the register-plan tool) runs `validateDiscriminator`
- * first — setting `verifiedDiscriminator` on the candidates that passed and
- * passing the failed claims through `ctx.demotions`.
- */
-export function selectPlan(candidates, ctx, opts = {}) {
-    const ranked = rankCandidates(candidates, { ...opts, diffText: opts.diffText ?? ctx.diffText });
-    const result = diversityBalancedBudgeter.select(ranked, ctx);
-    return { ...result, demotions: ctx.demotions ?? [] };
-}
-function compareRank(a, b, carveOutSet, onHunk) {
-    const carveA = carveOutSet.has(a.scenario?.category) ? 0 : 1;
-    const carveB = carveOutSet.has(b.scenario?.category) ? 0 : 1;
-    if (carveA !== carveB)
-        return carveA - carveB;
-    const verifiedA = a.verifiedDiscriminator ? 0 : 1;
-    const verifiedB = b.verifiedDiscriminator ? 0 : 1;
-    if (verifiedA !== verifiedB)
-        return verifiedA - verifiedB;
-    const hunkA = onHunk.has(a.candidateId) ? 0 : 1;
-    const hunkB = onHunk.has(b.candidateId) ? 0 : 1;
-    if (hunkA !== hunkB)
-        return hunkA - hunkB;
-    const catRankA = categoryRank(a);
-    const catRankB = categoryRank(b);
-    if (catRankA !== catRankB)
-        return catRankA - catRankB;
-    return (a.candidateId ?? "").localeCompare(b.candidateId ?? "");
-}
-function categoryRank(candidate) {
-    const tier = CATEGORY_PRIORITY[candidate.scenario?.category] ?? PriorityTier.LOW;
-    return PRIORITY_RANK[tier];
-}
-/** Whether any step of `scenario` targets a method+path on the changed hunk. */
-function scenarioOnChangedHunk(scenario, changedRoutes) {
-    return !!findStepOnChangedRoute(scenario.steps, changedRoutes);
-}

package/build/recommendation/testFixtures.d.ts

@@ -1,25 +0,0 @@
-import { ScenarioStep } from "../types/RepositoryAnalysis.js";
-import { Novelty, PriorityTier, ScenarioCategory } from "../types/TestRecommendation.js";
-import { Candidate } from "../types/Recommendation.js";
-/** Build a minimal ScenarioStep. */
-export declare function mkStep(method?: string, path?: string): ScenarioStep;
-interface CandidateOpts {
-    priority?: PriorityTier;
-    testType?: string;
-    steps?: number;
-    category?: ScenarioCategory;
-    description?: string;
-    novelty?: Novelty;
-}
-/**
- * Build a ranked Candidate for budgeter/ranker tests. Steps default to a
- * distinct path per candidate (so coverage keys don't collide) with the final
- * step as a mutation (so resolvePrimaryStep picks a stable primary step).
- *
- * Note the two distinct priority fields: `scenario.priority` is the agent's
- * own drafted label (lowercase — untrusted, ranking never reads it), while
- * `Candidate.priority` is the server-computed PriorityTier the rankers
- * actually order by.
- */
-export declare function mkCandidate(name: string, opts?: CandidateOpts): Candidate;
-export {};

package/build/recommendation/testFixtures.js

@@ -1,45 +0,0 @@
-import { Novelty, PriorityTier, } from "../types/TestRecommendation.js";
-import { CandidateSource, computeCandidateId, } from "../types/Recommendation.js";
-/** Build a minimal ScenarioStep. */
-export function mkStep(method = "GET", path = "/r") {
-    return {
-        order: 0,
-        method,
-        path,
-        description: "",
-        interactionType: "success",
-        expectedStatusCode: 200,
-    };
-}
-/**
- * Build a ranked Candidate for budgeter/ranker tests. Steps default to a
- * distinct path per candidate (so coverage keys don't collide) with the final
- * step as a mutation (so resolvePrimaryStep picks a stable primary step).
- *
- * Note the two distinct priority fields: `scenario.priority` is the agent's
- * own drafted label (lowercase — untrusted, ranking never reads it), while
- * `Candidate.priority` is the server-computed PriorityTier the rankers
- * actually order by.
- */
-export function mkCandidate(name, opts = {}) {
-    const stepCount = opts.steps ?? (opts.testType === "contract" ? 1 : 2);
-    const steps = Array.from({ length: stepCount }, (_, i) => mkStep(i === stepCount - 1 ? "POST" : "GET", `/${name}`));
-    const scenario = {
-        scenarioName: name,
-        description: opts.description ?? name,
-        category: opts.category ?? "workflow",
-        priority: "high",
-        steps,
-        chainingKeys: [],
-        requiresAuth: false,
-        estimatedComplexity: "moderate",
-        ...(opts.testType ? { testType: opts.testType } : {}),
-    };
-    return {
-        scenario,
-        priority: opts.priority ?? PriorityTier.HIGH,
-        novelty: opts.novelty ?? Novelty.EXISTING,
-        source: CandidateSource.AGENT,
-        candidateId: computeCandidateId(scenario),
-    };
-}

package/build/types/FrontendIntegration.d.ts

@@ -1,28 +0,0 @@
-/**
- * Frontend component integration check types — SKYR-3855.
- *
- * Produced by `checkFrontendFileIntegration` (src/utils/frontendIntegration.ts)
- * and surfaced to the agent as `uiContext.frontendFileIntegration` in the
- * `skyramp_analyze_changes` output and state file.
- */
-/** String enum so the JSON wire format (state file, tool output) stays unchanged. */
-export declare enum IntegrationReason {
-    /** Framework route/page/entrypoint file — reachable by convention, grep skipped. */
-    RouteOrEntrypoint = "route-or-entrypoint",
-    /** i18n/locale content file — often loaded via a runtime-templated path rather
-     *  than a static quoted import, so the grep-based check is skipped (SKYR-3977). */
-    I18nLocaleContent = "i18n-locale-content",
-    /** At least one production file imports/references the component's module path. */
-    Imported = "imported",
-    /** No production importer found — the component has no DOM presence in the running app. */
-    NoImporters = "no-importers",
-    /** The check could not run (missing file, scan failure) — reported integrated (fail-open). */
-    ScanError = "scan-error"
-}
-export interface FrontendFileIntegration {
-    file: string;
-    integrated: boolean;
-    /** Production files that import/reference the component, relative to repositoryPath. Capped at 10. */
-    importers: string[];
-    reason: IntegrationReason;
-}

package/build/types/FrontendIntegration.js

@@ -1,22 +0,0 @@
-/**
- * Frontend component integration check types — SKYR-3855.
- *
- * Produced by `checkFrontendFileIntegration` (src/utils/frontendIntegration.ts)
- * and surfaced to the agent as `uiContext.frontendFileIntegration` in the
- * `skyramp_analyze_changes` output and state file.
- */
-/** String enum so the JSON wire format (state file, tool output) stays unchanged. */
-export var IntegrationReason;
-(function (IntegrationReason) {
-    /** Framework route/page/entrypoint file — reachable by convention, grep skipped. */
-    IntegrationReason["RouteOrEntrypoint"] = "route-or-entrypoint";
-    /** i18n/locale content file — often loaded via a runtime-templated path rather
-     *  than a static quoted import, so the grep-based check is skipped (SKYR-3977). */
-    IntegrationReason["I18nLocaleContent"] = "i18n-locale-content";
-    /** At least one production file imports/references the component's module path. */
-    IntegrationReason["Imported"] = "imported";
-    /** No production importer found — the component has no DOM presence in the running app. */
-    IntegrationReason["NoImporters"] = "no-importers";
-    /** The check could not run (missing file, scan failure) — reported integrated (fail-open). */
-    IntegrationReason["ScanError"] = "scan-error";
-})(IntegrationReason || (IntegrationReason = {}));

package/build/types/Recommendation.d.ts

@@ -1,146 +0,0 @@
-import { DraftedScenario, SubjectEndpoint } from "../types/RepositoryAnalysis.js";
-import { Novelty, PriorityTier } from "../types/TestRecommendation.js";
-/**
- * The structural bug-shape a candidate claims to probe. Verified against the
- * candidate's `steps[]` by `validateDiscriminator` (discriminators.ts); a claim
- * that does not survive verification is demoted, never used to reject.
- */
-export declare enum DiscriminatorKind {
-    BOUNDARY_EQUALITY = "boundary_equality",
-    MULTI_RECORD_AGGREGATE = "multi_record_aggregate",
-    STATE_TRANSITION = "state_transition",
-    NEGATIVE_MATCH = "negative_match"
-}
-/** Who drafted a candidate: the LLM loop, or the MCP server's own pre-ranking. */
-export declare enum CandidateSource {
-    AGENT = "agent",
-    SERVER = "server"
-}
-/**
- * A ranked test candidate — the existing scored scenario plus the fields the
- * budgeting stage reads. Matches the shape produced today by the scoring block
- * in test-recommendation-prompt.ts (`{ scenario, priority, novelty }`), extended
- * for the SKYR-3879 Path B register-plan checkpoint with provenance, a stable id
- * and the verified-discriminator marker the ranker reads.
- */
-export interface Candidate {
-    scenario: DraftedScenario;
-    priority: PriorityTier;
-    novelty: Novelty;
-    /** Who drafted this candidate: the LLM loop or the MCP server. */
-    source: CandidateSource;
-    /**
-     * Stable, deterministic id: slugified `scenarioName` + short content hash.
-     * Reproducible across calls (same scenario → same id) so the generation-tool
-     * plan guard can match a generated test back to its approved candidate.
-     */
-    candidateId: string;
-    /**
-     * Set by the caller AFTER `validateDiscriminator` succeeds for a declared
-     * discriminator. Present only when the structural claim was verified against
-     * `steps[]` and the diff anchor; the ranker floats these ahead of unverified
-     * peers. Absent = no verified discriminator (unclaimed or demoted).
-     */
-    verifiedDiscriminator?: DiscriminatorKind;
-}
-/** Environment-derived inputs a Budgeter needs to split GENERATE vs ADDITIONAL. */
-export interface BudgetContext {
-    /** Upper bound on GENERATE items (a strategy parameter, formerly the hard cap). */
-    maxGenerate: number;
-    /** Total recommendations (GENERATE + ADDITIONAL); today's `topN`. */
-    maxTotal: number;
-    isUIOnlyPR: boolean;
-    hasFrontendChanges: boolean;
-    /** Method-aware coverage keys of external tests; matching candidates are dropped. */
-    externalCoverage: Set<string>;
-    /**
-     * Whether the PR's own diff changes any test file. External coverage is
-     * discovered from the working tree, so a test the PR itself adds is
-     * indistinguishable from pre-existing coverage; when this is true the
-     * covered-candidate reserve stays shut rather than forcing duplicates of a
-     * test the author already wrote.
-     */
-    diffChangesTestFiles: boolean;
-}
-/** A demoted claim: which candidate, and the human-readable reason returned to
- *  the agent so it can fix the claim (never a silent drop of the claim itself).
- *  A demotion records that a declared discriminator claim failed to verify.
- *  It does not say whether the candidate is still in the plan. Budgeting
- *  decides that separately. A candidate can be both demoted and dropped. */
-export interface Demotion {
-    candidateId: string;
-    reason: string;
-}
-/** A candidate the selection stage removed, and why. A demotion annotates a
- *  claim. A drop removes a candidate from `generate` and `additional`. The
- *  two are independent. The same candidate can carry both. */
-export interface Dropped {
-    candidateId: string;
-    reason: string;
-}
-/** Result of budgeting: the GENERATE set, the ADDITIONAL set, how many UI
- *  placeholder slots the render layer should add (mixed/UI-only PRs), the
- *  demoted-claim channel (the missing rejection surface for register-plan),
- *  and the dropped-candidate channel (SKYR-4214: every candidate the
- *  selection stage removed outright, with a human-actionable reason). */
-export interface SelectionResult {
-    generate: Candidate[];
-    additional: Candidate[];
-    reservedUISlots: number;
-    demotions: Demotion[];
-    dropped: Dropped[];
-}
-/** A pluggable budgeting algorithm. Deterministic and pure. */
-export interface Budgeter {
-    readonly name: string;
-    select(ranked: Candidate[], ctx: BudgetContext): SelectionResult;
-}
-/**
- * Slug of a scenario name alone (no content hash) — stable across independent
- * drafts of "the same" scenario even when their steps[] differ (e.g. the
- * server's auto-drafted version vs. the agent's own re-drafted version of a
- * scenario with an identical name). Used to dedupe by scenario identity where
- * `computeCandidateId`'s content-sensitive hash would wrongly treat two drafts
- * of the same named scenario as distinct (SKYR-4026).
- */
-export declare function scenarioNameSlug(scenarioName: string | undefined): string;
-/**
- * Merge-dedup identity key for a scenario name — like {@link scenarioNameSlug}
- * but NOT truncated and with no shared fallback for a missing name. The 48-char
- * truncation in `scenarioNameSlug` is fine for `computeCandidateId` (combined
- * with a content hash for uniqueness), but used bare as a Map key it would
- * silently collapse two distinct scenarios sharing a long common prefix, and
- * collapse every candidate with no scenarioName onto the same key. Returns ""
- * for a missing name so the caller can fall back to something already unique
- * (e.g. candidateId) instead of a shared literal.
- */
-export declare function scenarioMergeKey(scenarioName: string | undefined): string;
-/**
- * Deterministic candidate id: a slug of the scenario name plus an 8-char content
- * hash. Pure and reproducible — the same scenario always yields the same id, so
- * a candidate registered in the plan can be matched back when its test is later
- * generated. The hash covers the salient, stable structural fields (name,
- * category, testType, and each step's method/path/interactionType/status) so
- * cosmetic re-serialization does not change the id while a real edit does.
- */
-export declare function computeCandidateId(scenario: DraftedScenario): string;
-/** One approved plan item as persisted in `UnifiedAnalysisState.approvedPlan`.
- *  Deliberately slim (no steps/requestBody/etc.) — `matchKeys` already carries
- *  everything a downstream matcher needs.
- *
- *  `subjectEndpoints` is the one exception. `matchKeys` holds one key per
- *  step and is deliberately broad, so a generated test can be matched back
- *  to its plan item. It does not say which step is the subject. Dedup
- *  judges the subject, not the whole step list, so the plan item must
- *  record it too. See `DraftedScenario.subjectEndpoints` for the
- *  absent-vs-empty contract this field carries over unchanged. */
-export interface ApprovedPlanItem {
-    candidateId: string;
-    scenarioName: string;
-    testType: string;
-    category: string;
-    source: CandidateSource;
-    verifiedDiscriminator?: string;
-    subjectEndpoints?: SubjectEndpoint[];
-    matchKeys: string[];
-}

package/build/types/Recommendation.js

@@ -1,74 +0,0 @@
-import * as crypto from "crypto";
-/**
- * The structural bug-shape a candidate claims to probe. Verified against the
- * candidate's `steps[]` by `validateDiscriminator` (discriminators.ts); a claim
- * that does not survive verification is demoted, never used to reject.
- */
-export var DiscriminatorKind;
-(function (DiscriminatorKind) {
-    DiscriminatorKind["BOUNDARY_EQUALITY"] = "boundary_equality";
-    DiscriminatorKind["MULTI_RECORD_AGGREGATE"] = "multi_record_aggregate";
-    DiscriminatorKind["STATE_TRANSITION"] = "state_transition";
-    DiscriminatorKind["NEGATIVE_MATCH"] = "negative_match";
-})(DiscriminatorKind || (DiscriminatorKind = {}));
-/** Who drafted a candidate: the LLM loop, or the MCP server's own pre-ranking. */
-export var CandidateSource;
-(function (CandidateSource) {
-    CandidateSource["AGENT"] = "agent";
-    CandidateSource["SERVER"] = "server";
-})(CandidateSource || (CandidateSource = {}));
-/**
- * Slug of a scenario name alone (no content hash) — stable across independent
- * drafts of "the same" scenario even when their steps[] differ (e.g. the
- * server's auto-drafted version vs. the agent's own re-drafted version of a
- * scenario with an identical name). Used to dedupe by scenario identity where
- * `computeCandidateId`'s content-sensitive hash would wrongly treat two drafts
- * of the same named scenario as distinct (SKYR-4026).
- */
-export function scenarioNameSlug(scenarioName) {
-    return ((scenarioName ?? "")
-        .toLowerCase()
-        .replace(/[^a-z0-9]+/g, "-")
-        .replace(/^-+|-+$/g, "")
-        .slice(0, 48) || "scenario");
-}
-/**
- * Merge-dedup identity key for a scenario name — like {@link scenarioNameSlug}
- * but NOT truncated and with no shared fallback for a missing name. The 48-char
- * truncation in `scenarioNameSlug` is fine for `computeCandidateId` (combined
- * with a content hash for uniqueness), but used bare as a Map key it would
- * silently collapse two distinct scenarios sharing a long common prefix, and
- * collapse every candidate with no scenarioName onto the same key. Returns ""
- * for a missing name so the caller can fall back to something already unique
- * (e.g. candidateId) instead of a shared literal.
- */
-export function scenarioMergeKey(scenarioName) {
-    return (scenarioName ?? "")
-        .toLowerCase()
-        .replace(/[^a-z0-9]+/g, "-")
-        .replace(/^-+|-+$/g, "");
-}
-/**
- * Deterministic candidate id: a slug of the scenario name plus an 8-char content
- * hash. Pure and reproducible — the same scenario always yields the same id, so
- * a candidate registered in the plan can be matched back when its test is later
- * generated. The hash covers the salient, stable structural fields (name,
- * category, testType, and each step's method/path/interactionType/status) so
- * cosmetic re-serialization does not change the id while a real edit does.
- */
-export function computeCandidateId(scenario) {
-    const slug = scenarioNameSlug(scenario.scenarioName);
-    const canonical = {
-        scenarioName: scenario.scenarioName ?? "",
-        category: scenario.category ?? "",
-        testType: scenario.testType ?? "",
-        steps: (scenario.steps ?? []).map((s) => ({
-            method: s?.method ?? "",
-            path: s?.path ?? "",
-            interactionType: s?.interactionType ?? "",
-            expectedStatusCode: s?.expectedStatusCode ?? 0,
-        })),
-    };
-    const hash = crypto.createHash("sha256").update(JSON.stringify(canonical)).digest("hex").slice(0, 8);
-    return `${slug}-${hash}`;
-}