MIZOKI_Shopify_Only_Claude_Code_Prompt.txt

MIZOKI — SHOPIFY-ONLY EDITORIAL HOMEPAGE IMPLEMENTATION

Execute this task in Claude Code against the real Git checkout. Implement the page, test it, fix defects, and prepare a reviewable release. Do not respond with another planning prompt.

REPOSITORY AND EXACT DESIGN SOURCE
Canonical repository: MIZOKI-3-5/MIZOKICloudRun
Repository ID: 1008435662
Default branch: main
Design branch: work/shopify-editorial-design-2026-10-02
Design commit: d249fb9baa69126d9483edcbc95e6366b402c1d9
Exact reference file:
docs/design/shopify/MIZOKI_Shopify_Option_B_Editorial.html
Target served page: https://mizoki3.com/shopify
Expected implementation file: # MIZ OKI 3.5/shopify.html
Confirm current routing before editing; the expected file is not permission to modify another page.

OWNER INTENT
Install Option B's light editorial visual direction on the existing Shopify sales page, for independent merchants running their own marketing. Preserve the design's serif headlines, teal accents, dark product panels, merchant-readable content and focused audit offer. Integrate this page into the existing website through navigation and contextual links to the Journal, relevant demos and other established destinations.

“Shopify extension” here means the public /shopify website page. It does not authorize changes to Shopify app extensions, OAuth, webhooks, commerce APIs, the merchant console, campaign execution or any backend.

HARD SCOPE
Only /shopify may change in appearance, content or behavior.
Allowed implementation edits:
- The confirmed /shopify page file.
- New uniquely named Shopify-only CSS, JS or image files loaded exclusively by /shopify, if needed; prefer a small self-contained implementation.
- Tests dedicated to this page and a concise Shopify implementation/verification record.
- An existing canon-lock entry for this exact page or its dedicated assets, only if required by current rules. Never re-pin unrelated files or run a broad lock update that blesses unrelated drift.
The supplied design reference and this prompt remain provenance artifacts; preserve them.

Do not modify the main homepage, /marketing, /signal, /intent, /media, Journal articles or index, demos, Decision Studio, global navigation components, shared CSS/JS, routing, backend code, Shopify app configuration, deployment workflows, CI policies, permissions, secrets or advertising settings.
Do not add a public /shopify-v2 or duplicate page. Replace the current /shopify implementation.
Linking FROM /shopify to existing pages is authorized. Adding reciprocal links requires editing other pages and is outside scope. If a requested inbound link truly requires such an edit, list that specific optional change separately without performing it.

1. RESUME SAFELY AND READ AUTHORITY
Verify remote identity and git status. Preserve all unrelated local work; use an isolated worktree when necessary. Fetch current main and the design branch. Read the current CONSTITUTION.md, AGENTS.md, OPERATING_SYSTEM.md, GOVERNANCE.md, TRUTH.md, README.md, CLAUDE.md, applicable nested AGENTS/CLAUDE files, .claude/rules/website-governance.md, current platform and HTML Virtuoso skills, and relevant routed memory before implementation. Use the repository's documented memory router; do not bulk-import archives.
Inspect current branch automation before choosing a branch. Use a work/* branch that does not trigger an automatic merge. Never use a branch prefix that would land unreviewed changes automatically.
Start from fresh main. Read the exact design at the pinned commit, even if its branch is not merged. For example, fetch the design ref and read the reference with git show at the pinned commit. Verify the commit belongs to the canonical repo. If the file has since been intentionally superseded, compare and report that evidence before selecting a source; never silently substitute another design.
The reference was based on main e7348d5c95b5fb7992ddd17db2193e12187e5550 and live page reviews on October 1, 2026. Those facts are historical leads, not current runtime truth.

2. ESTABLISH THE BASELINE
Read the current Shopify source, page route, serving/template mechanism, relevant tests, content QA, design canon and release runbook. Read current Shopify onboarding/status/product documents and claim ledger sufficiently to validate public copy. Read /marketing for design consistency, not as a file to edit.
Record the baseline main SHA and the hashes of tracked website files. Inspect the actual live Shopify page. Distinguish repository state, deployed state and runtime evidence.
Determine whether a draft PR already exists for the saved design; update or reuse appropriate work rather than creating duplicate competing PRs. If building on fresh main, bring only the reference/prompt artifacts and scoped implementation, not unrelated historical changes.

3. CONNECT TO THE EXISTING SITE
Build a link inventory using current site routes, source navigation, Journal manifest and public-page checks. Verify the final response/page content as well as status codes; a generic fallback returning 200 is not proof of a valid destination.
Add a compact local header and useful footer on /shopify. Keep one dominant audit CTA and a secondary demo CTA. Preserve mobile usability and keyboard navigation.
Include links, where verified, to:
- Main homepage.
- Signal /signal and marketing overview /marketing.
- Journal — use this exact public label, even if canonical URLs contain /blog/. Locate the actual index or homepage section; do not invent /journal or assume /blog is an index.
- Signal Factory /demo/signal.
- The relevant marketing decision scenario /marketing#trace.
- Decision Studio and /animation if they are current, public and working. Use the live canonical hostname rather than choosing between older decision/decisionstudio hostnames from memory.
- Executive briefing, pricing and contact.
- Other core pages already in the site's relevant navigation, organized in the footer rather than crowding the header.
Add an “Explore Signal” or similar compact section with merchant-readable descriptions for the most relevant demos and Journal material. Link to existing content without copying or modifying those pages. A demo must be identified as an illustrative demonstration when appropriate.
If an optional destination is broken, use a verified existing alternative or omit it and record the reason. Do not repair other pages under this task. If a core conversion destination is broken, finish the page and tests and report that as a release blocker.
Use same-origin relative URLs for site navigation and verified absolute URLs for external properties. Preserve established attribution conventions; do not invent analytics events or personal-data collection.

4. IMPLEMENT THE DESIGN IN THE EXISTING /SHOPIFY PAGE
Adapt the exact Option B reference into the current website architecture. Retain the light editorial layout, warm neutral sections, large serif headlines, teal accent and dark product illustrations. Keep mobile text readable and CTAs visible without overflow.
Preserve the central section sequence: merchant hero; integrations; acquisition/economics/control benefits; illustrative contribution example; interactive Connect/Add costs/Review walkthrough; control explanation; audit offer; FAQ; contextual exploration links; final CTA; site-connected footer.
Use the commercial name MIZOKI Signal for Shopify and the current approved public brand. Do not add engineering version numbers to merchant copy where the canon excludes them.
Consolidate the prototype's base and override CSS cleanly. Namespace selectors or keep styles page-local. No dependency/framework migration. No global CSS changes. Keep JavaScript small, progressive and page-specific. The essential content must remain available without JavaScript; provide all workflow content in HTML or an accessible fallback.
Remove the prototype's design-review footer and noindex directive from the production page only. Keep illustrative labels next to concept UI and sample figures. Add correct canonical /shopify metadata, description and existing site-compatible Open Graph/favicons. Do not invent reviews, ratings, endorsements or structured-data offers.
Use semantic HTML, one H1, sequential headings, skip navigation, visible keyboard focus, appropriately labeled controls, reduced-motion support and touch targets. If using ARIA tabs, implement their keyboard behavior; otherwise use ordinary buttons with accurate pressed/expanded state. Native FAQ details are acceptable.

5. CONTENT AND COMMERCIAL HONESTY
Check current implementation and evidence before retaining any capability claim. Distinguish built, deployed, gated, preview and customer-proven. Do not turn merged engineering repairs into customer outcomes.
Do not promise 10x returns, guaranteed lower acquisition costs, unrestricted autonomous spending, an App Store listing, an immediate self-service trial or a setup-time promise without approved evidence and commercial terms.
Net-yield pricing/bidding and anticipatory intent stay “Preview · in development” unless the current claim ledger and required pilot artifacts authorize a stronger statement. The connecting-store flow does not itself authorize ad-spend changes.
Use real cost inputs; missing costs remain unknown. Label illustrative UI and numbers visibly. The sample $120 order less $42 product, $12 fulfillment, $6 fees and $10 returns equals $50 contribution BEFORE ad spend. Do not call that incremental NCM, net profit or a verified merchant result. Expected return costs are illustration assumptions, not a claim that current production predicts returns for every SKU.
Keep audit wording and pricing aligned with approved current public terms. Internal price decisions alone are not authorization to publish prices. If a commercial detail lacks authority, use a truthful request/confirmation CTA and record the unresolved detail.
Translate technical controls into merchant language. Do not place environment variables, internal gate codes, implementation caveats or operational runbooks into sales copy. Retain relevant plain-language limitations where they affect purchase decisions.

6. VERIFY AND REPAIR UNTIL THE SCOPED WORK IS COMPLETE
The supplied prototype passed only static ID/anchor and JavaScript syntax checks. Its browser rendering was not verified. Do not inherit a visual-pass claim.
Run existing relevant website/content/canon tests without weakening or bypassing them. Add focused tests only where necessary for page-specific interactions or regressions.
Serve the actual website using its supported development route. Inspect desktop and mobile screenshots at 375, 390, 768 and 1440 pixels; check horizontal overflow, reading order, contrast, menus, links, workflow controls, FAQ disclosures, keyboard focus, console errors, reduced motion and no-JavaScript access to essential content. Run the repo's accessibility/performance checks where available and report actual results, not targets as measured scores.
Verify public links and anchors, including Journal and demos. Do not submit contact forms or trigger account installation during checks.
Prove scope using git diff against the recorded baseline: list every changed file; compare hashes for all other tracked website files; identify shared dependencies referenced but unchanged. Test a representative set of unaffected routes to detect accidental global impact. Differences already present on main must not be attributed to this task.
Inspect every failure, fix the root cause within scope, rerun the affected check and then the final relevant gate set. Never remove assertions, broaden exemptions, fabricate results or change other pages to obtain green checks. Bound retries for identical infrastructure failures; persist the blocker and continue independent work.
Use a concise scoped checkpoint to survive context resets: baseline and head SHAs, reference path/commit, changed-file allowlist, completed steps, failing checks, remaining actions and release state. Resume from that record and current git state. Do not spawn recurring tasks, overwrite governing instructions or loop forever on an unchanged failure.

7. DELIVERY AND RELEASE BOUNDARY
Commit and push the scoped implementation on a safe work/* branch and open or update a review PR. The PR must explain the merchant problem, visual changes, navigation destinations, exact changed-file list, reference provenance, tests, screenshots and any remaining blockers. Do not auto-merge.
This prompt authorizes sourcing and implementing the Shopify-only page, testing it and preparing the release. It does not supply the repository's required human release token or authorize bypassing the owner-controlled workflow. Finish all agent-executable work before requesting the exact remaining human release action.
Before any subsequently authorized production release, compare the proposed whole-site release SHA with the currently serving site SHA. A site deployment may publish other previously merged website changes. If that comparison includes unrelated public changes, do not silently release them: prepare the existing supported scoped release path or report the concrete conflict for owner resolution. Do not change release workflows to bypass it.
After a valid human-controlled deployment, verify serving revision/traffic and live /shopify content, core links and representative unchanged pages. Record rollback information using the existing release mechanism. Never call a push or merge a deployment.

DEFINITION OF DONE
- Option B is sourced from the exact saved file and adapted to the existing /shopify page.
- Only authorized Shopify implementation/support artifacts changed.
- Journal, relevant demos and core-site links are present and verified, with no edits to their destinations.
- Page-specific interactions, responsive visuals, content claims and required repository checks pass with recorded evidence.
- A review PR and release-ready evidence exist; blockers are explicit.
- Report the state accurately as implemented/tested/awaiting human release, or deployed/live-verified only when actually verified.

Begin by verifying the repo and retrieving the named source file. Continue through implementation and validation; do not stop at a plan.