MWMS MCR

MWMS Opportunity Intake Phase One Developer Build Pack

Document Type: Protocol
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: M, mwmsbrain.site Phase 1 build execution, Supabase intake records, plugin/UI implementation, future Brain Request expansion
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11

Purpose

The MWMS Opportunity Intake Phase One Developer Build Pack consolidates all requirements for Phase 1 of the MWMS Opportunity System into a single developer-ready build pack.

Its purpose is to:

  • provide a single build reference for Phase 1 implementation
  • eliminate the need for M to reference multiple pages during the first build
  • define exactly what must be built
  • define exactly what must not be built
  • define completion criteria
  • protect the Phase 1 boundary
  • preserve future Supabase lineage
  • prevent hidden authority logic inside plugin/UI code
  • ensure Phase 1 supports future Opportunity System expansion

This is the execution pack M should follow during development.

The previous version already defined the Phase 1 target as the Affiliate Brain Opportunity Intake System, including the Opportunity Intake Queue, Opportunity Intake Record, and Status Management System. It also clarified that Offer Intelligence, Measurement Planning, Forecasting, Testing, Finance, Dashboards, Automation, AI integrations, advanced scoring, and cross-Brain linking must not be built yet.

Scope

This protocol applies to:

  • Affiliate Brain Intake System
  • mwmsbrain.site Phase 1 build
  • plugin/UI implementation
  • basic database structure
  • opportunity intake records
  • queue display
  • status management
  • manual testing
  • safe save points
  • future compatibility planning

It defines:

  • required features
  • required fields
  • required actions
  • system behaviour
  • completion requirements
  • testing requirements
  • build constraints
  • future compatibility requirements
  • what not to build

It does not include:

  • Offer Intelligence system
  • Measurement Planning
  • Forecasting
  • Testing system
  • Finance controls
  • Research signal system
  • dashboards
  • automation
  • AI integrations
  • full Brain Request automation
  • MCR update automation

Core Principle

Build a simple, usable intake system.

Do not build beyond Phase 1 requirements.

Speed, clarity, stability, and usability are prioritized over completeness.

Phase 1 should create the first real working operational surface on mwmsbrain.site.

The correct Phase 1 goal is:

Martyn can enter an opportunity, save it, see it in a queue, and update its status.

Nothing more is required for Phase 1.

Source Of Truth Rule

MCR remains the Source of Truth.

This build pack gives M permission to build the approved Phase 1 operational surface on mwmsbrain.site.

It does not give permission to:

  • change MCR canon
  • create new MCR rules inside code
  • create direct Brain site to MCR updates
  • build automatic MCR editing
  • create hidden source-of-truth logic inside plugin/UI systems

If M discovers a missing rule, field, workflow, or conflict, M must report it back to Martyn/HeadOffice.

The correct path is:

M identifies issue → HeadOffice review → MCR decision if required

Phase 1 Build Target

System Name

Affiliate Brain Opportunity Intake System

Components To Build

Phase 1 includes only:

  1. Opportunity Intake Queue
  2. Opportunity Intake Record
  3. Status Management System

Do not add additional modules during Phase 1.

1. Opportunity Intake Queue

Required Features

The Opportunity Intake Queue must:

  • display all opportunity records
  • group or filter records by status
  • allow record selection
  • allow opening a record
  • show basic opportunity information
  • update after records are created or edited

Required Fields In Queue

The queue should show:

  • Product Name
  • Platform
  • Vendor Name
  • Date Found
  • Status

Optional if easy:

  • Discovery Source
  • Last Updated

Do not overcomplicate the queue.

Required Status Groups

The queue must support these status groups:

  • New
  • Under Review
  • Rejected
  • Escalated

Required Actions

The queue must support:

  • Open Record
  • Change Status

Status changes may happen from the queue or from the record screen.

Either is acceptable for Phase 1 as long as the behaviour works reliably.

2. Opportunity Intake Record

Required Fields

The Opportunity Intake Record must include the following fields.

Identity Fields

  • Product Name
  • Product Link
  • Platform
  • Vendor Name
  • Discovery Source
  • Date Found

Basic Research Fields

  • Competitors Found
  • Ads Found
  • Notes

Allowed values for Competitors Found:

  • Yes
  • No
  • Unknown

Allowed values for Ads Found:

  • Yes
  • No
  • Unknown

Fit Fields

  • Fits MWMS
  • Exclusion Flag

Allowed values for Fits MWMS:

  • Yes
  • No
  • Unsure

Allowed values for Exclusion Flag:

  • None
  • Compliance Concern
  • Low Quality Offer
  • Poor Fit
  • Insufficient Information
  • Other

Workflow Fields

  • Status
  • Review Notes

Allowed values for Status:

  • New
  • Under Review
  • Rejected
  • Escalated

Required Behaviour

The intake record must:

  • allow all fields to be editable
  • save correctly
  • persist data after reload
  • allow later editing
  • always have a status value
  • not lose data during status changes
  • not require unnecessary clicks

No required field should block save in Phase 1.

Use flexible input so Martyn can capture incomplete opportunities quickly.

3. Status Management System

Allowed Statuses

Only these statuses are required in Phase 1:

  • New
  • Under Review
  • Rejected
  • Escalated

Required Actions

Reject

Sets status to:

Rejected

Under Review

Sets status to:

Under Review

Escalate

Sets status to:

Escalated

Behaviour Requirements

Status management must:

  • persist status changes
  • update the UI immediately after save/action
  • prevent invalid states
  • ensure status always has a value
  • preserve all record data during status changes

System Behaviour Requirements

The system must:

  • save records reliably
  • display records after creation
  • update status reliably
  • persist data after refresh
  • handle multiple records
  • allow fast data entry
  • allow records to be reopened
  • avoid confusing screens
  • avoid unnecessary complexity
  • show the current state clearly

This system should feel like a practical working intake tool.

User Flow

Step 1

Martyn creates a new opportunity.

Step 2

Martyn fills in basic fields.

Step 3

Martyn saves the record.

Step 4

The record appears in the queue.

Step 5

Martyn opens the record again.

Step 6

Martyn reviews and sets status.

Step 7

The queue reflects the updated status.

Completion Criteria

Phase 1 is complete when:

  • records can be created
  • records can be saved
  • records appear in the queue
  • records can be reopened
  • records can be edited
  • statuses can be changed
  • data persists after reload
  • multiple records behave correctly
  • system is usable without confusion
  • no visible UI errors exist
  • no obvious data loss occurs
  • no later-phase features have been added

Testing Requirements

M must verify:

  • record creation works
  • save works
  • edit works
  • queue display works
  • status updates work
  • data persists after reload
  • multiple records behave correctly
  • status has a default value
  • no invalid status can be saved
  • no UI errors exist
  • no record data is lost during status changes

Testing should be manual and simple.

Do not build a full testing framework for Phase 1.

What Not To Build

Do not include:

  • Offer Intelligence
  • Measurement Planning UI
  • Forecasting systems
  • Testing workflows
  • Finance logic
  • Research Brain signal systems
  • Dashboards
  • Automation
  • AI integrations
  • Advanced scoring
  • Cross-Brain linking
  • Full Brain Request automation
  • HeadOffice dashboard reporting
  • MCR update automation
  • Sync from Brain site back to MCR
  • Duplicate registries inside mwmsbrain.site

These are later phases.

Phase 1 must stay narrow.

Build Constraints

M must:

  • keep UI simple
  • avoid unnecessary features
  • minimize clicks
  • prioritize clarity
  • avoid premature structure complexity
  • avoid overengineering
  • maintain future expandability
  • preserve MCR authority
  • avoid hidden canon logic in code
  • create a stable first surface before adding features

Future Compatibility Rule

Even though Phase 1 is simple, the system must allow future expansion.

The system should later be able to connect to:

  • offer evaluation
  • Research Brain request
  • Experimentation Brain handoff
  • Finance Brain review
  • Brain Requests
  • task records
  • event records
  • result records
  • feedback records
  • HeadOffice visibility
  • dashboards

This does not mean building those features now.

It means avoiding hard-coded limitations that would block them later.

Supabase Future Lineage Rule

If Supabase is used in Phase 1, the structure must not block future lineage.

Phase 1 records should be able to later connect to:

  • opportunity_id
  • offer_id
  • brain_request_id
  • task_id
  • event_id
  • result_id
  • feedback_id

Phase 1 does not need to fully implement these relationships.

But it must not be built in a way that prevents them later.

Tasks should remain subordinate to future Brain Requests.

Event Logging Preparation

Where practical, Phase 1 should prepare for simple event logging.

Useful future events include:

  • opportunity_created
  • opportunity_updated
  • status_changed
  • opportunity_rejected
  • opportunity_escalated

If event logging is not wired yet, M should note:

Event logging not yet wired

Do not fake logs.

Do not silently create unusable event records.

Brain Request Preparation

Phase 1 does not require full Brain Request automation.

However, the system should be designed so Escalated can later become a structured Brain Request.

For Phase 1:

  • Escalate may only set the record status to Escalated.
  • Later, Escalate may create a Brain Request.
  • Do not build Escalate as a dead-end action.
  • Do not build full cross-Brain routing yet.

Safe Save Point Requirement

At the end of a meaningful development session, M must provide a safe save point.

The save point should include:

  • what was built
  • what works
  • what does not work yet
  • what files were touched
  • what database tables or fields were touched
  • whether Supabase was changed
  • whether event logging was changed
  • what was tested
  • what still needs testing
  • next recommended step
  • any missing MCR instruction or blocker

This protects continuity.

Blocker Reporting Rule

If M hits uncertainty, M should not guess.

M should report the blocker clearly.

A blocker report should include:

  • what M was trying to build
  • what is unclear
  • what decision is needed
  • whether it affects UI
  • whether it affects Supabase
  • whether it affects MCR
  • whether it affects future phases
  • suggested safe temporary option if one exists

HeadOffice or Martyn then decides.

Dependencies

This build pack is governed by:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Operating Protocol
  • MWMS Opportunity System Build Order
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS MCR To Brain Copy Rule
  • MWMS MCR Brain Wiring Map
  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol
  • MWMS Standard Cross Brain Flow
  • MWMS Supabase Task Schema Standard
  • MWMS Plugin Build Instruction Standard

This build pack is derived from:

  • Affiliate Brain Offer Intake Form
  • Affiliate Brain Opportunity Intake Workflow
  • Affiliate Brain Intake Screen Specification

Controlled Loss Alignment

This phase supports the MWMS Controlled Loss Principle by:

  • enforcing structured opportunity entry
  • enabling early filtering
  • preventing untracked decisions
  • reducing random testing
  • preparing clean input for future testing
  • creating a record before spend occurs

Governance Role

This document ensures:

  • Phase 1 build is executed correctly
  • development is focused
  • system integrity is maintained
  • unnecessary complexity is avoided
  • future phases can be layered cleanly
  • MCR remains Source of Truth
  • M’s build lane stays clear
  • mwmsbrain.site becomes practically useful
  • HeadOffice can later observe the system

Drift Protection

The system must prevent:

  • overbuilding
  • adding future features early
  • deviating from scope
  • incomplete implementation
  • early introduction of measurement or testing logic
  • hidden canon logic in code
  • MCR direct updates from Brain site
  • uncontrolled cross-Brain automation
  • disconnected records
  • fake event logs
  • future lineage dead ends

Architectural Intent

This build pack ensures MWMS begins with:

a working intake system

It provides:

  • real usage
  • real data
  • real feedback
  • basic workflow
  • stable first interaction
  • future expansion path

before expansion into later phases.

The architectural intent is:

Build the smallest useful system first, but do not block the larger system later.

Final Rule

Phase 1 is only the Affiliate Brain Opportunity Intake System.

Build:

  • queue
  • record screen
  • status management

Do not build:

  • evaluation
  • measurement
  • forecasting
  • testing
  • finance
  • dashboards
  • automation
  • AI
  • cross-Brain linking
  • MCR update automation

Keep it simple, stable, and expandable.

Change Log

v2.0 — 2026-04-25

Updated Build Pack to:

  • align with updated Opportunity System Flow
  • clarify Phase 1 boundaries
  • prevent early measurement and forecasting implementation
  • add future compatibility rule
  • improve developer clarity and constraints

Pages Updated:

  • MWMS Opportunity Intake Phase One Developer Build Pack

Pages Created:

  • None

Registries Requiring Update:

  • None

v2.1 — 2026-05-11

Updated Build Pack to align with:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Operating Protocol
  • MWMS MCR To Brain Copy Rule
  • MWMS MCR Brain Wiring Map
  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol
  • MWMS Standard Cross Brain Flow

Added:

  • Source Of Truth Rule
  • Supabase Future Lineage Rule
  • Event Logging Preparation
  • Brain Request Preparation
  • Safe Save Point Requirement
  • Blocker Reporting Rule
  • stronger no-MCR-direct-update protection
  • clearer Phase 1 completion and testing requirements

Change Impact Declaration

Pages Updated:
MWMS Opportunity Intake Phase One Developer Build Pack

Pages Created:
None

Pages Deprecated:
None

Registries Requiring Update:
None

Canon Version Update Required:
No

Monthly Change Log Entry Required:
Optional — only required if HeadOffice wants this build pack update recorded in the current MWMS System Change Log.