MWMS Plan Execute Clear Development Loop

System: MWMS
Page Type: Development Standard
Parent Page: MWMS Development Standards
Status: Active
Source: Claude Code for Real Engineers course absorption
Applies To: M, Claude Code, Dev Console, Brain Room, AI Manager, future AI development employees

Purpose

The purpose of the MWMS Plan Execute Clear Development Loop is to define the standard operating method for AI-assisted development inside MWMS.

This standard exists to prevent uncontrolled AI coding, context overload, incomplete implementation, broken plugin changes, and unsafe edits to live MWMS systems.

The loop requires every meaningful development task to move through a controlled cycle:

Plan → Execute → QA → Clear → Repeat

This standard applies especially to work involving Claude Code, AI coding agents, M’s development workflow, Dev Console support, WordPress plugin changes, Supabase integration, Brain Room development, AI Manager logic, dashboards, task systems, and future MWMS AI development employees.

The goal is simple:

No major AI-assisted development task should begin with direct editing. It should begin with planning, codebase understanding, risk awareness, and a clear execution path.

Scope

This standard applies to:

MWMS Brain WordPress plugin development.
MWMS HeadOffice Brain plugin development.
Dev Console development.
Brain Room development.
AI Manager and employee router development.
Supabase connector work.
Task executor systems.
Event logging systems.
Dashboard and admin UI development.
Claude Code usage by M or Martyn.
Future AI-assisted coding workflows.
Future development AI employees.

This standard does not replace existing MWMS governance standards. It sits underneath the broader MWMS architecture and build discipline rules, including:

MCR as Source of Truth.
Full File Output rule.
Brain Build Order Standard.
MCR To Brain Copy Rule.
Page Naming Standard.
Document Structure Standard.
Brain Routing Rule.
Supabase Event Schema.
Development save point discipline.

Definition

The Plan Execute Clear Development Loop is a controlled AI development cycle designed to prevent context decay, unsafe execution, and incomplete implementation.

The loop has five primary stages:

Plan
Execute
QA
Clear
Repeat

Each stage has a specific purpose.

The AI must not be allowed to treat planning, coding, testing, and continuation as one uncontrolled flow.

Stage 1 — Plan

Planning is mandatory before any meaningful code change.

The AI must first understand:

The requested outcome.
The system being changed.
The correct site or domain.
The relevant files.
The relevant database tables.
The existing patterns.
The protected systems that must not be touched.
The likely risks.
The expected test path.
The success criteria.

The planning stage should include:

Codebase exploration.
Relevant file identification.
Dependency mapping.
Clarifying questions where needed.
Risk notes.
Proposed implementation steps.
QA plan.
Rollback or safety notes if relevant.

The AI must not move into execution until the plan is clear enough to judge.

MWMS Planning Rule

For any non-trivial development task, the first AI instruction should not be:

“Edit this file.”

It should be:

“Inspect the relevant files, understand the current implementation, identify the safest change path, and produce a plan before editing.”

Stage 2 — Execute

Execution begins only after the plan has been reviewed and accepted.

Execution must be narrow, controlled, and aligned to the agreed plan.

During execution, the AI must:

Stay inside the agreed task scope.
Avoid unrelated refactoring.
Avoid touching protected systems.
Preserve existing working functionality.
Follow existing code patterns.
Use complete replacement outputs where required.
Avoid partial patch instructions where MWMS full file output is required.
Maintain naming and structural consistency.
Avoid inventing new architecture unless requested.
Avoid creating duplicate routes, duplicate files, duplicate database logic, or duplicate UI sections.

MWMS Execution Rule

The AI must solve the task requested, not redesign the surrounding system.

Stage 3 — QA

QA is mandatory.

The AI-assisted task is not complete when code has been written. It is complete only when the expected validation path has been defined and, where possible, completed.

QA must include relevant checks such as:

Does the page load without error?
Does the admin screen still display?
Does the form save correctly?
Does the REST route return the expected response?
Does the Supabase query work?
Does the event log record correctly?
Does the task status update correctly?
Does the dashboard still render?
Does the affected workflow still behave as expected?
Were permissions considered?
Were affected database fields checked?
Were naming rules followed?
Was the correct site or domain affected?
Was M’s active build protected?
Was a save point created if needed?

MWMS QA Rule

Testing must be part of the plan, not an afterthought.

If the plan does not mention QA, the plan is incomplete.

Stage 4 — Clear

Clearing context is a core part of the development loop.

AI coding sessions degrade when too much planning, exploration, failed attempts, old assumptions, and unrelated context remain in the active window.

After a meaningful plan or implementation step, the operator must decide whether to:

Continue with the existing context.
Clear the session and continue from the approved plan.
Start a new loop for the next task.
Preserve only the final plan, files changed, known risks, and next action.

Clearing should happen when:

Context is becoming too large.
The AI starts repeating itself.
The AI starts forgetting earlier constraints.
The AI begins inventing files or assumptions.
The task has shifted.
A planning stage has completed and execution can continue from a concise plan.
A bug has appeared and needs a fresh diagnostic loop.
A new development phase begins.

MWMS Clear Rule

Context is not memory. Context is working fuel.

Use it carefully, and clear it when it becomes polluted or overloaded.

Stage 5 — Repeat

Large MWMS development tasks must be split into multiple controlled loops.

A single session should not attempt to plan, build, debug, refactor, test, document, and extend a major system all at once.

Each loop should end with a clear status:

What was planned.
What was changed.
What was tested.
What passed.
What failed.
What remains.
What the next loop should address.

The next loop begins from the confirmed state, not from vague memory.

Standard MWMS Loop Format

Every AI-assisted development task should follow this structure:

1. Task Intake

Define:

Task name.
Site or domain.
System affected.
Current state.
Desired outcome.
Files likely involved.
Systems not to touch.
Known risks.

2. Planning Prompt

Ask the AI to:

Inspect relevant files.
Map current behavior.
Identify safe implementation path.
Ask clarifying questions if needed.
Produce a step-by-step plan.
Include QA checks.
Include risk notes.

3. Plan Review

Before execution, confirm:

Correct system.
Correct site.
Correct files.
No protected systems touched.
No unnecessary architecture changes.
QA path included.
Rollback or save point considered.

4. Execution

The AI performs only the agreed changes.

5. Validation

Run checks against the agreed QA list.

6. Status Capture

Record:

Completed changes.
Files changed.
Tests performed.
Remaining issues.
Next action.

7. Clear Or Continue Decision

Decide:

Continue in same context.
Clear and proceed from summary.
Stop and save point.
Start new loop.

MWMS Protected Systems Rule

Before execution, the AI must identify whether the task touches any protected or sensitive system.

Protected systems include:

Brain Room.
Dev Console.
AI Manager.
Employee router.
Supabase connector.
Task executor hooks.
Event logs.
Opportunity system.
Affiliate workflow systems.
HeadOffice newsletter intelligence.
Finance Brain logic.
Experimentation Brain logic.
Live dashboards.
Authentication or permission logic.
Database schema changes.

If a task touches a protected system, planning and QA requirements become stricter.

MWMS Do Not Touch Rule

Every development loop must include a “Do Not Touch” section when relevant.

Example:

Do not touch M’s active build.
Do not alter Brain Room routes unless requested.
Do not change Supabase schema unless explicitly instructed.
Do not alter existing dashboard styling unless requested.
Do not refactor unrelated plugin files.
Do not change production settings.
Do not create duplicate functions.
Do not rename working routes.
Do not change page slugs or MCR naming rules.

AI Behavior Rules

AI coding assistants used inside MWMS must follow these behavior rules:

Do not assume the current architecture.
Inspect before editing.
Ask when the task boundary is unclear.
Identify affected files before changing them.
Explain risk before execution.
Avoid unrelated cleanup.
Avoid “while I’m here” changes.
Preserve working functionality.
Include QA.
Stop when context becomes degraded.
Summarize before clearing.
Never treat untested code as complete.

M Workflow Application

When M uses Claude Code or another AI coding tool for MWMS, the expected working pattern is:

Start with the approved task brief.
Load only the relevant project instruction file.
Ask Claude Code to inspect before editing.
Use Plan Mode or equivalent planning behavior.
Review the plan.
Confirm the files to be changed.
Execute the smallest safe change.
Test in WordPress or Supabase.
Report result.
Save point if stable.
Clear context before the next major step.

This reduces the chance of AI-generated code damaging stable MWMS work.

Dev Console Application

The Dev Console should eventually support this loop by helping Martyn or M generate:

Planning prompts.
Codebase exploration prompts.
QA checklists.
Clear-context summaries.
Save point summaries.
Next-loop briefs.

Future Dev Console upgrades may include a “Plan Execute Clear” mode that produces structured development prompts automatically.

Relationship To Other MWMS Standards

This standard supports and strengthens:

MWMS AI Output Standard Full File Delivery Rule
Ensures execution outputs are complete and controlled.
MWMS Brain Build Order Standard
Ensures development work follows proper sequence.
MWMS MCR To Brain Copy Rule
Ensures canonical rules are not confused with operational copies.
MWMS Supabase Event Schema
Ensures development changes involving events are properly validated.
MWMS Brain Room Operating Model
Supports safe collaboration between Martyn, M, and AI systems.
MWMS Dev Console Standards
Provides a repeatable method for AI-assisted development support.
MWMS Progressive Context Disclosure Standard
Controls which rules are loaded into each development loop.

Drift Protection

This standard protects MWMS against the following forms of drift:

AI begins coding before understanding the system.
AI changes files outside the task scope.
AI breaks stable plugin functionality.
AI forgets protected systems.
AI uses stale assumptions.
AI overloads context with too many rules.
AI skips testing.
AI treats partial implementation as complete.
AI continues working after the context window has degraded.
M receives vague instructions instead of controlled development briefs.
Martyn loses track of what changed between sessions.

Any development task that bypasses planning, QA, and context reset discipline is considered drift.

Architectural Intent

The architectural intent of this standard is to make AI-assisted development inside MWMS safer, repeatable, and scalable.

MWMS is becoming too large for uncontrolled AI coding.

As the system grows across multiple Brain sites, plugins, dashboards, Supabase tables, employee routers, and automation layers, development must be handled through disciplined loops.

This standard converts AI coding from a risky “ask and hope” process into a controlled operating method.

The long-term goal is for every future MWMS development employee to understand:

Plan before changing.
Execute narrowly.
Validate thoroughly.
Clear context when needed.
Continue only from stable state.

Implementation Notes

This standard should be used immediately for:

M’s Claude Code work.
Dev Console task preparation.
AI Manager development.
Brain Room wiring.
HeadOffice dashboard development.
Supabase connector updates.
Employee router work.
Any future AI-assisted plugin development.

Future implementation may include:

A Dev Console prompt generator.
A Plan Execute Clear checklist UI.
A development save point generator.
A QA gate before tasks can be marked complete.
A Code Review AI Employee.
A Development Planner AI Employee.

Change Log

2026-05-19

Created MWMS Plan Execute Clear Development Loop from the Claude Code for Real Engineers course absorption block covering Plan Mode, Plan Execute Clear workflow, context clearing, execution discipline, and QA requirements.

Initial standard created to improve M’s Claude Code workflow, MWMS Dev Console support, and future AI-assisted development systems.

MWMS Claude Code Project Instruction File Standard

Purpose

The purpose of the MWMS Claude Code Project Instruction File Standard is to define how MWMS should use project-level AI instruction files such as CLAUDE.md, AGENTS.md, or equivalent agent guidance files.

This standard exists because MWMS has a large and growing rule system. If all MWMS rules are dumped into a single AI instruction file, the AI may become overloaded, waste context, follow outdated rules, or allow instructions to compete with the current task.

The purpose of the project instruction file is not to contain the whole MWMS Brain.

Its purpose is to act as a short, high-signal operating map for AI coding agents.

The instruction file should tell the AI:

What project it is working inside.
What rules matter immediately.
What systems are protected.
How to behave before editing.
Where deeper rules live.
What current task boundaries apply.
How to test and report completion.

Scope

This standard applies to:

Claude Code usage.
CLAUDE.md files.
AGENTS.md files.
AI coding agent instruction files.
Dev Console development prompts.
M’s development workflow.
AI Manager coding support.
Brain Room development support.
Future MWMS code assistant employees.
Any AI tool used to inspect, edit, or generate MWMS code.

This standard applies across:

mwmsbrain.site
mwmsheadofficebrain.site
mwmscontentbrain.site
future Brain sites
MWMS WordPress plugins
Supabase-connected systems
admin dashboards
task and event systems

Definition

A Project Instruction File is a short markdown file placed inside a codebase to guide AI coding agents.

In Claude Code, this may be a CLAUDE.md file.

In other systems, it may be an AGENTS.md file or equivalent.

For MWMS, this file must not become a giant knowledge dump.

It should function as:

A rule map.
A safety guide.
A project orientation note.
A task boundary reference.
A pointer to deeper standards.
A protection layer against unsafe AI coding.

Core Principle

The core principle is:

The project instruction file should be a map, not an encyclopedia.

It should not contain every MWMS rule, every MCR page, every architecture explanation, or every historical decision.

It should contain only the essential instructions required for the AI to behave safely in the current codebase.

Standard File Role

The MWMS project instruction file should answer these questions:

What is this project?
What type of codebase is this?
What systems are protected?
What must the AI do before editing?
What output format is expected?
What testing is required?
What should the AI never do?
Where are deeper rules located?
What is the current active build scope?
What should be reported after changes?

Required Sections

Every MWMS Claude Code project instruction file should include the following sections.

1. Project Identity

This section defines the project and site.

It should include:

Project name.
Site/domain.
Plugin or codebase name.
Purpose of the system.
Whether the system is live, staging, or experimental.

Example:

# MWMS Project Instructions

Project: MWMS Brain WordPress Plugin
Site: mwmsbrain.site
Purpose: Operational Brain site for MWMS execution workflows.
Status: Active development. Treat existing working systems as protected.

2. Current Active Scope

This section defines what the AI is allowed to work on right now.

Example:

## Current Active Scope

Only work on the Dev Console status display issue described in the current task.

Do not modify Brain Room, AI Manager executor hooks, employee router files, Supabase schema, or Opportunity system files unless explicitly instructed.

This section should be updated per session or per task.

3. Protected Systems

This section lists systems that must not be changed unless specifically requested.

Example:

## Protected Systems

Do not touch these systems unless the task explicitly names them:

- Brain Room
- Dev Console core routing
- AI Manager executor hooks
- Employee router
- Supabase connector
- Opportunity intake workflow
- Affiliate Brain workflow
- Research Brain workflow
- Experimentation Brain workflow
- Finance Brain workflow
- HeadOffice newsletter intelligence
- Existing REST routes
- Existing database schema

4. Required Development Behavior

This section defines how the AI should behave before editing.

Example:

## Required Development Behavior

Before editing:

1. Inspect relevant files.
2. Identify the current implementation.
3. Identify affected files and functions.
4. Explain the safest change path.
5. Include QA checks.
6. Wait for approval if the task is risky or touches protected systems.

Do not refactor unrelated code.
Do not rename working routes.
Do not invent new architecture.
Do not change files outside the task scope.

5. Output Rules

This section defines MWMS output expectations.

Example:

## Output Rules

When providing code changes:

- Provide full replacement file output when requested.
- Do not provide vague patch instructions.
- Include the exact file path.
- Include the exact change purpose.
- Include testing steps.
- Include any assumptions.

6. QA Requirements

This section forces validation into the task.

Example:

## QA Requirements

Every implementation must include a QA checklist.

Relevant checks may include:

- WordPress admin page loads.
- No PHP fatal error.
- REST endpoint responds correctly.
- Supabase insert/update/select works.
- Existing UI still renders.
- Permissions are not weakened.
- Event logging still works.
- No duplicate routes or functions were created.

7. Context Management Rule

This section tells the AI and operator how to handle long sessions.

Example:

## Context Management

Use the Plan Execute Clear Development Loop.

For large tasks:

1. Plan first.
2. Execute only the approved step.
3. QA the result.
4. Summarize what changed.
5. Clear context before continuing to the next major step.

8. Linked Rule Files

This section points to deeper rules without loading them all by default.

Example:

## Deeper MWMS Rules

Only open these when relevant:

- docs/rules/full-file-output.md
- docs/rules/supabase-event-schema.md
- docs/rules/brain-room.md
- docs/rules/dev-console.md
- docs/rules/page-naming.md
- docs/rules/mcr-source-of-truth.md
- docs/rules/plan-execute-clear.md

This is essential for progressive disclosure.

9. Completion Report

This section defines what the AI must provide after work.

Example:

## Completion Report

After implementation, report:

- Files changed.
- What changed.
- Why it changed.
- QA performed.
- Any remaining risks.
- Recommended next step.

Maximum Size Rule

The project instruction file must remain short.

Standard Target

The preferred size is:

500–1,500 words maximum for normal codebases.
Shorter is better if the project is simple.
Longer files require review.

Warning Threshold

If the file becomes large enough that it contains multiple full standards, long histories, old decisions, or unrelated Brain rules, it must be split.

What Must Not Go Into CLAUDE.md

The project instruction file must not contain:

Full MCR page archives.
Entire MWMS Blueprint sections.
Long historical notes.
Old save point chains.
Full course absorption outputs.
Full governance registry copies.
Every Brain rule.
Every plugin specification.
Every newsletter rule.
Every affiliate rule.
Every dashboard specification.
Large code examples unless essential.
Duplicated rules already stored elsewhere.

These should be stored in linked rule files, MCR pages, or task-specific briefs.

Progressive Disclosure Rule

The instruction file should link to deeper standards instead of embedding them.

Example structure:

CLAUDE.md
docs/
  rules/
    full-file-output.md
    plan-execute-clear.md
    supabase-event-schema.md
    dev-console.md
    brain-room.md
    wordpress-plugin-safety.md
    mcr-source-of-truth.md

The AI should load deeper files only when the task requires them.

Active Scope Rule

Every session should include a current scope statement.

Without scope, the AI may overreach.

A good scope statement says:

What to change.
What not to change.
What site is involved.
What files are likely relevant.
What output is expected.
What success means.

Example:

Current Task:
Fix the HeadOffice Queue Review duplicate status display issue.

Allowed:
- Inspect queue review display files.
- Inspect relevant Supabase query logic.
- Suggest exact file changes.

Not Allowed:
- Do not alter Make.com body structure.
- Do not change Brain routing automation.
- Do not touch M’s active Affiliate Brain work.

Protected System Escalation Rule

If the requested change touches a protected system, the AI must stop and produce a plan before editing.

Protected systems include:

Authentication.
Permissions.
Supabase schema.
Event logging.
Task execution.
AI Manager.
Employee router.
Brain Room.
Dev Console.
Live dashboards.
Opportunity intake.
Finance controls.
Experimentation controls.
Any live production workflow.

Safe Editing Rule

The AI must follow safe editing behavior:

Identify the file before changing it.
Explain why the file is relevant.
Avoid unrelated refactoring.
Preserve existing function names unless instructed.
Preserve existing routes unless instructed.
Preserve existing database fields unless instructed.
Avoid inventing new tables.
Avoid adding hidden dependencies.
Avoid changing user-facing behavior outside the task.
Avoid changing working systems just to “clean up.”

Testing Rule

The instruction file must tell the AI that code is not complete until tested.

Testing may include:

Browser page load.
WordPress admin check.
REST endpoint test.
Supabase row check.
PHP error log check.
JavaScript console check.
Button/action check.
Form save check.
Event log check.
Task status transition check.

The AI must provide a QA checklist even if it cannot run the checks itself.

Relationship To MWMS Plan Execute Clear Development Loop

This standard depends on the MWMS Plan Execute Clear Development Loop.

The project instruction file should enforce that loop by default.

It should tell the AI:

Plan first.
Execute only after plan review.
QA before completion.
Summarize before clearing.
Start a new loop for the next major change.

Relationship To MWMS Progressive Context Disclosure Standard

This standard also depends on the MWMS Progressive Context Disclosure Standard.

The instruction file should not contain every rule.

It should point to deeper rule files and load only what is needed.

This avoids instruction overload and preserves AI performance.

Relationship To MCR

The MCR remains the Source of Truth for MWMS governance, architecture, standards, and canonical decisions.

The project instruction file is not the Source of Truth.

It is an operational guidance layer for a specific codebase or development session.

If there is a conflict:

MCR canonical standards win.
Current approved build brief wins for task scope.
Project instruction file guides execution.
AI assumptions lose.

Example MWMS CLAUDE.md Skeleton

# MWMS Claude Code Instructions

## Project Identity

Project: [Project Name]
Site: [Domain]
Codebase: [Plugin or Repo Name]
Status: Active development.

## Current Active Scope

[Describe the current task.]

Allowed:
- [Allowed area 1]
- [Allowed area 2]

Not Allowed:
- [Protected area 1]
- [Protected area 2]

## Required Behavior

Before editing:
1. Inspect relevant files.
2. Identify affected systems.
3. Produce a plan.
4. Include QA checks.
5. Wait for approval if protected systems are touched.

## Protected Systems

Do not touch unless explicitly instructed:
- Brain Room
- Dev Console core routes
- AI Manager
- Employee router
- Supabase schema
- Opportunity system
- HeadOffice newsletter intelligence
- Finance controls
- Experimentation controls

## Output Rules

- Provide exact file paths.
- Provide full replacement files when requested.
- Avoid vague patches.
- Do not refactor unrelated code.
- Do not invent architecture.

## QA Requirements

Every change must include testing steps:
- Page load check
- Error check
- Route check
- Database check if relevant
- UI action check if relevant

## Context Management

Use Plan Execute Clear:
1. Plan
2. Execute
3. QA
4. Summarize
5. Clear before next major task

## Linked Rules

Open only when relevant:
- docs/rules/plan-execute-clear.md
- docs/rules/full-file-output.md
- docs/rules/supabase-event-schema.md
- docs/rules/dev-console.md
- docs/rules/brain-room.md

## Completion Report

Report:
- Files changed
- What changed
- QA performed
- Risks
- Next step

Governance Role

This standard governs how MWMS prepares AI coding agents before they work inside MWMS codebases.

It prevents project instruction files from becoming bloated, stale, or dangerous.

It also ensures AI tools work from:

Clear scope.
Protected system awareness.
Safe planning behavior.
QA expectations.
Progressive rule loading.

Drift Protection

This standard protects MWMS against:

Oversized CLAUDE.md files.
Too many competing rules in context.
AI ignoring current task scope.
AI touching protected systems.
AI making unreviewed architecture changes.
AI skipping tests.
AI operating from stale instructions.
AI confusing MCR governance with codebase execution.
M or Martyn relying on memory instead of explicit task scope.
AI coding sessions degrading due to context overload.

Any instruction file that becomes too large, stale, or unclear must be reviewed and split.

Architectural Intent

The architectural intent of this standard is to make MWMS AI-assisted development scalable.

MWMS cannot rely on one giant prompt or one giant instruction file.

As MWMS grows, the correct model is:

Short project instruction file → linked rule files → task-specific brief → controlled development loop

This allows Claude Code and future AI coding agents to operate safely without being overwhelmed by the full MWMS governance system.

Implementation Notes

This standard should be used when creating or updating:

CLAUDE.md
AGENTS.md
Dev Console development prompts
M task briefs
AI Manager development instructions
Plugin development instructions
Future code assistant employee rules

Recommended next implementation step:

Create a starter CLAUDE.md template for the active MWMS development codebase once M is ready to use it.

Change Log

2026-05-19

Created MWMS Claude Code Project Instruction File Standard from the Claude Code for Real Engineers course absorption block covering CLAUDE.md, AGENTS.md, agent steering, context limits, project rules, testing omissions, and instruction-file structure.

Initial standard created to guide M’s Claude Code use, MWMS Dev Console development, and future AI-assisted codebase work.

MWMS Progressive Context Disclosure Standard

Purpose

The purpose of the MWMS Progressive Context Disclosure Standard is to define how MWMS should expose rules, instructions, standards, and project knowledge to AI systems without overloading them.

MWMS has a large and growing intelligence and governance system. It includes MCR pages, Brain rules, plugin standards, Supabase rules, development save points, newsletter protocols, affiliate frameworks, experimentation rules, finance controls, and many other standards.

If all of this is loaded into an AI session at once, the AI becomes less reliable.

This standard solves that problem by requiring MWMS to reveal context progressively.

The AI should receive:

The minimum essential task context first.
The active rule map second.
Deeper standards only when needed.
Full background only when directly relevant.

The goal is to keep AI responses accurate, focused, and efficient.

Scope

This standard applies to:

Claude Code sessions.
Dev Console prompts.
Brain Room AI requests.
AI Manager tasks.
AI Employee instructions.
M development briefs.
Martyn’s MWMS working sessions.
Course absorption implementation.
Newsletter intelligence routing.
MCR-to-Brain copy decisions.
Future AI agents and automations.

This standard applies wherever an AI system must work with MWMS knowledge.

Definition

Progressive Context Disclosure means giving AI systems only the amount of context needed for the current task, then allowing them to access deeper context only when required.

It prevents context overload by replacing one giant instruction dump with a layered context model.

The basic model is:

Task Brief → Rule Map → Relevant Standards → Deep References

Core Principle

The core principle is:

Do not load the whole MWMS Brain when the AI only needs one working rule.

AI context should be treated as limited working fuel.

Too little context causes mistakes.

Too much context causes confusion.

The correct approach is structured disclosure.

Why This Matters For MWMS

MWMS has a high risk of context overload because it contains:

Multiple Brain systems.
Multiple websites.
MCR governance pages.
WordPress plugin rules.
Supabase architecture.
AI employee logic.
Newsletter intelligence layers.
Affiliate Brain workflows.
Experimentation Brain workflows.
Finance Brain controls.
Course absorption standards.
Development save points.
Active build constraints.
M’s active development work.
Future build plans.

If all of these are supplied at once, the AI may:

Follow the wrong rule.
Mix systems together.
Reference outdated instructions.
Ignore the current task.
Overbuild.
Touch protected systems.
Invent pages or files.
Produce lower-quality output.
Lose track of priority.
Waste context on irrelevant material.

Progressive disclosure prevents this.

Context Layers

MWMS context should be organized into layers.

Layer 1 — Task Brief

This is the immediate task.

It should include:

What needs to be done.
Why it matters.
Which system is affected.
What output is expected.
What must not be touched.
Any known constraints.
Success criteria.

This is the first and most important context layer.

Layer 2 — Active Rule Map

This is a short list of relevant rules for the task.

It should not include full rule text unless needed.

Example:

Relevant rules:
- MCR is Source of Truth.
- Use Full File Output.
- Do not touch M’s active build.
- Follow Plan Execute Clear.
- Confirm correct site/domain.
- Use existing plugin patterns.

The rule map tells the AI what matters without flooding the session.

Layer 3 — Relevant Standards

This layer contains the specific standards needed for the task.

Examples:

Full File Output rule.
Page Naming Standard.
Supabase Event Schema.
Brain Room standard.
Dev Console standard.
Plan Execute Clear Development Loop.
Claude Code Project Instruction File Standard.

Only the standards needed for the task should be loaded.

Layer 4 — Deep References

This layer includes large background material.

Examples:

Full MCR page archives.
Long course absorption outputs.
Architecture registry history.
Multiple Brain registries.
Large plugin specs.
Full newsletter protocols.
Historical save points.

Deep references should be opened only when the AI cannot complete the task correctly without them.

Standard Disclosure Sequence

Every MWMS AI-assisted task should follow this context sequence:

Start with the task brief.
Add current site/domain if relevant.
Add protected systems list if relevant.
Add short active rule map.
Add only the standards needed.
Add deeper references only if necessary.
Remove or clear context when moving to a new task.

Good Context Example

Task:
Create a new MCR page called MWMS Plan Execute Clear Development Loop.

System:
MCR governance page.

Relevant rules:
- Use MWMS Document Structure Standard.
- Use Title Case.
- No dashes or special characters in title.
- Full page output required.
- This is a system-level development standard.
- Do not reference pages that have not been created.

Output:
Full page content ready to paste into WordPress.

This is enough context.

The AI does not need the entire Affiliate Brain, Finance Brain, newsletter system, or plugin codebase for this task.

Bad Context Example

A bad context approach would include:

Full Architecture Registry.
Full Page Naming Standard.
Full Course Absorption Handoff Standard.
Full Supabase schema.
Full newsletter protocol.
Full Affiliate Brain Page Registry.
Full Dev Console history.
Full Brain Room build notes.
Full MCR copy rules.
Full historical chat summaries.

This overloads the AI and creates competing instructions.

Rule Map Standard

MWMS should use rule maps to guide AI tools.

A rule map is a short, task-specific list of relevant standards.

Example:

## Active Rule Map

For this task, follow:

1. MWMS Document Structure Standard.
2. MWMS Page Naming Standard.
3. MWMS Full File Output Rule.
4. MWMS Plan Execute Clear Development Loop.
5. MWMS Do Not Touch M Active Build Rule.

Do not load unrelated Brain rules unless needed.

Rule maps should be used in:

Dev Console prompts.
Claude Code prompts.
M task briefs.
Brain Room AI requests.
Future AI employee instructions.

Linked Context Standard

Instead of embedding every rule in a prompt or instruction file, MWMS should link to deeper context.

Example:

Relevant references:
- docs/rules/full-file-output.md
- docs/rules/plan-execute-clear.md
- docs/rules/supabase-event-schema.md
- docs/rules/dev-console.md

The AI should open or consider only the files relevant to the task.

This keeps the main context small and clean.

MCR Application

In MCR work, progressive disclosure means:

Provide the page being created or updated.
Provide the relevant structural rule.
Provide the correct parent if known.
Provide the exact naming requirement.
Provide any related existing page title if needed.
Do not include unrelated Brain content.

For example, when creating a system-level development standard, the AI does not need Affiliate Brain operational rules unless the page directly affects Affiliate Brain.

Development Application

In development work, progressive disclosure means:

Start with current task.
Identify affected files.
Load only relevant code.
Load only relevant rules.
Use Plan Execute Clear.
Avoid dragging old session history into new tasks.
Summarize before clearing.
Continue from concise state.

For Claude Code, this means:

Keep CLAUDE.md short.
Link to deeper rule files.
Load specific standards only when needed.
Avoid placing the full MWMS Brain into one instruction file.

Brain Room Application

In Brain Room, progressive disclosure means:

AI responses should use the current thread context.
Long historical system rules should not be dumped into every request.
The AI should know where to retrieve deeper rules when needed.
Brain Room tasks should include a short active context map.
Replies should stay aligned to the thread’s purpose.

Future Brain Room automation should support:

Thread-level context summaries.
Rule maps.
Attached standards.
Task-specific context packets.
Context reset between unrelated tasks.

Dev Console Application

In Dev Console, progressive disclosure means:

The user asks a development question.
Dev Console identifies the affected system.
Dev Console loads only the relevant rule map.
Dev Console avoids unrelated MWMS history.
Dev Console returns a precise answer or build brief.
Large tasks are broken into Plan Execute Clear loops.

Future Dev Console upgrades may include a “Context Packet Builder” that creates short task-specific instruction packets for M or Claude Code.

AI Employee Application

Future MWMS AI Employees should not receive the entire MWMS Blueprint in every task.

Each employee should receive:

Its role definition.
Current task.
Relevant Brain rules.
Relevant standards.
Required output format.
Escalation conditions.

Examples:

Affiliate Brain Employee

Should receive:

Offer evaluation rules.
Affiliate compliance rules.
Traffic source constraints.
Current offer data.

Should not receive:

Full Dev Console code rules.
Full Supabase connector build history.
Full Content Brain registry unless relevant.

Development Planner AI

Should receive:

Current development request.
Protected systems.
Plan Execute Clear rule.
Relevant plugin or codebase rules.

Should not receive:

Affiliate campaign scripts.
Newsletter market intelligence unless relevant.

Context Bloat Warning Signs

AI context may be overloaded when the AI:

Repeats old assumptions.
Mentions irrelevant systems.
Confuses sites or domains.
Invents pages.
Suggests touching protected systems.
Produces vague instructions.
Contradicts recent instructions.
Forgets the requested output format.
Overbuilds simple tasks.
Mixes course absorption with development work.
Treats old save points as current state.
Gives generic advice instead of task-specific output.

When these signs appear, clear context and restart with a smaller task-specific packet.

Context Reset Rule

When switching tasks, reset context.

A new task should not automatically inherit the previous task’s full context.

Before continuing, create a short continuation summary:

Current stable state:
- [What is done]
- [What files/pages were changed]
- [What passed QA]
- [What remains]

Next task:
- [Exact next action]

Relevant rules:
- [Short rule map]

Do not touch:
- [Protected systems]

This becomes the starting context for the next loop.

Active Task Packet Standard

For any serious MWMS task, create an active task packet.

Active Task Packet Structure

## Task

[What needs to be done]

## System

[Which Brain/site/plugin/page]

## Current State

[What is currently true]

## Desired Outcome

[What success looks like]

## Relevant Rules

[Short rule map]

## Required References

[Only the standards/files needed]

## Do Not Touch

[Protected systems]

## Output Required

[Full page output, full file output, checklist, plan, etc.]

## QA / Validation

[How we know it worked]

This packet should be used for:

M development briefs.
Claude Code tasks.
Dev Console prompts.
Brain Room AI requests.
Future AI employee tasks.

Relationship To MWMS Claude Code Project Instruction File Standard

This standard directly governs how CLAUDE.md and AGENTS.md files should be structured.

The project instruction file should not contain everything.

It should contain:

Short project identity.
Current scope.
Protected systems.
Rule map.
Links to deeper standards.
QA expectations.

That is progressive disclosure in action.

Relationship To MWMS Plan Execute Clear Development Loop

The Plan Execute Clear loop controls development workflow.

Progressive Context Disclosure controls what information enters each loop.

Together they create a safer development system:

Progressive Disclosure decides what context is loaded.
Plan Execute Clear decides how the task is executed.
QA confirms the result.
Clear removes polluted or stale context before the next loop.

Relationship To MCR

MCR remains the Source of Truth.

Progressive disclosure does not weaken MCR authority.

It simply prevents the AI from needing the entire MCR in every working context.

The AI should receive the relevant MCR rule or page only when the task requires it.

Governance Role

This standard governs how MWMS controls context exposure across AI systems.

It is a system-level safety standard for:

Accuracy.
Efficiency.
Rule compliance.
Reduced hallucination.
Reduced overbuilding.
Reduced protected-system risk.
Better task focus.

It should be considered mandatory for AI-assisted development and recommended for all other AI-assisted MWMS operations.

Drift Protection

This standard protects MWMS against:

Context overload.
Competing instructions.
Stale rule usage.
AI confusion between Brains.
AI confusing MCR with Brain sites.
AI touching protected systems.
AI producing bloated outputs.
AI mixing development and absorption work.
AI losing task focus.
AI hallucinating pages or files.
AI continuing from outdated save points.
AI wasting context on irrelevant history.

Any workflow that loads excessive unrelated context into an AI session should be considered drift.

Architectural Intent

The architectural intent of this standard is to make MWMS scalable as an AI-governed business system.

MWMS cannot operate long term by copying every rule into every prompt.

The correct architecture is layered:

Source of Truth → Rule Map → Task Packet → Relevant Standard → Execution

This lets MWMS maintain a large governance system while still giving AI tools small, focused working contexts.

As MWMS grows, progressive disclosure will become essential for:

AI Employee reliability.
Dev Console accuracy.
Brain Room usefulness.
Claude Code performance.
M’s development speed.
Martyn’s ability to manage many systems without confusion.

Implementation Notes

Immediate use cases:

Claude Code task preparation.
M development briefs.
Dev Console prompts.
Brain Room requests.
MCR page creation.
Course absorption continuation.
Newsletter intelligence review.

Future implementation ideas:

Context Packet Builder.
Rule Map Generator.
AI Employee Context Router.
Dev Console active context selector.
Brain Room thread context summaries.
MCR-linked rule retrieval system.
Protected system warning layer.

Change Log

2026-05-19

Created MWMS Progressive Context Disclosure Standard from the Claude Code for Real Engineers course absorption block covering context bloat, CLAUDE.md size control, linked rule files, and the need to expose AI agents to only the rules required for the current task.

Initial standard created to improve MWMS Claude Code use, Dev Console accuracy, Brain Room task routing, and future AI Employee reliability.