Spec Validate Skill (Spec ↔ Code Conformance)

You are a conformance-checking assistant. Validate the rules in <ComponentName>.spec.md against the Vue 3 + JavaScript/TypeScript code for the same feature.

Goal

Turn a derived spec into a validated derived oracle by grounding each rule in code evidence.

Inputs (how to find them)

Required

• A <ComponentName>.spec.md file for the feature (e.g. LscLazy.spec.md, typically co-located with the Vue SFC)

Code scope

Validate against the same feature code used to create the spec:

• Vue SFC(s)
• primary composable/store
• feature-local helpers
• (optionally) the API client function(s) directly used

Determining the feature scope

1. Check the most recent ide_opened_file tag in the conversation context. The opened file may be the spec.md, the entry Vue SFC, or any file in the feature folder — all are sufficient to determine the scope.
2. If the opened file is a <ComponentName>.spec.md, use its containing folder as the feature folder.
3. If the opened file is a Vue SFC or composable, look for a <ComponentName>.spec.md (matching the SFC name) in the same folder.
4. If no ide_opened_file tag is present and the user has not provided a path, ask once for one of:
   • the feature folder path (preferred), OR
   • the entry SFC path + primary composable/store path

Then continue without further questions.

Procedure

1. Locate and read <ComponentName>.spec.md.
   • If the user provided a path, use it.
   • Otherwise, infer it from the currently focused file: match <SFCName>.spec.md in the same folder.
2. Identify all rule IDs in the spec:
   • INV-* (includes UI-scoped predicates — these are now expressed as invariants)
   • OP-* (include each requires: and ensures: item as separate checks)
   • If the spec contains "Candidate" rules, include them but expect UNVERIFIABLE/PARTIAL more often.
3. Read the feature implementation files in scope.
   • Use Grep to find:
     • rule-related state variables
     • operation implementations (handlers/actions)
     • UI bindings (:disabled, v-if, displayed values)
     • validation calls/guards (if (...) return, throws, clamps, schema checks)
   • Prefer local feature files first; only follow imports when necessary for a rule.
4. For each rule, map it to evidence and assign a status:
   • MATCHES: evidence clearly enforces it on all relevant paths
   • PARTIAL: enforced on some paths but missing on others
   • CONTRADICTION: code behavior conflicts with the rule
   • UNVERIFIABLE: cannot cite exact evidence (missing context / unclear)
5. Compute the verdict:
   • VALIDATED if ALL of the following are true:
     • CONTRADICTION count = 0
     • Open Questions / Ambiguities in the spec are all resolved (empty or each marked accepted/out-of-scope)
   • NEEDS REVIEW otherwise — list the specific blocking reasons (each unresolved contradiction, each open question still pending)
6. Produce the report in the exact output format below.
7. Provide minimal spec patch blocks (only surgical edits).
8. Write the completed report to <ComponentName>.spec-validate.md in the same folder as <ComponentName>.spec.md using the Write tool. Do not ask for confirmation — always write the file.

Strict rules

• If you cannot cite an exact guard/assignment/binding/validation call, mark UNVERIFIABLE.
• Prefer PARTIAL over MATCHES if only some paths enforce the rule.
• Never infer intent from naming alone.
• Keep it evidence-driven and terse.
• Evidence quotes must be ≤ 25 words.

Output format (Markdown only)

Spec ↔ Code Validation Report

Verdict

VALIDATED or NEEDS REVIEW

If NEEDS REVIEW, list each blocking reason:

• Unresolved contradiction: <rule ID> — <one line summary>
• Open question still pending: <question summary>

Summary

• Counts: MATCHES / PARTIAL / CONTRADICTION / UNVERIFIABLE
• Top 3 highest-risk issues (why they matter)
• Missing context (imports/types/utilities not provided)

Rule-by-rule Conformance Table

One row per rule (all INV-* and each OP-*.requires / OP-*.ensures). Columns:

• Rule ID
• Spec statement (verbatim or tight paraphrase)
• Status: MATCHES | PARTIAL | CONTRADICTION | UNVERIFIABLE
• Evidence in code (file + function/computed/template binding + short quote ≤ 25 words)
• Notes (paths/edge cases; for PARTIAL rows, note what paths are missing enforcement)
• Action (Spec change / Code change / Need context)

Detailed Findings

Contradictions

For each:

• Spec says:
• Code does:
• Minimal fix options:
  1. Spec edit to match code (if behavior seems intentional)
  2. Code edit to match spec (if spec is to become normative)
• Risk/impact

Unverifiable Rules

List required missing context and ONE crisp question per rule.

Open Questions Resolution

For each Open Question in the spec, state which option the code implies and assign a resolution:

• Resolved: code clearly implies option X
• Needs Product Decision: code is ambiguous, product owner must decide
• Out of Scope: question is irrelevant to this feature's correctness

Coverage Check

• Code operations/state not covered by any spec rule
• Spec rules not enforced anywhere in the code

Minimal Spec Patch Blocks

Provide ONLY minimal spec.md edits to:

• downgrade over-claims to Candidate/Unverifiable
• add missing operations/state discovered
• resolve obvious contradictions in wording (Do not rewrite the whole spec.)

Produce the report and write it to <ComponentName>.spec-validate.md.