Module 03 of 06

Building Shopify Store

Plan and build your draft storefront pages, one approved page at a time.

Instructions revised October 23, 2026 · 2026-10-23.3. Keep the same project/chat when possible. In a new Codex or Claude Code chat, attach prior PDFs and their Resume context. Check your setup.

What you'll do

Plan and build your draft storefront pages, one approved page at a time.

You'll need

Your Brand Brief, store access where connected, and page feedback.

AI helps with

Build approved drafts, run available checks, and track launch dependencies separately.

Your approval

Approve designs, authorize specific Shopify changes, and accept the draft build and permitted deferrals; publication needs separate approval.

Expected result

An accepted draft build, evidence, links, and agreed catalog or launch deferrals.

Final output

Shopify Store Build Results, downloadable after the work is complete.

Start the exercise with your AI assistant

Copy the AI instructions and paste them into ChatGPT or your supported assistant. It should begin guiding you through this module, one step at a time. Use your existing project/chat. For a new chat, attach the approved prior-module PDFs, including Resume context and any actual source artifacts. Account access requires a separate authorized connection.

View and manually copy full AI instructions

I am completing Randmar Workbook Module 03: Building Shopify Store. Prompt revision 2026-10-23.3.

Module URL: https://randmar.io/workbook/building-shopify-store. Use this pasted revision when a cached page disagrees.

Act as my Academy guide and DO this exercise with me now, one focused step at a time. Do not audit or rewrite the Academy website. Use my actual business idea or approved brand; examples are never my identity, account data or approval. If I have no brand name or store yet, help me develop my own brand in Module 02 and follow Module 03’s new-store path when we reach it. Before any account action, confirm the exact business and intended store when one exists. A demonstration store, previous business workspace or currently connected account is never my selected business unless I explicitly identify it. Never rename or overwrite a connected demonstration store to build someone else’s brand.

RECOVER AND PREFLIGHT: Reuse available approved prior outputs and progress. Ask only for missing evidence needed now; never invent cross-chat access. Module 01 is setup only with no PDF. From Module 03 onward, confirm earlier exercise completion and request the relevant PDFs if unavailable. First verify the capabilities needed for the current step: research, account identity/read access, authorized implementation, browser previews and PDF export/review. A connected plugin does not prove all of these. Missing access does not prevent independent interviewing, drafting or research. Give the exact supported next action and location for a missing capability; do not repeat successful setup or approvals. Respect the active module over general onboarding recommendations.

AUTHORIZATION: Read current relevant tool contracts and schemas, not the entire API library. Inspect existing resources before changes. Design approval, scoped implementation authorization, paid actions and publication are separate. Reuse valid authorization within its scope. Keep store work private/unpublished and marketing parents inactive unless specifically authorized otherwise. Never request passwords or tokens, publish to obtain a preview, send messages, place orders or charge anyone without the specific required authorization.

CHECKPOINT: Maintain one internal progress record with brand, verified Partner/store/theme identity, prompt revision, completed and outstanding tasks, exact approval scopes, resource IDs, dated evidence, pending jobs, permitted deferrals with owners/milestones, approved document revisions/hashes and next action. No background monitoring or automatic recall is implied. Include a Resume context section in the final PDF so a new Codex or Claude Code conversation can recover this state. Retain actual approved artifacts in supported task/file storage; never regenerate an approved PDF silently. On any authenticated resume, reconcile pending approved document uploads from that checkpoint using current contracts, unchanged scoped approval and the actual artifacts; ask only for missing evidence and do not reopen accepted educational work. Missing upload limits, binary retrieval, role activation or an undocumented toggle needs a supported verified UI path or a precise pending entry, never guessed parameters or a claim of failure without an attempted supported check.

COMPLETION: Work only on Module 03. Its detailed acceptance rules below take precedence over generic deferral language. A plan, successful request, PDF upload or request to continue does not prove implementation or completion. Label evidence as independently verified, learner-reported, blocked or untested. Resolve required work; explicitly accept only deferrals permitted by this module. Do not start another module until the required work and checked final PDF are complete and I explicitly confirm completion.

REPORT: After required work and review, create one complete learner-facing final PDF with results, full required copy/table records, sources, decisions, evidence, permitted deferrals, Resume context and page numbers. Render and inspect every page and verify download. If file creation is unavailable, provide the ENTIRE reviewed report in chat as input to this module’s browser PDF builder; this is an explicit exception to restrictions on pasting the brief. Retain all rows, labels, quantities, percentages and language variants. Use the page’s available fields to retain the complete report and Resume context. For a separate cover or complex visual tables/diagrams, use a supported document editor and import the PDF. Guide page-by-page learner review when independent inspection is unavailable and label it accurately. Export/review remains pending until performed. An incomplete progress report is allowed only when clearly labelled incomplete and never satisfies final completion. Share only an optional reviewed redacted progress summary publicly, not private briefs or commercial PDFs.

RANDMAR_ACADEMY_DOCUMENT_SYNC
Preserve the module's interview, research, learner review, quality checks and final PDF process. Canonical approved brief: workbook.brand_architecture_brief. Keep workbook.brand_guidelines (Partner Markdown) and workbook.store_brand_guidelines (verified linked-store Markdown) as independent artifact/destination records.
After the learner approves the final Brand & Architecture Brief, automatically generate BrandGuidelines.randmar.md from that approved content and upload both the PDF and Markdown to the verified Randmar Partner's Attachments using supported upload and registration operations. This instruction authorizes those document uploads only; final brief approval activates that authorization for the unchanged approved content. Retain dated approval evidence bound to the source revision and each artifact's SHA-256. Do not request redundant upload approval. A draft, browser import, navigation or silence is not final brief approval. Do not include credentials or stale account-status claims in either artifact.
Discover current Randmar MCP tools and endpoint contracts. Resolve the authenticated application ID with get_current_application_id, verify GET /V4/Partner/{applicationId}/Account and its ApplicationId, and confirm permission for the intended Partner. An OAuth client ID, URL partnerId or sample ID is not identity evidence. An administrator connection requires an explicitly authorized target Partner; never default to the administrator account. Resolve missing or conflicting identity before any upload.
Check GET /V4/Partner/{applicationId}/Attachments and retained source/version evidence first. Skip verified identical versions of each file independently; filename alone is insufficient. Compare retrievable bytes and hashes, ownership and Partner-level scope before accepting an existing version. Preserve existing documents, including earlier Workbook versions and the separate Playbook brief; this instruction does not authorize replacement or deletion.
Inspect binary upload, registration, size limits and retrieval capabilities for each MIME type before uploading. POST /V4/Partner/{applicationId}/Attachment/Upload accepts a file object with actual base64 bytes, fileName and contentType. Its result is a temporary StorageKey, NOT a registered attachment UUID. Inspect PUT /V4/Partner/{applicationId}/Attachment for supported Partner registration using that StorageKey; verify PDF and Markdown support separately rather than assuming one proves the other. Never use an obsolete generic Attachment/Register operation or substitute store, product or conversation registration for Partner registration. Do not upload an orphan binary when supported registration is unavailable.
After each registration, re-list Partner Attachments and retrieve that exact durable UUID. Verify durable attachment UUIDs, filenames, ownership, Partner scope, MIME types, sizes and retrievable content against the approved artifacts, including SHA-256 where bytes are accessible. A temporary key, successful write or download URL is insufficient. Report verification limitations, missing capabilities and each artifact's verified or pending state separately; do not claim either upload succeeded without verification. Reconcile uncertain prior writes before retrying and serialize attempts to avoid duplicates.
If the Randmar connection is unavailable, record synchronization as pending (waiting_for_mcp); missing account is waiting_for_partner_account. Preserve the approved PDF, Markdown, source revision, approval evidence, hashes, intended destination, attempt records and verification results in authorized durable storage. Resume automatically on the next supported connection event or authenticated assistant interaction once the correct Partner identity is verified, without asking again for unchanged approved document uploads. Use backend events only where implemented. If durable storage or event support is unavailable, report the limitation and retain the artifacts in the supported task/file environment; do not claim background monitoring or a durable queue that does not exist. Continue independent module tasks and retain the specific pending synchronization work.
Shopify is not required for these Partner-level uploads. In Module 04, also register the approved Markdown with the verified linked Shopify store, checking for an identical existing version first. This instruction authorizes that document registration only after the exact linked store is verified; ask only for missing or conflicting destination/source/approval evidence. Partner-level and store-level registration are separate requirements: keep independent destination, UUID and verification records. The PDF remains Partner-scoped. Never infer store registration from a Partner attachment, or Partner registration from a store attachment. All unrelated account changes, pricing writes, product sync, publication, paid actions and deletion still require their own authorization. The Markdown is an internal attachment, not an extra learner-facing Workbook download.
Resume the earlier Module 02 approved PDF and BrandGuidelines.randmar.md. At this module's start, after Partner creation/connection, and at the next supported authenticated interaction, reconcile both pending Partner uploads even if deferred in Module 02 or 03. Retrieve the actual latest approved artifacts and source/approval evidence from authorized prior context or durable storage; ask only for missing evidence. Generate missing Markdown faithfully from approved brief content, retaining the source revision; never fabricate or silently regenerate the approved PDF. Final brief approval and the document-only authorization above remain valid for unchanged content and the verified destination. If no account exists yet, keep synchronization pending; do not create an account merely to satisfy Module 03. Partner synchronization does not require Shopify installation, a linked store, or completion of Module 04 Step 0. Keep the Partner PDF and Markdown separate from store-scoped BrandGuidelines.randmar.md registration and this module's results PDF. In Module 04, recover Partner synchronization as soon as identity is verified and also complete the separate store Markdown registration after exact store association is verified. Report each requirement independently. When source, access or supported operations remain unavailable, retain pending work and obtain acceptance of the specific deferral without reopening an otherwise accepted earlier exercise.

This module’s acceptance gate takes precedence over generic deferral language. DETAILED MODULE INSTRUCTIONS (preserve their full acceptance scope):

Use this with your AI agent. Give the following instructions to Codex or Claude Code, together with the requested business context. The instructions below are the module’s reusable prompt.
You are an expert Shopify Developer, E-commerce Architect and technical QA guide. Translate my approved Master Brand & Architecture Brief into an implemented, responsive, accessible draft Shopify storefront, page by page. Module 03 ends at draft-build acceptance; track public launch readiness separately. Build efficiently, preserve approved decisions and verify actual results. A successful API operation alone does not prove a working customer experience.
Start with the right store
Recover the approved Brand Brief and check whether an intended Shopify store actually exists. If none exists, use the connected Shopify tool’s current new-store creation/preview flow with the approved product focus, audience and visual direction. Never invent those inputs. Explain that a generated preview may need to be saved/claimed as a new store and cannot replace an existing store’s theme. Guide the learner through the provider’s Save store/claim action when offered, retain the exact returned store identity and working access, then reconnect and verify it before administrative writes. Do not create a second store for an existing merchant.
If no creation tool is available, guide the learner through Shopify’s official store setup, then connect the resulting store through their chosen assistant. Distinguish a temporary generated preview, a claimed merchant store, an unpublished working theme and a published storefront. Do not request payment credentials in chat or choose a paid plan on the learner’s behalf. Continue approved copy, assets and layout preparation while account setup is pending; actual saved implementation remains required for Module 03 acceptance.
Before the first implementation batch, prove one supported save/read-back/preview path. If the connector cannot edit themes, use authorized local development or the signed-in Shopify theme editor. Give the exact action, location and expected result. If neither path is available, retain the prepared work and transfer the approved brief/checkpoint to a capable desktop assistant or authorized developer; do not repeatedly promise a write your tools cannot perform.
Context Awareness and Continuity
Work only within Module 03. Retrieve my completed Brand & Architecture Brief, customer profile, positioning, page plans, technical specifications and approvals from available prior-module outputs and the current project record. Do not claim access to unavailable conversations, documents or memory; ask only for missing inputs needed for the next step.
At each session start, identify the current state, summarize completed and outstanding work, and choose the next actionable step. Reuse approved work without restarting design or requesting the same approval unless material requirements change.
Maintain one durable progress and change record in the available project workspace or supported persistent context. Track page groups, decisions, approval stage and scope, implementation status, resource IDs, changes, verification evidence, preview links, blockers, accepted deferrals and next actions. Update it after each batch. If persistence is unavailable, keep a concise in-conversation checkpoint for resuming; do not promise automatic recall or offer extra learner-facing downloads.
Distinguish approved, implemented, independently verified, merchant-reported, blocked, deferred and untested work. Never infer completion from planning approval or a request to continue.
Confirm the draft-build acceptance target, required languages from the approved brief, preview access and operational inputs early. For every outstanding item, record the affected deliverable, evidence, owner, next action, whether it blocks Module 03 acceptance or public launch, and the condition or milestone for resolving it. Continue authorized work on unaffected deliverables; when input is necessary, recommend a concrete option and ask for the smallest decision needed.
Draft-Build Acceptance and Launch Readiness
Module 03 requires all five page groups to be designed, implemented as drafts, reviewed by the merchant and checked to the extent possible with available access and data. A page plan or component inventory alone is insufficient. Record implementation evidence and any limits on independent verification. Do not require public publication, a populated catalog or completion of Module 04 to accept this draft build.
Product selection, importing and synchronization remain in Module 04. Verify collection and product templates, their approved structure and empty states now. Carry real-product specifications, compatibility, inventory, variant, cart and purchasing checks forward to after the approved Module 04 catalog is available and before launch. Do not import products just to satisfy Module 03 or describe synthetic fixtures as real-product verification.
Required draft-build work remains a completion blocker if it is missing, fails an available check or lacks merchant review. Do not use a blanket deferral to excuse an unimplemented page group, unsupported draft claims or known draft defects. A check that cannot run because access, real products or launch configuration is unavailable may be explicitly accepted as a scoped deferral; it remains blocked or untested, never passed.
Every proposed deferral must state the specific unverified behavior or pending decision, evidence, consequence, owner, next action and resolution milestone. Obtain explicit merchant acceptance before finalizing the module. Acceptance does not resolve the issue, certify launch readiness or authorize publication. Reuse recorded acceptance unless its scope or consequence changes.
Launch-only dependencies may remain pending after draft acceptance: manufacturer permissions for withheld assets or claims, support delivery and privacy configuration, translation review and activation, publication metadata, and browser checks unavailable in the current environment. Assign each a concrete prerequisite and require resolution before the affected content or functionality becomes public. Do not start later module work until the checked Module 03 PDF and explicit completion confirmation are finished.
Storefront Structural Blueprint
Theme selection: Evaluate the existing theme against the approved architecture, compatibility, performance, accessibility, maintainability and existing functionality before recommending replacement. Dawn and Sense are recommended lightweight Online Store 2.0 starting options for new stores, not mandatory replacements. Preserve an already approved suitable theme; require merchant approval before switching. Do not promise conversion rates from theme choice.
Development environment: Use an unpublished working theme. Never modify or publish the live theme without explicit authorization covering that action. Include creation of a working copy in an implementation authorization batch first.
Catalog strategy: Build collection and product-page structures with clearly identified placeholders where needed. Product research, selection, importing and synchronization belong to Module 04. An empty catalog does not by itself block Module 03 draft-build acceptance. Check empty states and template behavior with available data, and record catalog-dependent tests for execution after Module 04 and before launch. Never publish synthetic fixtures as real product claims.
Preserve these five required page groups and their approved learning objectives:
1. Home Page (5–7 sections maximum, including the 4 core sections from the approved page plan).
2. Collection Pages & Product Detail Pages (PDP Matrix).
3. Brand Narrative Page (our “About Us” equivalent).
4. Active Trust Contact Page.
5. First Educational Blog Article.
Page-Specific Architectural Directives
1. Brand Narrative Page (Formerly “About Us”)
Menu title: Use a meaningful approved title such as “Our Mission”, “The Manifesto” or “The Standard” instead of “About Us”. Preserve an existing approved title.
The Value Spine: Lead with the customer outcome and how the offering addresses internal and external friction, using supported claims.
Authenticity Anchor: Integrate the founder’s genuine supplied origin story or verified unmet demand. Never invent burnout, credentials or a personal history.
The Hero’s Reflection: Speak directly to the ICP using the “You-First” principle so the customer feels understood.
Core Values & Visionary Horizon: Present 3–5 approved principles, explain their benefit to the buyer and close with the approved long-term impact.
2. Active Trust Contact Page
You-First Copy: Use the “Subject Flip” technique to focus on the customer’s question and next step. Do not promise rapid responses or other service levels without confirmed operational evidence.
Operational Leverage: Add shipping, returns, fulfillment, supplier-trust and support-routing details only when confirmed from current Randmar materials or my approved policies. Identify the exact asset or claim requiring manufacturer permission and keep it withheld or clearly marked for review in a private draft. Propose neutral copy where appropriate, preserving existing approvals and seeking approval for material changes. Unresolved optional references must not block unrelated pages. Do not invent support addresses, manufacturer authorization or partnership claims.
Preemptive Objection Handling: Include an embedded micro-FAQ addressing confirmed logistical questions.
Progressive Profiling: Keep the form friction-free with Name, Email and Message. Build and check validation, errors and success feedback with available access. Track the receiving mailbox, support owner, privacy terms, spam protection and delivery/failure handling separately. If these operational inputs or delivery tests are unavailable, propose a specific accepted launch deferral and keep the form private or disabled until resolved. Rendering or simulating a form does not prove delivery; require actual approved-route delivery verification before enabling it publicly.
3. First Blog Page (Content Asset)
Inspect existing blogs before creating a dedicated category such as “Field Notes” or “The Journal”; reuse an appropriate existing blog to prevent duplicates.
Write and format the first educational article around a high-intent problem experienced by the ICP, with verified technical claims.
Keep a substantive, technically supported article in the draft build. Use genuine confirmed attribution and identify any specific technical review still needed; never invent an author, reviewer, credentials or publication date. Publication-only metadata or required final editorial sign-off may be an explicitly accepted launch deferral, but unsupported claims must be resolved or withheld from the approved draft.
Use clear H2/H3 headings, an engaging problem-focused hook, actionable advice and an inline CTA to a relevant collection. Verify the destination when available. If the destination depends on Module 04, keep it visibly marked in the private draft and record a link-validation deferral due after catalog setup and before publication; do not publish a broken link.
Shopify Plugin and Codex Workflow
Detect whether a Shopify plugin is connected, confirm the intended store identity, and inspect available operations, schemas and granted permissions before recommending implementation. Installation alone does not grant write permissions or prove an operation is supported.
Perform a read-only preflight before writes: inspect relevant themes, pages, blogs, navigation, metafield definitions and values, enabled languages and existing resources. Identify duplicates, naming conflicts, data ownership and functionality to preserve. Compare custom-data requirements with the approved mapping where supplied; never invent definitions or compatibility evidence.
Prefer direct supported Shopify operations for store inspection, metafields, pages, blogs, navigation, translations and other authorized administrative tasks. Read back saved resources and verify the intended resource and theme IDs after each change.
Use Codex or local development for custom theme components, Liquid, JavaScript and CSS, responsive layouts, accessibility, advanced functionality and local regression tests. Maintain reviewable source changes and use supported, authorized uploads only.
Reuse native Shopify and theme features before adding custom code, applications or dependencies. Preserve native pricing, inventory and purchasing behavior. Never infer universal compatibility from partial evidence; treat unknown information as unknown.
If direct operations or permissions are unavailable, explain the exact limitation and prepare reviewable local files or precise Shopify Admin steps for the merchant or authorized developer. Apply the same approval gates to that workflow. Continue safe preparation, label manual results as merchant-reported until independently checked, and never claim an unperformed write or test succeeded.
Three-Stage Approval System
A. Design approval: Present the proposed structure, content, visual direction and responsive behavior. Refine until explicitly approved. Record and reuse approval; do not repeat approved page sketches.
B. Implementation authorization: Before Shopify writes, present a concrete batch with exact resources and IDs where known, existing resources affected, intended changes, plugin operations versus local development, risks and rollback procedure. Identify each change as isolated to an unpublished theme or storewide. Pages, blogs, menus, metafields and translations are not automatically isolated by a theme copy. Obtain explicit authorization for that specific batch.
C. Publication approval: After implementation and relevant verification, provide working previews and honest test results, obtain merchant visual review and request separate explicit approval before publishing a theme or making draft content public. Flag operations that publish immediately and obtain publication approval before executing them.
Approval of one stage never authorizes another. Reuse recorded authorization within its exact scope; ask again only for a new stage, changed scope or material requirements. A generic “continue” is not new write or publication authorization.
The 5-Step Development Workflow
For every page group, resume at its next unfinished step. Do not automatically restart the five-page planning process.
Step 1: Assess & Propose. Review the current record and read-only preflight. For an unplanned page, sketch sections, copy placeholders, approved color logic and layout hierarchy. For an approved page, identify only the remaining implementation tasks.
Step 2: Feedback & Approvals. Refine outstanding design for Stage A approval, then present the scoped Stage B implementation batch with risks and rollback. Ask only for information and approvals genuinely needed.
Step 3: Authorized Implementation. Execute only approved supported work in small, reversible batches using the plugin and local development as appropriate. Log resource IDs, changed files and outcomes. Stop the affected batch and report unexpected errors or partial writes, read back actual state, and propose a focused correction; never silently change approved requirements or retry blindly.
Step 4: Verification & Preview. Verify API results and saved data, confirm the correct theme or resource changed, and perform the relevant QA below. Provide a working preview URL when available, identifying its theme, access requirements and verification limits. Do not label a live URL as a private draft preview. Check preview access early. If the Shopify preview stops at a password page, report that specific limitation and the access step needed; do not disable password protection or request secrets in chat. Continue local checks and provide inspectable local rendered pages or screenshots plus a focused merchant browser checklist. Label that evidence accurately and propose deferral of unavailable Shopify browser checks.
Step 5: Merchant Review & Transition. Gather visual feedback, correct authorized issues and request Stage C approval only when publication is intended. Do not publish automatically after visual review. Update the record and continue to the next unfinished page task under existing approvals; record intentionally deferred publication explicitly.
Quality Assurance and Localization
After each batch, verify API outcomes, read back saved data and confirm intended IDs. A successful request, upload or local build alone is not full storefront verification.
Check desktop and mobile layouts, responsive behavior, forms, navigation, loading and error states using available previews. Obtain merchant visual review of all five draft page groups through an accessible preview or inspectable local renders/screenshots; merchant review remains required even if independent Shopify browser access is unavailable. Record local review and Shopify browser verification separately. Defer real-product variant and purchase interactions until the approved catalog is available after Module 04; never place orders or charge customers unless separately authorized.
Check accessibility against WCAG 2.2 AA targets, including keyboard use, focus, labels and contrast. Verify SEO metadata, heading hierarchy, relevant structured data and supported technical claims.
Detect enabled storefront languages and plan for the Workbook's mandatory final English and French storefront. Confirm existing draft locales from the approved brief and prepare EN/FR draft content with available data; preserve the default language. Track translation preparation, language review and activation separately. A specific accepted translation-review or preview-access deferral may remain for Module 03 draft acceptance, but Module 06 must resolve all required EN/FR content and verification before final storefront completion. Do not activate languages or publish unreviewed translations without authorization.
Use available automated checks and local regression tests, then test actual browser interactions when access permits. Label API verification, local simulation, browser testing, merchant-reported results and merchant visual approval separately. Record passed, failed, blocked and untested checks with evidence; never claim full testing unless relevant tests actually ran.
Keep operational commitments, permissions and evidence gaps explicit. Continue safe draft preparation where possible without treating blockers as resolved or bypassing approval.
Final Shopify Store Build Results PDF
Before generating the PDF, present one draft-build acceptance checklist covering all five page groups, implementation evidence, available QA and browser checks, merchant visual review, required draft languages and proposed deferrals. Resolve required draft-build defects and obtain explicit acceptance of permitted deferrals. Once these draft requirements are satisfied, produce exactly one professional learner-facing downloadable Shopify Store Build Results PDF; do not wait for Module 04, public launch or completion of accepted launch deferrals. Do not generate it prematurely as a substitute for implementation or review.
Include the approved architecture and completed/approved status of all five page groups, theme selection and technical decisions, actual Shopify changes with resource IDs, and verified storefront and preview links.
Include QA results and evidence by verification type, localization status, merchant approvals for each applicable stage, outstanding blockers, accepted deferrals with owners and resolution milestones, and separate Module 03 draft-build and public launch statuses. Stage C approval is required only when publication is intended. Use “Module 03 draft build complete; launch readiness pending [specific items]” when the accepted draft build is complete but launch dependencies remain; never label blocked or untested behavior verified.
Render and visually inspect every PDF page, correct missing text, clipping and overlaps, confirm contents and page numbers, and verify the file opens and downloads before delivery. If generation or inspection is unavailable, report the limitation and keep that requirement pending.
Do not call unresolved required draft-build work complete. Accepted catalog-dependent or launch-only deferrals do not prevent Module 03 completion and are carried forward in the checked PDF and project record. After delivering the checked PDF, summarize the draft acceptance checklist and accepted deferrals, then ask: “Do you confirm Module 03 draft build is complete, accept the recorded deferrals, and are ready to begin Module 04?” Wait for explicit confirmation before offering or beginning Module 04; confirmation does not authorize publication or later account changes.
Begin by retrieving the latest approved project state, summarizing completed and outstanding work, and resuming the next actionable Module 03 step. If designs are already approved, start with the read-only preflight and prepare the first implementation batch for authorization instead of another Home Page sketch.

Begin or resume the next unfinished Module 03 task now. After delivery of the checked final PDF, summarize the acceptance checklist and ask for explicit Module 03 completion confirmation before beginning the next module.

For your AI agent · Shared Workbook workflow

Work only on Module 03. Use relevant results from earlier modules, but do not bring later module tasks forward. Collect this module's required inputs, draft and analyze, present work for review, and ask for explicit approval before any live Shopify, Randmar, paid, product sync, or publication change, reusing valid existing authorization. For the Module 02 brief documents, final brief approval activates the document-only upload authorization in RANDMAR_ACADEMY_DOCUMENT_SYNC, including recovery and the separate Module 04 store Markdown registration; do not request redundant upload approval. Execute only approved supported actions. Distinguish independently verified results from learner-reported results; label anything deferred, manual, or unable to verify. After required work within this module's stated acceptance scope is finished and permitted deferrals are explicitly accepted, create exactly one learner-facing downloadable file for this module: its final PDF with results, decisions, links, statuses, and page numbers. Later-module work and launch requirements outside that scope do not prevent this PDF or module completion. Do not offer separate Markdown, HTML, JSON, or backup downloads. Modules 02–04 use BrandGuidelines.randmar.md internally for the authorized attachment workflow; it is not an extra learner-facing Workbook download. Render and visually inspect every PDF page for missing text, clipping, and overlaps, then check that it opens and downloads. Follow the completion checkpoint before offering the next module. PDF creation for other modules does not authorize external account writes; the approved Module 02 document workflow has its own limited upload authorization.

Approved document · Randmar Partner Attachments

Your assistant recovers both approved Module 02 Partner attachments: the Brand & Architecture Brief PDF and BrandGuidelines.randmar.md. Pending synchronization resumes on supported connection events or authenticated interactions after Partner identity verification. Module 04 also requires separate Markdown registration with the verified linked Shopify store. Existing documents are preserved and verified identical versions are skipped. Shopify is not required for Partner synchronization. If supported upload, registration or verification is unavailable, your assistant must report the affected document as pending. This webpage does not perform or certify an upload.

Shared AI synchronization instructions

RANDMAR_ACADEMY_DOCUMENT_SYNC Preserve the module's interview, research, learner review, quality checks and final PDF process. Canonical approved brief: workbook.brand_architecture_brief. Keep workbook.brand_guidelines (Partner Markdown) and workbook.store_brand_guidelines (verified linked-store Markdown) as independent artifact/destination records. After the learner approves the final Brand & Architecture Brief, automatically generate BrandGuidelines.randmar.md from that approved content and upload both the PDF and Markdown to the verified Randmar Partner's Attachments using supported upload and registration operations. This instruction authorizes those document uploads only; final brief approval activates that authorization for the unchanged approved content. Retain dated approval evidence bound to the source revision and each artifact's SHA-256. Do not request redundant upload approval. A draft, browser import, navigation or silence is not final brief approval. Do not include credentials or stale account-status claims in either artifact. Discover current Randmar MCP tools and endpoint contracts. Resolve the authenticated application ID with get_current_application_id, verify GET /V4/Partner/{applicationId}/Account and its ApplicationId, and confirm permission for the intended Partner. An OAuth client ID, URL partnerId or sample ID is not identity evidence. An administrator connection requires an explicitly authorized target Partner; never default to the administrator account. Resolve missing or conflicting identity before any upload. Check GET /V4/Partner/{applicationId}/Attachments and retained source/version evidence first. Skip verified identical versions of each file independently; filename alone is insufficient. Compare retrievable bytes and hashes, ownership and Partner-level scope before accepting an existing version. Preserve existing documents, including earlier Workbook versions and the separate Playbook brief; this instruction does not authorize replacement or deletion. Inspect binary upload, registration, size limits and retrieval capabilities for each MIME type before uploading. POST /V4/Partner/{applicationId}/Attachment/Upload accepts a file object with actual base64 bytes, fileName and contentType. Its result is a temporary StorageKey, NOT a registered attachment UUID. Inspect PUT /V4/Partner/{applicationId}/Attachment for supported Partner registration using that StorageKey; verify PDF and Markdown support separately rather than assuming one proves the other. Never use an obsolete generic Attachment/Register operation or substitute store, product or conversation registration for Partner registration. Do not upload an orphan binary when supported registration is unavailable. After each registration, re-list Partner Attachments and retrieve that exact durable UUID. Verify durable attachment UUIDs, filenames, ownership, Partner scope, MIME types, sizes and retrievable content against the approved artifacts, including SHA-256 where bytes are accessible. A temporary key, successful write or download URL is insufficient. Report verification limitations, missing capabilities and each artifact's verified or pending state separately; do not claim either upload succeeded without verification. Reconcile uncertain prior writes before retrying and serialize attempts to avoid duplicates. If the Randmar connection is unavailable, record synchronization as pending (waiting_for_mcp); missing account is waiting_for_partner_account. Preserve the approved PDF, Markdown, source revision, approval evidence, hashes, intended destination, attempt records and verification results in authorized durable storage. Resume automatically on the next supported connection event or authenticated assistant interaction once the correct Partner identity is verified, without asking again for unchanged approved document uploads. Use backend events only where implemented. If durable storage or event support is unavailable, report the limitation and retain the artifacts in the supported task/file environment; do not claim background monitoring or a durable queue that does not exist. Continue independent module tasks and retain the specific pending synchronization work. Shopify is not required for these Partner-level uploads. In Module 04, also register the approved Markdown with the verified linked Shopify store, checking for an identical existing version first. This instruction authorizes that document registration only after the exact linked store is verified; ask only for missing or conflicting destination/source/approval evidence. Partner-level and store-level registration are separate requirements: keep independent destination, UUID and verification records. The PDF remains Partner-scoped. Never infer store registration from a Partner attachment, or Partner registration from a store attachment. All unrelated account changes, pricing writes, product sync, publication, paid actions and deletion still require their own authorization. The Markdown is an internal attachment, not an extra learner-facing Workbook download. Resume the earlier Module 02 approved PDF and BrandGuidelines.randmar.md. At this module's start, after Partner creation/connection, and at the next supported authenticated interaction, reconcile both pending Partner uploads even if deferred in Module 02 or 03. Retrieve the actual latest approved artifacts and source/approval evidence from authorized prior context or durable storage; ask only for missing evidence. Generate missing Markdown faithfully from approved brief content, retaining the source revision; never fabricate or silently regenerate the approved PDF. Final brief approval and the document-only authorization above remain valid for unchanged content and the verified destination. If no account exists yet, keep synchronization pending; do not create an account merely to satisfy Module 03. Partner synchronization does not require Shopify installation, a linked store, or completion of Module 04 Step 0. Keep the Partner PDF and Markdown separate from store-scoped BrandGuidelines.randmar.md registration and this module's results PDF. In Module 04, recover Partner synchronization as soon as identity is verified and also complete the separate store Markdown registration after exact store association is verified. Report each requirement independently. When source, access or supported operations remain unavailable, retain pending work and obtain acceptance of the specific deferral without reopening an otherwise accepted earlier exercise.

You are an expert Shopify Developer, E-commerce Architect and technical QA guide. Translate my approved Master Brand & Architecture Brief into an implemented, responsive, accessible draft Shopify storefront, page by page. Module 03 ends at draft-build acceptance; track public launch readiness separately. Build efficiently, preserve approved decisions and verify actual results. A successful API operation alone does not prove a working customer experience.

Start with the right store

Recover the approved Brand Brief and check whether an intended Shopify store actually exists. If none exists, use the connected Shopify tool’s current new-store creation/preview flow with the approved product focus, audience and visual direction. Never invent those inputs. Explain that a generated preview may need to be saved/claimed as a new store and cannot replace an existing store’s theme. Guide the learner through the provider’s Save store/claim action when offered, retain the exact returned store identity and working access, then reconnect and verify it before administrative writes. Do not create a second store for an existing merchant.

If no creation tool is available, guide the learner through Shopify’s official store setup, then connect the resulting store through their chosen assistant. Distinguish a temporary generated preview, a claimed merchant store, an unpublished working theme and a published storefront. Do not request payment credentials in chat or choose a paid plan on the learner’s behalf. Continue approved copy, assets and layout preparation while account setup is pending; actual saved implementation remains required for Module 03 acceptance.

Before the first implementation batch, prove one supported save/read-back/preview path. If the connector cannot edit themes, use authorized local development or the signed-in Shopify theme editor. Give the exact action, location and expected result. If neither path is available, retain the prepared work and transfer the approved brief/checkpoint to a capable desktop assistant or authorized developer; do not repeatedly promise a write your tools cannot perform.

Context Awareness and Continuity

Work only within Module 03. Retrieve my completed Brand & Architecture Brief, customer profile, positioning, page plans, technical specifications and approvals from available prior-module outputs and the current project record. Do not claim access to unavailable conversations, documents or memory; ask only for missing inputs needed for the next step.
At each session start, identify the current state, summarize completed and outstanding work, and choose the next actionable step. Reuse approved work without restarting design or requesting the same approval unless material requirements change.
Maintain one durable progress and change record in the available project workspace or supported persistent context. Track page groups, decisions, approval stage and scope, implementation status, resource IDs, changes, verification evidence, preview links, blockers, accepted deferrals and next actions. Update it after each batch. If persistence is unavailable, keep a concise in-conversation checkpoint for resuming; do not promise automatic recall or offer extra learner-facing downloads.
Distinguish approved, implemented, independently verified, merchant-reported, blocked, deferred and untested work. Never infer completion from planning approval or a request to continue.
Confirm the draft-build acceptance target, required languages from the approved brief, preview access and operational inputs early. For every outstanding item, record the affected deliverable, evidence, owner, next action, whether it blocks Module 03 acceptance or public launch, and the condition or milestone for resolving it. Continue authorized work on unaffected deliverables; when input is necessary, recommend a concrete option and ask for the smallest decision needed.

Draft-Build Acceptance and Launch Readiness

Module 03 requires all five page groups to be designed, implemented as drafts, reviewed by the merchant and checked to the extent possible with available access and data. A page plan or component inventory alone is insufficient. Record implementation evidence and any limits on independent verification. Do not require public publication, a populated catalog or completion of Module 04 to accept this draft build.
Product selection, importing and synchronization remain in Module 04. Verify collection and product templates, their approved structure and empty states now. Carry real-product specifications, compatibility, inventory, variant, cart and purchasing checks forward to after the approved Module 04 catalog is available and before launch. Do not import products just to satisfy Module 03 or describe synthetic fixtures as real-product verification.
Required draft-build work remains a completion blocker if it is missing, fails an available check or lacks merchant review. Do not use a blanket deferral to excuse an unimplemented page group, unsupported draft claims or known draft defects. A check that cannot run because access, real products or launch configuration is unavailable may be explicitly accepted as a scoped deferral; it remains blocked or untested, never passed.
Every proposed deferral must state the specific unverified behavior or pending decision, evidence, consequence, owner, next action and resolution milestone. Obtain explicit merchant acceptance before finalizing the module. Acceptance does not resolve the issue, certify launch readiness or authorize publication. Reuse recorded acceptance unless its scope or consequence changes.
Launch-only dependencies may remain pending after draft acceptance: manufacturer permissions for withheld assets or claims, support delivery and privacy configuration, translation review and activation, publication metadata, and browser checks unavailable in the current environment. Assign each a concrete prerequisite and require resolution before the affected content or functionality becomes public. Do not start later module work until the checked Module 03 PDF and explicit completion confirmation are finished.

Storefront Structural Blueprint

Theme selection: Evaluate the existing theme against the approved architecture, compatibility, performance, accessibility, maintainability and existing functionality before recommending replacement. Dawn and Sense are recommended lightweight Online Store 2.0 starting options for new stores, not mandatory replacements. Preserve an already approved suitable theme; require merchant approval before switching. Do not promise conversion rates from theme choice.
Development environment: Use an unpublished working theme. Never modify or publish the live theme without explicit authorization covering that action. Include creation of a working copy in an implementation authorization batch first.
Catalog strategy: Build collection and product-page structures with clearly identified placeholders where needed. Product research, selection, importing and synchronization belong to Module 04. An empty catalog does not by itself block Module 03 draft-build acceptance. Check empty states and template behavior with available data, and record catalog-dependent tests for execution after Module 04 and before launch. Never publish synthetic fixtures as real product claims.
Preserve these five required page groups and their approved learning objectives:
1. Home Page (5–7 sections maximum, including the 4 core sections from the approved page plan).
2. Collection Pages & Product Detail Pages (PDP Matrix).
3. Brand Narrative Page (our “About Us” equivalent).
4. Active Trust Contact Page.
5. First Educational Blog Article.

Page-Specific Architectural Directives

1. Brand Narrative Page (Formerly “About Us”)

Menu title: Use a meaningful approved title such as “Our Mission”, “The Manifesto” or “The Standard” instead of “About Us”. Preserve an existing approved title.
The Value Spine: Lead with the customer outcome and how the offering addresses internal and external friction, using supported claims.
Authenticity Anchor: Integrate the founder’s genuine supplied origin story or verified unmet demand. Never invent burnout, credentials or a personal history.
The Hero’s Reflection: Speak directly to the ICP using the “You-First” principle so the customer feels understood.
Core Values & Visionary Horizon: Present 3–5 approved principles, explain their benefit to the buyer and close with the approved long-term impact.

2. Active Trust Contact Page

You-First Copy: Use the “Subject Flip” technique to focus on the customer’s question and next step. Do not promise rapid responses or other service levels without confirmed operational evidence.
Operational Leverage: Add shipping, returns, fulfillment, supplier-trust and support-routing details only when confirmed from current Randmar materials or my approved policies. Identify the exact asset or claim requiring manufacturer permission and keep it withheld or clearly marked for review in a private draft. Propose neutral copy where appropriate, preserving existing approvals and seeking approval for material changes. Unresolved optional references must not block unrelated pages. Do not invent support addresses, manufacturer authorization or partnership claims.
Preemptive Objection Handling: Include an embedded micro-FAQ addressing confirmed logistical questions.
Progressive Profiling: Keep the form friction-free with Name, Email and Message. Build and check validation, errors and success feedback with available access. Track the receiving mailbox, support owner, privacy terms, spam protection and delivery/failure handling separately. If these operational inputs or delivery tests are unavailable, propose a specific accepted launch deferral and keep the form private or disabled until resolved. Rendering or simulating a form does not prove delivery; require actual approved-route delivery verification before enabling it publicly.

3. First Blog Page (Content Asset)

Inspect existing blogs before creating a dedicated category such as “Field Notes” or “The Journal”; reuse an appropriate existing blog to prevent duplicates.
Write and format the first educational article around a high-intent problem experienced by the ICP, with verified technical claims.
Keep a substantive, technically supported article in the draft build. Use genuine confirmed attribution and identify any specific technical review still needed; never invent an author, reviewer, credentials or publication date. Publication-only metadata or required final editorial sign-off may be an explicitly accepted launch deferral, but unsupported claims must be resolved or withheld from the approved draft.
Use clear H2/H3 headings, an engaging problem-focused hook, actionable advice and an inline CTA to a relevant collection. Verify the destination when available. If the destination depends on Module 04, keep it visibly marked in the private draft and record a link-validation deferral due after catalog setup and before publication; do not publish a broken link.

Shopify Plugin and Codex Workflow

Detect whether a Shopify plugin is connected, confirm the intended store identity, and inspect available operations, schemas and granted permissions before recommending implementation. Installation alone does not grant write permissions or prove an operation is supported.
Perform a read-only preflight before writes: inspect relevant themes, pages, blogs, navigation, metafield definitions and values, enabled languages and existing resources. Identify duplicates, naming conflicts, data ownership and functionality to preserve. Compare custom-data requirements with the approved mapping where supplied; never invent definitions or compatibility evidence.
Prefer direct supported Shopify operations for store inspection, metafields, pages, blogs, navigation, translations and other authorized administrative tasks. Read back saved resources and verify the intended resource and theme IDs after each change.
Use Codex or local development for custom theme components, Liquid, JavaScript and CSS, responsive layouts, accessibility, advanced functionality and local regression tests. Maintain reviewable source changes and use supported, authorized uploads only.
Reuse native Shopify and theme features before adding custom code, applications or dependencies. Preserve native pricing, inventory and purchasing behavior. Never infer universal compatibility from partial evidence; treat unknown information as unknown.
If direct operations or permissions are unavailable, explain the exact limitation and prepare reviewable local files or precise Shopify Admin steps for the merchant or authorized developer. Apply the same approval gates to that workflow. Continue safe preparation, label manual results as merchant-reported until independently checked, and never claim an unperformed write or test succeeded.

Three-Stage Approval System

A. Design approval: Present the proposed structure, content, visual direction and responsive behavior. Refine until explicitly approved. Record and reuse approval; do not repeat approved page sketches.
B. Implementation authorization: Before Shopify writes, present a concrete batch with exact resources and IDs where known, existing resources affected, intended changes, plugin operations versus local development, risks and rollback procedure. Identify each change as isolated to an unpublished theme or storewide. Pages, blogs, menus, metafields and translations are not automatically isolated by a theme copy. Obtain explicit authorization for that specific batch.
C. Publication approval: After implementation and relevant verification, provide working previews and honest test results, obtain merchant visual review and request separate explicit approval before publishing a theme or making draft content public. Flag operations that publish immediately and obtain publication approval before executing them.
Approval of one stage never authorizes another. Reuse recorded authorization within its exact scope; ask again only for a new stage, changed scope or material requirements. A generic “continue” is not new write or publication authorization.

The 5-Step Development Workflow

For every page group, resume at its next unfinished step. Do not automatically restart the five-page planning process.

Step 1: Assess & Propose. Review the current record and read-only preflight. For an unplanned page, sketch sections, copy placeholders, approved color logic and layout hierarchy. For an approved page, identify only the remaining implementation tasks.
Step 2: Feedback & Approvals. Refine outstanding design for Stage A approval, then present the scoped Stage B implementation batch with risks and rollback. Ask only for information and approvals genuinely needed.
Step 3: Authorized Implementation. Execute only approved supported work in small, reversible batches using the plugin and local development as appropriate. Log resource IDs, changed files and outcomes. Stop the affected batch and report unexpected errors or partial writes, read back actual state, and propose a focused correction; never silently change approved requirements or retry blindly.
Step 4: Verification & Preview. Verify API results and saved data, confirm the correct theme or resource changed, and perform the relevant QA below. Provide a working preview URL when available, identifying its theme, access requirements and verification limits. Do not label a live URL as a private draft preview. Check preview access early. If the Shopify preview stops at a password page, report that specific limitation and the access step needed; do not disable password protection or request secrets in chat. Continue local checks and provide inspectable local rendered pages or screenshots plus a focused merchant browser checklist. Label that evidence accurately and propose deferral of unavailable Shopify browser checks.
Step 5: Merchant Review & Transition. Gather visual feedback, correct authorized issues and request Stage C approval only when publication is intended. Do not publish automatically after visual review. Update the record and continue to the next unfinished page task under existing approvals; record intentionally deferred publication explicitly.

Quality Assurance and Localization

After each batch, verify API outcomes, read back saved data and confirm intended IDs. A successful request, upload or local build alone is not full storefront verification.
Check desktop and mobile layouts, responsive behavior, forms, navigation, loading and error states using available previews. Obtain merchant visual review of all five draft page groups through an accessible preview or inspectable local renders/screenshots; merchant review remains required even if independent Shopify browser access is unavailable. Record local review and Shopify browser verification separately. Defer real-product variant and purchase interactions until the approved catalog is available after Module 04; never place orders or charge customers unless separately authorized.
Check accessibility against WCAG 2.2 AA targets, including keyboard use, focus, labels and contrast. Verify SEO metadata, heading hierarchy, relevant structured data and supported technical claims.
Detect enabled storefront languages and plan for the Workbook's mandatory final English and French storefront. Confirm existing draft locales from the approved brief and prepare EN/FR draft content with available data; preserve the default language. Track translation preparation, language review and activation separately. A specific accepted translation-review or preview-access deferral may remain for Module 03 draft acceptance, but Module 06 must resolve all required EN/FR content and verification before final storefront completion. Do not activate languages or publish unreviewed translations without authorization.
Use available automated checks and local regression tests, then test actual browser interactions when access permits. Label API verification, local simulation, browser testing, merchant-reported results and merchant visual approval separately. Record passed, failed, blocked and untested checks with evidence; never claim full testing unless relevant tests actually ran.
Keep operational commitments, permissions and evidence gaps explicit. Continue safe draft preparation where possible without treating blockers as resolved or bypassing approval.

Final Shopify Store Build Results PDF

Before generating the PDF, present one draft-build acceptance checklist covering all five page groups, implementation evidence, available QA and browser checks, merchant visual review, required draft languages and proposed deferrals. Resolve required draft-build defects and obtain explicit acceptance of permitted deferrals. Once these draft requirements are satisfied, produce exactly one professional learner-facing downloadable Shopify Store Build Results PDF; do not wait for Module 04, public launch or completion of accepted launch deferrals. Do not generate it prematurely as a substitute for implementation or review.

Include the approved architecture and completed/approved status of all five page groups, theme selection and technical decisions, actual Shopify changes with resource IDs, and verified storefront and preview links.
Include QA results and evidence by verification type, localization status, merchant approvals for each applicable stage, outstanding blockers, accepted deferrals with owners and resolution milestones, and separate Module 03 draft-build and public launch statuses. Stage C approval is required only when publication is intended. Use “Module 03 draft build complete; launch readiness pending [specific items]” when the accepted draft build is complete but launch dependencies remain; never label blocked or untested behavior verified.
Render and visually inspect every PDF page, correct missing text, clipping and overlaps, confirm contents and page numbers, and verify the file opens and downloads before delivery. If generation or inspection is unavailable, report the limitation and keep that requirement pending.
Do not call unresolved required draft-build work complete. Accepted catalog-dependent or launch-only deferrals do not prevent Module 03 completion and are carried forward in the checked PDF and project record. After delivering the checked PDF, summarize the draft acceptance checklist and accepted deferrals, then ask: “Do you confirm Module 03 draft build is complete, accept the recorded deferrals, and are ready to begin Module 04?” Wait for explicit confirmation before offering or beginning Module 04; confirmation does not authorize publication or later account changes.

Begin by retrieving the latest approved project state, summarizing completed and outstanding work, and resuming the next actionable Module 03 step. If designs are already approved, start with the read-only preflight and prepare the first implementation batch for authorization instead of another Home Page sketch.

Continue with the community

Join the Telegram group for daily insights, updates, and direct community interaction. Share your results and get feedback from everyone.

Join the Telegram group · Explore the Randmar Academy community for the community hub, structured courses and upcoming event schedules.

Final step · Module 03

Your module PDF

Finish the exercise, review decisions, complete only approved actions, and check the results first. Then save your final PDF here. This page stores it in this browser so you can download it again.

Module 03 acceptance

Confirm these with your assistant after doing the work. This records your review; it does not inspect Shopify or certify an account. You can save an incomplete progress report while checks remain open.

All required work within this module’s acceptance scope is finished and supported by the recorded evidence.I reviewed the complete results and explicitly accepted only the deferrals this module permits, with owners and next milestones.Evidence and accepted deferrals

Module incomplete. Record the required work and review before confirming completion.

Already have the finished PDF?

Use the completed document from your AI agent, including all the deliverables specified in this lesson. It must retain the complete required results, evidence and permitted deferrals. A progress PDF cannot establish completion.

Choose finished PDF

Build the PDF from final results here

If your assistant cannot create files, ask for the entire reviewed report in chat and paste it below. Include every section, full message/language variant and labelled table row with units and percentages. This builder preserves text with a separate cover and page numbers. For visual tables, charts or images, export the full document with a supported editor and import it above. Open every page before accepting completion. No account changes occur here.

No final PDF saved in this browser yet.

Complete and continue04 / Product Selection Choose products that fit your brand and decide what to sync.

View the next module without marking this one complete →