Canonical doctrine
Build the implementation control center. Do not drift into generic SaaS.
This is the source of truth for Warlocks while the MVP is in development. Every feature, screen, copy decision, and data model decision must serve one outcome: helping Accelerator turn approved Murals.ng implementation context into completed real-world work.
Active variant
Hand-painted mural
Launch mode
Staging only
Primary surface
Control center
01
What Warlocks is
Warlocks is the Murals.ng implementation control center. A bounty is the work unit; the product is the command layer.
It begins with one repeatable Murals.ng field workflow: hand-painted mural implementation.
A Playbook link, approved design context, invoice/revenue signal, and target installation location come in. Warlocks turns that into a completed mural through offers, protected briefs, proof packages, review decisions, and payment state.
Philosophically, Warlocks is the instrument through which Accelerator makes things in the real world for Femi, Murals.ng clients, and approved agents.
02
What Warlocks is not
Warlocks is not a CRM, a generic project-management board, a broad marketplace, a contractor directory, a template library, or a design tool.
If a feature makes Warlocks feel like generic SaaS, it is probably wrong for the MVP.
03
MVP proof target
The MVP proves one thing: Warlocks can take a Playbook link plus approved Murals.ng implementation context and reliably drive the field process until a completed mural, proof package, reviewer decision, and payment-ready earnings state exist.
Airtable company brain and CRM bases can enrich the decision, but Warlocks remains the command layer, not a CRM mirror.
04
First bounty only
The only active MVP bounty variant is hand-painted mural implementation under the Mural Implementation template.
The surface size does not need to be known before the bounty is created. The Warlock can determine it during the bounty.
05
UI doctrine
The primary screen is the bounty list. No heavy chrome. No fake analytics. No CRM dashboard. No vanity metric cards.
The product should feel sparse, premium, and field-command: a control center for real-world implementation, not generic SaaS.
06
Development rule
Production stays as a coming-soon page until launch readiness.
Active product work happens on staging until the bounty workflow is strong enough to show publicly.
Required sub-bounties
One parent bounty. Six required gates.
01
Playbook + location intake
02
Surface measurement + site verification
03
Execution scope + material plan
04
Procurement + surface preparation
05
Mural execution
06
Final proof + review receipt
Use this language
Refuse for now
Build review checklist
- 1. Does this make Mural Execution clearer, faster, safer, or more repeatable?
- 2. Does it preserve bounty language?
- 3. Does it avoid CRM/dashboard drift?
- 4. Does it improve proof capture, review, or receipt generation?
- 5. Does it help the Warlock know exactly what to do next?
- 6. Does it help Femi know what is complete, blocked, or risky?
- 7. Does it avoid adding another bounty template prematurely?
- 8. Can it be verified on staging with screenshots or a live URL?