docs(launch): prepare crawlable multilingual content and SEO contracts

docs/launch-site/CONTENT_ARCHITECTURE.md

@@ -0,0 +1,20 @@
+# Public content architecture — proposed, not implemented
+
+2 November 2026. Independent preparation under the owner's current direct-roadmap instruction. No visual concept selected, public route added, marketing claim published or application source changed. Final layout/section order remains an owner decision.
+
+Reuse the current Next static-export build, React Router private shell, MUI design tokens, shared plan ownership and en/nb translation contracts. Avoid a CMS or second application shell. Public descriptive content should be emitted as crawlable static HTML from repository-managed, locale-aware content; authenticated routes retain their current client-only providers. Do not turn private account data, feature flags or arbitrary query strings into build-time content.
+
+Separate content domains:
+
+- Feature catalogue: stable feature ID and links to implementation, scoped acceptance, deployed identity, entitlement, market, locale, approved screenshot and marketing approval. Missing evidence withholds a current-availability claim. Existing MARKETING_CLAIM_VALIDATION.md remains the authority; do not duplicate it into a competing status list.
+- Page copy: complete title, description, headings, feature narratives, links, FAQ and accessible text in approved locale resources. Whole sentences and explicit placeholders; reuse terminology and distinguish canonical Career Profile from a CV variant.
+- Market: available product/provider capabilities, actual billing/currency, legal links and applicable languages. A market is not a language, nationality or automatic grant to fetch jobs.
+- Assets: genuine synthetic product captures with source commit/date/surface/theme/viewport, rights and alt-text context. The five application design concepts are conceptual prototypes, not screenshots of a released product. No unlicensed images or invented customer testimonials.
+
+Draft profession-neutral content options for later copy review: “Your job search, organised.” / “Jobbsøkingen din, organisert.” Supporting proposition: “Keep applications, career information and documents together.” / “Samle søknader, karriereinformasjon og dokumenter på ett sted.” These are unpublished candidate copy, not released-capability approval or native-language acceptance. Avoid promising universal import accuracy, live international sources, automatic employer actions, AI availability or privacy certifications.
+
+Candidate narrative modules (not an approved order): clear outcome and product preview; tracking and next steps; Career Profile/document workflow; optional import review; how it works; verified plan information; factual FAQ; supported registration path; legal/support footer. Where registration is disabled, the CTA must use the existing truthful sign-in/access path rather than promise account creation. Legal destinations and final FAQ answers require verified content; never invent links or policies.
+
+Implementation gate: after final visual approval, use the approved composition with static public copy and a small client interaction boundary for preference/navigation. Preserve signed-in redirect, protected-route return state and the existing dashboard-first optional onboarding. No second onboarding flow. Reverting future content is an ordinary version-controlled content rollback; no database migration is proposed by this architecture.
+
+Open: final visual choice, actual released feature/plan/provider evidence, production origin/deployed identity, public asset provenance and native copy review. Full European catalogue work does not automatically publish locale pages.

docs/launch-site/INTERNATIONALISATION.md

@@ -0,0 +1,11 @@
+# Marketing locale integration — proposed contract
+
+2 November 2026. EN/Bokmål source support is existing; no additional locale is released by this report. Reuse I18N-00 registry/catalogue proposals and their review gates instead of a second country-language mapping. Full European locale identities, script distinctions and native review remain the localisation workstream's responsibility.
+
+Keep marketing content locale, selected market, application UI language, ad-language preferences and document language distinct. A marketing selector may offer a deliberate explicit application-language action after sign-in; it must not silently write ad/document preferences. Current shared UI preference behavior must be inspected and migrated compatibly before introducing a separate persisted marketing choice. No persistence change is made here.
+
+Supported choices show native and English names, retain English access, and allow another supported language independent of market. Bokmål/nb/nb-NO/no legacy compatibility does not grant Nynorsk support. Unreleased languages may be described truthfully as forthcoming only with approved copy; they do not receive public routes, hreflang or sitemap entries. User-generated CV/job text is not translated by changing chrome language.
+
+Complete each published variant's visible, form, error, accessibility, metadata, social and legal text. Validate keys/placeholders, fallback behavior, interpolation escaping, long labels, plural/number/date/currency rules and dirty-form switching. Native terminology review is separate from syntactic coverage. Currency display follows real billing capability, not a selected country. Preserve provider names, original job language, rights/attribution and the distinction between source descriptions and any reviewed translation.
+
+Acceptance remains BLOCKED for additional released locales until architecture entry, coverage, translation rights/proficient review, actual market capabilities, approved content and integrated QA are satisfied. This does not prevent independent catalogue, fixture, content and SEO planning. See SEO_STRATEGY.md for published-only URL constraints and CONTENT_ARCHITECTURE.md for content ownership.

docs/launch-site/RELEASE_HANDOFF.md

@@ -1,5 +1,7 @@
 # Partial homepage planning handoff
 
+Continuation 2 November: CONTENT_ARCHITECTURE.md, INTERNATIONALISATION.md and SEO_STRATEGY.md add independent design-neutral content/routing/publication proposals. Byte-matched existing build-shell evidence confirms raw export lacks descriptive marketing HTML, canonical and hreflang. No public UI/routes/metadata implementation or final visual choice made. These source/build checks are not live SEO, performance or release qualification. The five application UI concepts remain separate from LAUNCH-01's required homepage exploration; no sixth application concept created.
+
 Branch `feature/launch-site-redesign`, baseline `5cb903b989742b7a96cb22ddf4c0e24993b18980`. Documentation-only source audit. LAUNCH-00 remains IN_PROGRESS. LAUNCH-01 four actual desktop/mobile concepts are PENDING, not replaced by written descriptions. No owner design decision requested until reviewable concepts exist.
 
 Next authorised work:

docs/launch-site/SEO_STRATEGY.md

@@ -0,0 +1,22 @@
+# SEO baseline and design-neutral proposal
+
+2 November 2026. Source/available-build review only; no deployment, crawl, search-engine ranking, Lighthouse or performance score claimed.
+
+## Measured raw-export baseline
+
+Reused the successful local I18N static build, checking byte identity of launch-branch `app/layout.tsx`, `app/page.tsx` and `app/[[...slug]]/ClientShell.tsx` first. Their SHA256 values respectively: `8e4f0cd2776d821c958480aec5c93943674acb0fe28cd60d0822df40009cb262`, `bf661f17c1c7c06ff8fda41b1afa44144bce694c815d52c3d5a927e32063b1b1`, `0afd4379fbfaeb2059cfa860b10523b212a20dc19c64f961de77bb8572ee6791`. ClientShell disables SSR for the application. This is reused build evidence for unchanged shell sources, not a fresh launch-branch build or proof of every bundle.
+
+A standard-library HTML parser excluding script/style text found only `Jobbjakt` and `You need to enable JavaScript to run this app.` in out/index.html; canonical link count 0, hreflang count 0. This confirms missing descriptive raw HTML, not an assertion that JavaScript-capable crawlers cannot index the client UI. Root metadata is generic and document language initially en. Record post-implementation comparisons against this narrow baseline.
+
+## Proposed contract after design/routing approval
+
+- Emit approved public headings, descriptions, feature text and FAQs in static HTML. Keep private routes and provider/account content outside the prerendered marketing boundary.
+- Give each published page a descriptive locale-specific title/description, semantic heading hierarchy, Open Graph metadata and approved social asset. Use factual SoftwareApplication/Organization structured data only when supported by the actual page; no fabricated ratings, offers or testimonials.
+- Obtain the production public origin from release-approved configuration. Do not guess a hostname or use localhost as a public canonical. Canonicals must refer to the intended published page, with query/tracking variants normalised.
+- Derive canonical/reciprocal alternate/sitemap entries from the same approved published market/content-locale inventory. Include only fully supported published variants; self and reciprocal links must agree. An unreviewed locale is absent, not an empty indexable page. Use valid language/script/region tags; country NO must not be treated as Bokmål nb.
+- Decide URL shape separately from visuals: proposed explicit `/market/{market}/{contentLocale}/...` or another approved unambiguous scheme. This is a proposal, not an added route. Preserve existing auth and application links and static-host fallback behavior; do not implement speculative duplicate country pages.
+- Keep incomplete/pre-release previews outside production index publication. Robots directives are not an authorisation boundary or protection for private content. Do not expose private or admin routes through sitemap generation.
+
+## Required verification before acceptance
+
+Parse exported HTML per approved locale/market; assert meaningful non-JS content, title/description/lang, one intended h1, canonical origin, reciprocal published-only alternates and sitemap membership. Check no unpublished variants, private URLs or unsupported prices/providers. Follow links in an isolated browser; test auth redirect/registration configuration, language persistence and separation from ad/document preferences. Then measure responsive/accessibility/performance budgets on realistic test conditions, preserving manual/device/native-language and deployed-origin gates. No executable SEO publishing infrastructure is introduced by this report.