Per-cut-class arming ladder: arm the surgical edge-cut before the quarantines (ADR-0035)

[thejefflarson]

Summary

Closes JEF-671. Implements ADR-0035: splits network-class arming under mode: enforce
into an ORDERED LADDER instead of a single flip that armed all three network cuts
(surgical DenyNetworkPath edge-cut + QuarantineEntry + QuarantineWorkload) at once.

• Rung 1 — edge-cut (the enforce default): arms only the surgical,
  most-reversible DenyNetworkPath cut. The quarantines stay propose-only.
• Rung 2 — quarantine: an explicit second opt-in that also arms
  QuarantineEntry/QuarantineWorkload — implying the edge-cut rung, never replacing it.
  One ordered position, not independent per-cut toggles (preserves ADR-0021's anti-drift
  intent).
• enforceScope (the where dial) and mode (the shadow-vs-act gate) are unchanged.
• audit still arms nothing — byte-identical shadow default, empty-scope-refused
  preserved.

Design

• New module engine/src/engine/respond/actuator/arming_ladder.rs — a small,
  single-purpose module (not bolted onto the already-large respond/mod.rs). Defines
  ArmingRung { EdgeCut, Quarantine } and ArmingRung::enabled_actions() -> EnabledActions.
  EnabledActions itself is untouched — it stays the pure armed-classes type, exactly per
  the ADR's implementation note.
• engine/src/main.rs: Posture gains a rung: ArmingRung field, parsed from the new
  PROTECTOR_ENFORCE_RUNG env var (default edge-cut, unrecognized values fall back to
  the narrowest/safest rung). engine_arming() now delegates to self.rung.enabled_actions()
  instead of hand-enabling all three classes.
• engine/src/engine/respond/actuator/mod.rs: unchanged behaviorally — only a pub mod arming_ladder; declaration and a doc-comment cross-reference clarifying that
  actions_from_name/EnabledActions::from_names (the generic "network" name → all
  three actions grouping) is a test convenience, distinct from the production
  arming ladder.

Chart (hand-port needed — the deployed cluster chart is a fork)

charts/protector/values.yaml gains enforceRung: edge-cut (documented alongside
enforceScope); templates/deployment.yaml wires PROTECTOR_ENFORCE_RUNG and adds a
helm-side validation mirroring the existing mode guard; templates/NOTES.txt and
README.md are updated to describe the ladder instead of "arms all three surfaces".

The ../cluster/charts/protector chart is a diverged fork (per prior team notes) —
only the image tag auto-bumps there; everything else (including this new enforceRung
value + its env wiring + the helm validation) needs a manual hand-port before any
cluster actually escalates past the edge-cut rung. Until that port lands, the fork simply
has no enforceRung key, so any mode: enforce install through it stays on whatever the
engine's built-in default resolves to (edge-cut — safe, narrowest).

Tests

engine/src/engine/respond/actuator/arming_ladder.rs (new, unit tests in-module):

• edge_cut_is_the_default_and_arms_only_the_surgical_cut
• quarantine_rung_implies_the_edge_cut_and_adds_both_quarantines
• unknown_or_empty_names_fall_back_to_the_narrowest_rung
• neither_rung_arms_a_non_network_action_class

engine/src/main.rs (Posture/engine_arming tests, extended):

• audit_arms_nothing_even_at_the_quarantine_rung
• enforce_narrowest_rung_arms_only_the_edge_cut
• enforce_quarantine_rung_adds_both_quarantines_and_still_implies_the_edge_cut
• enforce_rung_env_var_selects_the_ladder_position (env-var parsing, default + explicit)
• existing audit_posture_is_the_safe_default_everywhere / enforce_posture_arms_all_surfaces_in_exactly_the_scope
  / labels_behave_like_namespaces / webhook_and_engine_share_one_scope /
  enforce_with_empty_scope_is_refused all still pass unchanged (they exercise the
  edge-cut default, which the ladder preserves byte-for-byte).

How I tested

• npm --prefix engine/web run build — green (needed npm install first; ran clean).
• cargo fmt — clean.
• cargo clippy --all-targets -- -D warnings — clean, zero warnings.
• cargo nextest run --workspace — 1105/1105 passed (2 skipped, pre-existing),
  including the file-size guard test.
• helm lint charts/protector — clean.
• helm template smoke tests: rendered PROTECTOR_ENFORCE_RUNG=quarantine correctly;
  confirmed helm template --set enforceRung=bogus fails fast with a clear error; helm install --dry-run NOTES.txt shows ARMED at rung 'quarantine'.
• Ran /soundcheck:pr-review (single-pass) on the diff manually — no Critical/High
  findings; this is a config-gating/enum-mapping change with no new injection, secrets,
  auth, or access-control surface.
• Ran a manual /simplify pass (Agent tool unavailable in this context) — added one
  clarifying doc cross-reference between the new production ladder and the pre-existing
  generic actions_from_name test helper so future readers don't conflate the two
  "network arms 3 classes" representations; decided not to collapse them into one
  source of truth, since that would either wire production arming through a
  string-parsing test API or require exposing new crate-internal surface beyond this
  ticket's scope.

Scope / risks

• Does not touch shadow-default, enforceScope semantics, RBAC derivation, or the
  actuation/revert mechanics — only the arming-class granularity under enforce, per the
  ticket's explicit constraint.
• No new PROTECTOR_*_ENABLE toggle — PROTECTOR_ENFORCE_RUNG is a rung on the single
  enforcement gate (mode: enforce), not a detection toggle (CLAUDE.md's two-gate rule).
• Two sibling tickets (disarm/kill-switch; judge-freshness gate) are touching adjacent
  enforcement code in parallel — this PR only edits engine/src/main.rs's Posture/
  engine_arming, the new arming_ladder.rs module, actuator/mod.rs's module
  declaration + one doc comment, the ADR status flip, and chart/docs — no other files.
• Cluster-chart hand-port required (flagged above) before any cluster can actually
  escalate to the quarantine rung via the fork; until then it's inert (defaults safe).

🤖 Generated with Claude Code

https://claude.ai/code/session_01VtjoJttCvBY4dzCoE4f9vP