feat: add drop-in replacement fix field to lint output

[ayo6706]

This PR introduces a new fix field to the lint output across all JSON-based formatters. While the existing suggestion field provides a human-readable instruction (e.g., "Replace 'leverage' with 'use'"), the new fix field contains the literal corrected text (e.g., "use") that can be used as a direct drop-in replacement for the identified violation.

This enables downstream consumers (like IDE extensions or automated refactoring scripts) to apply corrections programmatically without parsing the natural language suggestion.

Example Output

{
  "line": 5,
  "column": 12,
  "severity": "warning",
  "message": "AI buzzword detected",
  "rule": "StyleGuide.Clarity",
  "match": "leverage our synergies",
  "suggestion": "Replace with simpler language",
  "fix": "use our combined strengths"
}

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

## Summary by CodeRabbit

## Release Notes

* **New Features**
  * Added optional fix suggestions for detected violations and issues. Fix fields now appear in reporting outputs and scoring results, providing corrected replacement text that can be directly applied to resolve issues.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR extends type definitions and LLM schemas across the codebase to support an optional fix field for carrying corrected replacement text or fix suggestions through violation reporting, scoring, and JSON output generation without altering existing control flow.

Changes

Cohort / File(s)	Summary
Type Definitions src/cli/types.ts, src/output/json-formatter.ts	Added optional fix?: string field to ReportIssueParams, violation objects within ProcessViolationsParams, and the Issue interface for JSON serialization.
Schema & Prompts src/prompts/schema.ts, src/prompts/directive-loader.ts	Extended LLM schemas (buildJudgeLLMSchema, buildCheckLLMSchema) and result types (JudgeLLMResult, CheckLLMResult, JudgeResult, CheckItem, CheckResult) to include fix: string; added directive documentation describing the fix field as corrected replacement text.
Processing & Scoring src/cli/orchestrator.ts, src/scoring/scorer.ts	Updated violation processing to propagate the fix field through reportIssue calls and JSON emission; modified calculateCheckScore and averageJudgeScores to include and aggregate fix values in violation objects.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 With whiskers twitched, I've added fix,
A field to aid the developer's mix,
Through schemas deep and scores so bright,
Corrections flow—now that's just right! ✨
No warning bare, but wisdom true,
The perfect patch awaits in queue!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a 'fix' field to lint output for drop-in replacement text. It is concise, specific, and directly relates to the primary purpose of the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ft/fix

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/cli/orchestrator.ts (1)

401-409: ⚠️ Potential issue | 🟡 Minor

Type assertion is missing the new fix field.

The explicit as Array<{...}> cast here omits fix, even though the source type (JudgeResult.criteria[].violations[]) now carries fix: string. While this works at runtime (the property is still present on the object), the cast is stale after this PR's changes. It should include fix for completeness and to avoid confusion for future maintainers.

Proposed fix

       const violationResult = locateAndReportViolations({
         violations: violations as Array<{
           line?: number;
           quoted_text?: string;
           context_before?: string;
           context_after?: string;
           analysis?: string;
           suggestion?: string;
+          fix?: string;
         }>,

🧹 Nitpick comments (2)

src/scoring/scorer.ts (1)

56-64: Truthiness check silently drops empty-string fix values.

item.fix && { fix: item.fix } (line 59) filters out "", which is the same pattern used for suggestion (line 58). Since the LLM schema marks fix as required, the LLM may return fix: "" for violations with no applicable replacement. This is likely acceptable (no meaningful fix to propagate), but note that the judge path in averageJudgeScores (line 221) preserves empty strings via v.fix || "". If you want consistent behavior, consider using item.fix !== undefined instead.

src/cli/orchestrator.ts (1)

108-141: Inconsistent empty-string handling between ValeJson and Json/RdJson for fix (and suggestion).

Line 119 uses fix !== undefined (includes empty strings), while line 138 uses truthiness fix ? ... (excludes empty strings). This mirrors the existing suggestion handling on lines 118 vs 137, so this is a pre-existing inconsistency. Just calling it out for awareness — if a downstream consumer of the Json/RdJson format relies on seeing fix: "" to distinguish "no fix available" from "fix field absent," it would be silently dropped.

[oshorefueled]

 "rule": "StyleGuide.Clarity",

Does VectorLint have a rule called StyleGuide, or is this from the user instructions?

[ayo6706]

 "rule": "StyleGuide.Clarity",

Does VectorLint have a rule called StyleGuide, or is this from the user instructions?

That’s just a content example not the actual test data from vectorlint