How `case-guard.sh` Enforces Authorization Boundaries in Reverse-Skill

case-guard.sh enforces authorization boundaries by validating a case's scope.md file for mandatory auth grants, network profile compliance, asset definitions, and sign-off readiness before permitting any ACT operation.

The case-guard.sh script in the zhaoxuya520/reverse-skill repository serves as a mandatory security gate that runs before any analysis, code execution, or tool invocation (ACT). By systematically inspecting the case's scope.md configuration, it ensures that only properly authorized, scoped, and reviewed cases proceed through the workflow.

Core Validation Checks

The script performs five sequential authorization boundary checks. Each failure accumulates an issue and ultimately blocks execution with exit code 2.

1. Presence of scope.md

The gate first verifies that the case configuration exists at the expected path. In skills/scripts/case-guard.sh lines 33-37, the script aborts immediately if scope.md is missing:

if [[ ! -f "$SCOPE_PATH" ]]; then
    fatal "scope.md not found at $SCOPE_PATH"
fi

Without this file, no authorization context exists—halting execution is the only safe response.

2. Auth Status Verification

The script extracts the auth.status field and requires it to be granted. Lines 67-72 implement this check:

AUTH_STATUS=$(yq '.auth.status' "$SCOPE_PATH")
if [[ "$AUTH_STATUS" != "granted" ]]; then
    ISSUES+=("auth.status is not granted")
fi

This enforces the fundamental authorization boundary: explicit permission must be recorded before any ACT can occur.

3. Network Profile Mode Restrictions

The network_profile.mode field must match an allowed whitelist: offline, lab_only, authorized_target_only, or unrestricted_lab. Additionally, offline mode requires evidence of offline sample availability. Lines 73-82 codify this:

NETWORK_MODE=$(yq '.network_profile.mode' "$SCOPE_PATH")
if [[ "$NETWORK_MODE" == "offline" ]]; then
    OFFLINE_CUE=$(yq '.network_profile.offline_sample // ""' "$SCOPE_PATH")
    if [[ -z "$OFFLINE_CUE" ]]; then
        ISSUES+=("network_profile.mode is offline without offline sample cue")
    fi
fi

This boundary prevents accidental online operations against unauthorized targets.

4. Asset Definition Requirements

When not operating in offline mode, the script validates that in_scope.assets contains at least one entry. Lines 88-106 check this:

if [[ "$NETWORK_MODE" != "offline" ]]; then
    ASSETS_COUNT=$(yq '.in_scope.assets | length' "$SCOPE_PATH")
    if [[ "$ASSETS_COUNT" -eq 0 ]]; then
        ISSUES+=("in_scope.assets appears empty")
    fi
fi

Empty asset lists in networked modes indicate incomplete scoping—a boundary violation that must block progress.

5. Sign-Off Readiness Flag

Finally, the script requires explicit confirmation that the case is ready for ACT. Lines 108-112 validate:

READY=$(yq '.signoff.ready_for_act' "$SCOPE_PATH")
if [[ "$READY" != "true" ]]; then
    ISSUES+=("ready_for_act is not true")
fi

This human-attested boundary ensures deliberate, reviewed authorization.

Execution Outcomes

Success Path

When all checks pass, the script outputs confirmation and exits cleanly (lines 14-17):

# Typical usage

bash skills/scripts/case-guard.sh --case-root work/my-case

# Output

# CASE-GUARD OK: work/my-case

# Exit code 0

Failure Path

Any validation failure produces a detailed issue report and exit code 2 (lines 19-27):

# Missing authorization

bash skills/scripts/case-guard.sh --case-root work/my-case

# Output

# CASE-GUARD NOT READY: work/my-case

#  - auth.status is not granted

# Exit code 2

The --force Flag Limitation

The script accepts a --force parameter for compatibility, but this flag does not bypass authorization boundaries. Lines 22-25 explicitly warn:

# Using --force (no effect on hard gates)

bash skills/scripts/case-guard.sh --case-root work/my-case --force

# Output when issues remain

# CASE-GUARD NOT READY: work/my-case

#  - auth.status is not granted

# CASE-GUARD: --force does not bypass scope hard gates.

# Exit code 2

According to the zhaoxuya520/reverse-skill source code, this design guarantees that --force cannot override the repository's mandatory authorization policy.

File Structure and Integration

File	Role in Authorization Enforcement
skills/scripts/case-guard.sh	Core gate implementation; validates all boundary conditions
work/<case>/scope.md	Per-case authorization record with auth, network_profile, in_scope.assets, and signoff sections
skills/scripts/case-init.sh	Creates properly structured scope.md during case setup
skills/config/routing.json	Ensures case-guard.sh executes before permitted ACT operations

Summary

• case-guard.sh validates five mandatory authorization boundaries before any ACT proceeds
• Hard gates (scope.md presence, auth.status, ready_for_act) cannot be bypassed by --force
• Network profiles restrict operational modes and require evidence for offline claims
• Asset scoping ensures target clarity in networked environments
• Exit code 2 consistently signals authorization boundary violations for CI/CD integration

Frequently Asked Questions

What happens if scope.md is missing?

The script calls fatal and exits immediately with a "scope.md not found" message. This is the first and most fundamental check at lines 33-37 in skills/scripts/case-guard.sh. No further validation occurs without the configuration file present.

Can --force override a denied authorization?

No. As explicitly implemented in lines 22-25, --force "does not bypass scope hard gates." The flag exists only for backward compatibility with calling scripts. Authorization boundaries require actual changes to scope.md fields, not command-line flags.

Which network profile modes are permitted?

The allowed values are offline, lab_only, authorized_target_only, and unrestricted_lab. The offline mode carries an additional requirement: the network_profile.offline_sample field must contain a valid offline sample cue such as "sample", "offline path", or a recognizable file extension.

How does the script communicate validation results?

case-guard.sh uses exit codes and structured console output. Exit code 0 indicates all boundaries satisfied. Exit code 2 signals one or more violations, with each issue listed explicitly for diagnostic clarity. This design supports automated pipeline integration where exit code checking triggers appropriate workflow routing.

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