@mknrt/autotests-overkill 1.1.3 → 1.1.5

package/dist/src/mcp/registerTools.js

@@ -4,6 +4,7 @@ import { analyzeTestGaps } from '../domain/analyzeTestGaps.js';
 import { buildRerunScope } from '../domain/buildRerunScope.js';
 import { buildSetupTeardownPlan } from '../domain/buildSetupTeardownPlan.js';
 import { findExistingTestAssets } from '../domain/findExistingTestAssets.js';
+import { findBackendTestContext } from '../domain/findBackendTestContext.js';
 import { findFrontendContract } from '../domain/findFrontendContract.js';
 import { findFrontendRuntimeLogic } from '../domain/findFrontendRuntimeLogic.js';
 import { findTestAreaContext } from '../domain/findTestAreaContext.js';
@@ -22,6 +23,13 @@ export function buildToolRegistry() {
             outputSchema: toolOutputSchema,
             execute: findExistingTestAssets,
         },
+        {
+            name: 'find_backend_test_context',
+            description: 'Finds autotests2 API interaction flows plus backend endpoint, validation, async-task, and error hints.',
+            inputSchema: z.object({ query: z.string().min(1) }),
+            outputSchema: toolOutputSchema,
+            execute: findBackendTestContext,
+        },
         {
             name: 'find_test_area_context',
             description: 'Returns conventions, init patterns, and area context for constructor or formRunner.',

package/docs/operator-cookbook.md

@@ -5,8 +5,9 @@
 1. Run `find_existing_test_assets` for the target widget or feature.
 2. Run `find_frontend_contract`.
 3. Run `find_frontend_runtime_logic`.
-4. Run `generate_spec_blueprint`.
-5. Review reuse candidates, setup hints, and selector guidance before editing `autotests2`.
+4. For API-heavy flows, run `find_backend_test_context` to inspect `ApiDiscoveryCatalog`, `api-interaction`, and `backend-endpoint` evidence.
+5. Run `generate_spec_blueprint`.
+6. Review reuse candidates, setup hints, selector guidance, backend params, validation hints, and async completion hints before editing `autotests2`.
 
 ## Find coverage gaps
 
@@ -20,7 +21,17 @@
 1. Run `summarize_ci_context`.
 2. Run `triage_failed_run`.
 3. Run `build_rerun_scope`.
-4. If frontend files changed, run `analyze_diff_impact`.
+4. If frontend or backend files changed, run `analyze_diff_impact`.
+5. When API capture files exist, treat triage backend hints as evidence-backed hypotheses only when the capture path matches high-confidence `api-interaction` and `backend-endpoint` records.
+
+## Use backend indexing
+
+1. Set optional `repos.fisPlatform` to `../fis_platform` in `overkill.config.json`.
+2. Run `npm run index`; refresh builds `ApiDiscoveryCatalog` from `autotests2` support code before scanning backend sources.
+3. Review snapshots under `.overkill-cache/snapshots`: `api-discovery-catalog.json`, `api-interactions.json`, and `backend-contracts.json`.
+4. Use backend context for debugging request flows discovered from support code or API capture, generating API-heavy blueprints, triaging failures with API captures, and analyzing backend REST/resource diffs.
+5. Do not treat backend indexing as a hardcoded file allowlist. Discovery uses REST/JAX-RS signals and evidence metadata such as `confidence`, `whySelected`, `whyMatched`, `normalizedPaths`, and `evidencePaths`.
+6. Runtime API captures are on-demand in iteration 1; raw captures are not persisted to the knowledge store.
 
 ## Onboard a new engineer