How `case-guard --force` Interacts With the Authorization Hard-Gate Mechanism

case-guard --force never bypasses the authorization hard-gate—it only accepts the flag for compatibility while enforcing all three mandatory scope checks.

The case-guard script in the zhaoxuya520/reverse-skill repository acts as a lightweight but strict gatekeeper that blocks any ACT (real action) until a case meets every hard-gate condition. Understanding exactly how the --force flag operates prevents false assumptions about emergency overrides.

What the Authorization Hard-Gate Enforces

In skills/scripts/case-guard.sh, the hard-gate validates three non-negotiable requirements from the case's scope.md file:

• auth.status must equal granted — documented legal permission exists
• A valid network_profile must be present — or an explicit offline sample declared
• ready_for_act must be true — the case is explicitly marked ready for execution

The script parses scope.md, accumulates violations in an ISSUES array, and exits with status 2 if any check fails. This exit code propagates upward to block downstream ACT execution.

How --force Actually Works

The --force flag is implemented as a compatibility no-op. The script parses it, sets FORCE=1, but continues through all hard-gate logic unchanged.

From skills/scripts/case-guard.sh:

if [[ $FORCE -eq 1 ]]; then
  echo "CASE‑GUARD: --force does not bypass scope hard gates."
fi

This message appears after failures are reported—not instead of them. The flag exists solely to prevent command-line parsers from rejecting unknown flags, not to create escape hatches.

Repository Policy Reinforces No-Bypass

Multiple policy documents lock in this behavior:

Document	Clause
RULES.md	"-Force / --force never bypasses the gate" (hot-path "Next" step)
skills/ops/scope-contract.md	Explicitly states case-guard --force "不得绕过 auth.status、合法 scope、network profile 或 ready_for_act 硬门"

These sources eliminate any ambiguity: scope hard-gates are architectural, not optional.

Runtime Behavior Examples

Normal execution fails when auth.status is missing:

$ bash skills/scripts/case-guard.sh --case-root work/sample
CASE‑GUARD NOT READY: work/sample
 - auth.status is not granted
Fix scope (or re-run case-init with --auth‑granted --target-url ...).
$ echo $?
2

Adding --force produces identical output with an additional notice:

$ bash skills/scripts/case-guard.sh --case-root work/sample --force
CASE‑GUARD NOT READY: work/sample
 - auth.status is not granted
CASE‑GUARD: --force does not bypass scope hard gates.
Fix scope (or re-run case-init with --auth‑granted --target-url ...).
$ echo $?
2

Only when all gates pass does either command succeed:

$ bash skills/scripts/case-guard.sh --case-root work/ready --force
CASE‑GUARD OK: work/ready
$ echo $?
0

Why This Design Matters

The hard-gate architecture protects against two failure modes:

1. Accidental ACT on unscoped cases — --force could mislead operators into assuming "emergency override"
2. Malicious scope tampering — bypass logic would create exploitable injection points

By making --force purely cosmetic, zhaoxuya520/reverse-skill enforces structural integrity: legal authorization, network isolation, and explicit readiness must be declared in scope.md, not command-line flags.

Summary

• case-guard --force does not override auth.status requirements — the authorization hard-gate remains absolute
• All three scope conditions (auth.status, network_profile, ready_for_act) are checked regardless of flag presence
• Exit code 2 consistently signals gate failure; 0 signals readiness for ACT
• The compatibility flag prevents CLI parsing errors while preserving strict enforcement as documented in RULES.md and scope-contract.md

Frequently Asked Questions

Does --force grant emergency authorization to run ACT?

No. The authorization hard-gate has no emergency override. auth.status must be granted in scope.md regardless of flags used. The --force option only suppresses "unknown flag" errors for tooling compatibility.

Where is the --force behavior implemented?

The flag parsing and no-op warning appear in skills/scripts/case-guard.sh. The definitive policy statement resides in RULES.md under the hot-path "Next" step, with additional Chinese-language clarification in skills/ops/scope-contract.md.

What exit code does case-guard return on hard-gate failure?

Exit code 2. This non-zero status propagates to parent processes to block ACT execution. Exit code 0 indicates all three conditions (auth.status granted, valid network_profile, ready_for_act true) are satisfied.

Why include --force if it does nothing?

Command-line compatibility. Wrapper scripts and CI pipelines may pass --force from generic templates. By accepting and acknowledging the flag without changing logic, case-guard prevents breaking changes while maintaining strict scope enforcement.

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