68 lines
2.8 KiB
Markdown
68 lines
2.8 KiB
Markdown
# Mailshot Plugin Environment Baseline
|
|
|
|
## Purpose
|
|
|
|
Define the persistent environment assumptions for this plugin so all requirements and implementation work use the same baseline.
|
|
|
|
## Global Requirement Context
|
|
|
|
This document will be referenced from every requirements specification document in this repository.
|
|
This document remains in the working context for all operations.
|
|
|
|
## Core Policy
|
|
|
|
"Do not use fallbacks without specific instruction"
|
|
|
|
No fallback behavior may be introduced or enabled unless a requirement explicitly instructs it.
|
|
|
|
## Repository Context
|
|
|
|
- Primary workspace: `mailshot-plugin`
|
|
- Reference implementation patterns: `../members-list-plugin`
|
|
- Requirements folder: `requirements/`
|
|
- Credentials folder (local dev only): `credentials/`
|
|
- Results folder for test outputs and investigation findings: `results/`
|
|
|
|
## Development Assumptions
|
|
|
|
- Development should support a local fixture/harness workflow where practical.
|
|
- Runtime code paths used in tests should match production plugin code paths as closely as possible.
|
|
- Environment-specific behavior must be explicit, documented, and testable.
|
|
|
|
## Configuration Principles
|
|
|
|
- Use a single clear active configuration path per environment.
|
|
- Prefer explicit configuration over implicit defaults.
|
|
- Keep secrets outside committed source files.
|
|
|
|
## Database Routing Contract
|
|
|
|
- Mailshot feature writable state (definitions, assets, run logs, and related mailshot tables) must be stored in the database named by `.env` variable `MAILSHOTS_REMOTE_MYSQL_DB`.
|
|
- Recipient/source data reads (for DSL execution against contacts/accounts/renewals and approved custom source tables) must use the database named by `.env` variable `MEMBERS_REMOTE_MYSQL_DB`.
|
|
- Requirements documents must state whether each table/operation is a write-path (`MAILSHOTS_REMOTE_MYSQL_DB`) or read-path (`MEMBERS_REMOTE_MYSQL_DB`).
|
|
|
|
## Testing Hygiene
|
|
|
|
- Every test must clean up its own test artefacts.
|
|
- No test may leave persistent data/files/state behind unless a requirement explicitly allows it.
|
|
- Test results and investigation findings must be written under `results/`.
|
|
|
|
## Build And Release Scripts
|
|
|
|
- `scripts/` must contain a deployment script for deploying to the production server.
|
|
- `scripts/` must contain a packaging script that creates an uploadable WordPress plugin package.
|
|
|
|
## Versioning Requirements
|
|
|
|
- The code must expose a WordPress-reportable semantic version number in `x.y.z` format.
|
|
- `x` is major, `y` is minor, `z` is patch level.
|
|
- Every deployment must increment patch level `z`.
|
|
|
|
## Documentation Contract
|
|
|
|
Each future requirements document should:
|
|
|
|
1. Link or refer to `requirements/environment.md`.
|
|
2. Declare any additional environment constraints beyond this baseline.
|
|
3. State if a requirement is local-only, test-only, or production-relevant.
|