pub struct Policy {
pub auto_apply_enabled: bool,
pub auto_apply: Vec<AutoApplyGrant>,
pub deny: Vec<String>,
pub severity_floors: BTreeMap<String, Severity>,
pub telemetry: TelemetryMode,
}Expand description
The parsed host policy. Everything default-closed.
Fields§
§auto_apply_enabled: boolMaster opt-in (same posture as allow_destructive_ops: default off).
Auto-apply never fires unless this is true AND a grant matches.
auto_apply: Vec<AutoApplyGrant>Auto-apply grants (default: none).
deny: Vec<String>Analyzer families the host disables entirely.
severity_floors: BTreeMap<String, Severity>Per-analyzer severity floors (family → floor); combined with the file’s floors by taking the stricter of the two.
telemetry: TelemetryModeImplementations§
Source§impl Policy
impl Policy
Sourcepub fn from_json(s: &str) -> Result<Self>
pub fn from_json(s: &str) -> Result<Self>
Parse a policy JSON string. Unknown keys are rejected (fail-closed).
Sourcepub fn severity_floor(&self, family: &str) -> Option<Severity>
pub fn severity_floor(&self, family: &str) -> Option<Severity>
The host severity floor for a family, if any.
Sourcepub fn grants_auto_apply(
&self,
family: &str,
target_class: &str,
severity: Severity,
) -> bool
pub fn grants_auto_apply( &self, family: &str, target_class: &str, severity: Severity, ) -> bool
Does a grant permit auto-applying this family to target_class at
severity? Only the memory class is ever eligible.
query was eligible until definition rewrites became executable
(issue #28). A grain edit changes one remembered value; a saved-query
or template rewrite changes what EVERY future context contains — the
blast radius is every turn from now on, not one fact. So a definition
rewrite always requires a human APPROVE + APPLY with BECAUSE, and
the class is excluded here by name, exactly as code/evalset are.