---
name: no-local-exemptions
description: Review environment branches for hidden local exemptions when required values, guards, service contracts, or failure paths differ across environments. Require explicit, purpose-limited variance and fail-fast handling. Not for setup drift, test-layer or harness concerns, visual verification, host-OS portability, or Post.Build.Ship workflow gates.
---

# No Local Exemptions

Use this skill when runtime behavior varies by environment and a local path could hide a missing
requirement, weakened protection, changed service contract, or altered failure path. It covers runtime
configuration, authentication and security behavior, safety controls, feature flags, service
contracts, URL and origin behavior, and failure semantics. It does not require identical values or
infrastructure.

## Parity Is the Default

- Enumerate every environment the target project defines. Treat local and every project-defined
  environment—including development, staging, and production where those labels exist—as subject to
  the same required conditions and protections. These labels are illustrative; do not assume a
  four-environment model.
- Inventory environment-dependent conditions before changing an environment branch. Include each
  condition, guard, contract, protection, and failure behavior that must hold.
- Compare every condition across every project-defined environment. Keep changed values or service
  instances separate from skipped requirements. Different secrets, URLs, data, infrastructure, or
  service instances can be valid environment-specific values; they are not local privileges.
  Capacities and backing-service instances may also differ without granting a local privilege.
- A local branch that skips a guard, weakens a protection, changes a required contract, defaults
  absent configuration, swallows an error, or bypasses a failure path is a hidden exemption unless
  explicitly declared and narrowly justified.

## Declare Any Narrow Variance

A permitted local-only runtime variation must be explicit, purpose-limited, and environment-gated.
Record all of the following at the decision boundary:

- the exact condition and scope of the variation;
- why local execution needs it;
- which required conditions and protections remain enforced;
- how the path behaves outside its scope and in every other project-defined environment; and
- the verification evidence or the reason the difference is not locally observable.

The path must fail closed outside its declared scope. A missing required condition must fail clearly
and early at the boundary with an actionable diagnostic. Never silently skip, default, bypass, or
swallow a missing condition or protection. Do not infer permission from a development label, an
absent local value, or convenience.

## Narrow Transport Accommodation

The sole general local transport accommodation is loopback HTTP or an absent local TLS/full HTTPS
origin. This accommodation covers only the transport difference; it does not waive authentication,
authorization, cookie, origin, cross-site request, secure-context, certificate, or other safety
behavior.

Map and verify transport-dependent behavior where it is locally observable. If a behavior requires a
deployed HTTPS origin and cannot be observed locally, record it as a known deployed-only difference
with its verification evidence or owner; do not silently inherit local behavior. Non-loopback HTTP,
an arbitrary insecure endpoint, or any other local-only runtime difference is not automatically
accepted. Surface it for an explicit decision.

## Concise Parity Check

Use a comparison that makes omissions visible:

1. Identify the environment selector and enumerate the complete set of environments the project
   defines. Separate shipped runtime paths from test-harness-only setup.
2. Inventory environment-dependent conditions, guards, contracts, protections, transport behavior,
   and failure paths.
3. Compare every project-defined environment in a table such as:

   | condition or guard | local | each other project-defined environment | changed value or service instance versus skipped requirement | missing-condition failure | evidence |
   | ------------------ | ----- | -------------------------------------- | ------------------------------------------------------------ | ------------------------- | -------- |

4. Verify that each environment either preserves the required condition or has an explicit,
   purpose-limited variance that fails closed outside its scope. Check missing-condition failure
   behavior, not only the successful path.
5. Verify locally observable transport-dependent behavior. Record any deployed-only difference and
   surface every other local-only runtime difference for explicit decision.

Do not call different secrets, URLs, data, infrastructure, or service instances a local exemption
when the required contract and protections still hold. Do not call a skipped requirement a value
difference.

## Keep Ownership Separate

- `reconcile-setup` owns idempotent setup drift, run-once bootstrap, and setup reconciliation. This
  skill does not evaluate setup-drift concerns.
- `test-layer-fit` owns test-layer and harness placement, suite or readiness behavior, and
  test-harness-only setup shortcuts, automation identities, or documented local/test bootstrap
  paths. This skill does not evaluate those concerns.
- `playwright-visual-verification` owns screenshots, accessibility snapshots, computed styles, and
  visual verification. This skill does not own visual proof.
- Keep host-OS portability and shell mechanics outside this skill's ownership.
- `post-build-ship` owns workflow gates, approval chronology, receipts, staging, and shipping. This
  skill supplies environment-parity reasoning and does not duplicate workflow enforcement.

Do not use this skill to choose backing-service products, versions, or infrastructure topology, or to
add deployment systems, schemas, drift checkers, continuous integration gates, or release policy. It
checks that the selected runtime behavior does not hide local exemptions.