# Case Guard Mechanism and Scope Enforcement in reverse-skill: A Complete Guide

> Understand the reverse-skill case guard mechanism and scope enforcement. Learn how this hard gate validates critical conditions before allowing active operations. Get the complete guide.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-05

---

**The reverse-skill case guard mechanism is a "hard gate" that validates four mandatory conditions in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)—authentication status, in-scope assets, network profile, and ready-for-act flag—before allowing any active operation to execute.**

The **case guard mechanism** in reverse-skill is a safety-critical enforcement layer that prevents unauthorized or out-of-scope offensive security operations. Implemented across two PowerShell scripts and a markdown contract schema, this system ensures every action (ACT) is preceded by explicit scope validation and documented authorization.

## Core Components of the Case Guard System

### `case-init.ps1` — Case Bootstrap and Contract Creation

Located at `skills/scripts/case-init.ps1`, this script initializes a new case directory under `work/<case>/` and generates the foundational **[`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)** contract. The initialization process:

- Creates the case workspace hierarchy
- Populates [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) from the template in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)
- Records authentication status, primary skill selection, and network profile
- Seeds a minimal timeline and work-item list
- Sets the **`ready_for_act`** flag to `false` by default

Key parameters include `-AuthGranted`, `-TargetUrl`, and `-NetworkProfile` to pre-populate contract fields.

### `case-guard.ps1` — The Hard Gate Validator

The `skills/scripts/case-guard.ps1` script implements the actual enforcement logic. At execution (lines 33-73), it parses [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) using regular expressions and validates four non-negotiable conditions:

1. **`auth.status = granted`** — Written permission must be documented
2. **`in_scope.assets` non-empty** — Or an offline sample path must be provided
3. **`network_profile.mode`** set to a permissible value (offline, lab_only, authorized_target_only, etc.)
4. **`ready_for_act = true`** — The analyst checklist is complete

Failure of any check triggers exit code **2** and blocks the ACT. The **`-Force`** flag permits controlled bypass: warnings emit to console, but exit code 0 allows continuation for exceptional circumstances.

### [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md) — The Authority Schema

The template at [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) defines the exact markdown structure the guard expects. Valid sections include:

- `meta` — case identifiers and timestamps
- `auth` — status and evidence of authorization
- `in_scope` / `out_of_scope` — asset boundaries
- `network_profile` — containment mode
- `deliverables`, `constraints`, `sign-off` — operational parameters

## How Scope Enforcement Works in Practice

### Step 1: Initialize with Explicit Parameters

```powershell
powershell -File skills/scripts/case-init.ps1 `
    -Hint "Web pentest on example.com" `
    -CaseName my-case `
    -AuthGranted `
    -TargetUrl "https://app.example.com" `
    -NetworkProfile authorized_target_only

```

This creates [`work/my-case/scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/my-case/scope.md) with pre-filled authentication and network containment settings.

### Step 2: Complete the Contract

The analyst manually edits [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) to provide:

```yaml
ready_for_act: true

auth:
  status: granted
  evidence_of_auth: ticket-12345

in_scope:
  assets:
    - https://app.example.com/

network_profile:
  mode: authorized_target_only

```

### Step 3: Execute the Guard Check

```powershell

# Standard validation

powershell -File skills/scripts/case-guard.ps1 -CaseRoot work/my-case

# Expected output on success:

# CASE-GUARD OK: work/my-case

# (exit code 0)

```

### Step 4: Force Override (Exceptional Use)

```powershell
powershell -File skills/scripts/case-guard.ps1 -CaseRoot work/my-case -Force

```

This emits violation warnings but returns exit code 0, maintaining audit visibility while permitting emergency continuation.

## Why Scope Enforcement Matters

| Enforcement Layer | Risk Mitigated |
|-------------------|--------------|
| **Authentication validation** | Legal liability from unauthorized testing |
| **Asset boundary checks** | Accidental scanning of out-of-scope systems |
| **Network profile containment** | Data exfiltration or lateral movement |
| **Ready-for-act checklist** | Skipped procedural safeguards |

According to the reverse-skill source code, the guard is invoked after master routing per [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md), ensuring no ACT executes without validation. The architecture documented in [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md) treats this as a non-bypassable control except via explicit `-Force` flagging.

## Summary

- **`case-init.ps1`** bootstraps cases with a template [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract
- **`case-guard.ps1`** validates four mandatory conditions before any ACT
- **[`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md)** provides the authoritative schema for scope documentation
- Exit code **2** blocks execution; **`-Force`** enables audited bypass
- The guard enforces legal compliance, scope discipline, network containment, and operational safety

## Frequently Asked Questions

### What happens if the case guard validation fails?

The `case-guard.ps1` script exits with code 2, prints specific violations to stderr, and prevents downstream ACT scripts from executing. The failure mode is fail-closed: no network operations or code execution can proceed until [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) is corrected or `-Force` is applied.

### Can the case guard be completely disabled?

No. The guard architecture in reverse-skill has no silent disable switch. The only bypass mechanism is the `-Force` flag, which still executes validation logic, emits warning output for audit trails, and requires explicit operator intent. This design prevents accidental circumvention.

### How does the guard handle offline or lab-only assessments?

The `network_profile.mode` field accepts `offline` and `lab_only` as valid values. For `offline` mode, `case-guard.ps1` accepts a non-empty `offline_sample_path` in lieu of `in_scope.assets`. The mechanism adapts validation rules based on the declared operational context while maintaining enforcement rigor.

### Who is responsible for setting `ready_for_act: true`?

The analyst performing the assessment must manually set this flag after completing the checklist in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md). This human-in-the-loop step ensures deliberate confirmation of scope boundaries, authorization evidence, and constraint acknowledgment before any active operations commence.