Document Type: Standard
Status: Active
Authority: HeadOffice
Applies To: All MWMS WordPress plugins, PHP modules, Supabase integrations, and AI-assisted development outputs
Parent: Governance
Version: v1.0
Last Reviewed: 2026-04-28
Purpose
This standard defines how plugin build instructions must be written, structured, and delivered within MWMS.
Its purpose is to ensure:
• clear developer execution
• zero ambiguity in implementation
• consistent plugin architecture
• compatibility with AI-assisted development
• reduced debugging time
• stable system growth
Without structured instructions, plugin builds become inconsistent, error-prone, and difficult to maintain.
Scope
This standard applies to:
• WordPress plugin development
• MWMS Brain UI modules
• Supabase integration logic
• API handlers
• admin interface builds
• AI-generated development instructions
It governs how instructions are written and delivered.
It does not govern:
• business logic decisions
• Brain authority rules
• UI design frameworks
• Canon promotion
Core Principle
Instructions must be executable, not interpretive.
The developer must never need to guess:
• what to build
• where to place it
• how it connects
• what is included or excluded
If interpretation is required, the instruction is invalid.
Instruction Structure
All plugin build instructions must follow this structure:
1. Context Declaration
Every instruction must begin with:
• Active Brain
• System Layer
• Scope
• Explicit Restrictions
Example:
Active Brain: Affiliate Brain
Layer: Plugin / UI Implementation
Scope: Opportunity Intake System
Restrictions: No Offer Intelligence, no automation, no cross-brain logic
2. Objective
Define:
• what is being built
• what the outcome must be
Example:
Build Opportunity Intake Queue with grouped status display and record access.
3. Files Involved
Clearly list:
• plugin file names
• module files
• new vs existing files
Example:
mwms-affiliate.php
admin/pages/opportunity-queue.php
admin/actions/intake-save-handler.php
4. Data Structure
Define:
• table name
• required fields
• field types (if relevant)
Must follow:
• MWMS Supabase Naming Standard
• lowercase snake_case
Example:
affiliate_opportunity_intake
Fields:
id
product_name
product_link
platform
status
created_at
5. UI Structure
Define:
• screen type (queue / record)
• layout sections
• required fields
• visible columns
Must be:
• minimal
• usable
• aligned to specification
6. Actions / Behaviour
Define exactly:
• buttons
• state changes
• validation rules
• system responses
Example:
Reject
→ requires review_notes
→ sets status = rejected
Escalate
→ validate required fields
→ set status = escalated
7. Save / Persistence Rules
Define:
• how data is saved
• when save occurs
• expected behaviour after save
Example:
• Save on button click
• Return success message
• Refresh queue view
8. Validation Rules
Define:
• required fields
• blocked actions
• error behaviour
Example:
Escalation must fail if:
product_name missing
platform missing
fit decision missing
9. Output Requirement (CRITICAL)
All implementation instructions must follow:
Full File Delivery Rule
Meaning:
• full file output only
• no partial edits
• no patch instructions
Developer must be able to:
copy → paste → replace → done
10. Acceptance Criteria
Define:
• what success looks like
• what must be testable
Example:
• record saves
• appears in queue
• status updates persist
• no UI errors
Instruction Quality Rules
All instructions must be:
Complete
No missing steps or assumptions
Bounded
Clear scope — no expansion
Sequential
Logical build order
Testable
Must include validation criteria
Minimal
No unnecessary features
Prohibited Instruction Types
The system must prevent:
• vague instructions
• “improve this” type requests
• partial code suggestions
• mixed architecture decisions
• combining multiple systems in one step
• introducing future-phase features early
Phase Discipline Rule
Instructions must respect build phase:
Phase 1:
• intake only
• no automation
• no dashboards
• no AI
• no cross-brain logic
Future phases must not leak into current instructions.
AI Collaboration Rule
When AI generates instructions:
• must follow full structure
• must not assume context
• must not skip sections
• must produce implementation-ready output
AI acts as:
execution assistant, not system designer
Drift Protection
The system must prevent:
• inconsistent instruction formats
• missing validation logic
• incomplete file outputs
• scope creep during builds
• deviation from MWMS architecture
• premature system expansion
Instruction drift leads to system instability.
Architectural Intent
This standard ensures that:
• development remains controlled
• builds are predictable
• AI assistance is reliable
• system growth is modular
• implementation risk is minimized
It converts development from:
ad hoc coding
→
structured system construction
Change Log
Version: v1.0
Date: 2026-04-28
Author: HeadOffice
Change:
Initial creation of MWMS Plugin Build Instruction Standard defining structured instruction format, execution rules, full file delivery requirement, and phase-based discipline for all MWMS plugin development.