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.