jungho-git/validate

Validate

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

---

Scope

Use this rule when:

• code has been edited
• config, hooks, scripts, generated artifacts, schemas, migrations, or contracts changed
• a fix needs confirmation on the original failing path
• a review finding needs proof that the proposed behavior now holds

Validation should be scoped, evidence-based, and matched to the changed surface and its real execution path.

---

Validation Order

• identify the changed surface and expected behavior
• validate parser, syntax, or static contract safety first when relevant
• validate the directly changed unit, command, route, mapper, script, hook, or config
• validate the original failing path when fixing a bug
• validate coupled callers, generated artifacts, schemas, migrations, API contracts, or jobs when risk is real
• validate data, permission, transaction, concurrency, timezone, encoding, and rollback paths when touched
• report what remains unverified and why

---

Validation Depth

• Use the smallest command that proves the changed behavior.
• Prefer targeted tests over full suites when they cover the changed path.
• Run broader suites when the change touches shared contracts, framework glue, persistence, security, build config, or generated outputs.
• For database changes, validate DDL parseability, migration order, rollback assumptions, mapper/query compatibility, constraints, indexes, nullability, default values, and representative read/write paths when available.
• For API or event changes, validate producers, consumers, serialization, versioning, backward compatibility, and error payloads.
• For UI changes, validate build/type safety and at least one real render or interaction path when the runtime is available.
• For scripts and tools, execute the real script with safe representative input and inspect the output artifact.

---

Evidence Levels

• ran and passed: command executed successfully and output supports the claim.
• ran and failed: command executed and exposed a failing result; include the first useful failure.
• checked by inspection: source, schema, config, or artifact was read directly without executing.
• not run: validation was intentionally skipped; include the boundary reason.
• could not run: validation was attempted or required but blocked; include the blocker.

---

Preferred Validation Types

• parser or syntax checks
• lint or type checks on the smallest sufficient target
• focused unit, mapper, integration, migration, or contract tests
• bounded end-to-end commands for changed user flows
• direct script execution with safe inputs
• database migration dry-runs or schema checks when supported
• generated artifact regeneration or stale-artifact checks when generation is part of the contract

---

Practical Rules

• Prefer real commands over assumption-only claims.
• Keep validation proportional to the changed surface and risk.
• Derive the validation path from observed code, config, tests, logs, DDL, callers, and documented commands.
• Do not substitute new mock tests for understanding a real file or runtime path.
• If full execution is not available, state exactly what was checked by inspection.
• Distinguish not run, could not run, checked by inspection, ran and failed, and ran and passed.
• Report command names and meaningful results, not raw noise.
• When validation fails, stop claiming success, summarize the first actionable failure, and identify the next check or fix.
• When validation passes but coverage is partial, state the remaining gap concretely.

---

Output Shape

• checks actually run or inspected
• result for each check
• behavior or contract proven by each check
• unverified gaps and blockers
• residual risk when validation is partial

---

Boundaries

• Do not claim coverage you did not execute or inspect.
• Do not skip validation because the change looks small.
• Do not run destructive verification unless the task explicitly requires it.
• Do not run production-impacting commands without explicit user direction and a bounded plan.