Derives the effective status of one shipped rule under the built-in default policy and an
optional YAML config file. This is the core data layer for the future
deltascope config status <rule-id> CLI command.
Files
File
Responsibility
status.go
Inspect derives ON/OFF, Loaded, effective level, default vs current snapshots, config effect, and FK-forbid suppression for one rule
Suppression — { Reason, By } for enabled Default Policy rules that are not Loaded
Inspect(ctx, Request) (Result, error)
What it does
Reads the built-in default policy (policy.Default) and the rule catalog
(catalog.Lookup). Catalog-only opt-in rules are inspectable as default-disabled
even when Default Policy does not include them.
Loads the effective policy via the existing viperconfig.LoadPolicy when a config path
is supplied, and uses its output verbatim as the "current" snapshot.
Compares default versus current enabled, level, and params, producing deterministic
ChangedFields (enabled, level, then params.<key> alphabetically) and messages.
Validates the config with the same semantics as deltascope config lint (unknown rule,
invalid level, unknown param, param type mismatch) so malformed configs error instead of
producing partial status.
Clones all params maps before returning; it never mutates the default or effective policy.
Reports status.loaded separately from status.enabled. Under the shipped baseline the three
ddl.constraint.foreign_key.name.* rules stay enabled and are not Loaded; suppression.reason
is fk_forbid. Catalog-only dml.impact.* rules are inspectable as default-disabled without
a suppression.
What it does not do
It does not run an audit.
It does not parse SQL.
It does not connect to a database.
It does not add a severity field; the public priority field is level.
It does not modify viperconfig.LoadPolicy or audit behavior.
The "current" snapshot matches what the audit path actually applies. Mentioning a rule in
YAML replaces its entire RulePolicy; fields the file omits become zero values
(enabled -> false, level -> "", params -> empty). Therefore a partial override
such as level: warning alone leaves the rule OFF, because enabled is omitted and
replaced with false. Inspect surfaces this with explicit omitted-field warnings rather
than hiding it. Whether LoadPolicy should adopt merge semantics is a separate decision
and is intentionally out of scope here. See
docs/decisions/2026-06-14-v0.310.0-rule-config-status.md.
Dependencies
Upstream: (none yet; the CLI config status command in Task 3 will call Inspect)
Package configstatus derives the effective status of one shipped rule under the
default policy and an optional YAML config file.
input: a rule ID, an optional config path, built-in default policy, the rule catalog,
and the existing Viper-backed policy loader
output: a stable Result describing whether the rule is ON or OFF, whether it is Loaded,
its effective level, default versus current policy snapshot, FK-forbid suppression,
and what the user's config changed
pos: application use case for single-rule config status, below the CLI surface
note: if this file changes, update this header and module README.md.
Inspect derives the effective status of one shipped rule under the default policy
and an optional YAML config file. It does not run an audit, parse SQL, or touch a
database. ctx is reserved for future cancellation and is currently unused.
type RuleStatus struct {
Enabled bool `json:"enabled"`
Level rule.Level `json:"level"`
State string `json:"state"`
Loaded bool `json:"loaded"`
}
RuleStatus reports the effective runtime state of the rule.
Enabled/State follow Default Policy (or the caller's config). Loaded is the
distinct registration fact: a rule can be enabled and still not Loaded.