feat(config): delete_with_cascade for channels (#7175)

[Nillth]

📋 Stacked series — 5 of 8

Typed delete-with-cascade (#7175) + alias rename (#7468), sliced for review. Opened as draft for CI; merge strictly in order. While the PRs ahead are unmerged this diff is cumulative — it includes the un-merged slices below and collapses to its own delta once they land.

Sequence: 1 #7785 ✅ · 2 #7830 ✅ · 3 #7837 · 4 #7838 · 5 #7839 ← this PR · 6 #7840 · 7 #7841 · 8 #7842

This slice (own delta): crates/zeroclaw-config/src/alias_refs.rs only — +298 / −29. Cumulative shown until #3–#4 merge: 14 files, +1294 / −76.

Summary

Adds the channel arm of delete_with_cascade, completing the provider/agent/channel trio. For channels.<type>.<alias> it refuses on HARD refs, otherwise scrubs the SOFT refs, removes the entry via the same generic delete_map_key("channels.<type>", alias) the gateway/CLI use, and re-checks no dangling reference remains. DryRun mutates nothing.

• SOFT (scrubbed): every agent's channels[] and escalation.alert_channels[] entry naming the target (retain, trimmed to mirror find_all_references + validate()).
• HARD (refused), two classes — both mirror Config::validate():
  1. a mandatory dotted peer_groups.<g>.channel naming the target;
  2. a member of a bare-type group (channel = "discord") whose only <type>.* channel is the target — scrubbing it would leave that member without a required channel.
• No owned non-config state: channels have no memory/workspace/cron/session rows, so this is the full cascade for the kind — no surface-side half.

Review: 1 blocker found + fixed

Bare-type peer-group member orphaning. validate() enforces three channel sites, not two: besides agents.<X>.channels[] (soft) and peer_groups.<g>.channel (hard), every member of a bare-type group must keep some <type>.* channel. The first cut enumerated only the first two — so deleting a member's only discord.* channel returned Ok but produced a config that validate() rejects. Fixed: collect_channel_refs now emits a HARD ref at peer_groups.<g>.agents[i] when scrubbing would orphan a bare-group member; the survivor test mirrors validate()'s untrimmed bare-membership comparison exactly. (This guard was subsequently lifted into the #7785 foundation during its review; retained here so the channel arm is self-contained.)

Validation

cargo clippy --workspace --all-targets + cargo fmt --all --check clean at the stack tip. Channel test matrix: scrub-soft+remove · refuse-on-peer-group-channel · refuse-on-orphaning-bare-member · proceed-when-member-keeps-another · dry-run · not-found. Full CI runs on this draft. Pure library arm (no new surface) — exercised through the handle_delete_map_key route /verify'd in slice 4.

Security & Privacy — no new fs/network/permissions/secrets; pure in-memory config mutation; synthetic-alias tests.

Compatibility — backward compatible; adds a delete arm that previously returned NotImplemented. No surface change.

Rollback (risk: low) — git revert <sha>; no migration; no persisted-state effect.

Related #7175.

[singlerider]

I reviewed slice 5 on its own delta (0568269), ignoring the cumulative ancestors. I read the new delete_channel / scrub_channel_refs arm and collect_channel_refs, and cross-checked the HARD detection against Config::validate()'s channel sites in schema.rs. I confirmed the channel suite green locally (cargo test -p zeroclaw-config cascade_channel 6/6, full alias_refs 35/35, clippy clean). This is a clean library arm with the subtle validate-mirroring done correctly. Approving on merits.

This stays draft and merges strictly after slice 4 (#7838), which currently has an outstanding changes-requested from me on the workspace-archive ordering bug. Nothing here depends on that fix, so this approval is independent of it.

🟢 The two HARD channel-ref classes mirror validate() exactly, including the trim asymmetry

The hard part of this slice is the bare-type peer-group orphaning case, and it is right. collect_channel_refs emits a HARD ref at peer_groups.<g>.agents[i] when a bare-type group member's only <type>.* channel is the target. I traced the survivor test against validate()'s bare-membership check (schema.rs ~17682, the None arm):

• validate's survival test is ch.as_str().starts_with("<type>.") on the untrimmed string.
• collect's survival test (line ~710) is ch.trim() != target && ch.as_str().starts_with(&type_prefix) - the membership-match clause trims (mirroring what the scrub removes), the survival clause does not trim (mirroring validate).

That asymmetry is deliberate and correct: a whitespace-padded " discord.other" would not count as a surviving channel in validate's eyes, so collect must refuse rather than report a success that yields a config validate rejects. Getting trim-vs-no-trim aligned per-clause is exactly the kind of thing that silently rots; the comment explains why, and the survivor test (cascade_channel_proceeds_when_bare_group_member_keeps_another) plus the orphan test (cascade_channel_refuses_orphaning_bare_group_member) pin both sides.

🟢 The type-level last-alias guard is the right companion to the member-level guard

removes_last_alias (sole key of the type) reports every bare-type group whose channel = "<type>" as HARD, because emptying the [channels.<type>.*] block makes peer_groups.<g>.channel = "<type>" resolve to nothing and validate bails (schema.rs ~17657). This fires at the type level (the block disappears) while the member-level guard fires even when another alias keeps the block present but the member's own only matching channel is the target. Both are needed; neither subsumes the other.

🟢 Scrub mirrors collect, post-condition re-walk, dotted-ref safety

• scrub_channel_refs drops exactly the two SOFT sites collect marks (agents.<X>.channels[] and escalation.alert_channels[]), trimming to match find_all_references, and never touches peer_groups.<g>.channel (HARD, refused before reaching the scrub).
• Removal goes through the same generic delete_map_key("channels.<type>", alias) the gateway/CLI use, and the post-mutation find_all_references re-walk converts any future scrub/collect drift into a loud PostCondition error.
• Correctly distinguishes the dotted target (discord.work) from a bare group channel (discord): the direct peer-group-channel HARD ref only matches the dotted form, and the bare cases are handled by the two type/member guards. DryRun mutates nothing; NotFound short-circuits.

Channels carry no owned non-config state, so unlike the agent arm this is the complete cascade for the kind with no surface-side half. Clean slice.

[singlerider]

Re-reviewed at b3c1191 (my prior APPROVED was at 0568269). The head moved because the stack was rebased, not because the channel arm changed. I diffed alias_refs.rs between the two commits and md5'd the three channel functions: delete_channel, scrub_channel_refs, and collect_channel_refs are byte-identical to what I approved. The only file deltas are already-merged-and-approved slice-3 material now appearing in the rebased base (the RefStrength::Hard doc-comment correction and the cascade_agent_refuses_when_solely_owned_channel test from c02c8aa). I re-ran the channel suite green on the new head (cargo test -p zeroclaw-config cascade_channel 6/6). Re-approving.

The channel cascade review stands unchanged: both HARD channel-ref classes mirror Config::validate() exactly including the deliberate trim-vs-no-trim asymmetry, the type-level and member-level orphan guards are correct companions, scrub mirrors collect, and the post-condition re-walk is fail-closed. RESOLVED ✅ status for everything in the prior pass.

One note for the merge mechanics, not a review finding: the rebased head now carries the slice-4 fix 927921e (resolve the workspace dir before the cascade removes the entry) in its history, which correctly fixes the 🔴 I raised on #7838 - I confirmed the fix and its regression test (delete_cascade_resolves_custom_workspace_before_removing_entry) green. That is the right fix. But #7838 itself is still open with my changes-requested on record. Merging this slice does not substitute for landing slice 4 in order through its own PR; sequence the merges so slice 4 lands first and shows Merged rather than being swept in here.