# How the Pack Enable/Disable System Works with Category Expansion in dcg

> Learn how dcg's pack enable/disable system uses category expansion for granular control. Disable parent categories to disable descendants while keeping core packs enabled.

- Repository: [Jeff Emanuel/destructive_command_guard](https://github.com/Dicklesworthstone/destructive_command_guard)
- Tags: internals
- Published: 2026-07-14

---

**The destructive-command-guard (dcg) implements hierarchical pack control through prefix-based category expansion in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs), where disabling a parent category automatically disables all descendant packs while keeping the `core` pack mandatory and `system.disk` opt-out by default.**

The `dcg` repository organizes destructive pattern detection into modular **packs** that users can toggle via configuration files. Understanding how the **pack enable/disable system with category expansion** works is critical for customizing protection levels without accidentally exposing dangerous commands. The logic resides primarily in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs), where the `PacksConfig::enabled_pack_ids` method builds the active set using dot-separated namespace rules and conditional platform logic.

## Pack ID Hierarchy and Configuration Structure

Packs in dcg follow a **dot-separated namespace** (e.g., `core.git`, `system.disk`, `windows.filesystem`). The configuration in `~/.config/dcg/config.toml` supports three top-level keys under `[packs]`:

- **`enabled`** – Explicit pack IDs to activate.
- **`disabled`** – Explicit pack IDs to deactivate.
- **`custom_paths`** – External files defining additional packs.

This hierarchy allows fine-grained control. For example, `system` acts as a category parent to `system.disk`, while `windows` encompasses `windows.filesystem` and `windows.system`.

## The Expansion Algorithm in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs)

The core logic lives in `PacksConfig::enabled_pack_ids` within [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs). The method constructs a `HashSet<String>` of active packs through five deterministic steps:

```rust
let mut enabled: HashSet<String> = self.enabled.iter().cloned().collect(); // 1

// 2 – Remove disabled packs and their sub‑packs
for disabled in &self.disabled {
    enabled.remove(disabled);
    enabled.retain(|p| !p.starts_with(&format!("{disabled}.")));
}

// 3 – Core is always on
enabled.insert("core".to_string());

// 4 – system.disk default‑on unless disabled
let sys_disk_disabled = self.disabled.iter().any(|d| d == "system.disk" || d == "system");
if !sys_disk_disabled {
    enabled.insert("system.disk".to_string());
}

// 5 – Windows packs default‑on only on Windows
#[cfg(windows)]
{
    for pack_id in ["windows.filesystem", "windows.system"] {
        let disabled = self.disabled.iter().any(|d| d == pack_id || d == "windows");
        if !disabled {
            enabled.insert(pack_id.to_string());
        }
    }
}

```

### Step 1: Base Enable Set Minus Explicit Disables

The algorithm begins by cloning the `enabled` list into a mutable `HashSet`. It then removes any IDs found in the `disabled` list. This handles direct conflicts where a pack appears in both lists.

### Step 2: Category-Wide Disabling via Prefix Matching

**Category expansion** occurs during the disable phase. For each entry in `disabled`, the code removes not only the exact match but also any pack whose ID starts with that prefix followed by a dot:

```rust
enabled.retain(|p| !p.starts_with(&format!("{disabled}.")));

```

This means disabling `system` automatically excludes `system.disk`, `system.network`, and any future `system.*` packs. The expansion is **unidirectional downward**—parent disables propagate to children, but child disables do not affect parents.

### Step 3: Mandatory and Default Packs

After processing user preferences, the system enforces two hardcoded rules:

1. **`core` is mandatory** – Inserted regardless of user settings via `enabled.insert("core".to_string())`.
2. **`system.disk` is opt-out** – Added automatically unless the user explicitly disables `system.disk` or the parent `system` category.

## Platform-Specific Handling for Windows Packs

The algorithm handles cross-platform safety through conditional compilation. On Windows targets (`#[cfg(windows)]`), the code iterates over `["windows.filesystem", "windows.system"]` and adds each to the enabled set unless disabled directly or via the `windows` category parent.

On non-Windows platforms, these packs remain **registered but inactive** by default. Unix users can opt-in by manually adding them to `enabled`, allowing PowerShell script scanning even on Linux hosts.

## Agent-Specific Pack Resolution

When running under specific agents (e.g., Claude Code), dcg calls `enabled_pack_ids_for_agent` instead of the base method. According to the source in [`src/main.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/main.rs), this variant:

1. Starts with the base set from `enabled_pack_ids()`.
2. Adds any extra packs the agent declares as required.

This allows CI/CD agents to inject additional protection packs without modifying the user's global configuration.

## Practical Configuration Examples

### Enable Specific Packs

Add explicit pack IDs to activate custom protection:

```toml
[packs]
enabled = ["database.postgresql", "cloud.aws"]

```

### Disable an Entire Category

Prevent all system-related packs by disabling the parent category:

```toml
[packs]
disabled = ["system"]

```

This removes `system.disk` and any future `system.*` packs automatically.

### Fine-Grained Windows Control

Enable the `windows` category for discovery but disable specific sub-packs:

```toml
[packs]
enabled = ["windows"]
disabled = ["windows.system"]

```

This keeps `windows.filesystem` active while excluding `windows.system`.

### Opt-Out of Default Protections

Disable the automatic `system.disk` pack if your workflow requires unfettered disk operations:

```toml
[packs]
disabled = ["system.disk"]

```

## Summary

- **Category expansion** propagates downward: disabling `system` blocks all `system.*` packs via prefix matching in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs).
- **Explicit enables** do not auto-expand; enabling `windows` makes packs discoverable but does not activate `windows.filesystem` unless configured.
- **Core packs** (`core`) are always loaded, while **system packs** (`system.disk`) are opt-out only.
- **Windows-specific packs** auto-enable on Windows unless explicitly disabled or the `windows` category is turned off.
- **Agent variants** (`enabled_pack_ids_for_agent`) allow runtime injection of additional packs on top of the base configuration.

## Frequently Asked Questions

### What happens if I enable a category like "windows" but disable a specific sub-pack?

Enabling a category adds only that specific ID to the active set; it does not automatically expand to children. If you enable `windows` but disable `windows.system`, the `windows.filesystem` pack remains inactive (unless also enabled or auto-enabled by the platform), while `windows.system` is explicitly excluded. This design provides fine-grained control without implicit inheritance of enable states.

### Why is the "core" pack always enabled regardless of my configuration?

The `core` pack contains fundamental protection patterns that the dcg maintainers deem critical for safe operation. In [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs), the code explicitly inserts `"core"` into the enabled set after processing user preferences, ensuring baseline protection cannot be accidentally disabled through configuration errors.

### How do I disable the automatic system.disk protection?

Add either `system.disk` or the parent `system` category to your `disabled` list in `~/.config/dcg/config.toml`. The logic checks `self.disabled.iter().any(|d| d == "system.disk" || d == "system")` before inserting the pack, so either entry prevents automatic activation.

### Can Unix systems use Windows-specific packs?

Yes. While `windows.filesystem` and `windows.system` auto-enable only on Windows targets (guarded by `#[cfg(windows)]`), non-Windows systems can explicitly opt-in by adding these IDs to the `enabled` list. This allows Linux or macOS users to scan PowerShell scripts or Windows-specific commands without changing the source code.