import { z } from 'zod';
import { defineTool, } from '../toolDefinition.js';
import { AgentToolNames } from '../shared/agentToolNames.js';
import { NO_FOLLOW_UP_NEEDED } from '../shared/constants.js';
import { RECOVERY_VERDICT_FAIL, RECOVERY_VERDICT_PASS, RECOVERY_VERDICT_STATUS_VALUES } from './recoveryVerdictStatus.js';
export const submitRuntimeRecoverySummaryStepVerdictArgumentsSchema = z.object({
    step_run_id: z
        .string()
        .describe('Step run ID for the recovered step, copied verbatim from the Runtime Recovery session data. Used to link the verdict back to the exact step run in the runner UI.'),
    step_id: z
        .string()
        .describe('Stable step ID (invariant across runs), copied verbatim from the Runtime Recovery session data.'),
    step_description: z
        .string()
        .describe('Human-readable description of the original step, used as the card title in the Recovery review panel. Example: "Click the \'Save plan\' button".'),
    step_display_number: z
        .string()
        .describe('Step number as shown in the runner — top-level steps are bare numbers ("7"), nested steps inside a flow use dotted notation ("3.1").'),
    issue: z
        .string()
        .describe("One-sentence description of what went wrong on this step. For steps the recovery handled, this is the failure that triggered Runtime Recovery (e.g. \"'Welcome back' modal appeared after login, blocking Step 7 interactions\"). For an auto-heal-only step you flagged while reviewing the recovery evidence, describe the auto-heal mismatch (e.g. \"Auto-heal selected the wrong list item: bound to 'ISSUE-101' instead of 'ISSUE-100'\")."),
    recovery_action: z
        .string()
        .describe('One-sentence description of what was done in response to the issue. For steps the recovery handled, this is what Runtime Recovery did (e.g. "Clicked \'Got it\' to dismiss the modal and continued"). For an auto-heal-only step, this is what the auto-heal substituted (e.g. "Auto-heal substituted the closest visible list item; the runner continued without re-checking"). USER-FACING TEXT — never write the acronym TRA; refer to it as "Runtime Recovery" or "the recovery".'),
    outcome: z
        .string()
        .describe("One-to-three-sentence judgment of whether the recovery (or auto-heal) preserved the step's semantic intent. Be specific about what actually happened versus what the original step was supposed to verify. USER-FACING TEXT — never write the acronym TRA."),
    technical_recommendation: z
        .string()
        .describe(`Actionable follow-up for the test author or developer. If there is nothing to recommend, write exactly "${NO_FOLLOW_UP_NEEDED}".`),
    status: z
        .enum(RECOVERY_VERDICT_STATUS_VALUES)
        .describe(`Per-step verdict. Use "${RECOVERY_VERDICT_PASS}" when the recovery or auto-heal preserved the step's semantic intent. Use "${RECOVERY_VERDICT_FAIL}" when it bypassed an assertion, modified application state to satisfy a check, bound to a wrong-but-similar element, or otherwise changed the business outcome the step was supposed to verify. Auto-heal-only verdicts are typically "${RECOVERY_VERDICT_FAIL}" — if an auto-heal worked correctly there is usually nothing to flag.`),
});
export const submitRuntimeRecoverySummaryStepVerdictResponseSchema = z.object({
    acknowledged: z
        .boolean()
        .describe('True when the step verdict was accepted. False means the call was rejected for the reason in error and you should fix it and call again.'),
    error: z
        .string()
        .optional()
        .describe('Present only when acknowledged is false; explains what to fix before re-calling.'),
});
export const SubmitRuntimeRecoverySummaryStepVerdictToolDefinition = defineTool({
    name: AgentToolNames.SubmitRuntimeRecoverySummaryStepVerdict,
    description: `Non-terminal — submit a per-step verdict for a single step. Call this tool BEFORE the terminal ${AgentToolNames.SubmitRuntimeRecoverySummaryVerdict} tool, once for every step you reviewed:
- One call per entry in recovered_step_indices (every step the recovery handled needs a verdict).
- One additional call for any step not in recovered_step_indices where you discover, while reviewing the recovery evidence, that an auto-heal bound to a wrong element and that mistake materially changed the test's outcome (e.g. seeded the data the next assertion checked).

The tool calls themselves are persisted in the agent session message history; the UI reads them to render one card per reviewed step in the Recovery review panel. There is no need to also write step-level verdicts into the reasoning file.

Use exact step_run_id and step_id values copied from the Runtime Recovery session data or from the prefetched current-run step ID map — never paraphrase or fabricate them. If you cannot locate a step's IDs, do not emit a verdict for that step.

USER-FACING TEXT: \`issue\`, \`recovery_action\`, \`outcome\`, and \`technical_recommendation\` are rendered directly to the test author. Never write the acronym TRA in those fields — refer to it as "Runtime Recovery" or "the recovery". The acronym is internal only.

Status semantics:
- '${RECOVERY_VERDICT_PASS}' = the recovery preserved the step's semantic intent (e.g. dismissed an unrelated modal, waited out a transient delay, re-found the same element after cosmetic markup change).
- '${RECOVERY_VERDICT_FAIL}' = the recovery or auto-heal bypassed or invalidated the step's intent (e.g. skipped an assertion, modified app data to satisfy a check, bound to a visually-similar but semantically-wrong element, moved interaction to a different flow).

Status is judged independently of outcome wording — a recovery whose outcome reads benign can still be '${RECOVERY_VERDICT_FAIL}' if it bypassed the step's intent.`,
    argumentsSchema: submitRuntimeRecoverySummaryStepVerdictArgumentsSchema,
    responseSchema: submitRuntimeRecoverySummaryStepVerdictResponseSchema,
});
//# sourceMappingURL=SubmitRuntimeRecoverySummaryStepVerdictDefinition.js.map