Documentation
¶
Overview ¶
Package validateresult defines the JSON payload shape and shared constants used by the SQL validation surfaces (the `crdb-sql validate` CLI command and the `validate_sql` MCP tool). Centralizing these symbols lets the two surfaces emit the same envelope so agents can rely on a single contract — adding a new validation phase means editing one place, not two.
The package has a single inbound dependency (internal/output) and no transitive deps on cmd or MCP code, so either surface can import it without pulling in the other.
Index ¶
Constants ¶
const CapabilityNameResolution = "name_resolution"
CapabilityNameResolution is the canonical short identifier of the table-name-resolution phase, embedded both in the warning's Context and in the Checks field name so the two cannot drift.
const CapabilityRequiredCode = "capability_required"
CapabilityRequiredCode is the envelope error Code (and Category) for a skipped validation phase. Reusing one constant for both fields — rather than defining two separate constants with the same literal — makes drift impossible.
Variables ¶
This section is empty.
Functions ¶
func CapabilityRequiredError ¶
CapabilityRequiredError builds the warning entry that signals a validation phase was skipped because its prerequisite is missing. capability is the short identifier of the skipped phase (e.g. CapabilityNameResolution); message is the user-facing summary; hint tells the user how to enable the phase. The result is appended to the envelope's Errors list rather than aborting the request — the CLI exit code stays 0 (or the MCP tool result stays successful) because the phases that did run all passed.
Types ¶
type CheckStatus ¶
type CheckStatus string
CheckStatus is the per-phase outcome reported in Checks. Defined as a named string so call sites get compile-time checking against the closed set of legal values — bare strings would let a typo like "okay" reach the wire. JSON marshaling is unchanged.
const ( CheckOK CheckStatus = "ok" CheckSkipped CheckStatus = "skipped" CheckFailed CheckStatus = "failed" )
CheckStatus values. CheckOK means the phase ran and produced no errors; CheckSkipped means its prerequisite (typically --schema or the schemas MCP argument) was missing; CheckFailed means the phase ran but produced one or more errors. The failure path emits Checks alongside Errors so consumers can attribute errors to phases and see which downstream phases (if any) were skipped because an upstream phase could not produce usable input.
type Checks ¶
type Checks struct {
Syntax CheckStatus `json:"syntax"`
FunctionResolution CheckStatus `json:"function_resolution"`
TypeCheck CheckStatus `json:"type_check"`
NameResolution CheckStatus `json:"name_resolution"`
}
Checks records the per-phase outcome for a validation run. Each field is CheckOK, CheckSkipped, or CheckFailed. Both the success and failure paths populate this struct so agents always learn which phases ran. Adding a phase means adding a field here and updating both surfaces (CLI and MCP) on each path (success and failure) — four rendering sites total. Field declaration order matches the phase-execution order in semcheck.Run (and the prose order in its doc comment): syntax, then function-name resolution, then expression type-checking, then table/column name resolution. Keeping the two in lockstep means a reader can use either source as the authoritative ordering and the JSON envelope renders fields in execution order, which makes failure paths easier to scan.
Source Files