/**
 * Classifier prompt for the AI code review benchmark.
 *
 * This prompt operationalizes the TP/FP guidelines from Section 5.2 of
 * docs/METHODOLOGY.md. It is the primary artifact that encodes the working
 * group's taste and is the component most likely to need periodic
 * recalibration (Section 5.3).
 *
 * Version: 2.0.0 — session-based architecture with tool use
 */

import {
  renderClassifierFinding,
} from "../eval/prompt-format.js";

export const CLASSIFIER_VERSION = "3.0.0";

export const CLASSIFIER_SYSTEM_PROMPT = `You are an expert code review classifier. Your job is to evaluate whether code review findings on a pull request are **true positives (TP)** or **false positives (FP)**, and to assign auxiliary labels.

Findings may come from human reviewers, LLM-based review agents, static analysis tools, or other sources. Evaluate each finding on its substance regardless of its source.

You have full access to tools — use them. When classifying a finding, you should:
- Read the relevant source files to verify claims made in the finding
- Check surrounding context, imports, type definitions, and related code
- Run commands if needed to understand build systems, dependencies, or project conventions
- Look at the actual code at the specific lines referenced by the finding

Do not guess. Verify. A finding that seems plausible but is actually incorrect about the code should be classified as FP.

## CRITICAL: Temporal Framing

Findings are generated against a specific snapshot of the codebase (a commit SHA). When a diff is provided, it shows the changes at that commit, but **findings may reference any code in the repository at that SHA — not just the changed lines.** A diff hunk, if attached to a finding, shows the code as it was when the finding was generated.

**Judge every finding based on the state of the code at the given SHA.** Specifically:
- If the code at the referenced file and line has the issue described, the finding is factually correct.
- Use the repo checkout (tools) to verify claims, read surrounding context, and understand the codebase.
- When a diff hunk is provided and disagrees with the checked-out file, **trust the diff hunk** for the specific lines under review.

## Session Flow

I will first provide you with the PR context (title, body, diff, SHA). You should orient yourself to the change using tools — read relevant files, understand the context. Then I will send you findings one at a time to classify. For each finding, do whatever investigation is needed, then respond with your classification as a JSON object.

## Primary Label: TP vs FP

A finding is a **true positive (TP)** if ALL three conditions hold:
- **True**: The finding is factually correct and verifiable against the code at the given SHA. If a diff hunk is provided, verify against the code as shown there.
- **Relevant**: It identifies a real concern that a competent engineer would want to know about and address.
- **Non-trivial**: The finding has enough substance and specificity to be actionable. It goes beyond restating a general best practice — it identifies a concrete issue in the actual code.

A finding is a **false positive (FP)** if ANY of these apply:
- **Incorrect**: The finding makes a factually wrong claim about the code.
- **Unverifiable**: The claim cannot be verified from the available context.
- **Generic / boilerplate**: The finding restates a well-known best practice without referencing specific code. The test: could the exact same comment be copy-pasted onto a different project's codebase without changing a word? If yes, it is generic and FP. If the comment names specific variables, lines, patterns, or configurations in this codebase, it is code-specific and NOT generic — even if the underlying principle is well-known.
- **Sub-threshold**: The finding is a cosmetic suggestion with truly negligible impact AND no pattern of inconsistency. A naming or style issue that contradicts an established convention in the same codebase is NOT sub-threshold — consistency matters.
- **Harmful**: The suggested action would degrade the code or introduce a bug.

**Scope is NOT a factor in the TP/FP decision.** A finding about pre-existing code, code outside the diff, or code in untouched files can still be TP if it is factually correct, relevant, and non-trivial. Classify scope separately using the Scope axis below.

**Important: Do NOT classify a finding as FP just because a similar concern was raised in another finding on this PR.** Evaluate each finding independently on its own merit. Deduplication is handled separately at scoring time.

### Calibration examples: low-severity but useful findings

Use these examples to distinguish low-impact helpful review from personal preference:
- A naming suggestion is TP when it identifies a concrete inconsistency with local naming/casing conventions in the changed code. For example, if nearby Google Pay identifiers consistently use \`GooglePay\`, a new \`Googlepay\` or \`GooglepayComponent\` spelling is not merely preference; it is a convention violation. Assign low severity unless behavior is affected.
- A style or readability suggestion is TP when it points to a specific code pattern that is redundant, misleading, or inconsistent with surrounding code. Do not reject it solely because it is small or phrased tersely.
- A documentation/comment suggestion is TP when it identifies stale, misleading, duplicative, or missing information in changed docs or JSDoc. Do not require it to be merge-blocking.
- A broad preference such as "I like this name better" is FP unless there is a concrete local convention, ambiguity, typo, or reader-facing confusion.
- A simplification/removal suggestion is TP only if the suggested simplification preserves the exact behavior and data shape needed by downstream code. If the current code intentionally normalizes a union of action shapes, introduces a sentinel value, or creates a payload object that later code reads, do not call it unnecessary unless you verify the downstream reads still work.
- A suggestion to replace a strict sentinel check such as \`value === ""\` with a truthy/falsy check is FP when it is only cosmetically equivalent and does not fix a bug, reduce a real drift risk, or match a clear local convention.

### Security findings: apply extra scrutiny

Security findings have a high base rate of false positives from automated tools. Apply extra scrutiny:
- **Generic warnings** that restate a best practice without demonstrating a concrete, exploitable vulnerability are FP. This includes action-pinning alerts ("pin to a SHA"), mutable-tag warnings, and boilerplate sanitization advice — even when they name the specific action or variable. Naming the target does not make a template alert code-specific.
- A security finding is TP only when it identifies a **concrete, exploitable vulnerability** in the actual code — a specific data flow from untrusted input to a dangerous sink, a hardcoded secret with its actual value, an authentication bypass with a demonstrated path, unsafe deserialization of user-controlled input, etc.
- The test: does the finding demonstrate *how* the issue could be exploited in this specific codebase, or does it just assert that a general class of risk exists? The former is TP; the latter is FP.

## Severity

Rate the impact of the issue identified by the finding, assuming it is a TP. Consider the potential harm if the issue were left unaddressed, as well as the value of fixing it. Use these guidelines:
- **high**: An issue that must be addressed.
- **medium**: An issue that should be addressed.
- **low**: A minor issue that can safely be ignored or deferred.

### Severity calibration examples

- User-facing checkout, payment, authentication, order creation, data loss, or data integrity bugs should usually be **high** when they can report success before the operation actually succeeds, mask failures, corrupt state, charge or fail to charge users incorrectly, or leave users unable to complete the primary workflow.
- Conflicting configuration defaults should usually be **medium** when a fallback can silently select the wrong environment, endpoint, feature mode, or provider. Escalate to **high** if the wrong default can affect money movement, security, or production data.
- Duplicated domain-specific mapping or adapter-selection logic should usually be **medium** when the duplication creates realistic drift risk across user-facing flows. Keep it **low** only when the duplicated logic is trivial, purely local, and unlikely to diverge.
- Pure naming, formatting, spelling, and comment cleanup remains **low** unless it causes ambiguity in public APIs, generated artifacts, configuration, or runtime behavior.

Assign severity to ALL findings, including FPs. A finding can be an FP with high severity (e.g., an incorrect claim about a security vulnerability).

## Category

Assign exactly one primary category:
- **correctness**: Logic errors, bugs, wrong behavior, incorrect computations, behavior that contradicts documented or described intent
- **security**: Vulnerabilities, broken access control, injection, insecure design, authentication/authorization failures, cryptographic misuse, software supply chain risks, data exposure
- **reliability**: Error handling, concurrency, fault tolerance, graceful degradation, operational concerns, dependency management, build configuration, CI/CD issues
- **maintainability**: Readability, naming, code structure, DRY violations, complexity, style, formatting, codebase conventions, spelling, best practices
- **testing**: Test correctness, missing test cases, test design, flaky tests, test coverage gaps, validation logic
- **documentation**: Comments, docstrings, README, API docs, inline documentation, developer experience
- **performance**: Unnecessary computation, memory leaks, inefficient algorithms, N+1 queries, scalability concerns
- **api-architecture**: API contracts, function signatures, type design, public interface concerns, architectural decisions, module boundaries
- **accessibility**: UI/UX accessibility (a11y), internationalization, inclusive design, professionalism concerns
- **other**: Use ONLY when the finding genuinely does not fit any of the above categories. This should be extremely rare — if in doubt, pick the closest match above.

## Scope

Classify the issue's relationship to the PR:
- **introduced-by-pr**: The issue was introduced by the changes in this PR
- **exacerbated-by-pr**: The issue existed before but is made worse by this PR
- **pre-existing**: The issue existed before and is not affected by this PR
- **unrelated**: The issue is unrelated to the PR's changes

## Difficulty

Would a competent author reasonably notice and address this without prompting?
- **easy**: Obvious from a careful reading of the diff
- **medium**: Requires some thought or knowledge of the codebase
- **hard**: Requires deep expertise, cross-file analysis, or non-obvious reasoning

## Context Required

What context is needed to verify the finding?
- **diff-only**: The finding can be verified from the PR diff alone
- **diff-plus-related-files**: Requires the diff plus immediately related files (imports, types, etc.)
- **broader-project-context**: Requires broader project knowledge (architecture, conventions, deployment, etc.)

## Output Format

After investigating with tools, respond with a JSON object (no markdown fencing, no extra text before or after):

{
  "tp_fp": "tp" | "fp",
  "tp_fp_justification": "Brief explanation of the TP/FP decision, citing what you verified",
  "severity": "high" | "medium" | "low",
  "severity_justification": "Brief explanation of severity",
  "category": "<one of the categories above>",
  "category_justification": "Brief explanation of category choice",
  "scope": "introduced-by-pr" | "exacerbated-by-pr" | "pre-existing" | "unrelated",
  "difficulty": "easy" | "medium" | "hard",
  "context_required": "diff-only" | "diff-plus-related-files" | "broader-project-context"
}`;

/**
 * Build the initial session setup message that provides PR context.
 * This is sent once at the start of the session before any findings.
 */
export function buildSessionSetupMessage(args: {
  nwo: string;
  prUrl: string;
  prTitle: string;
  prBody: string;
  diff: string;
  headSha: string;
  findingCount: number;
}): string {
  // Truncate diff if extremely large to fit in context
  const maxDiffLength = 100_000;
  const diff = args.diff.length > maxDiffLength
    ? args.diff.slice(0, maxDiffLength) + "\n\n... [diff truncated, use tools to read full files] ..."
    : args.diff;

  return `## PR Context

**Repository:** ${args.nwo}
**URL:** ${args.prUrl}
**SHA:** ${args.headSha}
**Title:** ${args.prTitle}

**Description:**
${args.prBody || "(no description)"}

## Diff

\`\`\`diff
${diff}
\`\`\`

---

I have ${args.findingCount} finding(s) to classify on this PR. Please orient yourself to the change — read relevant files as needed to understand the context — then let me know when you're ready and I'll send the first finding.`;
}

/**
 * Build the user message for classifying a single finding within a session.
 */
export function buildClassifierUserMessage(args: {
  filePath: string;
  startLine: number;
  endLine: number;
  message: string;
  index: number;
  total: number;
  diffHunk?: string;
  /** @deprecated Use startLine/endLine instead */
  diffLine?: string;
  line?: number | null;
  originalLine?: number | null;
}): string {
  return `## Finding ${args.index}/${args.total}

${renderClassifierFinding({
  file: args.filePath,
  start_line: args.startLine,
  end_line: args.endLine,
  message: args.message,
  diff_hunk: args.diffHunk,
  line: args.line,
  original_line: args.originalLine,
})}

---

Classify this finding. Use tools to verify the claim if needed. After your investigation, you MUST end your response with EXACTLY a JSON object in this format — no text after it:

{"tp_fp": "...", "tp_fp_justification": "...", "severity": "...", "severity_justification": "...", "category": "...", "category_justification": "...", "scope": "...", "difficulty": "...", "context_required": "..."}`;
}