# How `case‑init.ps1` Establishes the Ops Gate with `auth.status=granted` in Reverse‑Skill

> Discover how case-init.ps1 establishes the ops gate with auth.status=granted. Learn the multi-step validation process and authorization methods used in Reverse-Skill.

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

---

**`case‑init.ps1` enforces the operations gate through a validated, multi‑step resolution process that sets `auth.status=granted` only when explicit authorization is provided via CLI flags or parameters, then embeds this status into the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract.**

The `case‑init.ps1` script serves as the entry point for the [reverse‑skill](https://github.com/zhaoxuya520/reverse-skill) framework, preparing new case directories and generating the authoritative **scope.md** contract. A core security principle of this framework is the *ops gate*: downstream automation must not proceed without explicit authentication. This article examines exactly how `case‑init.ps1` establishes this gate through parameter handling, validation logic, and contract generation.

## Parameter Declaration for Auth Control

The script declares two complementary parameters that operators use to establish authorization status:

```powershell
[Parameter()]
[switch] $AuthGranted,

[Parameter()]
[string] $AuthStatus

```

- **`[switch] $AuthGranted`**: A boolean flag that immediately grants authorization when present.
- **`[string] $AuthStatus`**: Allows explicit string values (`pending`, `granted`, `denied`, `unknown`) for precise control.

These parameters appear at lines 13‑14 of `skills/scripts/case-init.ps1`, giving operators flexible ways to set the ops gate.

## The Auth Resolution Pipeline

`case‑init.ps1` implements a layered resolution process that determines the final `authStatusResolved` value. The pipeline prioritizes explicit input while maintaining safe defaults.

### Step 1: Default to Pending

```powershell
$authStatusResolved = 'pending'

```

At initialization (lines 70‑71), the script assumes a restrictive posture. No operations can proceed without deliberate authorization.

### Step 2: Immediate Grant via Switch

```powershell
if ($AuthGranted) {
    $authStatusResolved = 'granted'
}

```

When `-AuthGranted` is supplied (lines 71‑72), the status flips directly to `granted`. This provides a concise CLI option for authorized operators.

### Step 3: Explicit Status with Validation

```powershell
if ($AuthStatus) {
    $clean = $AuthStatus.Trim().ToLower()
    $valid = @('pending','granted','denied','unknown')
    if ($clean -in $valid) {
        $authStatusResolved = $clean
    } else {
        Write-Warning "Invalid AuthStatus '$AuthStatus'; using '$authStatusResolved'"
    }
}

```

The `-AuthStatus` parameter (lines 72‑78) allows fine‑grained control. The script:
- Normalizes input via `Trim().ToLower()`
- Validates against an explicit allowlist
- Falls back gracefully with a warning for invalid values

## Evidence and Audit Trail

The script constructs an `evidenceAuth` variable (lines 83‑87) that documents how authorization was established:

```powershell
if ($AuthGranted) {
    $evidenceAuth = "cli-flag AuthGranted"
} elseif ($AuthStatus) {
    $evidenceAuth = "AuthStatus=$authStatusResolved"
} else {
    $evidenceAuth = "default pending"
}

```

This audit trail becomes part of the permanent case record, supporting compliance and forensic review.

## The Ready‑for‑Act Gate Check

Authorization alone does not open the ops gate. The script enforces three mandatory conditions at lines 25‑31:

```powershell
$ready = (
    ($authStatusResolved -eq 'granted') -and
    ($inScopeAssets.Count -gt 0) -and
    ($NetworkProfile -ne 'offline')
)

```

| Condition | Purpose |
|-----------|---------|
| `authStatusResolved -eq 'granted'` | Explicit authorization confirmed |
| `inScopeAssets.Count -gt 0` | At least one target asset defined |
| `NetworkProfile -ne 'offline'` | Network mode permits action |

If any condition fails, `ready` remains `$false` and the script emits a diagnostic warning. This **multi‑factor gate** prevents accidental execution against unauthorized or undefined targets.

## Scope.md Contract Generation

The authoritative enforcement mechanism is the generated [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file (lines 98‑102). The script injects the `auth` block:

```markdown

## auth

- status: granted
- basis: own_system
- evidence_of_auth: cli-flag AuthGranted
- MUST NOT proceed if status != granted

```

The hard comment **“MUST NOT proceed if status != granted”** creates a machine‑readable and human‑auditable contract. Downstream tools—including `master‑route.ps1`—parse this file and respect its constraints.

## Runtime Verification

The script concludes with explicit console output (lines 15‑16):

```powershell
Write-Host "auth.status=$authStatusResolved network_profile=$NetworkProfile ready_for_act=$readyStr"

```

Operators immediately verify gate status:

```

auth.status=granted network_profile=authorized_target_only ready_for_act=true

```

## Practical CLI Examples

### Create a Pending Case (No Authorization)

```powershell
powershell -File skills/scripts/case-init.ps1 -Hint "web pentest"

```

Result: `auth.status=pending`, `ready_for_act=false`

### Grant Authorization via Switch

```powershell
powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthGranted -TargetUrl "https://target.example/"

```

Result: `auth.status=granted`, ready status depends on assets and network profile.

### Explicit Status Override

```powershell
powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthStatus "granted" -TargetUrl "https://target.example/"

```

Equivalent to `-AuthGranted` with explicit string control.

### Force Ready State with Full Prerequisites

```powershell
powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthGranted -TargetUrl "https://target.example/" `
    -NetworkProfile authorized_target_only -ReadyForAct

```

This demonstrates the complete gate opening: granted auth, defined assets, and permissive network profile.

## Key Files in the Ops Gate Architecture

| File | Role |
|------|------|
| `skills/scripts/case-init.ps1` | Core script; resolves auth status and enforces gate conditions. |
| `skills/scripts/lib/WorkRoot.ps1` | Discovers work directory for case placement. |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) | Specification defining `auth.status` requirements for downstream tools. |
| `skills/scripts/master-route.ps1` | Optional router that respects the scope contract for skill execution. |

These components form a defense‑in‑depth system where `case‑init.ps1` establishes the gate and downstream automation validates it.

## Summary

- **`case‑init.ps1` default posture is restrictive**: `auth.status` starts as `pending` and gates remain closed.
- **Authorization requires explicit action**: Operators must supply `-AuthGranted` or valid `-AuthStatus`.
- **Validation prevents configuration errors**: Invalid status strings are rejected with warnings.
- **Multi‑factor readiness check**: `ready_for_act` demands granted auth, defined assets, and non‑offline network.
- **[`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) becomes the single source of truth**: The contract embeds status and enforcement language for all downstream tools.

## Frequently Asked Questions

### What happens if I provide both `-AuthGranted` and `-AuthStatus`?

The switch takes precedence in resolution order, but explicit `-AuthStatus` subsequently overwrites if valid. In practice, use one or the other to avoid confusion. The final `authStatusResolved` reflects the last valid assignment.

### Can I bypass the ops gate by editing [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) manually?

While physical file access permits modification, the design intent treats [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) as the authoritative contract. Framework tools validate the file's integrity through additional mechanisms. Operational procedures should treat unauthorized modifications as security incidents.

### Why does the script require assets and network profile for `ready_for_act`?

The three‑condition gate prevents two common failure modes: executing against undefined targets (empty asset list) and attempting network operations in air‑gapped mode (`offline` profile). This aligns with the principle of least privilege in offensive security workflows.

### How do downstream tools consume the `auth.status` value?

Tools like `master-route.ps1` parse the generated [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and check the `## auth` block before executing skills. The hard comment "MUST NOT proceed if status != granted" serves as both human instruction and parsing anchor for automated validators.