Document Type: Standard
Status: Active
Authority: HeadOffice
Applies To: All MWMS plugin builds, PHP development, UI implementation, and Supabase integration work
Parent: Governance
Version: v1.0
Last Reviewed: 2026-04-28
Purpose
This standard defines the correct workflow for building MWMS plugins so development remains:
• controlled
• fast
• testable
• stable
• easy to debug
• aligned with MWMS architecture
Without a defined workflow, development becomes:
• chaotic
• hard to test
• difficult to debug
• prone to breaking previous work
• slow due to rework
Scope
This standard applies to:
• M (developer)
• AI-assisted development sessions
• all MWMS plugin builds
• WordPress admin UI development
• Supabase-connected features
• Brain system implementation
It governs how development progresses step-by-step.
It does not govern:
• system design decisions
• Brain authority
• Canon governance
Core Principle
Build → Test → Confirm → Then Continue
Never stack multiple untested changes.
Every step must work before the next begins.
Standard Development Cycle
Every task must follow this loop:
Step 1 — Define One Task
Only one clear outcome.
Example:
Build intake record form
NOT
Build intake + queue + research + automation
Step 2 — Build The Smallest Working Version
Focus on:
• minimum fields
• minimum UI
• basic save functionality
Do NOT:
• optimise
• expand
• add future features
Step 3 — Test Immediately
M must verify:
• page loads
• no PHP warnings
• form works
• data saves
• data reloads
If not tested → task is not complete
Step 4 — Fix Before Expanding
If anything breaks:
• fix immediately
• do not continue building
• do not stack more features
Step 5 — Confirm Stable State
System must be:
• usable
• consistent
• error-free
Only then move forward
Step 6 — Move To Next Task
Repeat cycle.
Task Size Rule
Each task must be:
• small
• clear
• independently testable
Correct:
Build save handler
Build queue page
Build status update
Incorrect:
Build entire intake system in one go
File Change Rule
Each task should:
• modify one file where possible
• or introduce one new file
Avoid:
• changing multiple unrelated files in one step
Testing Discipline
Every step must pass:
• no PHP warnings
• no broken layout
• no failed saves
• no missing data
• no inconsistent behaviour
Error Handling Workflow
When an issue occurs:
- Identify file causing issue
- Isolate problem
- Replace or fix file
- Retest
- Confirm stable
Never guess across multiple files at once.
Save & Persistence Rule
Any feature involving data must confirm:
• data saves correctly
• data persists after refresh
• data reloads correctly
• no duplication
• no data loss
Status Workflow Rule
Any status system must confirm:
• valid states only
• correct transitions
• UI reflects changes immediately
• status persists after refresh
UI Stability Rule
UI must always:
• render cleanly
• handle empty states
• avoid layout breaks
• avoid null/undefined output
Phase Discipline Rule
Development must stay within the current phase.
For Phase 1 (Intake):
Allowed:
• intake form
• intake queue
• save/edit
• status actions
Not allowed:
• Offer Intelligence
• dashboards
• automation
• AI
• forecasting
• finance logic
AI Collaboration Workflow
When working with AI:
Operator provides:
• simple instruction
AI provides:
• structured build guidance
• correct file breakdown
• full file output when required
• validation logic
• testing steps
M provides:
• result
• errors
• screenshots or code
AI then:
• fixes smallest issue
• continues step-by-step
Debugging Discipline
Debugging must be:
• file-based
• isolated
• incremental
Never:
• guess multiple causes
• change multiple systems at once
• rewrite large parts without testing
Stop Conditions
Development must stop when:
• task is complete
• system is stable
• acceptance criteria met
Do NOT continue expanding beyond scope.
Definition Of Done (Per Task)
A task is complete when:
• feature works
• no errors exist
• behaviour is consistent
• test cases pass
• system remains stable
Governance Role
This standard ensures:
• development stays controlled
• system remains stable
• progress is measurable
• debugging is simple
• expansion happens safely
Relationship To Other MWMS Standards
This standard works with:
• MWMS Plugin Build Coordination Standard
• MWMS Plugin File Structure Standard
• MWMS PHP Build And Modularity Standard
• MWMS Opportunity System Implementation Brief For M
Drift Protection
The system must prevent:
• building multiple features without testing
• expanding beyond scope
• skipping validation
• stacking broken changes
• large uncontrolled updates
• debugging by guesswork
Architectural Intent
This standard ensures MWMS is built as:
a working system
not
a partially broken system
It converts development from:
trial and error
→
controlled iteration
Change Log
Version: v1.0
Date: 2026-04-28
Author: HeadOffice
Change:
Initial creation of MWMS Plugin Development Workflow Standard defining step-by-step build discipline, testing loop, debugging process, and task control for all MWMS plugin development.