How `work/<case>/scope.md` Enforces Network-Profile Boundaries in Reverse-Skill

work/<case>/scope.md enforces network-profile boundaries through a two-layer defense: the declarative scope-contract.md schema defines required fields, and the case-guard scripts parse and validate network_profile.mode before any action executes.

The reverse-skill repository implements a strict scope-driven authorization model where every case must declare its operational constraints in a per-case scope.md file. This article explains how the network_profile field acts as a critical boundary mechanism, with enforcement logic distributed across the contract definition, initialization scripts, and runtime guards.

Scope-Contract.md: The Schema Definition

The foundation of network-profile enforcement resides in skills/ops/scope-contract.md. This file defines the mandatory structure that every work/<case>/scope.md must follow, including the network_profile section with its mode field.

According to the repository's rule set in RULES.md (lines 20, 150), no ACT (action) may proceed without:

• auth.status=granted
• A valid network_profile configuration

The contract ensures that case initialization scripts populate these fields during case setup.

Case-Init Scripts: Populating the Network Profile

When a practitioner creates a new case, the initialization scripts (skills/scripts/case-init.ps1 and its Bash counterpart) generate the scope.md file with the required structure. These scripts:

• Prompt for or infer the appropriate network_profile.mode
• Write the populated metadata to work/<case>/scope.md

This ensures every case begins with explicit network boundaries declared before any tools execute.

Case-Guard Scripts: Runtime Enforcement

The critical enforcement layer runs immediately before any destructive or investigative command. The guard scripts—skills/scripts/case-guard.sh and skills/scripts/case-guard.ps1—parse the active case's scope.md and validate the network_profile configuration.

Extracting the Network Profile

Bash implementation (case-guard.sh line 73):

net_mode="$(section_field network_profile mode | tr -d '\r' | awk '{print $1}')"

PowerShell implementation (case-guard.ps1 lines 48-55):

$networkSection = Get-ScopeSection -Text $scope -Name 'network_profile'

Validating Required Fields

If network_profile.mode is absent, the guard immediately flags the violation (case-guard.sh line 75):

if [[ -z "$net_mode" ]]; then
    ISSUES+=("network_profile.mode missing")
fi

The PowerShell version performs equivalent validation, adding 'network_profile.mode missing' to its issues collection when the section is empty.

Enforcing Supported Profiles

The guard scripts maintain an allowlist of operational modes. Unauthorized values trigger enforcement actions (case-guard.ps1 lines 61-65):

if (-not $networkSection) {
    $issues.Add('network_profile.mode missing')
}

The Bash implementation expands this with explicit case handling:

case "$net_mode" in
    offline)
        # Additional offline-specific validation

        ;;
    authorized_target_only|lab_only)
        # Permitted operational modes

        ;;
    *)
        ISSUES+=("network_profile.mode is unsupported: $net_mode")
        ;;
esac

Offline Mode: Special Restrictions

The offline profile carries additional constraints. When network_profile.mode=offline, the guard requires an explicit offline-sample cue to proceed (case-guard.sh lines 80-84):

offline)
    if [[ -z "$offline_sample_cue" ]]; then
        ISSUES+=("network_profile.mode is offline without offline sample cue")
    fi
    ;;

This prevents accidental online activity when the case scope explicitly restricts operations to offline artifacts.

Execution Flow: How Boundaries Are Applied

The complete enforcement pipeline operates as follows:

1. Case creation → case-init generates work/<case>/scope.md with auth and network_profile sections
2. Pre-action verification → Routing framework invokes case-guard before any ACT
3. Profile parsing → Guard extracts network_profile.mode from the current scope
4. Validation cascade:
   • Presence check: mode must exist
   • Value check: mode must be in supported set
   • Constraint check: special rules apply for offline mode
5. Execution decision: Any issues block the action; clean validation permits continuation

Supported Network Profile Modes

Based on the guard script implementations, the repository recognizes these operational boundaries:

Mode	Description	Special Requirements
offline	No network activity permitted	Requires offline_sample_cue
lab_only	Restricted to designated lab infrastructure	None
authorized_target_only	Only pre-approved targets allowed	None

Any other value triggers the "unsupported mode" enforcement path.

Summary

• skills/ops/scope-contract.md defines the network_profile schema that every case must implement
• skills/scripts/case-init.ps1 populates work/<case>/scope.md with the required network_profile.mode value
• skills/scripts/case-guard.sh and case-guard.ps1 parse and validate the profile at runtime, blocking actions when boundaries are violated
• Special offline restrictions require explicit sample cues to prevent unintended network activity
• All enforcement aligns with RULES.md policy requiring both auth.status=granted and valid network_profile before any ACT executes

Frequently Asked Questions

What happens if network_profile.mode is missing from scope.md?

The case-guard scripts detect the absence during pre-action validation and add network_profile.mode missing to their issues collection. This blocks execution until the case is reinitialized with proper scope metadata.

Can I use a custom network profile mode beyond the supported values?

No. The guard scripts explicitly check against an allowlist of modes (offline, lab_only, authorized_target_only). Unsupported values trigger network_profile.mode is unsupported: <value> and halt execution.

Why does offline mode require a sample cue?

The offline_sample_cue serves as an additional safety verification when the case explicitly restricts network activity. This prevents scenarios where misconfiguration or script errors might accidentally enable online operations against the stated scope.

Where is the network profile validation enforced in the codebase?

Primary enforcement occurs in skills/scripts/case-guard.sh (lines 73-84) and skills/scripts/case-guard.ps1 (lines 48-65), with policy definitions in RULES.md (lines 20, 150) and schema requirements in skills/ops/scope-contract.md.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}