audreyinc.com archive snapshot + Shopify ↔ GitHub theme integration — sketch

Date: 2026-05-20 · Status: Sketch, ready to execute in phases · Scope: Two distinct workstreams that share infrastructure

Dan, 2026-05-20:

“Are we able to test what archive.audreyinc.com will do, once I change the dns on shopify - we should sketch it first” “Shopify Content API pull (existing audreyinc.com Shopify content → snapshot to static)? Its an exact copy of the site, and the entire site on shopify should be connected to github, so that we can swap in and out, versions of the site” “lets begin doing changes to her site, git push back and forth - test and evaluate”

The two workstreams (deliberately distinct)

Both are valuable. They share zero infrastructure beyond the CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF zone (audreyinc.com). Build them independently in either order.

Reframe — Dan’s three additions (2026-05-20 follow-up)

After the initial sketch, Dan added three clarifications that materially expand the design:

“thats why archive.audreyinc.com will exist, to show us the older versions…” “And given the a/b test routines, we can plot variances and improvements across the board” “Showing where we gain lift and rise” “audreyinc has her own git btw, under my account, fyi”

These change Workstream A from “one snapshot” to a time-series of snapshots with cross-version analytics, and confirm that Workstream B’s repo home already partially exists. Pulling these in:

1. Archive as a time-series, not a single snapshot

archive.audreyinc.com/ becomes an index of dated snapshots, each lockable in time:

archive.audreyinc.com/
├── 2026-05-20/          ← today's snapshot (the first)
│   ├── index.html       ← exact copy of audreyinc.com homepage as it was 2026-05-20
│   ├── products/...     ← all product pages frozen
│   └── ...
├── 2026-08-15/          ← Q3 content refresh
├── 2026-12-01/          ← winter campaign launch
├── 2027-Q1/             ← named milestones, not just dates
└── index.html           ← landing page showing the timeline of versions

The root index shows a timeline:

2026-05-20    Spring 2026 baseline — 47 products, 12 collections, 8 blog posts
2026-08-15    Summer 2026 — 51 products (+4), gift-guide editorial added (8 posts)
2026-12-01    Winter campaign — 58 products, new hero treatment, 3 SEO refreshes

Each row links to that version’s frozen homepage. Each version is browsable as a complete site of its moment.

Why this is the right shape: - “Show us the older versions” is the explicit ask - Same pattern as Wayback Machine but under Dan’s full control, indexable on Dan’s terms, with deeper context (named milestones, change summaries) the public archive can’t provide - Each snapshot is a known-good fallback if Shopify is ever down + the live theme is in flux - Cross-portfolio: pa.gf.cx receipts, dare’s editorial archive, this — all are dated-historical-record patterns

2. A/B + lift analysis across versions

With dated snapshots existing as static artefacts, cross-version analysis becomes a real toolkit capability, not just storage:

~/bin/audrey_archive_diff.py 2026-05-20 2026-08-15
  ├─ Diff: pages added / removed / changed
  ├─ Content shifts: hero copy, product titles, navigation
  ├─ Design shifts: CSS deltas, font changes, color tokens
  ├─ Image swaps: which hero images, which product photos
  └─ Output: ~/Downloads/audrey_archive_diff_<a>_to_<b>.md

~/bin/audrey_archive_lift.py 2026-05-20 2026-08-15 --gsc --analytics
  ├─ Pull GSC data for the window
  ├─ Cross-reference URL changes from the diff
  ├─ Attribute clicks/impressions/CTR shifts to specific page changes
  ├─ Surface "X content moved → Y traffic change"
  └─ Output: ~/Downloads/audrey_archive_lift_<a>_to_<b>.md

This is the “show where we gain lift and rise” capability Dan named. The archive becomes the editorial-improvement substrate:

• “The hero copy changed on 2026-08-15. Did organic traffic for /collections/scarves go up or down?”
• “The gift-guide editorial added 8 posts. Which ones now rank? Which underperformed?”
• “The Q4 redesign shipped on 2026-12-01. Did conversion-proxies (pageviews → product-page-views) improve?”

Without dated snapshots, you can only ASK these questions; you can’t ANSWER them with primary evidence. With dated snapshots + cross-reference tooling, you can.

This compounds with what’s already shipped today: - gsc_pull.py (built earlier today) → traffic data per URL per day - harvest_pull.py (built earlier today) → revenue per project per month - dare_cf_analytics.py → request-pattern data - Pair any of these with the cross-version diff → editorial-change-to-traffic-shift attribution

The audrey commerce flywheel parked memory (project_audrey_commerce_flywheel.md) talks about stages 4-8 as compounding revenue work. The archive-as-time-series is the measurement substrate that proves the compounding actually happens.

3. Existing audreyinc git — xlab-co/audreyinc-beta

Verified 2026-05-20 — ~/Code/audreyinc-beta is cloned locally, remote at https://github.com/xlab-co/audreyinc-beta.git (note: xlab-co org, not xlab-nyc).

Current state: - CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages plumbing: wrangler.jsonc, public/, src/ - Business-identity docs: business-structure decision log, business-identity runbook, recent rename staff.audreyinc.com → studio.audreyinc.com - NOT a Shopify theme repo yet — no templates/, sections/, layout/theme.liquid

Decision needed for Workstream B repo home:

Recommendation: Option B — new xlab-co/audreyinc-theme repo. Shopify’s GitHub theme integration explicitly expects the theme files at repo root. The audreyinc-beta repo stays as the business-identity + CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages plumbing home; audreyinc-theme is the dedicated Shopify-theme version-control. They cross-reference in their READMEs.

(Same shape as dare-co-uk + dare-pipeline being two separate repos — content + tooling kept distinct.)

Workstream A — archive.audreyinc.com static snapshot

Architecture

~/bin/audrey_archive_snapshot.py
  ├─ Pull sitemap.xml from https://audreyinc.com/sitemap.xml
  ├─ Walk every URL → curl + save HTML (rewriting absolute URLs to relative)
  ├─ Pull every <img>/<link>/<script> asset referenced
  ├─ Save to ~/Code/audreyinc-archive/<YYYY-MM-DD>/
  └─ Stamp the archive with capture date in a banner + meta tags

Deploy:
  CF Pages project: audreyinc-archive
  → audreyinc-archive.pages.dev (preview, immediate)
  → archive.audreyinc.com (custom domain, when DNS swap happens)

DNS plan (audreyinc.com zone in CF):
  Add: CNAME  archive  →  audreyinc-archive.pages.dev  (proxied)
  Untouched: @ + www  →  Shopify (whatever the current records are)

Test paths that do NOT touch live DNS

Three ways to fully validate before the DNS CNAME:

1. Preview URL direct — https://audreyinc-archive.pages.dev/ — full site, no Shopify involvement, ready to browse the moment the build deploys.

2. curl --resolve to test the canonical hostname — pretends the DNS exists: bash IP=$(dig +short audreyinc-archive.pages.dev | head -1) curl --resolve archive.audreyinc.com:443:$IP https://archive.audreyinc.com/ The page renders as if archive.audreyinc.com were already live. Catches any hardcoded-hostname issues before they’re live-visible.

3. /etc/hosts override in your browser — Add line <IP> archive.audreyinc.com → reload browser → the live URL points at the preview. Full visual + interactive testing as if real. Remove the line when done.

Capture-date banner pattern (locks the snapshot in time)

Inject a small banner at the bottom of every page:

<aside class="archive-banner">
  <strong>Archive snapshot</strong> — captured 2026-05-20 from
  <a href="https://audreyinc.com">audreyinc.com</a>.
  Live store at <a href="https://audreyinc.com">audreyinc.com</a>.
  Re-snapshotted on demand.
</aside>

Same shape as dare.co.uk archive vs forward content distinction — labels the artefact’s nature so visitors (and agents) know what they’re reading.

Build effort estimate

Total: ~3.5 hours active work from cold start to live custom domain.

Open questions for Workstream A

1. Archive scope — full audreyinc.com or just specific sections? Products + collections only? Blog posts only? My default: full sitemap walk = full archive.
2. Asset hosting — keep referencing Shopify’s CDN for <img> URLs, or download all images locally too? Shopify CDN is fast + reliable, so referencing it makes the archive lightweight + always-fresh-looking. But if Shopify-CDN URLs ever break (rare), the archive breaks. Default: reference Shopify CDN; re-snapshot if it ever breaks.
3. Re-snapshot cadence — capture once, capture quarterly, capture on demand? Default: capture on demand initially; consider quarterly cron once the pattern is rhythmic.
4. noindex or indexable? — Default: noindex on the archive so it doesn’t compete with the live site in SERPs.
5. CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Access gating? — Default: public, since the live site is public.
6. Banner placement — top or bottom? Recommended: bottom (subtle), with optional top sticky for clarity.

Workstream B — Shopify theme ↔ GitHub bidirectional sync

How it works (Shopify-native feature)

Shopify shipped GitHub theme integration in 2018; it’s a stable, documented feature, not a hack. From Shopify admin:

Online Store → Themes → Add theme → Connect from GitHub

Select a repo + branch. Shopify: - Either clones the current theme into the repo (if the repo is empty), or - Imports the repo as a new theme (if the repo already has Liquid theme files)

Once connected: - Every push to the configured branch → auto-deploys to that theme (within ~30 seconds) - Edits made in Shopify’s theme editor → auto-commit to the repo (within ~30 seconds) - The connection is per-theme, not per-store — one store can have multiple themes, each connected to a different repo/branch

Themes can be either published (the live theme buyers see) or draft (preview-only, accessible via ?preview_theme_id=X).

The safe-practice ladder (the order that matters)

Step 1 — Duplicate the published theme as a draft, BEFORE any GitHub connection - In Shopify admin: duplicate “Live theme” → creates “Live theme - copy” as a draft - The live theme stays untouched; the draft is the experimental sandbox

Step 2 — Connect the DRAFT to GitHub, not the published theme - Create xlab-nyc/audreyinc-theme-draft (or similar) - Connect the duplicated draft theme to that repo - Shopify clones the theme files into the repo on first connection - Now: pushes to xlab-nyc/audreyinc-theme-draft deploy to the draft theme, NOT the live store

Step 3 — Practice the workflow on the draft - Make edits locally → git push → 30s later visible at audreyinc.com?preview_theme_id=<draft-id> - Edit in Shopify theme editor → auto-commits to the repo - Test the round-trip until it feels routine

Step 4 — When ready, promote the draft to published - In Shopify admin: actions → Publish on the (now-edited) draft theme - The live store flips to the new theme; the old “Live theme” becomes a draft (still available for rollback) - The published theme is now connected to GitHub; pushes deploy live

Step 5 — Establish branch discipline - main branch on the connected repo → published theme - experiment-X branches → not auto-deployed; merge to main when ready - For risky experiments: spin up a SECOND draft theme connected to the experiment branch, preview at ?preview_theme_id=

What’s actually in a Shopify theme repo

assets/             ← images, JS, CSS bundles
config/             ← settings_schema.json + settings_data.json (theme config)
layout/             ← theme.liquid (the master HTML wrapper)
locales/            ← translation files (en.default.json, en.json, etc)
sections/           ← section templates (Liquid)
snippets/           ← reusable Liquid partials
templates/          ← template files (product.liquid, collection.liquid, etc)
templates/customers/← customer-account templates

Everything is Liquid (Shopify’s templating language) + standard HTML/CSS/JS. Same shape Dan’s already working with on dare.co.uk, just with Shopify-specific tags like {% section 'header' %} instead of inline <header>.

Tooling — Shopify CLI (shopify theme)

Local dev without git roundtrips:

# Install: brew install shopify-cli  OR  npm install -g @shopify/cli @shopify/theme

shopify theme dev --store audreyinc.myshopify.com    # local dev server, hot-reload
shopify theme push --theme <id>                       # push to specific draft theme
shopify theme pull --theme <id>                       # pull from theme to local
shopify theme list --store audreyinc.myshopify.com    # list themes + IDs

The CLI auths against Shopify Partners/staff account; doesn’t need API tokens for theme work. Same machine, same single-user posture as the rest of the toolkit.

Build effort estimate

Total: ~3 hours active work to operational workflow.

Open questions for Workstream B

1. Which Shopify account — audrey’s own admin? a Partner-collab account Dan has access to?
2. What’s currently the published theme — Dawn (default), Sense, Symmetry, a paid theme, or custom?
3. Theme update strategy — when Shopify pushes a new Dawn version, do we accept it or stay pinned? GitHub-connected themes don’t auto-update; we’d merge in manually.
4. Multi-theme workflow — keep one main + experiment branches, or spin up parallel draft themes for big experiments?
5. CI/CD on the theme repo — Shopify auto-deploys via GitHub; do we ALSO want GH Actions for linting (Theme Check), accessibility audit, performance regression check? Defer until pattern is rhythmic.
6. Backup discipline — before connecting GitHub, take a Shopify-side backup of the current theme (Actions → Download theme file) so there’s a known-good fallback if something goes wrong during connection.

What we can test BEFORE any DNS / theme-publish change

Pre-flight tests that exercise the full pipeline without touching live state:

Archive (Workstream A)

1. ✅ Run snapshot script against current audreyinc.com → produces local static site
2. ✅ Deploy to CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages preview URL → audreyinc-archive.pages.dev — fully browsable
3. ✅ curl –resolve test → simulate the future archive.audreyinc.com URL
4. ✅ Browser /etc/hosts override → click around as a real user, on the real-looking hostname
5. ✅ Sample 20 pages for layout-fidelity + image-loading → spot check against the live store
6. ✅ Validate og: tags + canonical URLs render correctly at the canonical hostname
7. ⏳ Add DNS CNAME (the actual swap) — left for Dan to greenlight after pre-flight passes

Shopify theme (Workstream B)

1. ✅ Duplicate live theme to draft → no impact on live store
2. ✅ Connect draft theme to GitHub → clones into repo, still no live impact
3. ✅ Edit Liquid file locally → git push → see change at ?preview_theme_id=<draft> → preview-only, not visible to buyers
4. ✅ Edit in Shopify theme editor → see auto-commit land in GitHub → confirms bidirectional sync
5. ✅ Run shopify theme dev locally → hot-reload preview without git roundtrip
6. ⏳ Publish the draft theme (the actual swap) — left for Dan to greenlight after pre-flight passes

Both workstreams converge on the same pattern: build at preview, validate at preview, swap to live only when validation passes.

Order of operations — what to do when

Recommended sequence:

Each phase is reversible up to the next phase. Even phase 7 is reversible (re-publish the previous theme via Shopify admin).

Anti-sequence: never connect the LIVE published theme to GitHub directly. Always go through a draft first. The cost of doing it the safe way is ~20 minutes; the cost of getting it wrong is potentially the live store breaking on a typo’d push.

Credentials needed

No new tokens needed for Workstream A; Workstream B doesn’t need API tokens (Shopify CLI handles its own auth).

Risk profile

Resume conditions / next steps

Phase 1 — Archive snapshot (immediate):

Dan greenlights → I: 1. Build audrey_archive_snapshot.py 2. Run first snapshot 3. Deploy to audreyinc-archive.pages.dev 4. Hosts-file test guide + verify with you 5. Wait on DNS swap

Phase 2 — Shopify ↔ GitHub (next session or whenever Dan ready):

1. Dan duplicates the live theme → draft via Shopify admin (~2 min, Dan’s task)
2. Dan connects the draft to GitHub via Shopify admin (~5 min, Dan’s task)
3. I clone the resulting repo locally + audit the Liquid structure
4. We practice round-trips on the draft
5. When confident: publish the draft

Either phase can start independently. They don’t block each other.

Sibling memories + cross-references

• project_shopify_ucp_audrey_native.md — audrey’s already a native UCP merchant; Shopify’s the source of truth for agent-discoverability
• project_audrey_agent_discoverability.md — the editorial gift-guide work that’s the unchanged lever above the theme work
• project_shopify_audrey_api_unblocked.md — Shopify Admin API access already shipped; Storefront API for content pulls is a sister capability
• feedback_archive_as_credibility_jail_card.md — the archive-frame turning dates from liability to asset; archive.audreyinc.com lives in this pattern
• user_pa_gfcx_as_country_house_operating_system.md — audrey’s site benefits from the same “git as substrate” thinking; the Shopify-GitHub integration is the audrey equivalent of “everything matters → everything in git”
• feedback_git_is_crucial_for_everything.md — direct parent principle; the theme code is one more artefact that belongs under version control
• feedback_programmatic_dns_zero_overhead.md — the DNS CNAME for archive.* is one more easy programmatic op when we get there

The aphorism

Two pipelines, one substrate: the archive freezes what audrey shipped; the GitHub-connected theme lets us ship what audrey will. Both reversible up to the moment of swap.