import { z } from 'zod';
import { defineTool, } from '../toolDefinition.js';
import { NO_RELEVANT_TECHNICAL_DIAGNOSTIC, REASONING_FILENAME, REPAIR_NOTES_FILENAME } from '../shared/constants.js';
import { AgentToolNames } from '../shared/agentToolNames.js';
import { RECOVERY_VERDICT_FAIL, RECOVERY_VERDICT_PASS, RECOVERY_VERDICT_STATUS_VALUES } from './recoveryVerdictStatus.js';
export const runtimeRecoverySummaryInsightSchema = z.object({
    category: z
        .string()
        .describe('Short label rendered as a badge in the Insight footer. Use a noun phrase that names the failure pattern at a glance. Examples: "Selector drift", "Application defect", "Flaky environment", "Test design gap".'),
    text: z
        .string()
        .describe('One-to-three-sentence description of what the agent learned from this test run, written for the test author. Keep it brief — long explanations belong in the reasoning file.'),
});
export const submitRuntimeRecoverySummaryVerdictArgumentsSchema = z.object({
    verdict: z
        .enum(RECOVERY_VERDICT_STATUS_VALUES)
        .describe('The final verdict on whether the test run should be considered a pass or a fail after reviewing every Runtime Recovery session and auto-heal. Choose fail when any recovery changed the semantic outcome of the test.'),
    summary: z
        .string()
        .describe('One-sentence plain-text summary of the verdict outcome — required for both pass and fail. Plain text only; markdown is rendered literally and will look broken. For fail: explain which recovery or auto-heal invalidated the test intent. For pass: confirm that all recoveries preserved it. USER-FACING TEXT — never write the acronym TRA; refer to it as "Runtime Recovery" or "the recovery".'),
    insight: runtimeRecoverySummaryInsightSchema
        .optional()
        .describe('Optional structured learning surfaced in the Insight footer of the Recovery review panel. Include when there is a generalizable observation about the test, application, or environment that the test author would benefit from seeing. Omit when the test run is unremarkable.'),
});
export const submitRuntimeRecoverySummaryVerdictResponseSchema = z.object({
    acknowledged: z
        .boolean()
        .describe('True when the 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 SubmitRuntimeRecoverySummaryVerdictToolDefinition = defineTool({
    name: AgentToolNames.SubmitRuntimeRecoverySummaryVerdict,
    description: `Terminal tool - submit the final pass/fail verdict for the test run being evaluated.

Before calling this tool you MUST:
1. Call ${AgentToolNames.SubmitRuntimeRecoverySummaryStepVerdict} once for every recovered step (one call per recovered_step_indices entry).
2. Write ${REASONING_FILENAME} and ${REPAIR_NOTES_FILENAME} using ${AgentToolNames.WriteFile}. The tool will reject the call if either file is missing.

${REPAIR_NOTES_FILENAME} should contain actionable diagnostic information for the developer or next agent: wrong selectors (with text and correct target), the URL to reproduce the issue, and concrete steps to try. Write "${NO_RELEVANT_TECHNICAL_DIAGNOSTIC}" if there is nothing actionable.

USER-FACING TEXT: \`summary\` and \`insight.text\` 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.

You are an impartial reviewer. Do not bias toward pass or fail. Consider each Runtime Recovery session and each auto-heal on its own merits:
- Did the recovery preserve the semantic intent of the original step?
- If the failed step was an assertion, does the post-recovery state still satisfy the assertion?
- Did any auto-heal bind to an element that is actually the right target (use ${AgentToolNames.GetStepScreenshot} to verify)?

Always provide a one-sentence summary regardless of verdict:
- For '${RECOVERY_VERDICT_FAIL}': explain which recovery or auto-heal broke the test's intent.
- For '${RECOVERY_VERDICT_PASS}': confirm that all recoveries preserved the test's semantic intent.

Optionally include an insight when there's a generalizable lesson worth surfacing in the Recovery review panel footer: a recurring selector pattern that drifts, an application defect masquerading as flake, or a test design gap that lets recoveries hide failures. Skip the insight when the run is unremarkable.`,
    argumentsSchema: submitRuntimeRecoverySummaryVerdictArgumentsSchema,
    responseSchema: submitRuntimeRecoverySummaryVerdictResponseSchema,
});
//# sourceMappingURL=SubmitRuntimeRecoverySummaryVerdictDefinition.js.map