@skyramp/mcp 0.3.8 → 0.4.0-rc.1

package/build/utils/subjectEndpoints.d.ts

@@ -1,19 +0,0 @@
-import { DraftedScenario, SubjectEndpoint } from "../types/RepositoryAnalysis.js";
-import { ChangedRoute } from "./changedRoutes.js";
-export type { SubjectEndpoint };
-/**
- * The endpoints a scenario tests, in step order.
- *
- * 1. Every step on a changed diff line that names a resource. A test written
- *    for a pull request is about what the pull request changed, and a
- *    scenario can exercise more than one changed endpoint.
- * 2. If no step matches: the last mutating step that is not a teardown step.
- *    Earlier mutations are usually setup (POST /products before PATCH /orders).
- * 3. If no mutating step remains: the last step.
- *
- * Returns an empty list only for a scenario with no steps. Every caller must
- * treat an empty list as "no information", never as "covered".
- */
-export declare function resolveSubjectEndpoints(scenario: DraftedScenario, opts: {
-    changedRoutes?: ChangedRoute[];
-}): SubjectEndpoint[];

package/build/utils/subjectEndpoints.js

@@ -1,98 +0,0 @@
-import { findStepOnChangedRoute } from "./changedRoutes.js";
-import { extractResourceFromPath, isParamSegment } from "./routeParsers.js";
-const MUTATING_METHODS = new Set(["POST", "PUT", "PATCH", "DELETE"]);
-/**
- * A final-position DELETE that removes a resource an earlier POST created is
- * cleanup, not the subject. SKYR-4214 measured the cost of counting it: the
- * same fixture keyed as POST::flows on one run and DELETE::flows on the next,
- * decided only by whether the model appended a cleanup step.
- *
- * The step count matters. A two-step POST-then-DELETE has no room for a
- * verification step, so the DELETE is what the test is about; the cleanup shape
- * always has a step between the create and the delete. A scenario that asserts
- * the delete worked (…DELETE, then GET 404) leaves the DELETE off the final
- * position, so it is not excluded either.
- */
-function isTeardownStep(steps, index) {
-    const step = steps[index];
-    if (index !== steps.length - 1)
-        return false;
-    if ((step.method ?? "").toUpperCase() !== "DELETE")
-        return false;
-    if (steps.length < 3)
-        return false;
-    const resource = extractResourceFromPath(step.path ?? "");
-    // "unknown" is the sentinel for a path that names no resource, so comparing
-    // it by equality makes any two unidentifiable paths look like the same
-    // resource: `POST /` … `DELETE /{id}` read as create-then-cleanup and the
-    // DELETE — the real subject — got skipped. Only a named resource can pair.
-    if (resource === "unknown")
-        return false;
-    return steps.slice(0, index).some((earlier) => (earlier.method ?? "").toUpperCase() === "POST" &&
-        extractResourceFromPath(earlier.path ?? "") === resource);
-}
-/**
- * A route declaration made only of parameter segments (or none at all, e.g.
- * "/" or "") names no resource, so it cannot tell one endpoint from another —
- * every step's path ends in the same param segment. SKYR-4214: a changed
- * `@router.delete("/{id}")` line matched a step's trailing DELETE cleanup
- * step just as well as the step it was actually meant to catch, which
- * reinstated the bug this file exists to fix. Rule 1 only accepts a route
- * that contributes at least one non-parameter segment.
- */
-function routeIdentifiesResource(routePath) {
-    return routePath.split("/").filter(Boolean).some((segment) => !isParamSegment(segment));
-}
-/**
- * The endpoints a scenario tests, in step order.
- *
- * 1. Every step on a changed diff line that names a resource. A test written
- *    for a pull request is about what the pull request changed, and a
- *    scenario can exercise more than one changed endpoint.
- * 2. If no step matches: the last mutating step that is not a teardown step.
- *    Earlier mutations are usually setup (POST /products before PATCH /orders).
- * 3. If no mutating step remains: the last step.
- *
- * Returns an empty list only for a scenario with no steps. Every caller must
- * treat an empty list as "no information", never as "covered".
- */
-export function resolveSubjectEndpoints(scenario, opts) {
-    const steps = scenario.steps ?? [];
-    if (steps.length === 0)
-        return [];
-    const changedRoutes = (opts.changedRoutes ?? []).filter((route) => routeIdentifiesResource(route.path));
-    if (changedRoutes.length > 0) {
-        // Attribute PER ROUTE, not per step. A diff-extracted route is local to its
-        // own router declaration — the mount prefix lives in another file, so a bare
-        // `POST /items` suffix-matches a step on `/orders/{id}/items` and one on
-        // `/products/{id}/items` equally. Recording both would invent a subject the
-        // diff does not name, and dedup then needs every unrelated key covered
-        // before the candidate can be removed.
-        //
-        // A route matching exactly one step names that step. A route matching
-        // several names none of them: there is no evidence for choosing, and a
-        // guess is worse than an omission. Other routes still contribute, so a
-        // scenario that genuinely tests two changed endpoints keeps both subjects.
-        const attributed = [];
-        for (const route of changedRoutes) {
-            const matches = steps.filter((step) => findStepOnChangedRoute([step], [route]));
-            const distinct = new Map(matches.map((step) => [`${step.method} ${step.path}`, step]));
-            if (distinct.size === 1)
-                attributed.push([...distinct.values()][0]);
-        }
-        // Keep step order and drop the duplicates two routes can both name.
-        const onChanged = steps.filter((step) => attributed.includes(step));
-        if (onChanged.length > 0) {
-            return onChanged.map((step) => ({ method: step.method, path: step.path }));
-        }
-    }
-    for (let i = steps.length - 1; i >= 0; i--) {
-        if (!MUTATING_METHODS.has((steps[i].method ?? "").toUpperCase()))
-            continue;
-        if (isTeardownStep(steps, i))
-            continue;
-        return [{ method: steps[i].method, path: steps[i].path }];
-    }
-    const last = steps[steps.length - 1];
-    return [{ method: last.method, path: last.path }];
-}

package/build/utils/uiPageEnumerator.d.ts

@@ -1,172 +0,0 @@
-/**
- * Programmatic UI page enumeration — translates "which frontend files changed"
- * into "which URLs should the agent capture blueprints for."
- *
- * Replaces the prose-driven Task 0 strategy ladder in the testbot prompt with
- * deterministic code so the candidate page list lives in the stateFile and is
- * reusable across analyze_changes consumers (testbot, analyze_test_health,
- * future blueprint-grounded recommenders).
- *
- * Strategies, tried in order:
- *
- *   Strategy 1 — Framework route grep
- *     Translate file-system-routed component paths directly to URLs. Covers
- *     Next.js (app/ and pages/), Nuxt / Vue Router file-based, and SvelteKit.
- *     Gated on detection of a framework config file in the repo.
- *
- *   Strategy 1b — Import graph
- *     For a changed file that is not itself a route (a component, a constants
- *     module), map the production files that import it through the same
- *     filesystem-route mapper. Uses the importer list the production-importer integration
- *     check already computed. Merged with strategy 1 rather than tried after it.
- *
- *   Strategy 2 — Source-grounded routes
- *     Walks router/App files with the TS Compiler API for code-defined
- *     route declarations like `<Route path="/cart" element={<Cart/>}>`.
- *     Matches each route's component file OR declaration file against the
- *     changed-file list (so router rewrites surface their routes even when
- *     the component itself is unchanged). Handles React Router string-literal
- *     paths, cross-file constant resolution, Vue Router object literals,
- *     and Directus `defineModule` aggregation. See `sourceRouteExtractor.ts`.
- *
- *   Strategy 3 — Root fallback
- *     Read the workspace's frontend baseUrl and treat it as the single
- *     candidate page. Always available when a frontend service is configured.
- *
- * When no frontend baseUrl can be resolved, strategies 1/1b still run and their
- * results are returned as bare URL paths (`baseUrlResolved: false`) so the agent
- * can prefix the base URL it discovers; strategies 2–3 need a host and are skipped.
- */
-import type { FrontendFileIntegration } from "../types/FrontendIntegration.js";
-export type CandidateUiPageStrategy = "framework-route-grep" | "import-graph" | "source-grounded-routes" | "dart-go-router" | "root-fallback";
-export interface CandidateUiPage {
-    /**
-     * Fully qualified URL (workspace baseUrl + framework-derived path), or a bare
-     * URL path when `baseUrlResolved` is false.
-     */
-    url: string;
-    /** Source files that suggested this page (for traceability). */
-    sourcedFrom: string[];
-    /** Which strategy enumerated it. */
-    strategy: CandidateUiPageStrategy;
-    /**
-     * Present (false) only when no frontend baseUrl could be resolved and `url`
-     * is a bare path the agent must prefix. Absent means `url` is complete.
-     */
-    baseUrlResolved?: false;
-    /** import-graph only: the route files that import `sourcedFrom` and produced this path. */
-    via?: string[];
-}
-/**
- * Upper bound on candidate pages. Strategy 1b is bounded by changed files ×
- * importers, and every candidate costs the agent a navigate + a capture, so the
- * list is cut here — direct route matches first, then import-graph pages that
- * render the most changed files.
- */
-export declare const MAX_CANDIDATE_PAGES = 10;
-/**
- * File-system → URL mapping for filesystem-routed frameworks.
- *
- * Returns the URL path (no host) when the file is a route entrypoint, or
- * null when the file isn't a route in any recognized convention.
- *
- * The `null` cases include component files used by routes (e.g. shared
- * widgets in `components/`), API handlers (e.g. Next.js `pages/api/*`),
- * and arbitrary `.ts`/`.js` modules under frontend directories. These
- * are picked up by strategy 2 (import-graph walk, future) or by strategy
- * 3 (root fallback).
- */
-export declare function frameworkFileToUrlPath(filePath: string): string | null;
-/**
- * Detect whether the repository is configured for filesystem-based routing.
- *
- * Strategy 1 maps file paths to URLs based on conventions (Next.js Pages
- * Router, Nuxt, SvelteKit). Without a positive signal that the framework
- * is actually configured, a repo that just *happens* to have a `pages/`
- * directory (e.g. React with conventional layout, Vue with route-config
- * code) produces false-positive URLs. This guard suppresses strategy 1
- * for those repos so they fall through to root-fallback.
- *
- * Looks for framework config files in the repo root, common subdirectories,
- * and the `frontendFiles[]`-derived candidate frontend roots.
- */
-export declare function detectsFilesystemRouting(repositoryPath: string): boolean;
-/** Strategy 1 only (no import graph), joined to `baseUrl`. */
-export declare function findCandidatePagesByFrameworkRoute(frontendFiles: string[], baseUrl: string, repositoryPath?: string): CandidateUiPage[];
-/**
- * Strategy 2 implementation. Walks router/App files with the TS Compiler API
- * to find route declarations (`<Route path="/cart" element={<Cart/>}>`),
- * matches each declaration's component file against the changed-file list,
- * and emits one CandidateUiPage per matching route.
- *
- * Slice 3a covers string-literal `path` attributes only — `path={CONST}` and
- * Vue Router object literals are deferred to slice 3b.
- *
- * Returns empty when no route declarations match the changed files (which is
- * also the right answer for SPAs without client-side routing — they fall
- * through to root-fallback).
- */
-export declare function findCandidatePagesBySourceRoute(frontendFiles: string[], baseUrl: string, repositoryPath: string): CandidateUiPage[];
-/**
- * Strategy 2.5: walk the repo's Dart files for GoRoute(path: '...') calls.
- * Gated on `hasFlutterSdkDep(repoPath)` so non-Flutter Dart projects (e.g.
- * shelf_router servers) don't accidentally emit URLs.
- *
- * Diff-matching: each GoRoute references its screen widget via
- * `builder:`/`pageBuilder:` (e.g. `AuthorsScreen`). The extractor resolves
- * those identifiers through the route file's imports to absolute screen
- * file paths. We surface only routes whose screen file appears in the
- * changed-file list. Falls back to all-routes when no route's screen
- * file matches — preserves coverage for "router untouched, screen edited"
- * cases when the import-resolution heuristic doesn't find a match.
- *
- * Filters applied:
- *   1. Drop redirect-only routes (`redirect:` with no `builder:`/`pageBuilder:`).
- *      These have no UI to render — navigating there is wasted work.
- *   2. Drop nested relative children (paths that don't start with `/`).
- *      Without parent-path composition the URL is meaningless.
- *
- * Returns empty when the repo isn't Flutter or no GoRoute calls are
- * found — caller falls through to root-fallback.
- */
-export declare function findCandidatePagesByDartRoute(repositoryPath: string, baseUrl: string, frontendFiles: string[]): CandidateUiPage[];
-/**
- * Strategy 3: when strategies 1+2 yield nothing, fall back to the workspace's
- * frontend baseUrl as the single candidate page. The agent's downstream
- * explore-and-discover step can then surface gated UI from the root.
- *
- * Returns null when the workspace has no recognizable frontend service.
- */
-export declare function findRootFallbackPage(repositoryPath: string): Promise<CandidateUiPage | null>;
-/**
- * Resolves the frontend service's baseUrl from the workspace config.
- *
- * Returns the baseUrl string with environment variable override precedence:
- *   1. Per-service override: `SKYRAMP_TEST_SERVICE_URL_<NAME>` (where <NAME>
- *      is the picked frontend service's serviceName, sanitized via
- *      `sanitizeServiceName`)
- *   2. Global override: `SKYRAMP_TEST_BASE_URL` (single service or all
- *      services share one URL). Also honored when the workspace declares no
- *      services at all — the action can know the URL without a workspace entry.
- *   3. Static workspace.yml value: `api.baseUrl` from the picked frontend
- *      service
- *
- * Returns null when neither the environment nor any service has a usable URL.
- *
- * Exported (vs private) so analyze_changes and future tools can reuse the
- * same selection without re-implementing it.
- */
-export declare function pickFrontendBaseUrl(repositoryPath: string): Promise<string | null>;
-/**
- * Run the strategy ladder: framework route grep + import graph (1/1b) →
- * source-grounded routes (2) → Dart GoRouter (2.5) → root fallback (3). Each
- * later strategy is consulted only if the earlier ones produced no candidates.
- *
- * `integration` is the production-importer check for the same files; when given,
- * changed non-route files resolve to the pages that import them.
- *
- * Without a resolvable frontend baseUrl only strategies 1/1b can run; their
- * paths are returned with `baseUrlResolved: false` for the agent to prefix.
- * Returns empty only when nothing resolves at all.
- */
-export declare function enumerateCandidateUiPages(repositoryPath: string, frontendFiles: string[], integration?: FrontendFileIntegration[]): Promise<CandidateUiPage[]>;