31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
# 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.
|