Skip to main content

clamp_project_permissions

Function clamp_project_permissions 

Source
pub fn clamp_project_permissions(
    base: &HarnessConfig,
    sanitized_project: &HarnessConfig,
    merged: &mut HarnessConfig,
) -> Vec<String>
Expand description

§3.3’s monotonic clamp, applied specifically at the project-layer merge (not the general HarnessConfig::overlay, which is also used for the preset chain and the user layer — a user’s OWN config extending a preset and then setting a looser value is fine; only the UNTRUSTED project layer is clamped). Mirrors userconfig.rs’s clamp_sandbox/clamp_approval (F2/F3 fix precedent): even a project value that survived sanitize_for_project (because it isn’t the single GLOBAL loosest value) must still be no looser than the base layer’s OWN effective posture — e.g. a project setting workspace_write when the base layer has read_only is a real widening and must be clamped back.

pub (P5-10): also called directly by crates/cli/src/userconfig.rs’s overlay_project (via a throwaway HarnessConfig wrapping just the capabilities map, the same core_probe trick sanitized_for_project’s own doc comment already uses for [core]) so the CLI’s plain .supercode.toml route gets the SAME escalation/ env_policy relative-rank clamp as the SDK’s HarnessConfig resolver, rather than a second, potentially-drifting reimplementation.