# Meravoq Launch Factory Plan Status: execution spec Product name: Meravoq Date: 2026-04-30 Repo: `waterme7on/shopify-24h-llm-launch-plan` ## 0. Naming Decision `Meravoq` is the working product brand for the multi-store launch factory. The intended brand meaning is: ```text Meravoq = market signal + evoke action ``` It should feel less literal than `StoreFlow` or `CartFoundry`. The product is not just a store builder. It is the operating layer that catches market signals, turns them into Shopify experiments, and keeps the decision trail visible after launch. Quick public-name screening on 2026-04-30 did not show an obvious same-category Shopify or ecommerce SaaS collision for `Meravoq`. A DNS check in this workspace also did not show A or CNAME records for `meravoq.com`. This is not a trademark, registrar, app-store, or social-handle clearance. Before any public launch: - Run trademark and domain checks. - Check GitHub, app stores, X, LinkedIn, YouTube, and product directories. - Keep a fallback name ready until the public surface is registered. Working decision: ```text Working product brand: Meravoq Tagline: Turn market signals into live commerce experiments. Chinese positioning: 把市场信号变成可上线、可投流、可复盘的店铺实验。 ``` ## 1. What This Is Meravoq is not a new ecommerce backend. It is the control layer above Shopify that turns the existing `shopify-24h-launch` system into a multi-store launch factory: ```text new idea -> pre-launch pipeline -> 24H launch workspace -> Shopify store setup -> Cloudflare conversion funnel -> small-budget traffic test -> post-launch operating dashboard -> continue / iterate / scale / kill ``` The bottom of the stack stays Shopify: - products - variants - cart - checkout - payments - orders - customer notifications - inventory primitives The new layer owns coordination: - idea intake - stage tracking - agent handoffs - scorecards - artifacts - approval gates - funnel generation - campaign planning - metrics snapshots - portfolio-level decisions ## 2. Premises These premises came from the current conversation and existing repo: 1. Keep Shopify as the commerce source of truth. 2. Reuse the existing 24H launch workflow instead of replacing it. 3. Add a multi-store control plane above the workflow. 4. Before launch, the main question is "where is this idea in the pipeline?" 5. After launch, the main question is "what do the operating numbers say?" 6. Use `build.warp.dev` as an information-architecture reference, not as a visual clone. 7. Every agent output must leave evidence, owner, state, and next action. 8. Real money actions need explicit approval: ad publishing, budget increases, payment changes, product compliance approval, supplier purchase, and domain changes. Premise risk: - Store groups can become operationally chaotic fast. The system must make killing weak ideas easier than opening more stores. - Multiple Shopify stores multiply account, domain, payment, support, inventory, and ad-account risk. The plan must show state and blockers clearly. - "More automation" is not the product. Faster, cleaner decisions are the product. ## 3. Build.warp.dev Reference `build.warp.dev` is useful because it makes work visible: - top-level count of work in progress - status distribution - recent activity - personal blockers - links into the underlying system of record - stage names that map to real workflow states Meravoq should borrow that shape and translate it into ecommerce launch language: ```text Warp-like work states: Open -> Triaged -> Planning -> Implementing -> Reviewing -> Shipped Meravoq pre-launch states: Captured -> Researching -> Supply Validating -> Scoring -> Approved -> Building Store -> Building Funnel -> QA -> Ready To Launch -> Launched Meravoq post-launch states: Testing -> Iterating -> Scaling -> Paused -> Killed -> Archived ``` The important idea is not the exact UI. The important idea is that every item has one state, one owner, one next action, and a clear link to the underlying artifact. ## 4. Existing Code Leverage | Existing asset | Reuse decision | | --- | --- | | `docs/shopify-24h-llm-collaboration-plan.md` | Keep as the single-store launch workflow contract. | | `docs/scoring-matrices.md` | Reuse for product, supply, compliance, and media gates. | | `docs/agent-handoff-template.md` | Reuse for all agent handoffs in a launch workspace. | | `docs/cloudflare-agents-architecture-reference.md` | Reuse the Worker + Durable Object direction for live state. | | `skills/shopify-24h-launch/` | Keep as the single-launch skill package; extend later only after the multi-store plan stabilizes. | | `index.html` / `deck/` | Keep as current human-readable operating board and presentation layer. | | `scripts/validate-static.mjs` | Keep as static validation. Add Meravoq doc checks later if the dashboard becomes first-class. | | `.github/workflows/deploy-cloudflare-pages.yml` | Keep for static site deployment. Worker backend will need a separate deploy path later. | Do not rebuild the existing 24H plan. Meravoq wraps it. ## 5. Dream State ```text CURRENT STATE Static 24H Shopify launch plan Skill package for single-launch coordination No durable multi-store execution state THIS PLAN Meravoq product brand and architecture Pre-launch pipeline states Post-launch operating model Data model, UI, automation boundaries, rollout phases 12-MONTH IDEAL A launch command center where a new idea becomes a scored launch workspace, a Shopify-ready store packet, a Cloudflare funnel, first traffic tests, and a clear kill/scale decision without losing context across agents or stores. ``` ## 6. Implementation Alternatives ### Approach A: Docs + Templates First Summary: Extend the current static repo with Meravoq docs, launch workspace templates, store registry templates, and manual metrics sheets. Effort: S Risk: Low Pros: - Fastest path to operational clarity. - No new infrastructure. - Keeps current Cloudflare Pages deployment intact. Cons: - No live state. - Manual copying between templates. - Weak portfolio metrics. Reuses: - Existing docs, skill, scorecards, launch packet template, static site. ### Approach B: Static Dashboard MVP Summary: Add a static or file-backed dashboard to the existing Pages site. Ideas, launches, stores, and metrics live in JSON files checked into the repo or generated locally. Effort: M Risk: Medium Pros: - Makes the build.warp.dev-style pipeline visible quickly. - Can validate the information architecture before adding a backend. - Still deploys through the current Pages workflow. Cons: - State changes require commits or local generation. - Not safe for secrets or private operational data. - Does not solve multi-user or real-time coordination. Reuses: - `index.html`, `script.js`, `styles.css`, existing Cloudflare Pages workflow. ### Approach C: Live Meravoq Control Plane Summary: Add a Cloudflare Worker + Durable Object backend. Each idea or launch becomes a durable workspace with SQLite state, handoffs, artifacts, phase timers, and controlled integrations. Effort: L Risk: Medium Pros: - Correct long-term architecture. - Supports live state, approvals, schedules, and agent handoffs. - Fits the existing Cloudflare Agents architecture reference. Cons: - New backend deployment path. - Requires auth, secrets, API boundaries, and database schema. - Needs more QA and security work before touching real ad or Shopify writes. Reuses: - Cloudflare Agents reference, 24H workflow, scorecards, handoff template. Recommendation: Start with Approach A in this commit, then build Approach B as the first product surface. Do not jump straight to Approach C until the pipeline shape has survived real use with at least a few launch ideas. ## 7. Product Scope ### In Scope - Naming decision and project positioning. - Pre-launch idea pipeline. - Post-launch operating dashboard. - Store registry model. - Launch workspace model. - State machines for ideas, launches, stores, campaigns, and decisions. - Agent automation boundaries. - Human approval gates. - Metrics model. - Cloudflare + Shopify integration plan. - Rollout plan from docs to live control plane. - Test, security, observability, and deployment planning. ### Not In Scope - Building a replacement cart, checkout, payment, or order system. - Fully autonomous ad publishing without approval. - Fully autonomous supplier ordering. - Scraping private supplier or ad-platform data through unsafe methods. - Running adult/P2 products through normal Meta/TikTok assumptions. - Multi-tenant SaaS billing for third-party users. - Claiming final legal availability for the `Meravoq` name before trademark, registrar, app-store, GitHub, and social-handle checks. ## 8. System Architecture ```text Human operator | v Meravoq dashboard | +--> Pre-launch pipeline | idea intake | research status | supply validation | scorecards | approval gates | +--> Post-launch operations | traffic metrics | funnel metrics | sales metrics | profit metrics | ops metrics | v Meravoq control plane | +--> LaunchCoordinator | launch state | agent owners | handoff log | decision log | risk register | +--> Evidence/artifact storage | scorecards | supplier screenshots | creative briefs | Shopify import payloads | funnel specs | +--> Integration adapters Shopify Admin API Cloudflare Pages/Workers analytics reporting ad reporting supplier evidence collection External systems | +--> Shopify: product, checkout, payment, order source of truth +--> Cloudflare: conversion funnel, dashboard, Workers, Durable Objects +--> Meta/TikTok/Google: campaign setup and reporting +--> 1688/Alibaba: supplier evidence and sourcing notes ``` Recommended backend shape when live: ```text Cloudflare Pages static shell and public operating board Cloudflare Worker authenticated Meravoq API webhook receiver integration proxy LaunchCoordinator Durable Object one per launch workspace or store group owns state transitions and approval checks DO SQLite canonical workspace state handoffs decisions risk register metrics snapshots D1 optional cross-store reporting once multiple workspaces exist R2 screenshots supplier evidence generated creative assets exported launch packets ``` ## 9. Core Objects ### Idea Pre-launch object. Exists before there is a Shopify store. Fields: - `id` - `title` - `category` - `target_market` - `hypothesis` - `source` - `risk_tier` - `created_at` - `current_stage` - `owner` - `next_action` - `blockers` ### Launch 24H execution object. Created when an idea enters the launch pipeline. Fields: - `id` - `idea_id` - `launch_window` - `current_phase` - `status` - `main_product` - `backup_products` - `artifacts` - `handoffs` - `decision_log` - `risk_register` - `approval_requests` ### Store Shopify object. Created only after the idea passes scoring. Fields: - `id` - `launch_id` - `shopify_store_url` - `primary_domain` - `theme_template` - `main_product_id` - `checkout_status` - `payment_status` - `shipping_status` - `policy_pages_status` - `tracking_status` ### Funnel Cloudflare conversion object. Fields: - `id` - `launch_id` - `url` - `quiz_steps` - `recommendation_rules` - `offer_stack` - `checkout_handoff_url` - `utm_policy` - `event_map` - `qa_status` ### Campaign Traffic object. Starts as a plan and becomes live only after approval. Fields: - `id` - `launch_id` - `channel` - `campaign_structure` - `budget` - `creative_ids` - `utm_template` - `approval_status` - `live_status` - `metrics_snapshots` ### MetricSnapshot Post-launch measurement object. Fields: - `id` - `store_id` - `campaign_id` - `date` - `spend` - `impressions` - `cpm` - `ctr` - `cpc` - `lpv` - `quiz_start` - `quiz_complete` - `product_view` - `add_to_cart` - `initiate_checkout` - `purchase` - `orders` - `revenue` - `aov` - `cpa` - `roas` - `cogs` - `shipping_cost` - `refunds` - `contribution_margin` ### Decision Portfolio decision object. Fields: - `id` - `subject_type` - `subject_id` - `decision` - `reason` - `evidence` - `confidence` - `owner` - `created_at` Allowed decisions: - `continue` - `iterate` - `scale` - `pause` - `kill` - `archive` ## 10. State Machines ### Idea / Launch Pipeline ```text Captured | v Researching | v Supply Validating | v Scoring | +-- score fail --------------------> Rejected | +-- needs human decision ----------> Needs Review | | | v | Approved | v Building Store | v Building Funnel | v QA | +-- QA fail -----------------------> Blocked | | | v | QA | v Ready To Launch | +-- approval denied ---------------> Paused | v Launched ``` Invalid transitions: - `Captured -> Building Store`: blocked because research and scoring are missing. - `Scoring -> Building Store` with `New Entrant Score < 3`: blocked by hard gate. - `Building Funnel -> Launched` without QA: blocked by launch readiness gate. - `Ready To Launch -> Launched` without human approval: blocked by approval gate. ### Post-Launch Store State ```text Launched | v Testing | +-- weak signal -------------------> Iterating | | | v | Testing | +-- positive signal ----------------> Scaling | +-- no signal / hard fail ----------> Killed | +-- temporary issue ----------------> Paused | v Testing Killed -> Archived Scaling -> Archived Paused -> Archived ``` Scale gate: - contribution margin positive - CPA below tolerance - refund and return risk acceptable - at least 2 angles show repeatable signal - supplier and inventory can handle next step Kill gate: - traffic but no add-to-cart - add-to-cart but checkout cannot convert after offer fixes - compliance or payment risk blocks the channel - supply chain cannot support the product - new entrant space was misread ## 11. Dashboard Information Architecture The product has two visible layers: 1. Human layer: `/login` and `/dashboard`. This is the CEO/client board. It shows pipeline state, charts, store tables, decisions, metrics, blockers, and recent activity. It does not expose execution prompts by default. 2. Agent layer: `/agent-queue` plus `/api/agent/v1/*`. This is for local Codex, Claude, or future MCP clients. It exposes task context, schemas, dry-run packets, result validation, and approval boundaries. The dashboard itself still has two operating modes. ### Mode A: Pre-Launch Pipeline For ideas that are not live yet. Primary question: ```text Where is this idea blocked before launch? ``` First screen: ```text +----------------------------------------------------------------+ | Meravoq | | Ideas: 18 | Active launches: 4 | Ready: 1 | Live stores: 3 | +----------------------------------------------------------------+ | Pipeline | | Captured | Researching | Supply | Scoring | Build | QA | Ready | | 5 | 4 | 3 | 2 | 2 | 1 | 1 | +----------------------------------------------------------------+ | My Blockers | | - Approve P1 compliance framing for "holiday shapewear gift" | | - Confirm Shopify dev token for store #sf-024 | | - Decide whether to kill "heated loungewear insert" | +----------------------------------------------------------------+ | Recent Launch Activity | | - sf-023 moved Supply -> Scoring | | - sf-021 funnel QA failed: checkout handoff missing UTM | | - sf-018 launched first Meta test | +----------------------------------------------------------------+ ``` Detail page for one launch: ```text Launch: sf-024 holiday comfort kit Status: Building Funnel Owner: Conversion Agent Time left: H14-H18 Artifacts [x] market-research-table [x] product-shortlist [x] supply-sheet [x] profit-model [x] compliance-review [x] brand-brief [x] shopify-build-sheet [ ] conversion-page-brief [ ] creative-matrix [ ] media-plan [ ] tracking-checklist [ ] 30-day-operating-plan Next action Build quiz funnel and map checkout handoff. Blockers None ``` ### Mode B: Post-Launch Operations For live stores. Primary question: ```text Should this store continue, iterate, scale, pause, or die? ``` First screen: ```text +----------------------------------------------------------------------------+ | Store Portfolio | | Live: 7 | Testing: 3 | Iterating: 2 | Scaling: 1 | Killed this week: 4 | +----------------------------------------------------------------------------+ | Store | State | Spend | Revenue | ROAS | Margin | Next Action | | sf-018 | Testing | $120 | $86 | 0.72 | -$48 | rewrite hook | | sf-019 | Scaling | $480 | $1,420 | 2.96 | $392 | raise budget | | sf-020 | Killed | $75 | $0 | 0.00 | -$75 | archive | +----------------------------------------------------------------------------+ | Decision Queue | | - sf-018: iterate. CTR ok, ATC weak. Try bundle + shipping threshold. | | - sf-019: scale. Positive margin, 2 angles working. Approve budget +30%? | | - sf-020: kill. No ATC after 2 creative rounds. | +----------------------------------------------------------------------------+ ``` ## 12. Interaction States | Feature | Loading | Empty | Error | Success | Partial | | --- | --- | --- | --- | --- | --- | | Idea pipeline | Skeleton columns with stage counts pending | "No ideas captured. Add one idea to start the 24H gate." | Show failed data source and retry | Stage counts and cards visible | Some stages loaded, missing metrics badge | | Launch detail | Artifact checklist skeleton | "Launch workspace has no artifacts yet." | Show blocker and owner | Checklist, owner, next action visible | Some artifacts missing evidence | | Store portfolio | Table skeleton | "No live stores yet. Launch a tested idea first." | Reporting source failure | Store rows with decision status | Some channel metrics missing | | Decision queue | Pending recommendation spinner | "No decisions needed." | Explain which rule failed | Continue/iterate/scale/kill recommendations | Recommendation present but confidence low | | Approval gate | Pending risk summary | "No approvals requested." | Approval action failed, retry safe | Approval recorded in decision log | Approval blocked by missing compliance evidence | ## 13. Agent Automation Boundaries ### Safe To Automate - Create idea briefs. - Generate scorecards. - Summarize evidence. - Draft supplier sheets. - Draft brand briefs. - Draft product copy. - Generate Shopify product import payloads. - Generate funnel specs. - Generate creative matrices. - Generate media plans. - Generate UTM templates. - Run static QA. - Produce daily operating recommendations. - Draft kill/scale reasoning. ### Requires Human Approval - Opening or modifying real ad campaigns. - Increasing ad budget. - Publishing a product to a live store. - Enabling or changing payment methods. - Buying inventory. - Contacting suppliers with binding commitments. - Using adult/P2 product assumptions. - Connecting a production domain. - Rotating or changing production credentials. ### Must Never Happen - Print or commit Shopify Admin API tokens. - Store ad account credentials in repo, DO SQLite, D1, KV, R2, or browser local storage. - Fake compliance approval. - Hide a risky product under ordinary paid-social assumptions. - Auto-scale spend without explicit approval. - Treat hallucinated supplier or trend evidence as observed fact. ## 14. Data Flow ### Pre-Launch Happy Path ```text Idea input -> Idea Intake Agent normalizes brief -> Research Agent collects evidence -> Supply Agent validates 1688/Alibaba -> Product Agent scores candidate -> Compliance Agent assigns P0/P1/P2 -> Coordinator approves or rejects -> Shopify Agent prepares product import payload -> Conversion Agent prepares funnel -> QA verifies store/funnel/tracking -> Human approves launch -> Store enters Testing ``` ### Shadow Paths ```text nil idea -> reject with "missing idea brief" empty evidence -> move to Blocked, owner Research Agent supplier timeout -> record source failure, retry later, do not fabricate supply data compliance P2 -> route to high-risk branch, block normal paid-social plan Shopify API failure -> keep launch in Building Store, record exact API error, retry only if safe funnel QA failure -> move to Blocked, attach screenshot or failing URL ``` ### Post-Launch Data Flow ```text Ad platform reporting -> Campaign metrics snapshot -> Meravoq metric normalization -> Funnel and sales metrics join -> Profit calculation -> Decision rule evaluation -> Decision queue -> Human approval for scale/pause/kill if money or account state changes ``` ## 15. Error And Rescue Registry | Codepath | What can go wrong | Rescue action | User sees | | --- | --- | --- | --- | | Idea intake | Missing category, market, or hypothesis | Reject and request missing fields | "Idea brief incomplete. Add category, target buyer, and hypothesis." | | Research evidence | Source unavailable or blocked | Mark source unavailable, continue with lower confidence | "Research partial. Google Trends unavailable." | | Supply validation | Supplier page unavailable, suspicious MOQ, unclear certification | Block scoring until verified or reject | "Supply blocked. Certification unclear." | | Score calculation | Missing score dimension | Prevent approval until all hard gates are present | "Scoring incomplete. New Entrant Score missing." | | Compliance review | Product is P2 or platform/payment unclear | Route to high-risk branch and block normal paid social | "Compliance veto for normal Meta/TikTok plan." | | Shopify import | API auth failure, validation error, duplicate SKU | Do not retry blindly. Record exact error and owner | "Shopify import failed. Check token/scope/SKU." | | Funnel deploy | Cloudflare build/deploy failure | Keep prior version, record deploy log | "Funnel deploy failed. Existing funnel unchanged." | | Tracking QA | Pixel/GA4/TikTok event missing | Block launch readiness | "Tracking incomplete. Purchase event not observed." | | Metrics ingest | API rate limit or partial channel data | Retry with backoff, mark metric partial | "Metrics partial. TikTok unavailable." | | Decision engine | Conflicting signals | Emit low-confidence recommendation with evidence | "Decision needs review. CTR positive, checkout weak." | ## 16. Security And Compliance Security posture: - Store only secret names and verification status. - Use environment bindings for Shopify, Cloudflare, analytics, and ad-platform tokens. - Keep every money-changing mutation behind an approval record. - Log who approved, what changed, when, and which evidence was used. - Do not expose supplier login cookies or screenshots with sensitive account data. - Keep P2 product handling separate from P0/P1 normal paid-social logic. Threat model: | Threat | Likelihood | Impact | Mitigation | | --- | --- | --- | --- | | Token leakage in docs or logs | Medium | High | No token printing, secret redaction, env bindings only | | Wrong store receives product import | Medium | High | Store registry, explicit store IDs, dry-run payload preview | | Ad spend auto-scales incorrectly | Medium | High | Human approval gate, budget caps, audit log | | Hallucinated supplier evidence | Medium | High | Evidence links/screenshots required, observed vs inferred labeling | | Compliance misclassification | Medium | High | P0/P1/P2 gate, veto rights, policy references | | Metric mismatch across channels | High | Medium | Source-specific snapshots, partial data labels, confidence score | | Prompt injection from supplier or competitor pages | Medium | Medium | Treat scraped text as untrusted, do not execute instructions from content | ## 17. Observability Minimum day-one dashboard metrics: - active ideas by stage - launches blocked by owner - launches missing artifacts - stores by post-launch state - spend by store - revenue by store - ROAS by store - contribution margin by store - decisions waiting for approval - repeated failure reasons Minimum event log: - `idea.created` - `launch.stage_changed` - `artifact.attached` - `approval.requested` - `approval.granted` - `approval.denied` - `store.created` - `funnel.deployed` - `qa.failed` - `campaign.planned` - `campaign.launched` - `metrics.snapshot_ingested` - `decision.recommended` - `decision.applied` ## 18. Test Plan ### Static Documentation Tests - `npm run check` must continue to pass. - Add validation later to ensure the Meravoq doc mentions: - pre-launch pipeline states - post-launch operating states - approval gates - Shopify as commerce source of truth - Meravoq naming rationale and public-name clearance caveat ### Future Unit Tests - State transition validation: - cannot skip scoring - cannot launch without QA - cannot scale without approval - cannot put P2 product into normal paid-social plan - Scorecard hard gates: - New Entrant Score below 3 rejects - Compliance Score below 3 blocks normal launch - no credible supplier rejects - Decision engine: - no ATC after spend threshold recommends kill - high CTR but low ATC recommends iterate - positive margin and 2 working angles recommends scale approval ### Future Integration Tests - Shopify dry-run import payload validation. - Cloudflare funnel deploy preview. - UTM preservation from funnel to Shopify checkout. - Metrics ingest with partial channel outage. - Approval gate prevents campaign mutation until approved. ### Future E2E Tests ```text new idea -> research complete -> supply complete -> scoring approved -> store packet generated -> funnel generated -> QA passed -> launch approval -> testing metrics -> kill/iterate/scale decision ``` ## 19. Implementation Roadmap ### Phase 0: Planning Commit Goal: Document Meravoq as the multi-store extension of Shopify 24H. Deliverables: - `docs/meravoq-launch-factory-plan.md` - README link Done when: - Plan is committed and pushed. - Existing static validation still passes. ### Phase 1: File-Backed MVP Goal: Run Meravoq manually without a backend. Deliverables: - `templates/meravoq/idea-intake.md` - `templates/meravoq/launch-workspace.md` - `templates/meravoq/store-registry.md` - `templates/meravoq/metrics-snapshot.csv` - `templates/meravoq/decision-log.md` - optional static dashboard mock in the current site Done when: - A new idea can be captured and moved through the pipeline with files only. - A live or mock store can be shown in the portfolio table. ### Phase 2: Static Dashboard Goal: Make the pipeline visible in the current Cloudflare Pages site. Deliverables: - `data/meravoq/*.json` - pipeline summary - blocker queue - recent activity feed - store portfolio table - launched vs pre-launch view split Done when: - The dashboard can render multiple ideas and stores from static JSON. - `npm run check` validates required states and objects. ### Phase 3: Live Control Plane Goal: Add durable state without touching money-changing actions yet. Deliverables: - Cloudflare Worker API - LaunchCoordinator Durable Object - DO SQLite schema - R2 evidence bucket - authenticated dashboard session - stage transition API - artifact attachment API - approval request API Done when: - A launch workspace can be created, moved through states, and exported. - No production Shopify or ad mutation happens without approval. ### Phase 4: Shopify And Funnel Automation Goal: Generate and verify store/funnel assets. Deliverables: - Shopify product import dry-run - Shopify product import after approval - policy/page copy generator - Cloudflare funnel generator - tracking QA checklist - Browser Rendering smoke checks Done when: - A passed idea can produce a Shopify-ready product packet and deployed funnel. - QA can prove the funnel reaches Shopify checkout or product page. ### Phase 5: Metrics And Decision Engine Goal: Operate live stores with clear kill/iterate/scale decisions. Deliverables: - metrics snapshot ingestion - normalized traffic/funnel/sales/profit model - decision rules - decision queue - daily summary - portfolio view Done when: - Every live store has an operating state and next action. - Weak stores are killed faster than new stores are added. ### Phase 6: Controlled Media Automation Goal: Move from media planning to approved campaign mutations. Deliverables: - ad-platform read connectors - campaign draft generator - approval-gated publish action - budget cap enforcement - rollback/pause action Done when: - Meravoq can draft campaign structures automatically. - No campaign goes live or scales without explicit approval. ## 20. Workstream Parallelization | Workstream | Modules | Depends on | | --- | --- | --- | | Docs and templates | `docs/`, future `templates/meravoq/` | Phase 0 | | Static dashboard mock | `index.html`, `script.js`, `styles.css`, future `data/meravoq/` | Phase 1 | | Worker control plane | future `worker/`, `wrangler.toml` | Phase 2 schema | | Shopify adapter | future integration module | Phase 3 approval model | | Funnel generator | future Cloudflare pages/workers module | Phase 3 artifact model | | Metrics engine | future data/worker module | Phase 3 schema | | QA/browser checks | future scripts/worker module | Phase 4 URLs | Parallel lanes after Phase 1: ```text Lane A: Static UI/dashboard Lane B: Templates and schema Lane C: Integration adapter specs Lane D: QA/check scripts ``` Do not parallelize live Shopify or ad mutations until the approval model exists. ## 21. Autoplan Review Report ### CEO Review Mode: selective expansion. Findings: - The strategic reframing is correct: this is not "more stores", it is "faster evidence-backed kill/scale decisions across multiple stores." - The main risk is operational sprawl. The plan must make store killing and archiving first-class. - `Meravoq` is more ownable than `StoreFlow` or `CartFoundry`, but still needs trademark, domain, and handle checks before a public launch. - The correct first product surface is a pipeline dashboard, not API automation. Decision: - Adopt Meravoq as the working product brand. - Defer public-name clearance until trademark, domain, and handle checks are run. - Build file-backed and static-dashboard MVP before live backend. ### Design Review Classifier: app UI. Information architecture score: 8/10 after this plan. Design decisions: - Borrow build.warp.dev's status-board clarity. - Use two modes: Pre-Launch Pipeline and Post-Launch Operations. - Keep dense, scan-friendly tables for operating data. - Avoid marketing-site hero treatment for the internal control surface. Remaining design gaps: - Final visual style for the dashboard is not specified here. - Mobile behavior needs a dedicated spec before implementation. ### Engineering Review Architecture score: 8/10 after this plan. Key decisions: - Shopify remains the commerce source of truth. - Cloudflare Worker + Durable Object is the live-state path. - File-backed MVP comes first. - Human approval gates are mandatory before irreversible actions. Risks: - Metrics normalization across ad platforms will be messy. - Shopify store provisioning may vary by store/account constraints. - Supplier evidence capture may require manual or browser-assisted workflows. ### DX / Operator Experience Review Primary operator persona: ```text Who: founder/operator running many fast Shopify experiments Context: wants to turn new product ideas into stores and traffic tests without losing control Tolerance: low for hidden state, high for explicit checklists and evidence Expects: a dashboard that says what is blocked, what is live, and what to do next ``` Operator experience score: 8/10 after this plan. Magical moment: ```text An idea enters Meravoq and immediately becomes a visible launch workspace: stage, owner, artifacts, blockers, next action, and estimated launch readiness. ``` TTHW target: ```text Under 5 minutes from "new idea" to visible launch workspace in Phase 1. Under 15 minutes from "approved product" to Shopify import packet + funnel brief. ``` ### Decision Audit Trail | # | Phase | Decision | Classification | Principle | Rationale | Rejected | | --- | --- | --- | --- | --- | --- | --- | | 1 | CEO | Keep Shopify as bottom layer | Mechanical | Reuse what works | Shopify already owns checkout, payment, orders | Rebuilding commerce backend | | 2 | CEO | Adopt Meravoq as working brand | Mechanical | Reduce brand risk | StoreFlow is too crowded and CartFoundry is too literal | Keep StoreFlow as final brand | | 3 | CEO | Start with docs/templates | Mechanical | Bias toward action | Validates workflow before backend | Build Worker first | | 4 | Design | Split pre-launch and post-launch modes | Mechanical | Explicit over clever | Different user questions before vs after launch | One blended dashboard | | 5 | Eng | Require human approval for money-changing actions | Mechanical | Safety boundary | Prevents accidental spend/account damage | Full autonomous ad/store mutation | | 6 | DX | Treat operator as primary user first | Mechanical | User outcome | The first user is the founder/operator, not a third-party developer | Multi-tenant SaaS first | ## 22. Open Questions These do not block this planning commit. They block implementation. 1. How many Shopify stores should one Meravoq workspace manage at first: 3, 10, or unlimited? 2. Should Phase 1 store data live in Markdown, JSON, or both? 3. Should the first dashboard be private-only or deploy as a public mock with fake data? 4. Which analytics source should be canonical for early metrics: manual CSV, Shopify reports, GA4, or ad-platform exports? 5. Should Meravoq eventually manage multiple Shopify stores or multiple brands inside one Shopify organization? 6. What is the first real product idea to use as the pilot launch workspace? ## 23. Next Concrete Step After this planning commit, build Phase 1: ```text templates/meravoq/ idea-intake.md launch-workspace.md store-registry.md metrics-snapshot.csv decision-log.md data/meravoq/ sample-portfolio.json ``` Then evolve the static Meravoq dashboard section so it can render `data/meravoq/sample-portfolio.json` and prove the information architecture before the live backend. ## 24. Implementation Update Status: complete as production-safe dry-run control plane The execution path changed after the original plan because the product direction was clarified: - The existing Cloudflare Pages frontend remains the Shopify 24H skill and plan presentation surface. - The actual Meravoq workbench is a separate Cloudflare Worker. - The workbench is primarily a visualization and local-agent coordination layer. - Local Codex or Claude agents execute operational work after reading Worker state and receiving explicit human approval. The roadmap is therefore complete under the safety definition in `docs/meravoq-implementation-status.md`: Phase 0-6 now have safe, testable implementation paths as state APIs, dry-run packets, draft generators, approval objects, metrics decisions, local-agent prompts, and deployment checks. The Worker still must not perform real Shopify, ad-platform, supplier, payment, domain, or credential mutations by itself.