Where to start

Current correction

The active E:\blockdata starting point is not the old route-level "everything outside AuthGuard" set. It is the three public landing pages already started in the new repo:

• apps/web/public/index.html
• apps/web/public/solutions.html
• apps/web/public/brand.html

Login, register, auth callback, welcome, app shell, and auth-gated product pages are deferred. When one of those pages moves, it moves as a page/workflow slice: required frontend components, required API/backend contract, required Neon tables/migrations, required secrets/storage/adapters, then live verification.

Existing SQL and migration files in E:\writing-system are reference material only. Do not copy them into the new repo's migration history.

This page is historical dependency research against the old non-auth (public) surface. It is retained for reference, but the current first wave is only the three landing pages already present in E:\blockdata.

Lens 1 — Foundation audit (frontend-foundation-audit)

Clean / liftable as-is

• web/src/components/layout/PublicLayout.tsx — trivial centered shell (Outlet + PublicFooter), Tailwind utilities only.
• MarketingLayout.tsx, PublicFooter.tsx, pages/NotFound.tsx.
• Login.tsx (owns its own chrome by design), AuthCallback.tsx, AuthWelcome.tsx.
• The Tailwind v4 base in web/src/tailwind.css.

Drift to leave behind (do NOT carry)

1. Dual token systems. The app uses tailwind.css; the public/landing pages use a parallel set — web/src/lib/landingTokens.ts + web/src/styles/landing-tokens.css + landing-typography.css. Two sources for the same surface. Effort: moderate.
2. Per-surface CSS bypasses — settings-surface.css, blockdata-settings-surface.css (later waves, but the pattern is drift).
3. Four competing shells (Marketing, Public, AppLayout, ChromeFreeShell). The non-auth wave needs only Public + Marketing.

Decision before lifting the landing pages: collapse the landing token set into a single Tailwind v4 @theme source in the new repo. This is the #1 thing not to reproduce.

Lens 2 — Capability liftout (capability-liftout)

Key finding: the "non-auth" pages are not auth-free in code — Login / AuthCallback / AuthWelcome import @/lib/supabase and @/auth/AuthContext (Login.tsx:31,33). So the cut-line is at route protection (AuthGuard), not the auth client. The auth client seam stands up in Wave 1; only the guard is deferred.

Proof slice (smallest safe first transplant): token base + PublicLayout + NotFound — renders with zero backend.

Lens 3 — Sequenced start plan (writing-plans)

Ordered file sets, each with the gate it passes before it lands.

Set 0 — scaffold (no pages): Vite + React + TS + Tailwind v4; platform-api skeleton; clean asset_id-native Neon migration chain; SOPS; /healthz/data-plane; router skeleton.

Set 1 — token base + zero-backend proof slice

• web/src/tailwind.css (unified @theme), PublicLayout.tsx, PublicFooter.tsx, pages/NotFound.tsx
• Gate: renders at / and a 404 route · build passes · rg source_uid = 0 · exactly one token source (no landing-tokens.css).

Set 2 — public content pages

• MarketingLayout.tsx (+ PublicNav), pages/MarketingIntegrations.tsx, pages/experiments/PlatformLanding.tsx
• Gate: render on unified tokens · visual parity vs current · build · zero source_uid.

Set 3 — auth-entry pages (stands up the auth client seam)

• future auth client seam, auth/AuthContext.tsx, pages/Login.tsx, pages/AuthCallback.tsx, pages/AuthWelcome.tsx
• Gate: target auth provider works end-to-end in dev, JWT/session issued, build passes, and zero source_uid. This is deferred until the first auth-entry/auth-gated page slice.

Per-file verification gate (applies to every file): renders on its route · pnpm build passes · rg source_uid = 0 in the file and its lifted deps · interactive pages get a browser smoke per pm-manifest §19.