@skyramp/mcp 0.3.8 → 0.4.0-rc.1

package/build/prompts/test-recommendation/scopeAssessment.js

@@ -1,359 +0,0 @@
-import * as fs from "fs";
-import * as path from "path";
-import { MAX_RECOMMENDATIONS, MAX_TESTS_TO_GENERATE } from "./recommendationSections.js";
-// .vue and .svelte cannot be route handlers in any framework — always frontend.
-// Stylesheets cannot be either (SKYR-4292): `packages/excalidraw/css/styles.scss`
-// classified as backend because `css/` is not in FRONTEND_DIR_PATTERN, so a
-// stylesheet-only PR took the zero-classified backend branch and never saw the
-// changed-behavior rule.
-const ALWAYS_FRONTEND_EXT = /\.(vue|svelte|css|scss|less)$/i;
-// .dart is always frontend in Flutter projects (no server-side Dart web framework
-// in scope). Gated on hasFlutterPubspec so non-Flutter Dart files (rare, but
-// possible — e.g. Dart-on-server backends) don't accidentally classify as UI.
-const FLUTTER_DART_EXT = /\.dart$/i;
-// .tsx/.jsx are usually UI components but can be Next.js API handlers (pages/api/*.tsx).
-const LIKELY_FRONTEND_EXT = /\.(tsx|jsx)$/i;
-// Ambiguous extensions need directory context to distinguish frontend from backend.
-const AMBIGUOUS_FRONTEND_PATTERN = /\.(tsx?|jsx?|html?|erb|jsp|asp|jinja2?|twig)$/i;
-// /api/ always signals backend — even .tsx files (e.g. Next.js pages/api/*.tsx handlers).
-const STRICT_API_DIR_PATTERN = /\/(api)\//i;
-// Framework route dirs that contain React page components in modern full-stack apps
-// (Medusa Admin, Remix, React Router v6). These only block non-.tsx/.jsx files —
-// a .tsx file in routes/ is a page component, not a route handler.
-const FRAMEWORK_ROUTE_DIR_PATTERN = /\/(routes?|controllers?|routers?|handlers?|endpoints?|server)\//i;
-const FRONTEND_DIR_PATTERN = /(^|\/)(components?|pages?|views?|layouts?|app|src\/app|frontend|client|public|styles?|templates?)\//i;
-// A .json (or .yaml/.yml) file nested under an i18n/locale directory holds only
-// user-facing copy — frontend regardless of nesting depth (subject to the
-// /api/ check above), unlike generic JSON (package.json, tsconfig.json, data
-// fixtures) which needs no such carve-out since it's never under one of these
-// directory names.
-const I18N_LOCALE_FILE_PATTERN = /(^|\/)(i18n|locales?|lang|translations?)\/.*\.(json|ya?ml)$/i;
-/**
- * Returns true if the file path looks like i18n/locale content (a JSON/YAML
- * file under an i18n/, locale(s)/, lang/, or translation(s)/ directory).
- * Exported so callers outside the frontend/backend classification itself
- * (e.g. the production-importer integration check, which greps for static
- * quoted imports) can special-case these files: real i18n loaders commonly
- * fetch locale content by a templated runtime path rather than a static
- * import, so the grep-based check would otherwise misreport them as
- * unintegrated dead code (SKYR-3977).
- */
-export function isI18nLocaleFile(filePath) {
-    return I18N_LOCALE_FILE_PATTERN.test(filePath);
-}
-/**
- * Returns true if the repository root's `pubspec.yaml` declares a Flutter
- * SDK dependency (i.e., a `flutter:` key with `sdk: flutter` under
- * `dependencies:`). This is the load-bearing signal that the project
- * is a Flutter UI app or package, NOT a pure Dart server / CLI / library
- * (those have a `pubspec.yaml` too but no `sdk: flutter` dep).
- *
- * Used as the gate for treating `.dart` files as frontend in
- * `isFrontendFile`. Pure-Dart-backend repos correctly fall through to
- * the existing classifier behaviour (no `.dart` recognition).
- *
- * Synchronous + best-effort: returns false on any read/parse error.
- * Cheap because pubspec.yaml is small and we only call this once per
- * tool invocation (computed at the budget-driving boundary, then passed
- * through as an option).
- */
-/**
- * Common subdir locations for `pubspec.yaml` in real Flutter repos:
- *   - root (single-app — birdle, customer SPA)
- *   - app/, mobile/, frontend/, web/ (mixed-stack repos)
- *   - apps/<name>/, packages/<name>/ (monorepos — depth-2 walked)
- *
- * We stop at the first pubspec we find that declares `sdk: flutter`. Pure-Dart
- * subprojects (e.g. a CLI tool in `tools/`) are correctly skipped because their
- * pubspec doesn't have the Flutter SDK line.
- *
- * Less-common shapes that are NOT auto-discovered: `services/mobile/`,
- * `clients/<name>/`, etc. If a customer's repo uses one of those, add the
- * parent dir here or tell them to symlink `pubspec.yaml` at the root.
- */
-const PUBSPEC_SEARCH_DIRS = [
-    ".",
-    "app",
-    "mobile",
-    "frontend",
-    "web",
-    "client",
-];
-const PUBSPEC_MONOREPO_PARENTS = ["apps", "packages"];
-export function hasFlutterSdkDep(repositoryPath) {
-    for (const subdir of PUBSPEC_SEARCH_DIRS) {
-        if (checkPubspec(path.join(repositoryPath, subdir, "pubspec.yaml"))) {
-            return true;
-        }
-    }
-    // Monorepo shape: apps/<name>/pubspec.yaml, packages/<name>/pubspec.yaml.
-    // One level of fan-out — enough for typical Flutter monorepos, cheap to walk.
-    for (const parent of PUBSPEC_MONOREPO_PARENTS) {
-        const parentPath = path.join(repositoryPath, parent);
-        let entries;
-        try {
-            entries = fs.readdirSync(parentPath, { withFileTypes: true });
-        }
-        catch {
-            continue;
-        }
-        for (const entry of entries) {
-            if (!entry.isDirectory())
-                continue;
-            if (checkPubspec(path.join(parentPath, entry.name, "pubspec.yaml"))) {
-                return true;
-            }
-        }
-    }
-    return false;
-}
-function checkPubspec(pubspecPath) {
-    try {
-        if (!fs.existsSync(pubspecPath))
-            return false;
-        const content = fs.readFileSync(pubspecPath, "utf8");
-        // Detect the `flutter:` SDK dep — proper YAML parsing would be overkill.
-        // The canonical pattern is:
-        //   dependencies:
-        //     flutter:
-        //       sdk: flutter
-        // The `sdk: flutter` line under a `flutter:` key is unique to Flutter
-        // projects; pure-Dart projects use `sdk: dart` or no sdk: line at all.
-        return /^\s+sdk:\s*flutter\s*$/m.test(content);
-    }
-    catch {
-        return false;
-    }
-}
-/**
- * Returns true if the file path is a frontend file.
- *
- * Five tiers:
- * 1. .vue / .svelte — always frontend; these file types cannot be route handlers.
- * 2. .dart — always frontend IFF `hasFlutterSdkDep` is true (Flutter project).
- *    Sits above `STRICT_API_DIR_PATTERN` because there's no server-side Dart
- *    web framework in scope when the Flutter SDK dep is present.
- * 3. i18n/locale JSON/YAML (e.g. locales/en/common.json) — frontend UNLESS in
- *    an API/backend directory (e.g. an i18n content API under api/), since
- *    unlike tiers 1-2 a locale file CAN be served by a backend route (SKYR-3977).
- * 4. .tsx / .jsx — frontend unless in an API/backend directory (e.g. pages/api/).
- * 5. Ambiguous extensions (.ts, .js, .css, .html, …) — require a recognised
- *    frontend directory AND must not be in an API/backend directory.
- *
- * The `hasFlutterSdkDep` opt is passed in by the budget-driving caller
- * (analyzeChangesTool) which has repository context.
- * Pure-path callers (test-recommendation-prompt, analysisOutputPrompt,
- * scopeAssessment's own buildScopeAssessmentSection) default to false —
- * they don't drive the budget.
- */
-export function isFrontendFile(filePath, { hasFlutterSdkDep = false } = {}) {
-    if (ALWAYS_FRONTEND_EXT.test(filePath))
-        return true;
-    if (hasFlutterSdkDep && FLUTTER_DART_EXT.test(filePath))
-        return true;
-    // /api/ always means backend regardless of extension (Next.js API routes use .tsx).
-    // Must run before I18N_LOCALE_FILE_PATTERN — unlike .vue/.svelte/.dart, a locale
-    // JSON/YAML file CAN be served by a backend route (e.g. an i18n content API), so
-    // it doesn't get the same always-frontend exemption as those extensions.
-    if (STRICT_API_DIR_PATTERN.test(filePath))
-        return false;
-    if (isI18nLocaleFile(filePath))
-        return true;
-    // routes/, controllers/ etc. block .ts/.js but not .tsx/.jsx — Medusa Admin and
-    // React Router place page components under routes/, not API handlers.
-    if (!LIKELY_FRONTEND_EXT.test(filePath) && FRAMEWORK_ROUTE_DIR_PATTERN.test(filePath))
-        return false;
-    if (LIKELY_FRONTEND_EXT.test(filePath))
-        return true;
-    return AMBIGUOUS_FRONTEND_PATTERN.test(filePath) && FRONTEND_DIR_PATTERN.test(filePath);
-}
-/**
- * Returns true if the file path looks like a test file rather than UI source.
- *
- * Catches:
- *   - Skyramp-generated tests (`*_test.ts`, `*_smoke.ts`, `*_contract.ts`,
- *     `*_fuzz.ts`, `*_integration.ts`, `*_load.ts`, `*_e2e.ts`, `*_ui.ts`)
- *   - Skyramp scenario files (`scenario_*.json`)
- *   - Conventional Vitest/Jest/Playwright spec naming
- *     (`*.spec.{ts,tsx,js,jsx}`, `*.test.{ts,tsx,js,jsx}`)
- *   - Files inside `__tests__/` directories (Jest convention)
- *
- * Used by callers that want to filter test files OUT of frontend-source
- * processing — `isFrontendFile` returns true for `.spec.ts` under a
- * frontend directory because the rule is "tier-3 ambiguous + frontend dir,"
- * but those tests aren't UI source we'd want to ground recommendations in.
- */
-export function isTestFile(filePath) {
-    return (/(?:_test|_smoke|_contract|_fuzz|_integration|_load|_e2e|_ui)\.[^/]+$/.test(filePath) ||
-        /scenario_[^/]+\.json$/.test(filePath) ||
-        // Include the `.e2e.` dot form so Playwright/Cypress specs discovery treats as UI tests
-        // (UI_TEST_EXT matches `.(test|spec|e2e).`) are recognized here too — e.g. `login.e2e.ts`.
-        /\.(spec|test|e2e)\.(tsx?|jsx?)$/.test(filePath) ||
-        /(?:^|\/)__tests__\//.test(filePath));
-}
-// ── LLM scope assessment ──────────────────────────────────────────────────────
-/**
- * The changed-behavior budget rule, shared by every branch that can see a frontend
- * diff (SKYR-4292).
- *
- * This replaces the zero-new-surface abstention override (SKYR-4099). That override
- * named three abstain categories — cosmetic, deletion-only, and modification of an
- * already-covered surface — and its only sanctioned action was a Budget Plan of 0. On
- * a 20-change UI-only diff under a 20 budget (Wipro PR #24) the agent generalized it
- * into a graded cut to 3, classified option additions no test asserted (Siebel,
- * Windows, .NET, GO, MQ) as "modification of an already-covered surface" because the
- * existing specs reached the wizard page, and shipped zero recommendations for the
- * rest. The taxonomy is gone: every observable behavior the diff changes gets a
- * candidate, coverage means an existing test ASSERTS the changed value (not that it
- * reaches the component), and the total tracks the count of changed behaviors — the
- * ranker in `skyramp_register_test_plan` trims to the ceiling and reports the drops.
- *
- * Backend-only diffs do not render this: their GENERATE list is server pre-ranked
- * from classified endpoints (and SKYR-3820 handles a zero-classified diff), whereas a
- * frontend GENERATE list is placeholders the agent must fill from the diff itself.
- */
-function changedBehaviorSection(effectiveGenerate, budgetPlanTiming = "") {
-    return `**Fill the budget from changed behavior:** The ceiling above is the most this run may plan, not a quota to reach or a default to cut. Enumerate every observable behavior this diff changes — each option value added, removed, renamed or reordered; each label, element, route, state, validation rule or computed value that renders or behaves differently — and give each one its own candidate. Treat no change as too trivial to test: a changed option value that no test asserts is a test. A changed style value counts too — a spacing, size, color, radius, font weight, icon size or class name that now renders differently is a changed behavior; its candidate asserts the new computed style or class on that element, or records a \`browser_visual_snapshot\` of it. A removed option, element or feature is a changed behavior too: its candidate asserts the removed thing is absent from the page where it used to render — the removal is what this PR ships, so the removal is what gets tested.
-
-A changed behavior is something a user can observe differently after this diff. Code the diff deletes, dedupes or simplifies without changing what renders is not a changed behavior — its coverage is maintenance of the tests that reach it — and a pre-existing defect you notice nearby is an \`issuesFound\` entry, not a slot in this budget. Only a comment, whitespace or equivalent-value edit (\`0px\` → \`0\`) changes nothing observable.
-
-A changed behavior is covered only when an existing test asserts the changed value (including after a maintenance UPDATE you recorded). A test that merely reaches the component does not cover it — that change still needs its own candidate.
-
-- Fewer changed behaviors than the ceiling → your Budget Plan total is that count, split as generate first (up to ${effectiveGenerate}) and the remainder additional. Do not pad with tests of behavior this diff did not change.
-- More changed behaviors than the ceiling → keep every one in the candidate list you register; \`skyramp_register_test_plan\` trims to the ceiling and reports what it dropped.
-
-**A requirement the diff did NOT implement counts too.** The enumeration above is of behaviors the diff changed; a \`requirement_conflict\` is the opposite — the PR title/description (or a requirements file it references) states a requirement and the diff failed to implement it. Give it its own candidate anyway, category \`requirement_conflict\`, asserting what the description requires so that it fails on the current code. When the description says a feature was removed and it still renders, the absence assertion IS that test — it fails today, which is the finding. It counts toward your total like any changed behavior, and it is the one candidate a total of zero must never swallow: abstaining past a stated requirement reports the code back to the author as if it were the requirement.
-
-Never reduce the total below the number of changed behaviors you found. State your Budget Plan in the canonical format${budgetPlanTiming} — \`Budget Plan: <total> total (<generate> generate + <additional> additional), <ui_pct>% UI/E2E\` — and use those numbers throughout the rest of the prompt.`;
-}
-/**
- * Builds the PR scope assessment section.
- *
- * When `precomputedUIPct` is provided (0 = backend-only, 100 = UI-only) the server has
- * already determined the split unambiguously, so Steps A–C are skipped. Backend-only
- * (0) renders a single Budget Plan line; UI-only (100) renders that line plus the
- * changed-behavior budget rule (SKYR-4292), because a frontend GENERATE list is
- * placeholders the agent fills from the diff and the total must track what changed.
- *
- * For mixed PRs (`precomputedUIPct` is undefined, `hasFrontendChanges` is true) skip
- * Steps A–C but keep Step D so the LLM can apply judgment to determine the UI%.
- *
- * Falls back to the full four-step assessment when no precomputed data is available.
- */
-export function buildScopeAssessmentSection(maxTotal = MAX_RECOMMENDATIONS, maxGenerate = MAX_TESTS_TO_GENERATE, isUIOnly = false, 
-/** Server-determined UI/E2E percentage. `undefined` = mixed PR or unknown. */
-precomputedUIPct, 
-/** Whether the diff contains frontend files (true ↔ mixed PR when precomputedUIPct is undefined). */
-hasFrontendChanges, 
-/**
- * PR-mode: whether the diff classified at least one new/modified/removed endpoint.
- * When false on the backend branch (precomputedUIPct === 0), the Budget Plan
- * defaults to 0 total with a conditional ceiling instead of a fixed mandate —
- * SKYR-3820: a config-only PR must not be pushed to fill the budget with
- * baseline tests for unchanged endpoints. Defaults to true so existing callers
- * keep the unconditional fixed-budget rendering.
- */
-hasClassifiedApiChanges = true) {
-    const effectiveGenerate = Math.min(maxGenerate, maxTotal);
-    const additional = Math.max(0, maxTotal - effectiveGenerate);
-    // Backend-only diff with zero classified endpoint changes (SKYR-3820): the
-    // budget defaults to 0 so the tool output agrees with the testbot prompt's
-    // zero-test report path, instead of mandating a fixed total the diff cannot
-    // justify. The ceiling stays claimable because a zero-classified diff can be
-    // a classification miss on a real behavior change (e.g. a DTO/serializer
-    // change the endpoint scanner cannot attribute — SKYR-3855's immich case).
-    if (precomputedUIPct === 0 && !hasClassifiedApiChanges) {
-        return `### PR Scope Assessment
-Budget Plan: 0 total — no new, modified, or removed endpoints were classified from this diff, and no frontend files changed.
-
-With a 0-total Budget Plan: generate zero tests, recommend zero tests, and follow the zero-test report path. Do NOT draft baseline or generic tests for unchanged endpoints to fill a budget — an empty diff surface is a valid, expected outcome.
-
-**Exception — claim the ceiling only with evidence:** if your code review of the changed files shows an observable API behavior change the classifier missed (e.g. a DTO/serializer/service change that alters a response shape, a shared library/default-value or business-rule constant change that alters the behavior of an existing, unchanged endpoint (e.g. a default schedule, threshold, or config constant imported by a route handler elsewhere in the codebase), a deployment/config change that newly exposes or removes endpoints, or a schema-defined API contract change — a CRD type/kubebuilder validation marker, GraphQL schema, or gRPC proto edit that adds, removes, or re-validates what the server accepts or returns), raise your Budget Plan to cover exactly those affected endpoints, up to ${maxTotal} total (${effectiveGenerate} generate + ${additional} additional), 0% UI/E2E. Note: repositories whose entire API surface is schema-defined (e.g. a Kubernetes operator serving CRDs through the kube-apiserver) ALWAYS classify zero endpoints — for these, a schema change in the diff IS the endpoint change; evaluate this exception against the schema files instead of concluding there is nothing to test. Similarly, a changed file with zero classified endpoints is not by itself evidence of "no testable surface" — trace what imports the changed export (grep for its name) to check whether it feeds an existing endpoint's behavior before concluding the diff has no test value. **A requirement conflict is also grounds to raise the plan:** if the PR title/description (or a requirements file it references) states a requirement the diff did not implement, claim at least one slot for a \`requirement_conflict\` test asserting that requirement — it fails on the current code, which is the finding. Every test must name the changed file that justifies it. State your raised plan now in the canonical format — \`Budget Plan: <total> total (<generate> generate + <additional> additional), 0% UI/E2E\` — and use those exact numbers throughout the rest of the prompt; the raised generate count is your committed generate count.`;
-    }
-    // Unambiguous backend-only or UI-only: no LLM counting needed. Backend-only emits just
-    // the Budget Plan line; UI-only appends the changed-behavior budget rule (see above).
-    if (precomputedUIPct !== undefined) {
-        const uiSuffix = precomputedUIPct > 0 ? `, ${precomputedUIPct}% UI/E2E` : "";
-        // Backend-only (precomputedUIPct === 0): the server pre-ranked the GENERATE list
-        // from classified endpoints, so the numbers are fixed. UI-only: the list is
-        // placeholders the agent fills from the diff, so the line is a ceiling and the
-        // changed-behavior rule sets the Budget Plan — a fixed "Budget Plan" plus "use
-        // these exact numbers" here would contradict that rule (Copilot on mcp#835).
-        if (precomputedUIPct === 0) {
-            return `### PR Scope Assessment
-Budget Plan: ${maxTotal} total (${effectiveGenerate} generate + ${additional} additional)
-
-Use these exact numbers throughout the rest of the prompt.`;
-        }
-        return `### PR Scope Assessment
-Budget ceiling: ${maxTotal} total (${effectiveGenerate} generate + ${additional} additional)${uiSuffix}
-
-${changedBehaviorSection(effectiveGenerate)}`;
-    }
-    // Mixed PR: server can pre-compute the total but not the UI/E2E split — keep Step D.
-    if (hasFrontendChanges) {
-        return `### PR Scope Assessment — determine UI% before planning recommendations
-
-Budget ceiling: **${maxTotal} total (${effectiveGenerate} generate + ${additional} additional)**
-
-${changedBehaviorSection(effectiveGenerate, ", after Step D below sets your UI%")}
-
-**Step D — Determine UI vs backend split for your Budget Plan:**
-- Non-UI slots are backend tests; start from file-count ratio for UI%, then apply judgment:
-  - Cosmetic CSS/style changes alongside real changes inflate the frontend file count without adding test value → reduce UI%
-  - Frontend logic bugs (state management, calculation errors, form validation) in the diff → increase UI% even if few frontend files
-  - Frontend component calls a changed backend API → an E2E test covers both sides → count toward UI%
-  - Frontend files only in \`__tests__/\` or \`.stories.\` → exclude from the ratio
-
-**Append your UI% now** and state your Budget Plan — total and split per the changed-behavior rule above, within the ceiling:
-\`Budget Plan: <total> total (<generate> generate + <additional> additional), <ui_pct>% UI/E2E\`
-
-Use those numbers throughout the rest of the prompt.`;
-    }
-    // Fallback (no diff context — full_repo else-branch or test): full four-step assessment.
-    const minTotal = Math.min(effectiveGenerate + 1, maxTotal);
-    const minAdditional = Math.max(0, minTotal - effectiveGenerate);
-    const baselineFormula = `${effectiveGenerate} (generate) + ${minAdditional} (min additional) = ${minTotal}`;
-    const stepD = isUIOnly
-        ? `**Step D — UI/E2E confirmation (frontend-only PR):**
-This is a frontend-only PR — set **100% UI/E2E** in your Budget Plan.
-Budget generate slots toward directly recording and generating UI tests; budget additional slots toward more UI/E2E flows derived from the changed components.`
-        : `**Step D — Determine UI vs backend split:**
-- Backend-only PR (0 frontend files changed or only CSS/copy): **0% UI/E2E** — focus on integration and contract tests
-- Frontend-only PR: **100% UI/E2E** — all tests should be UI/E2E
-- Mixed PR — non-UI slots are backend tests; start from file-count ratio for UI%, then apply judgment:
-  - Pure CSS/style changes inflate the frontend file count without adding test value → reduce UI%
-  - Frontend logic bugs (state management, calculation errors, form validation) in the diff → increase UI% even if few frontend files
-  - Frontend component calls a changed backend API → an E2E test covers both sides → count toward UI%
-  - Frontend files only in \`__tests__/\` or \`.stories.\` → exclude from the ratio`;
-    return `### PR Scope Assessment — complete this first, before planning any recommendations
-
-Read the Changed Files list and endpoint changes above, then work through the four steps below. This determines your **Budget Plan** (total count + backend/frontend split) for the rest of the prompt.
-
-**Step A — Classify changed files:**
-Count each type from the diff context (ignore generated test files, lock files, and build artifacts):
-- **Frontend files**: .vue / .svelte / .css / .scss / .less anywhere (always UI). .dart anywhere (always UI in a Flutter project — repo has a \`pubspec.yaml\` with \`sdk: flutter\`). .tsx / .jsx anywhere except in api/, routes/, routers/, controllers/, handlers/, endpoints/, or server/ directories. .ts / .js / .html / .erb / .jsp / .asp / .jinja2 / .twig only when in a frontend directory (components/, pages/, views/, layouts/, app/, frontend/, client/, styles/, templates/).
-- **Backend files**: route handlers, controllers, services, models, API modules, middleware, config with business logic
-- **Non-application** (exclude from test value): README and docs, lock files, CI config with no logic
-
-**Step B — Assess semantic complexity (quality over quantity):**
-Weigh changes by their test value, not file count:
-- New API endpoint → HIGH test value: needs happy path + at least one error path (contributes ~2 to budget)
-- Modified endpoint with formula / business logic change → HIGH: edge cases matter (contributes ~1–2)
-- Auth middleware change → CRITICAL: flag for extra security tests regardless of file count
-- Frontend state / validation / calculation logic → HIGH for UI tests even if zero backend endpoints changed
-- Changed style values, labels or copy → each rendered difference is a changed behavior: assert the new value (computed style, class or text) — no change is too trivial to test
-
-**Step C — Determine total recommendation count (${minTotal}–${maxTotal}):**
-Start from the baseline formula: *${baselineFormula}*, then adjust:
-- **Scale up** for: critical auth/data-integrity changes (+2), complex multi-step business workflows (+1 each), new endpoints with non-trivial validation (+1 each beyond the formula)
-- **Scale down** for: already well-tested paths confirmed by existing test list, trivial CRUD with no validation
-- **Hard cap**: ${maxTotal}
-
-${stepD}
-
-**State your Budget Plan now** (one line, before any recommendation):
-\`Budget Plan: <total> total (<generate> generate + <additional> additional), <ui_pct>% UI/E2E\`
-
-Use these exact numbers throughout the rest of the prompt.`;
-}

package/build/recommendation/budgeters/diversityBalancedBudgeter.d.ts

@@ -1,7 +0,0 @@
-import { Budgeter } from "../../types/Recommendation.js";
-/**
- * Budgeter that guarantees cross-test-type coverage in the GENERATE set.
- * `maxGenerate` acts as an upper cap (not a hard N). Fixes the single-type skew
- * that starves contract/error-path tests. Opt-in via strategy selection.
- */
-export declare const diversityBalancedBudgeter: Budgeter;

package/build/recommendation/budgeters/diversityBalancedBudgeter.js

@@ -1,105 +0,0 @@
-import { runBudget } from "./shared.js";
-import { bucketByType, inferScenarioType, isProtectedCandidate, roundRobinFill, } from "../diversity.js";
-const typeOf = (c) => inferScenarioType(c.scenario);
-/**
- * Pick `count` items guaranteeing each present test type at least one slot.
- *
- * Unlike roundRobinByType (which fills ALL protected items first and can
- * starve other types at small N — the SKYR-3879 "0 contract executed" skew),
- * this caps protected occupancy to `count - (numTypes - 1)` so at least one slot
- * per remaining type is always reachable, then:
- *   Phase 1 — one item for each still-uncovered present type (by rank), then
- *   Phase 2 — round-robin the remainder across types until `count` is reached.
- * Rank order is preserved within each type; degenerate cases match a rank slice.
- */
-function floorBalancedPick(items, count) {
-    if (count <= 0)
-        return [];
-    if (count >= items.length)
-        return items.slice(0, count);
-    // Present types in first-appearance (rank) order.
-    const typesOrder = [];
-    const seen = new Set();
-    for (const it of items) {
-        const t = typeOf(it);
-        if (!seen.has(t)) {
-            seen.add(t);
-            typesOrder.push(t);
-        }
-    }
-    // Two passes, because "protected" is broader than "is a caught bug".
-    //
-    // A `bug_caught` candidate may take a type-floor slot: a caught bug is the
-    // strongest thing a run produces, and it outranks type spread. Every OTHER
-    // protected candidate — anything else CRITICAL, and attack-surface
-    // security_boundary items — still yields to the floor, which is what stops
-    // the SKYR-3879 skew where three CRITICAL integration candidates took all
-    // three slots and no contract test was generated.
-    //
-    // The second pass replaces `maxProtected = count - (typesOrder.length - 1)`,
-    // a static cap computed from the whole pool. It reserved a slot for every
-    // other type whether or not the picks already covered it, so at the default
-    // budget of 3 with three types present it evaluated to 1. Counting the types
-    // still uncovered keeps the same floor and drops the arithmetic that made a
-    // second finding unreachable.
-    // The same bound the prompt states (`maxGen - 1`, and the whole budget only
-    // at a budget of 1). Without it the first pass took every caught bug up to
-    // `count`, which put the SKYR-3879 skew back: at the default budget of 3, two
-    // same-type bugs left no slot for the type floor, and a measured 9-20% of
-    // backend-only pools lost a test type. It also evicted attack-surface
-    // security_boundary items the prompt in this same branch says to preserve
-    // while any non-bug slot remains.
-    const bugSlots = count <= 1 ? count : count - 1;
-    const selected = [];
-    const deferred = [];
-    const pool = [];
-    let bugsTaken = 0;
-    for (const it of items) {
-        if (it.scenario?.category === "bug_caught" && bugsTaken < bugSlots && selected.length < count) {
-            selected.push(it);
-            bugsTaken++;
-        }
-        else {
-            deferred.push(it);
-        }
-    }
-    const takenTypes = new Set(selected.map(typeOf));
-    for (const it of deferred) {
-        const stillUncovered = typesOrder.filter((t) => !takenTypes.has(t) && t !== typeOf(it)).length;
-        if (isProtectedCandidate(it.priority, it.scenario) &&
-            selected.length < count &&
-            count - (selected.length + 1) >= stillUncovered) {
-            selected.push(it);
-            takenTypes.add(typeOf(it));
-        }
-        else {
-            pool.push(it);
-        }
-    }
-    const { buckets } = bucketByType(pool, typeOf);
-    const covered = new Set(selected.map(typeOf));
-    // Phase 1 — floor: one item per still-uncovered present type.
-    for (const t of typesOrder) {
-        if (selected.length >= count)
-            break;
-        if (covered.has(t))
-            continue;
-        const bucket = buckets.get(t);
-        if (bucket && bucket.length > 0) {
-            selected.push(bucket.shift());
-            covered.add(t);
-        }
-    }
-    // Phase 2 — round-robin the remainder across types until full.
-    roundRobinFill(selected, typesOrder, buckets, count);
-    return selected;
-}
-/**
- * Budgeter that guarantees cross-test-type coverage in the GENERATE set.
- * `maxGenerate` acts as an upper cap (not a hard N). Fixes the single-type skew
- * that starves contract/error-path tests. Opt-in via strategy selection.
- */
-export const diversityBalancedBudgeter = {
-    name: "diversity-balanced",
-    select: (ranked, ctx) => runBudget(ranked, ctx, floorBalancedPick),
-};

package/build/recommendation/budgeters/fixedNBudgeter.d.ts

@@ -1,7 +0,0 @@
-import { Budgeter } from "../../types/Recommendation.js";
-/**
- * Default budgeter — reproduces the pre-refactor behavior exactly: fill up to
- * `maxGenerate` GENERATE slots by round-robin across the present test types
- * (protected items first), the rest become ADDITIONAL.
- */
-export declare const fixedNBudgeter: Budgeter;

package/build/recommendation/budgeters/fixedNBudgeter.js

@@ -1,11 +0,0 @@
-import { roundRobinByType } from "../diversity.js";
-import { runBudget } from "./shared.js";
-/**
- * Default budgeter — reproduces the pre-refactor behavior exactly: fill up to
- * `maxGenerate` GENERATE slots by round-robin across the present test types
- * (protected items first), the rest become ADDITIONAL.
- */
-export const fixedNBudgeter = {
-    name: "fixed-n",
-    select: (ranked, ctx) => runBudget(ranked, ctx, roundRobinByType),
-};

package/build/recommendation/budgeters/shared.d.ts

@@ -1,32 +0,0 @@
-import { Candidate, BudgetContext, SelectionResult } from "../../types/Recommendation.js";
-/**
- * What each PR class GUARANTEES in GENERATE (SKYR-4275). These are floors, not
- * quotas: the slots above them are open to either kind, decided by `pick`.
- * An open slot goes to whichever candidate `pick` chooses on rank, so a backend
- * candidate takes one when it outranks the UI candidates, not merely because it
- * exists. Measured against main on random mixed pools at `maxGenerate` 5 with no
- * caught bugs: 35% get fewer backend tests than main did, average 3.53 to 3.24.
- *
- * Backend-only floors nothing on purpose: of 86 backend-only diffs in the eval
- * corpus, ZERO generated a UI test, so a floor there would guarantee what
- * already happens every time.
- *
- * At one slot there is no room for a floor plus an open slot, so each class
- * keeps that slot for its own kind.
- *
- * The floors always sum to at most `maxGenerate`, which is what lets
- * `applyFloors` satisfy both without one starving the other.
- */
-export declare function generateFloors(ctx: BudgetContext): {
-    ui: number;
-    backend: number;
-};
-/**
- * Shared budgeting pipeline. All Budgeters run the same external-dedup,
- * attack-surface prioritization, and ADDITIONAL set-difference; they differ
- * ONLY in how they pick the GENERATE items from the slot-ordered list (`pick`).
- *
- * With `pick = roundRobinByType` this reproduces the pre-refactor selection in
- * diffExecutionPlan.ts exactly.
- */
-export declare function runBudget(ranked: Candidate[], rawCtx: BudgetContext, pick: (items: Candidate[], count: number) => Candidate[]): SelectionResult;