# Architecture and Runtime Separation Requirements

## Purpose
Define strict boundaries between deployable plugin code and local WordPress emulation/testing support.

## Core Separation Rule
- `code/` contains deployable WordPress plugin code only.
- `compatibility-layer/` contains local emulation/shims/test harness support only.

## Deployable Code Requirements (`code/`)
- Code under `code/` must be deployable to real WordPress without modification.
- Code under `code/` must not import, include, or require files from `compatibility-layer/`.
- Runtime behavior in `code/` must not branch on "test vs production" environment flags.
- Plugin logic in `code/` should depend on WordPress APIs/contracts, not on harness-specific APIs.

## Compatibility Layer Requirements (`compatibility-layer/`)
- Provides stand-alone/local execution support by emulating required WordPress behavior.
- Must adapt to `code/` contracts; `code/` must not adapt to compatibility-layer internals.
- May include local HTTP harness, fake WP functions, and local data/bootstrap tooling for tests.

## Packaging and Deployment Boundary
- Build/package inputs for production come from `code/` (plus approved runtime assets) only.
- `compatibility-layer/`, `tests/`, and local tooling are excluded from production artifacts.

## Verification Requirements
Acceptance must verify:

1. The same `code/` content runs in real WordPress without source edits.
2. Production package contains no files from `compatibility-layer/`.
3. No `code/` references to `compatibility-layer/` paths/symbols are present.