Product

The new React frontend — the surface we are optimizing.

What it is

The new React frontend, in its own git repo at ../../AlaskanFishermanFrontend/. It is the active product for German conversion work. Old-web docs are historical; CZ exists as a separate market and is out of scope here.

One variant is in production today. The frontend’s routing layer supports running multiple variants concurrently with weighted traffic splits — additional variants can be added when the testing strategy needs them.

Layout 

AlaskanFishermanFrontend/
├── shared/      shared components, hooks, API client, utils
├── version1/    the active variant
└── api-schema.yaml

Variants are placed in folders named version1, version2, … and added when needed.

Operational details — dev commands, build, deploy, how traffic-split is configured — live in the repo’s own README.md and cloud_flare_deploy.md. The KB does not duplicate them.

Variants and analytics attribution

Every visitor is stickied to a variant for a session. Each request and analytics event from that visitor is stamped with the variant so all segmentation described in semantic.md works — even with one variant in production today, the attribution scaffolding is in place.

  • A query parameter ?ab=<variant_name> overrides the assignment and stickies the visitor to a specific variant — useful for QA and stakeholder reviews.
  • The variant assignment is the single source of truth for A/B attribution. Analytics, content, and components must read it, never re-decide it.
  • The frontend uses the canonical event taxonomy from semantic.md. New event names go into semantic.md first.
  • Each event carries the variant identifier in its envelope so segmentation works — property names and shapes are in semantic.md.

Source repos and deploy convention

The agentic system has two source repos in scope. Both auto-deploy from main, so the merge date on main is the deploy date (modulo CDN cache TTLs of a few minutes).

Repo Purpose Path
AlaskanFishermanFrontend The new React web — what visitors see, where every custom analytics event is emitted from ../../AlaskanFishermanFrontend/
workflow The analytics MCP server agents query for PostHog / Meta / GA4 / Plausible / Clarity data ../../workflow/

Rules:

  • Read origin/main, not local main. Local branches drift; origin/main is what’s live. Fetch with git -C <repo> fetch origin --no-tags --prune before any deploy-history question — that’s non-destructive (doesn’t touch the working tree or any local branch).
  • PR OPEN ≠ live. A change is only live once its PR is merged into main. The merge commit on main is the deploy event.
  • Read-only by contract. Agents inspect these repos; they never modify, commit, push, reset, or stage anything. The deploy-history skill (../skills/deploy-history/) lists the canonical commands.

Use this whenever a hypothesis depends on what the code actually does, when a feature shipped, or whether the implementation matches semantic.md. The code-analyst persona owns code-and-deploy investigation; lighter one-shot lookups (e.g. confirming an event is emitted from somewhere) can be done directly via the deploy-history skill.

Internal-traffic opt-out (for agent-driven browser inspection)

Agents that drive a real browser against production URLs (e.g. the page-ux-analyst via mcp__browser-run__*) must not pollute live PostHog with bot-shaped sessions. The frontend ships an opt-out flag for exactly this case.

  • Append ?af_internal=1 to the first navigation on any production URL the agent visits. The flag accepts any non-empty value (1, agent, qa, …); 1 is canonical.
  • The frontend persists af_internal_traffic=1 to localStorage and then calls posthog.opt_out_capturing(). After that, every subsequent navigation on the same browser context skips:
    • PostHog capture() (custom events) and PostHog autocapture ($pageview, $autocapture, $exception)
    • PostHog session recording
    • dataLayer pushes via afDl.push
    • Third-party trackers via trackEvent / trackConversion (Meta Pixel, Google Ads, GA4, GTM)
  • The flag persists for the browser-context lifetime; you don’t need to re-append it on follow-up navigate_page calls in the same session. Closing the page resets it (since the agent’s browser context is per-page).
  • To clear the flag manually (e.g. mid-session if you want to verify a real fire), navigate to ?af_internal=clear.

This is also the canonical way to keep staff / QA traffic out of analytics dashboards; the opt-out implementation lives in AlaskanFishermanFrontend/shared/src/utils/internalTraffic.ts (read-only reference for the code-analyst persona).

Design direction

Priorities for any page/content work the agentic system proposes. Not a fixed spec.

  • Stronger premium / luxury fish presentation. The product is premium; the page should look it.
  • Mobile-first clarity. Paid traffic skews mobile; design decisions are evaluated on mobile first.
  • Mobile body-copy weight. Body text in regular weight reads as too thin on mobile; the German target audience skews older. Headline-size optimization should not collateral-damage body-copy readability.
  • Creative-to-landing-message match. The above-the-fold message should mirror the promise of the dominant creative for that traffic source.
  • Acquisition contract. Meta ad sets are organized by theme (sushi, protein, health, family). Each theme should map to a matching landing variant — this is the input contract the component-library approach must satisfy.
  • Component library / lego approach. Page sections should be reusable building blocks so creative-specific landing experiences can be assembled quickly.
  • Commerce-focused design ownership. Page work needs a web designer with an ecommerce mindset.

When a test introduces a second variant, the change must be attributable to that variant.

This site uses Just the Docs, a documentation theme for Jekyll.