.github/agents/copilot-instructions.md

@@ -266,6 +266,8 @@ ## Active Technologies
 - PostgreSQL via existing `workspace_settings` rows plus existing audit log records; no new table or billing/account model (251-commercial-entitlements-billing-state)
 - PHP 8.4 (Laravel 12) + Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `UiEnforcement`, `OperationUxPresenter`, `OperationRunService`, `OperationCatalog`, `SystemOperationRunLinks`, `OperationRunLinks`, `AuditRecorder`, `WorkspaceAuditLogger`, and `PlatformCapabilities` (253-remove-findings-backfill-runtime-surfaces)
 - PostgreSQL existing `findings`, `operation_runs`, `audit_logs`, and related runtime tables only; no new persistence, migration, or data backfill is planned (253-remove-findings-backfill-runtime-surfaces)
+- TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 + Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwrigh (404-public-content-messaging)
+- N/A - static website content and generated build output only; no database or product persistence (404-public-content-messaging)
 
 - PHP 8.4.15 (feat/005-bulk-operations)
 
@@ -300,9 +302,9 @@ ## Code Style
 PHP 8.4.15: Follow standard conventions
 
 ## Recent Changes
+- 404-public-content-messaging: Added TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 + Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwrigh
 - 253-remove-findings-backfill-runtime-surfaces: Added PHP 8.4 (Laravel 12) + Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `UiEnforcement`, `OperationUxPresenter`, `OperationRunService`, `OperationCatalog`, `SystemOperationRunLinks`, `OperationRunLinks`, `AuditRecorder`, `WorkspaceAuditLogger`, and `PlatformCapabilities`
 - 251-commercial-entitlements-billing-state: Added PHP 8.4 (Laravel 12) + Filament v5 + Livewire v4, existing workspace settings stack (`SettingsRegistry`, `SettingsResolver`, `SettingsWriter`), `WorkspaceEntitlementResolver`, `ReviewPackService`, system directory detail page
-- 249-customer-review-workspace: Added PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Pest v4, existing review/evidence/review-pack/audit/RBAC support services
 <!-- MANUAL ADDITIONS START -->
 
 ### Pre-production compatibility check

Agents.md

@@ -945,6 +945,7 @@ ## Active Technologies
 - TypeScript 5.9, Astro 6 static components, HTML, CSS + Astro 6.0.0, Tailwind CSS 4.2.2 through CSS-first `@theme` and `@tailwindcss/vite`, `astro-icon`, `@iconify-json/lucide`, Playwright 1.59.1 (400-tenantial-homepage-visual-rebuild)
 - TypeScript 5.9.3, Astro 6.0.0, Tailwind CSS v4.2.2 via `@tailwindcss/vite`, `astro-icon`, `@iconify-json/lucide`, and Playwright smoke tests for the static website; no database, CMS, API, customer data, tenant data, or runtime persistence. (401-tenantial-platform-page)
 - TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 + Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwright; static website content only, no database or product persistence. (feat/403-public-website-launch-readiness)
+- No new technology; reuses TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0, Starlight, Tailwind CSS v4, Preline, Lenis, GSAP, Sharp, and Playwright for static website content, docs content, route metadata, and generated build output only; no database or product persistence. (404-public-content-messaging)
 
 ## Recent Changes
 - 066-rbac-ui-enforcement-helper-v2-session-1769732329: Planned UiEnforcement v2 (spec + plan + design artifacts)

apps/website/.prettierignore

@@ -0,0 +1,14 @@
+node_modules/
+dist/
+build/
+coverage/
+.astro/
+playwright-report/
+test-results/
+blob-report/
+package-lock.json
+yarn.lock
+pnpm-lock.yaml
+*.log
+.env
+.env.*

apps/website/src/components/pages/HomePage.astro

@@ -5,6 +5,8 @@ import FeaturesGeneral from '@components/sections/features/FeaturesGeneral.astro
 import FeaturesNavs from '@components/sections/features/FeaturesNavs.astro';
 import PricingSection from '@components/sections/pricing/PricingSection.astro';
 import FAQ from '@components/sections/misc/FAQ.astro';
+import PrimaryCTA from '@components/ui/buttons/PrimaryCTA.astro';
+import SecondaryCTA from '@components/ui/buttons/SecondaryCTA.astro';
 import heroImage from '@images/tenantial-dashboard.avif';
 import featureImage from '@images/tenantial-review-board.avif';
 import reviewImage from '@images/tenantial-evidence-intake.avif';
@@ -25,9 +27,17 @@ interface Props {
 }
 
 const copy = siteCopy[locale].home;
+const workflowImages = [
+  heroImage,
+  featureImage,
+  reviewImage,
+  evidenceImage,
+  governanceImage,
+  featureImage,
+];
 const tabs = copy.tabs.map((tab: any, index: number) => ({
   ...tab,
-  src: [reviewImage, evidenceImage, governanceImage][index],
+  src: workflowImages[index],
 }));
 ---
 
@@ -59,7 +69,85 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({
 
   <FeaturesNavs title={copy.workflowTitle} tabs={tabs} />
 
+  <section class="mx-auto max-w-[85rem] px-4 py-10 sm:px-6 lg:px-8 lg:py-14 2xl:max-w-full">
+    <div class="max-w-(--breakpoint-md)">
+      <h2 class="text-2xl font-bold text-balance text-neutral-800 md:text-3xl dark:text-neutral-200">
+        {copy.audienceTitle}
+      </h2>
+      <p class="mt-3 max-w-prose text-pretty text-neutral-600 md:text-lg dark:text-neutral-400">
+        {copy.audienceSubtitle}
+      </p>
+    </div>
+
+    <div class="mt-8 grid gap-6 lg:grid-cols-3">
+      {
+        copy.audiences.map((audience: any) => (
+          <article class="rounded-3xl border border-neutral-300 bg-neutral-100/70 p-6 shadow-xs dark:border-neutral-700 dark:bg-white/[0.04]">
+            <h3 class="text-lg font-semibold text-neutral-800 dark:text-neutral-200">
+              {audience.title}
+            </h3>
+            <p class="mt-3 text-pretty text-neutral-600 dark:text-neutral-400">
+              {audience.content}
+            </p>
+          </article>
+        ))
+      }
+    </div>
+  </section>
+
+  <section class="mx-auto max-w-[85rem] px-4 py-10 sm:px-6 lg:px-8 lg:py-14 2xl:max-w-full">
+    <div class="rounded-[2rem] border border-neutral-300 bg-neutral-100/80 p-6 md:p-10 dark:border-neutral-700 dark:bg-white/[0.05]">
+      <div class="max-w-(--breakpoint-md)">
+        <h2 class="text-2xl font-bold text-balance text-neutral-800 md:text-3xl dark:text-neutral-200">
+          {copy.boundaryTitle}
+        </h2>
+        <p class="mt-3 max-w-prose text-pretty text-neutral-600 md:text-lg dark:text-neutral-400">
+          {copy.boundarySubtitle}
+        </p>
+      </div>
+
+      <div class="mt-8 grid gap-4 md:grid-cols-3">
+        {
+          copy.boundaries.map((boundary: any) => (
+            <article class="rounded-2xl bg-neutral-200/80 p-5 dark:bg-neutral-900/70">
+              <h3 class="text-base font-semibold text-neutral-800 dark:text-neutral-200">
+                {boundary.title}
+              </h3>
+              <p class="mt-3 text-sm leading-6 text-neutral-600 dark:text-neutral-400">
+                {boundary.content}
+              </p>
+            </article>
+          ))
+        }
+      </div>
+    </div>
+  </section>
+
   <PricingSection pricing={pricingByLocale[locale]} locale={locale} />
 
   <FAQ title={copy.faqTitle} faqs={faqsByLocale[locale]} />
+
+  <section class="mx-auto max-w-[85rem] px-4 pb-10 sm:px-6 lg:px-8 lg:pb-14 2xl:max-w-full">
+    <div class="rounded-[2rem] bg-linear-to-r from-neutral-900 to-neutral-700 px-6 py-8 text-neutral-50 md:px-10 md:py-12 dark:from-neutral-100 dark:to-neutral-300 dark:text-neutral-900">
+      <div class="max-w-(--breakpoint-lg)">
+        <h2 class="text-2xl font-bold text-balance md:text-3xl">
+          {copy.finalCtaTitle}
+        </h2>
+        <p class="mt-3 max-w-2xl text-pretty text-neutral-200 dark:text-neutral-700">
+          {copy.finalCtaSubtitle}
+        </p>
+      </div>
+
+      <div class="mt-6 flex flex-col gap-3 sm:flex-row">
+        <PrimaryCTA
+          title={copy.finalPrimaryCta}
+          url={localizeHref('/contact', locale)}
+        />
+        <SecondaryCTA
+          title={copy.finalSecondaryCta}
+          url={localizeHref('/trust', locale)}
+        />
+      </div>
+    </div>
+  </section>
 </MainLayout>

apps/website/src/components/pages/PlatformPage.astro

@@ -57,6 +57,32 @@ const canonicalPath = localizedPath('/platform', locale);
     btnURL={localizeHref('/contact', locale)}
   />
 
+  <section class="mx-auto max-w-[85rem] px-4 py-4 sm:px-6 lg:px-8 lg:py-8 2xl:max-w-full">
+    <div class="max-w-(--breakpoint-md)">
+      <h2 class="text-2xl font-bold text-balance text-neutral-800 md:text-3xl dark:text-neutral-200">
+        {copy.focusTitle}
+      </h2>
+      <p class="mt-3 max-w-prose text-pretty text-neutral-600 md:text-lg dark:text-neutral-400">
+        {copy.focusSubtitle}
+      </p>
+    </div>
+
+    <div class="mt-8 grid gap-6 md:grid-cols-2">
+      {
+        copy.focusCards.map((card: any) => (
+          <article class="rounded-3xl border border-neutral-300 bg-neutral-100/70 p-6 shadow-xs dark:border-neutral-700 dark:bg-white/[0.04]">
+            <h3 class="text-lg font-semibold text-neutral-800 dark:text-neutral-200">
+              {card.title}
+            </h3>
+            <p class="mt-3 text-pretty text-neutral-600 dark:text-neutral-400">
+              {card.content}
+            </p>
+          </article>
+        ))
+      }
+    </div>
+  </section>
+
   <RightSection
     title={copy.backupTitle}
     subTitle={copy.backupSubtitle}

apps/website/src/components/sections/misc/ContactSection.astro

@@ -44,7 +44,11 @@ const copy = siteCopy[locale].contact;
           /* Form for user input with various input fields.-->
         {/* Each field utilizes a different input component for the specific type of input (text, email, phone, and textarea)*/
         }
-        <form>
+        <form
+          action="mailto:hello@tenantial.com"
+          method="post"
+          enctype="text/plain"
+        >
           <div class="grid gap-4">
             <div class="grid grid-cols-1 gap-4 sm:grid-cols-2">
               <TextInput

apps/website/src/components/ui/blocks/IconBlock.astro

@@ -16,7 +16,9 @@ const contentClasses =
 {/* The root container that arranges your slot and the heading/content */}
 <div class="flex gap-x-5">
   {/* Slot to allow for extensibility of the component */}
-  <slot />
+  <div class="flex size-11 shrink-0 items-center justify-center rounded-2xl bg-neutral-200/80 text-orange-500 dark:bg-white/[0.06] dark:text-orange-300 [&>svg]:!m-0 [&>svg]:!size-6 [&>svg]:!shrink-0 [&>svg]:!fill-current">
+    <slot />
+  </div>
   <div class="grow">
     {/* Heading of the section */}
     <h3 class={headingClasses}>

apps/website/src/components/ui/blocks/LeftSection.astro

@@ -33,7 +33,7 @@ interface Props {
   <div class="mt-4 md:mt-0">
     {/* The title of the section */}
     <h2
-      class="mb-4 text-4xl font-extrabold tracking-tight text-balance text-neutral-800 dark:text-neutral-200"
+      class="mb-4 text-3xl font-extrabold tracking-tight break-words text-balance text-neutral-800 md:text-4xl dark:text-neutral-200"
     >
       {title}
     </h2>

apps/website/src/components/ui/blocks/RightSection.astro

@@ -37,7 +37,7 @@ interface Props {
   <div>
     {/* Title of the section */}
     <h2
-      class="mb-4 text-4xl font-extrabold tracking-tight text-balance text-neutral-800 dark:text-neutral-200"
+      class="mb-4 text-3xl font-extrabold tracking-tight break-words text-balance text-neutral-800 md:text-4xl dark:text-neutral-200"
     >
       {title}
     </h2>

apps/website/src/components/ui/blocks/StatsBig.astro

@@ -9,9 +9,11 @@ interface Props {
 ---
 
 {/* Container for the title and subtitle */}
-<div class="lg:pe-6 xl:pe-12">
-  <p class="text-6xl leading-10 font-bold text-orange-400 dark:text-orange-300">
+<div class="min-w-0 lg:pe-6 xl:pe-12">
+  <p class="text-6xl leading-10 font-bold break-words text-balance text-orange-400 dark:text-orange-300">
     {title}
   </p>
-  <p class="mt-2 text-neutral-600 sm:mt-3 dark:text-neutral-400">{subTitle}</p>
+  <p class="mt-2 break-words text-neutral-600 sm:mt-3 dark:text-neutral-400">
+    {subTitle}
+  </p>
 </div>

apps/website/src/components/ui/blocks/StatsSmall.astro

@@ -9,7 +9,11 @@ interface Props {
 ---
 
 {/* Container for title and subtitle */}
-<div>
-  <p class="text-3xl font-bold text-orange-400 dark:text-orange-300">{title}</p>
-  <p class="mt-1 text-neutral-600 dark:text-neutral-400">{subTitle}</p>
+<div class="min-w-0">
+  <p class="text-3xl font-bold break-words text-balance text-orange-400 dark:text-orange-300">
+    {title}
+  </p>
+  <p class="mt-1 break-words text-neutral-600 dark:text-neutral-400">
+    {subTitle}
+  </p>
 </div>

apps/website/src/components/ui/blocks/TabNav.astro

@@ -14,6 +14,8 @@ interface Props {
 // Define button classes
 const BUTTON_CLASS =
   'dark:hover:bg-neutral-700 rounded-xl p-4 text-start outline-hidden ring-zinc-500 transition duration-300 hover:bg-neutral-200 focus-visible:ring-3 hs-tab-active:bg-neutral-50 hs-tab-active:shadow-md hs-tab-active:hover:border-transparent dark:ring-zinc-200 dark:focus:outline-hidden  dark:hs-tab-active:bg-neutral-700/60 md:p-5';
+const ICON_CLASS =
+  'mt-0.5 flex size-10 shrink-0 items-center justify-center text-neutral-500 transition-colors hs-tab-active:text-orange-500 dark:text-neutral-400 dark:hs-tab-active:text-orange-300 [&_svg]:m-0 [&_svg]:h-7 [&_svg]:w-7 [&_svg]:fill-current';
 
 /*
 first: This property should be set to true for the initial TabNav component in your list
@@ -40,13 +42,15 @@ Example:
   role="tab"
 >
   {/* Slot for additional content */}
-  <span class="flex">
-    <slot />
+  <span class="flex items-start gap-5">
+    <span class={ICON_CLASS}>
+      <slot />
+    </span>
     {/* Container for the heading and content of the tab */}
-    <span class="ms-6 grow">
+    <span class="grow">
       {/* Heading of the tab, changes color when active */}
       <span
-        class="hs-tab-active:text-orange-400 dark:hs-tab-active:text-orange-300 block text-lg font-bold text-neutral-800 dark:text-neutral-200"
+        class="hs-tab-active:text-orange-500 dark:hs-tab-active:text-orange-300 block text-lg font-bold text-neutral-800 dark:text-neutral-200"
         >{heading}</span
       >
       {/* Content of the tab, changes color when active */}

apps/website/src/components/ui/buttons/LoginBtn.astro

@@ -1,5 +1,5 @@
 ---
-const { title = 'Log in' } = Astro.props;
+const { title = 'Contact' } = Astro.props;
 
 interface Props {
   title?: string;
@@ -31,7 +31,7 @@ const userSVG = `<svg
 <button
   type="button"
   class={`${baseClasses} ${hoverClasses} ${darkClasses} ${mdClasses} ${txtSizeClasses}`}
-  data-hs-overlay="#hs-toggle-between-modals-login-modal"
+  data-hs-overlay="#hs-public-contact-modal"
 >
   {
     /* About Fragment: https://docs.astro.build/en/basics/astro-syntax/#fragments */

apps/website/src/components/ui/forms/LoginModal.astro

@@ -1,19 +1,17 @@
 ---
 // Import necessary components from their individual files
 import EmailInput from './input/EmailInput.astro';
-import PasswordInput from './input/PasswordInput.astro';
-import Checkbox from './input/Checkbox.astro';
+import TextAreaInput from './input/TextAreaInput.astro';
 import AuthBtn from '@components/ui/buttons/AuthBtn.astro';
-import GoogleBtn from '@components/ui/buttons/GoogleBtn.astro';
 
-// Variables for customization of the LoginModal Component
+// Variables for customization of this legacy contact modal.
 
 const config = {
-  id: 'hs-toggle-between-modals-login-modal', // Modal IDENTIFIER
-  title: 'Sign in', // Main HEADING
-  subTitle: "Don't have an account yet?", // Sub-Heading TEXT
-  registerBtn: 'Sign up here', // Text for REGISTRATION BUTTON
-  registerBtnDataHS: '#hs-toggle-between-modals-register-modal', // TARGET LINK for registration button
+  id: 'hs-public-contact-modal',
+  title: 'Contact Tenantial',
+  subTitle: 'Need a scoped evaluation path?',
+  registerBtn: 'Open scope request',
+  registerBtnDataHS: '#hs-public-scope-modal',
 };
 ---
 
@@ -49,30 +47,23 @@ const config = {
             </p>
           </div>
           <div class="mt-5">
-            <GoogleBtn title="Sign in with Google" />
-
-            <div
-              class="flex items-center py-3 text-xs text-neutral-400 uppercase before:me-6 before:flex-[1_1_0%] before:border-t before:border-neutral-200 after:ms-6 after:flex-[1_1_0%] after:border-t after:border-neutral-200 dark:text-neutral-500 dark:before:border-neutral-600 dark:after:border-neutral-600"
-            >
-              Or
-            </div>
             {/* The container for the form */}
-            <form>
+            <form
+              action="mailto:hello@tenantial.com"
+              method="post"
+              enctype="text/plain"
+            >
               {/* A grid layout for the form fields */}
               <div class="grid gap-y-4">
                 {/* The email input field */}
-                <EmailInput id="login-email" errorId="login-email-error" />
-                {/* The password input field */}
-                <PasswordInput
-                  forgot={true}
-                  id="password"
-                  errorId="login-password-error"
-                  content="8+ characters required"
+                <EmailInput id="contact-email" errorId="contact-email-error" />
+                <TextAreaInput
+                  id="contact-context"
+                  name="contact-context"
+                  label="Evaluation context"
                 />
-                {/* The remember-me checkbox */}
-                <Checkbox id="remember-me" />
-                {/* The sign-in button */}
-                <AuthBtn title="Sign in" />
+                {/* The contact button */}
+                <AuthBtn title="Prepare contact request" />
               </div>
             </form>
           </div>

apps/website/src/components/ui/forms/RecoverModal.astro

@@ -1,15 +1,16 @@
 ---
 // Import necessary components from individual files
 import EmailInput from './input/EmailInput.astro';
+import TextAreaInput from './input/TextAreaInput.astro';
 import AuthBtn from '@components/ui/buttons/AuthBtn.astro';
 
 // Config object for customization of the component
 const config = {
   id: 'hs-toggle-between-modals-recover-modal', // Modal identifier
-  title: 'Forgot password?', // Main heading
-  subTitle: 'Remember your password?', // Sub-heading text
-  loginBtn: 'Sign in here', // Text for login button
-  loginBtnDataHS: '#hs-toggle-between-modals-login-modal', // Target link for login button
+  title: 'Prepare email context', // Main heading
+  subTitle: 'Need a walkthrough instead?', // Sub-heading text
+  contactBtn: 'Open contact request', // Text for contact button
+  contactBtnDataHS: '#hs-public-contact-modal', // Target link for contact button
 };
 ---
 
@@ -39,24 +40,33 @@ const config = {
             </div>
             <p class="mt-2 text-sm text-neutral-600 dark:text-neutral-400">
               {config.subTitle}
-              {/* Button that, when clicked, opens the login modal */}
+              {/* Button that, when clicked, opens the contact modal */}
               <button
                 class="rounded-lg p-1 font-medium text-orange-400 decoration-2 ring-zinc-500 outline-hidden hover:underline focus-visible:ring-3 dark:text-orange-400 dark:ring-zinc-200 dark:focus:outline-hidden"
-                data-hs-overlay={config.loginBtnDataHS}
+                data-hs-overlay={config.contactBtnDataHS}
               >
-                {config.loginBtn}
+                {config.contactBtn}
               </button>
             </p>
           </div>
 
           <div class="mt-5">
-            {/* The form for password recovery */}
-            <form>
+            {/* The form for public contact context */}
+            <form
+              action="mailto:hello@tenantial.com"
+              method="post"
+              enctype="text/plain"
+            >
               <div class="grid gap-y-4">
                 {/* Email input field imported from EmailInput component */}
-                <EmailInput id="recover-email" errorId="recover-email-error" />
-                {/* Reset password button imported from AuthBtn component */}
-                <AuthBtn title="Reset password" />
+                <EmailInput id="email-context" errorId="email-context-error" />
+                <TextAreaInput
+                  id="email-notes"
+                  name="email-notes"
+                  label="Notes for Tenantial"
+                />
+                {/* Contact button imported from AuthBtn component */}
+                <AuthBtn title="Prepare email context" />
               </div>
             </form>
           </div>

apps/website/src/components/ui/forms/RegisterModal.astro

@@ -1,17 +1,15 @@
 ---
 // Import necessary components from individual files
 import EmailInput from './input/EmailInput.astro';
-import PasswordInput from './input/PasswordInput.astro';
-import Checkbox from './input/Checkbox.astro';
-import GoogleBtn from '@components/ui/buttons/GoogleBtn.astro';
+import TextAreaInput from './input/TextAreaInput.astro';
 import AuthBtn from '@components/ui/buttons/AuthBtn.astro';
 // Config object for customization of the component
 const config = {
-  id: 'hs-toggle-between-modals-register-modal', // Modal identifier
-  title: 'Sign up', // Main heading
-  subTitle: 'Already have an account?', // Sub-heading text
-  loginBtn: 'Sign in here', // Text for login button
-  loginBtnDataHS: '#hs-toggle-between-modals-login-modal', // Target link for login button
+  id: 'hs-public-scope-modal', // Modal identifier
+  title: 'Scope request', // Main heading
+  subTitle: 'Need a lighter contact path?', // Sub-heading text
+  contactBtn: 'Open contact request', // Text for contact button
+  contactBtnDataHS: '#hs-public-contact-modal', // Target link for contact button
 };
 ---
 
@@ -40,57 +38,36 @@ const config = {
             </div>
             <p class="mt-2 text-sm text-neutral-600 dark:text-neutral-400">
               {config.subTitle}
-              {/* Button to toggle login modal */}
+              {/* Button to toggle the contact modal */}
               <button
                 class="rounded-lg p-1 font-medium text-orange-400 decoration-2 ring-zinc-500 outline-hidden hover:underline focus-visible:ring-3 dark:text-orange-400 dark:ring-zinc-200 dark:focus:outline-hidden"
-                data-hs-overlay={config.loginBtnDataHS}
+                data-hs-overlay={config.contactBtnDataHS}
               >
-                {config.loginBtn}
+                {config.contactBtn}
               </button>
             </p>
           </div>
-          {/* The form for user registration */}
+          {/* The form for public scope context */}
           <div class="mt-5">
-            {/* Google signup button */}
-            <GoogleBtn title="Sign up with Google" />
-            {/* Dividing line with 'Or' text */}
-            <div
-              class="flex items-center py-3 text-xs text-neutral-400 uppercase before:me-6 before:flex-[1_1_0%] before:border-t before:border-neutral-200 after:ms-6 after:flex-[1_1_0%] after:border-t after:border-neutral-200 dark:text-neutral-500 dark:before:border-neutral-600 dark:after:border-neutral-600"
+            {/* Scope request form */}
+            <form
+              action="mailto:hello@tenantial.com"
+              method="post"
+              enctype="text/plain"
             >
-              Or
-            </div>
-            {/* Registration form */}
-            <form>
               <div class="grid gap-y-4">
                 {/* Email input field */}
                 <EmailInput
-                  id="register-email"
-                  errorId="register-email-error"
+                  id="scope-email"
+                  errorId="scope-email-error"
                 />
-                {/* Password input field */}
-                <PasswordInput
-                  id="create-password"
-                  errorId="register-password-error"
-                  content="8+ characters required"
+                <TextAreaInput
+                  id="scope-context"
+                  name="scope-context"
+                  label="Rollout or evaluation context"
                 />
-                {/* Password confirmation input field */}
-                <PasswordInput
-                  label="Confirm Password"
-                  id="confirm-password"
-                  errorId="confirm-password-error"
-                  content="Password does not match the password"
-                />
-                {
-                  /* Checkbox with a label and a link for accepting the terms and conditions */
-                }
-                <Checkbox label="I accept the " , id="terms-agree">
-                  <a
-                    class="font-medium text-orange-400 decoration-2 hover:underline dark:text-orange-400 dark:focus:outline-hidden"
-                    href="/terms">Terms and Conditions</a
-                  >
-                </Checkbox>
-                {/* Submit button for the registration form */}
-                <AuthBtn title="Sign up" />
+                {/* Submit button for the scope form */}
+                <AuthBtn title="Prepare scope request" />
               </div>
             </form>
           </div>

apps/website/src/content/docs/en/guides/first-project-checklist.mdx

@@ -9,7 +9,10 @@ sidebar:
 Use this checklist before a product walkthrough:
 
 - Confirm which Microsoft tenant workflows are in scope.
+- Confirm that Microsoft 365 is the current focus and any other providers are treated only as future direction.
 - Separate read-only review needs from any future write or restore needs.
 - Identify audit and approval expectations.
+- Map backup, restore, drift, findings, evidence, auditability, exceptions, and reviews to the buyer questions that matter most.
+- Keep trust, compliance, and recovery assumptions listed as items to verify rather than promises already made.
 - Plan staging validation before production rollout.
 - Keep private tenant data out of public website communication.

apps/website/src/content/docs/en/guides/getting-started.mdx

@@ -6,13 +6,16 @@ sidebar:
   order: 2
 ---
 
-Start with a scoped conversation about the tenant governance problem you want to solve.
+Start with a scoped conversation about the tenant governance problem you want to solve. The focus is category, risk, decision paths, and review participants, not self-serve access.
 
 Useful preparation:
 
 - Identify the Microsoft tenant administration workflows that need review.
+- Note which questions are clearly in current Microsoft 365 scope and which provider questions stay future direction.
 - List which policy families, backup flows, or restore planning scenarios matter first.
 - Decide who needs to participate in evidence review and approval.
+- Note which findings, exceptions, or auditability expectations would carry the most decision value.
+- Separate trust, compliance, and recovery questions into verified facts versus open review points.
 - Avoid sending private tenant exports or credentials through public website contact paths.
 
 Tenantial walkthroughs should stay focused on review clarity, least-privilege rollout planning, and staging validation before production use.

apps/website/src/content/docs/en/guides/intro.mdx

@@ -1,18 +1,20 @@
 ---
 title: Introduction to Tenantial
-description: Public introduction to Tenantial's evidence-first Microsoft tenant governance model.
+description: Public introduction to Tenantial's policy-governance model for Microsoft 365.
 sidebar:
   label: Introduction
   order: 1
 ---
 
-Tenantial is positioned around careful Microsoft tenant governance. Public materials focus on observed inventory, immutable policy snapshots, drift review, findings, exceptions, audit context, and defensive restore planning.
+Tenantial is positioned around policy governance for Microsoft 365. Public materials explain how observed state, policy evidence, drift, review, decisions, and audit trail fit together as one reviewable operating model.
+
+Microsoft 365 is the current public focus. Other providers may appear only as architecture or roadmap direction, not as live supported integrations.
 
 The website documentation is intentionally public and static. It does not expose live tenant data, operational evidence, private support material, credentials, or connected Microsoft accounts.
 
 ## What to review first
 
-- How policy evidence is collected and normalized for review.
-- How snapshots support comparison and restore planning.
-- How findings and exceptions make decisions attributable.
-- How restore is treated as preview-first work.
+- How observed state and policy evidence are collected and normalized for review.
+- How drift, findings, and review work lead into a traceable decision.
+- How Microsoft 365 as the current focus is separated from provider-extensible future direction.
+- How controlled recovery stays preview-first work with validation, selective scope, and explicit confirmation.

apps/website/src/content/docs/en/platform/evidence-review.mdx

@@ -1,17 +1,19 @@
 ---
 title: Evidence Review
-description: Public platform note for Tenantial evidence review workflows.
+description: Public platform note for Tenantial evidence-review workflows inside the Microsoft 365 policy-governance model.
 sidebar:
   label: Evidence Review
   order: 1
 ---
 
-Evidence review is the public framing for Tenantial's product direction.
+Evidence review is the public framing for Tenantial's policy-governance model for Microsoft 365. This note describes static product concepts and no live tenant connection.
+
+Microsoft 365 is the current focus of this public story. Other providers may appear only as architecture or roadmap direction.
 
 The model is intentionally cautious:
 
-- Inventory is treated as observed state.
-- Snapshots are explicit records for comparison and planning.
-- Drift and findings become review work.
-- Exceptions and audit notes keep decisions attributable.
-- Restore is planned through preview, validation, selective scope, and explicit confirmation.
+- Observed state is the starting point for review work.
+- Policy evidence and snapshots become explicit records for comparison and planning.
+- Drift and findings turn into visible review work instead of background diagnostics.
+- Decisions, exceptions, and accepted risk stay attributable through audit trail.
+- Recovery is planned through preview, validation, selective scope, and explicit confirmation without promising recovery success.

apps/website/src/content/docs/en/welcome-to-docs.mdx

@@ -3,13 +3,13 @@ title: Tenantial Docs
 head:
   - tag: title
     content: Tenantial Docs
-description: Public notes for understanding Tenantial's evidence-first Microsoft tenant governance model.
+description: Public notes for understanding Tenantial's policy-governance model for Microsoft 365.
 editUrl: false
 lastUpdated: false
 next: false
 hero:
   title: Tenantial documentation
-  tagline: Public notes for evidence review, snapshot discipline, drift review, and cautious restore planning.
+  tagline: Public notes for observed state, evidence, drift, review, decisions, and audit trail with controlled recovery planning.
   actions:
     - text: Get started
       icon: right-arrow
@@ -21,11 +21,11 @@ import '@styles/starlight_main.css';
 import { Card, CardGrid } from '@astrojs/starlight/components';
 
 <CardGrid stagger>
-  <Card title="Evaluation Guides" icon="document">
-    Understand the public product model before planning a rollout conversation.
+  <Card title="Operating model" icon="document">
+    Understand the sequence from observe to evidence, detect, review, decide, and audit before planning a rollout conversation.
   </Card>
 
-  <Card title="Platform Notes" icon="seti:terraform">
-    Review how Tenantial frames inventory evidence, snapshots, findings, and restore planning.
+  <Card title="Provider and trust boundaries" icon="seti:terraform">
+    Review how Tenantial keeps Microsoft 365 as the current focus, treats other providers as future direction, and keeps trust claims conservative.
   </Card>
 </CardGrid>

apps/website/src/content/docs/guides/first-project-checklist.mdx

@@ -9,7 +9,10 @@ sidebar:
 Nutze diese Checkliste vor einem Produkt-Walkthrough:
 
 - Bestätige, welche Microsoft-Tenant-Workflows im Scope sind.
+- Bestätige, dass Microsoft 365 der aktuelle Fokus ist und weitere Provider nur als Zukunftsrichtung behandelt werden.
 - Trenne Read-only-Review-Bedarf von künftigem Write- oder Restore-Bedarf.
 - Identifiziere Audit- und Approval-Erwartungen.
+- Ordne Backup, Restore, Drift, Findings, Evidence, Auditability, Exceptions und Reviews den wichtigsten Buyer-Fragen zu.
+- Halte Trust-, Compliance- und Recovery-Annahmen als zu prüfende Themen fest statt als gegebene Zusagen.
 - Plane Staging-Validierung vor einem Produktionsrollout.
 - Halte private Tenant-Daten aus öffentlicher Website-Kommunikation heraus.

apps/website/src/content/docs/guides/getting-started.mdx

@@ -6,13 +6,16 @@ sidebar:
   order: 2
 ---
 
-Starte mit einem scoped Gespräch über das Tenant-Governance-Problem, das gelöst werden soll.
+Starte mit einem scoped Gespräch über das Tenant-Governance-Problem, das gelöst werden soll. Der Fokus liegt auf Kategorie, Risiko, Entscheidungswegen und Review-Beteiligten, nicht auf Self-Service-Zugang.
 
 Sinnvolle Vorbereitung:
 
 - Identifiziere die Microsoft-Tenant-Administrationsworkflows, die Review brauchen.
+- Halte fest, welche Themen heute klar in Microsoft 365 liegen und welche Provider-Fragen nur Zukunftsrichtung bleiben.
 - Liste die Policy-Familien, Backup-Flows oder Restore-Planungsszenarien, die zuerst relevant sind.
 - Entscheide, wer an Evidence Review und Approval teilnehmen muss.
+- Notiere, welche Findings, Exceptions oder Auditability-Erwartungen den größten Entscheidungswert hätten.
+- Trenne Trust-, Compliance- und Recovery-Fragen in bestätigte Fakten versus offene Prüfpunkte.
 - Sende keine privaten Tenant-Exporte oder Credentials über öffentliche Website-Kontaktpfade.
 
 Tenantial Walkthroughs sollten auf Review-Klarheit, Least-Privilege-Rollout-Planung und Staging-Validierung vor Produktionseinsatz fokussiert bleiben.

apps/website/src/content/docs/guides/intro.mdx

@@ -1,18 +1,20 @@
 ---
 title: Einführung in Tenantial
-description: Öffentliche Einführung in Tenantials evidenzbasiertes Microsoft-Tenant-Governance-Modell.
+description: Öffentliche Einführung in Tenantials Policy-Governance-Modell für Microsoft 365.
 sidebar:
   label: Einführung
   order: 1
 ---
 
-Tenantial ist auf vorsichtige Microsoft-Tenant-Governance ausgerichtet. Öffentliche Materialien fokussieren beobachtetes Inventory, unveränderliche Policy-Snapshots, Drift Review, Findings, Exceptions, Audit-Kontext und defensive Restore-Planung.
+Tenantial ist auf Policy Governance für Microsoft 365 ausgerichtet. Öffentliche Materialien erklären, wie beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail als ein prüfbares Operating Model zusammenhängen.
+
+Microsoft 365 ist der aktuelle öffentliche Fokus. Weitere Provider dürfen nur als Architektur- oder Roadmap-Richtung erscheinen, nicht als live unterstützte Integrationen.
 
 Die Website-Dokumentation ist bewusst öffentlich und statisch. Sie legt keine Live-Tenant-Daten, operative Evidence, private Support-Materialien, Credentials oder verbundenen Microsoft-Konten offen.
 
 ## Was zuerst geprüft werden sollte
 
-- Wie Policy Evidence für Reviews gesammelt und normalisiert wird.
-- Wie Snapshots Vergleich und Restore-Planung unterstützen.
-- Wie Findings und Exceptions Entscheidungen zuordenbar machen.
-- Wie Restore als preview-first Arbeit behandelt wird.
+- Wie beobachteter Zustand und Policy-Evidence für Reviews gesammelt und normalisiert werden.
+- Wie Drift, Findings und Review-Arbeit zu einer nachvollziehbaren Entscheidung führen.
+- Wie Microsoft 365 als aktueller Fokus von provider-extensibler Zukunftsrichtung getrennt wird.
+- Wie kontrollierte Recovery als preview-first Arbeit mit Validierung, selektivem Scope und expliziter Bestätigung behandelt wird.

apps/website/src/content/docs/platform/evidence-review.mdx

@@ -1,17 +1,19 @@
 ---
 title: Evidence Review
-description: Öffentliche Plattform-Notiz für Tenantial Evidence-Review-Workflows.
+description: Öffentliche Plattform-Notiz für Tenantials Evidence-Review-Workflows im Policy-Governance-Modell für Microsoft 365.
 sidebar:
   label: Evidence Review
   order: 1
 ---
 
-Evidence Review ist die öffentliche Rahmung für Tenantials Produktrichtung.
+Evidence Review ist die öffentliche Rahmung für Tenantials Policy-Governance-Modell für Microsoft 365. Die Notiz beschreibt statische Produktkonzepte und keine Live-Tenant-Verbindung.
+
+Microsoft 365 ist der aktuelle Fokus dieser öffentlichen Story. Weitere Provider dürfen nur als Architektur- oder Roadmap-Richtung erscheinen.
 
 Das Modell ist bewusst vorsichtig:
 
-- Inventory wird als beobachteter Zustand behandelt.
-- Snapshots sind explizite Records für Vergleich und Planung.
-- Drift und Findings werden zu Review-Arbeit.
-- Exceptions und Audit-Notizen halten Entscheidungen zuordenbar.
-- Restore wird über Preview, Validierung, selektiven Scope und explizite Bestätigung geplant.
+- Beobachteter Zustand ist der Ausgangspunkt für Review-Arbeit.
+- Policy-Evidence und Snapshots werden als explizite Records für Vergleich und Planung festgehalten.
+- Drift und Findings werden zu sichtbarer Review-Arbeit statt zu stiller Hintergrunddiagnose.
+- Entscheidungen, Ausnahmen und akzeptierte Risiken bleiben über Audit Trail nachvollziehbar.
+- Recovery wird über Preview, Validierung, selektiven Scope und explizite Bestätigung geplant, ohne Recovery-Erfolg zu versprechen.

apps/website/src/content/docs/welcome-to-docs.mdx

@@ -3,13 +3,13 @@ title: Tenantial Docs
 head:
   - tag: title
     content: Tenantial Docs
-description: Öffentliche Notizen zum evidenzbasierten Microsoft-Tenant-Governance-Modell von Tenantial.
+description: Öffentliche Notizen zum Policy-Governance-Modell für Microsoft 365 von Tenantial.
 editUrl: false
 lastUpdated: false
 next: false
 hero:
   title: Tenantial Dokumentation
-  tagline: Öffentliche Notizen zu Evidence Review, Snapshot-Disziplin, Drift Review und vorsichtiger Restore-Planung.
+  tagline: Öffentliche Notizen zu beobachtetem Zustand, Evidence, Drift, Review, Entscheidung und Audit Trail mit kontrollierter Recovery-Planung.
   actions:
     - text: Starten
       icon: right-arrow
@@ -21,11 +21,11 @@ import '@styles/starlight_main.css';
 import { Card, CardGrid } from '@astrojs/starlight/components';
 
 <CardGrid stagger>
-  <Card title="Evaluierungsleitfäden" icon="document">
-    Verstehe das öffentliche Produktmodell, bevor ein Rollout-Gespräch geplant wird.
+  <Card title="Operating Model" icon="document">
+    Verstehe die Abfolge aus beobachten, Evidence sammeln, Drift erkennen, Review, Entscheidung und Audit Trail, bevor ein Rollout-Gespräch geplant wird.
   </Card>
 
-  <Card title="Plattform-Notizen" icon="seti:terraform">
-    Prüfe, wie Tenantial Inventory Evidence, Snapshots, Findings und Restore-Planung rahmt.
+  <Card title="Provider- und Trust-Grenzen" icon="seti:terraform">
+    Prüfe, wie Tenantial Microsoft 365 heute fokussiert, weitere Provider nur als Richtung rahmt und Trust-Claims bewusst konservativ hält.
   </Card>
 </CardGrid>

apps/website/src/data_files/constants.ts

@@ -2,11 +2,11 @@ import ogImageSrc from '@images/social.png';
 
 export const SITE = {
   title: 'Tenantial',
-  tagline: 'Evidenzbasierte Microsoft-Tenant-Governance',
+  tagline: 'Policy Governance für Microsoft 365',
   description:
-    'Tenantial hilft Microsoft-Tenant-Administratoren, Policy-Evidence, Snapshots, Drift, Findings und Restore-Pläne vor kritischen Änderungen zu prüfen.',
+    'Tenantial hilft MSPs, internen IT-Teams und Governance-Verantwortlichen, beobachteten Zustand, Policy-Evidence, Drift, Findings, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 in prüfbare Entscheidungen zu übersetzen.',
   description_short:
-    'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Review, Backup, Drift und Restore-Planung.',
+    'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.',
   url: 'https://tenantial.com',
   author: 'Tenantial',
 };
@@ -35,9 +35,9 @@ export const OG = {
   locale: 'de_DE',
   type: 'website',
   url: SITE.url,
-  title: `${SITE.title}: Evidenzbasierte Microsoft-Tenant-Governance`,
+  title: `${SITE.title}: Policy Governance für Microsoft 365`,
   description:
-    'Prüfe Tenant Inventory, Snapshots, Drift, Findings, Exceptions und Restore-Pläne mit konservativen, auditfreundlichen Workflows.',
+    'Ordne beobachteten Zustand, Evidence, Drift, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 mit konservativen, auditfreundlichen Workflows ein.',
   image: ogImageSrc,
 };
 

apps/website/src/data_files/faqs.json

@@ -3,19 +3,19 @@
   "faqs": [
     {
       "question": "What does Tenantial help teams understand?",
-      "answer": "Tenantial is positioned around backup evidence, restore planning, drift detection, findings, auditability, exceptions, and reviews for Microsoft tenant configuration."
+      "answer": "Tenantial explains policy governance for Microsoft 365: observed state, evidence, drift, review, decisions, audit trail, and controlled recovery planning in one operating model."
+    },
+    {
+      "question": "Is Microsoft 365 the only relevant context?",
+      "answer": "Microsoft 365 is the current public focus. Other providers may be referenced as architecture or roadmap direction, but not as live supported integrations."
     },
     {
       "question": "Does this public website connect to a live tenant?",
       "answer": "No. Product previews and examples are static demonstrations and do not authenticate visitors or read tenant data."
     },
     {
-      "question": "Is restore positioned as an automatic outcome?",
-      "answer": "No. Tenantial describes restore as a cautious workflow with preview, validation, selective scope, explicit confirmation, and review context."
-    },
-    {
-      "question": "Does Tenantial publish customer proof here?",
-      "answer": "No customer logos, third-party endorsements, external assurance statements, service-level commitments, or recovery promises are published without supplied and reviewed evidence."
+      "question": "Is Tenantial meant for MSPs and internal IT teams?",
+      "answer": "Yes. The public positioning speaks to MSPs, internal IT, security, and governance teams that need to align policy context, review work, and recovery readiness."
     }
   ]
 }

apps/website/src/data_files/features.json

@@ -1,22 +1,32 @@
 [
   {
-    "heading": "Backup evidence",
-    "content": "Review observed policy metadata and backup snapshots from one readable source before decisions start.",
+    "heading": "Policy evidence",
+    "content": "Bring observed policy state, snapshots, and supporting context into one readable evidence base before governance decisions begin.",
     "svg": "frame"
   },
   {
-    "heading": "Restore planning",
-    "content": "Compare immutable snapshots and plan restore work with validation, selective scope, and explicit review.",
+    "heading": "Drift and change signals",
+    "content": "Make drift, findings, and differences visible before teams talk about approval, exceptions, or controlled recovery work.",
     "svg": "dashboard"
   },
   {
-    "heading": "Drift detection",
-    "content": "Turn differences, findings, and evidence into readable review work before administrators decide what to change.",
+    "heading": "Governance reviews",
+    "content": "Align MSPs, internal IT teams, and governance stakeholders around the same review lane instead of isolated tool views.",
     "svg": "verified"
   },
   {
-    "heading": "Auditability and exceptions",
-    "content": "Keep exceptions, review notes, and auditability visible so decisions stay attributable.",
-    "svg": "checkCircle"
+    "heading": "Controlled recovery",
+    "content": "Plan restore and recovery defensively with preview, validation, selective scope, and explicit confirmation instead of automation promises.",
+    "svg": "tools"
+  },
+  {
+    "heading": "Provider readiness",
+    "content": "Keep Microsoft 365 explicit as the current focus while describing other providers only as architecture or roadmap direction.",
+    "svg": "frame"
+  },
+  {
+    "heading": "Decision traceability",
+    "content": "Connect findings, exceptions, accepted risk, and audit trail so later decisions remain inspectable.",
+    "svg": "dashboard"
   }
 ]

apps/website/src/data_files/pricing.json

@@ -1,9 +1,9 @@
 {
   "title": "Evaluation and rollout options",
-  "subTitle": "Commercial packaging is intentionally conservative on the public website. No instant payment path or fixed access package is implied.",
+  "subTitle": "Commercial packaging is intentionally conservative on the public website. No instant payment path, subscription activation, or fixed access package is implied.",
   "badge": "Scoped",
   "thirdOption": "Need a narrower evaluation conversation?",
-  "btnText": "Contact Tenantial",
+  "btnText": "Discuss evaluation",
   "starterKit": {
     "name": "Evaluation",
     "description": "For teams reviewing fit before any rollout commitment.",

apps/website/src/data_files/site-copy.ts

@@ -35,11 +35,11 @@ type FaqGroup = {
 export const siteCopy: Record<Locale, any> = {
   de: {
     site: {
-      tagline: 'Evidenzbasierte Microsoft-Tenant-Governance',
+      tagline: 'Policy Governance für Microsoft 365',
       description:
-        'Tenantial hilft Microsoft-Tenant-Administratoren, Policy-Evidence, Snapshots, Drift, Findings und Restore-Pläne vor kritischen Änderungen zu prüfen.',
+        'Tenantial hilft MSPs, internen IT-Teams und Governance-Verantwortlichen, beobachteten Zustand, Policy-Evidence, Drift, Findings, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 in prüfbare Entscheidungen zu übersetzen.',
       descriptionShort:
-        'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Reviews, Backup, Drift und Restore-Planung.',
+        'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.',
     },
     nav: [
       { name: 'Start', url: '/' },
@@ -70,9 +70,9 @@ export const siteCopy: Record<Locale, any> = {
           ],
         },
       ],
-      conversationTitle: 'Scoped Conversation starten',
+      conversationTitle: 'Walkthrough oder Rollout-Gespräch starten',
       conversationContent:
-        'Nutze die Kontaktseite oder E-Mail nur für Business-Kontext. Sende keine Secrets, Credentials oder Tenant-Exporte über die öffentliche Website.',
+        'Nutze die Kontaktseite oder E-Mail für Business-Kontext, Evaluierungsfragen und Rollout-Scope. Sende keine Secrets, Credentials oder Tenant-Exporte über die öffentliche Website.',
       contactButton: 'Kontaktseite öffnen',
       copyrightSuffix: 'Nur öffentliche Website-Inhalte.',
     },
@@ -80,98 +80,179 @@ export const siteCopy: Record<Locale, any> = {
       walkthrough: 'Walkthrough anfragen',
     },
     home: {
-      pageTitle: 'Tenantial | Evidenzbasierte Microsoft-Tenant-Governance',
+      pageTitle: 'Tenantial | Policy Governance für Microsoft 365',
       metaDescription:
-        'Tenantial ist evidenzbasierte Governance für Microsoft-Tenant-Konfiguration mit Backup, Restore, Drift Detection, Findings, Evidence, Auditability, Exceptions und Reviews.',
+        'Tenantial ist Policy Governance für Microsoft 365: beobachteter Zustand, Policy-Evidence, Drift Detection, Reviews, Entscheidungen, Audit Trail und kontrollierte Recovery-Planung in einem prüfbaren Operating Model.',
       heroTitle:
-        'Evidenzbasierte Governance für <span class="text-yellow-500 dark:text-yellow-400">Microsoft-Tenant-Konfiguration</span>',
+        'Policy Governance für <span class="text-yellow-500 dark:text-yellow-400">Microsoft 365</span> und moderne Cloud-Umgebungen',
       heroSubtitle:
-        'Tenantial hilft Administratoren, Backup-Evidence, unveränderliche Snapshots, Drift Detection, Findings, Exceptions, Auditability und Restore-Pläne zu prüfen, bevor kritische Änderungen umgesetzt werden.',
+        'Tenantial zeigt, wie beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail zu einem evidenzbasierten Governance-Modell werden. Microsoft 365 ist heute der erste Fokus; weitere Provider bleiben bewusst Zukunftsrichtung.',
       primaryCta: 'Walkthrough anfragen',
-      secondaryCta: 'Plattform ansehen',
+      secondaryCta: 'Governance-Modell ansehen',
       heroAlt: 'Statische Tenantial Governance-Dashboard-Vorschau',
-      featureTitle: 'Backup, Restore und Drift Detection mit Review-Kontext',
+      featureTitle: 'Die richtige Produktkategorie zuerst',
       featureSubtitle:
-        'Tenantial hält Backup-Snapshots, Findings, Evidence, Auditability, Exceptions und Reviews sichtbar, damit Restore-Entscheidungen preview-first bleiben. Die öffentliche Vorschau ist statisch und verbindet sich nicht mit Live-Tenant-Daten.',
+        'Tenantial ist weder ein Intune-only Hilfstool noch ein Admin-Center-Klon. Die Plattform rahmt Microsoft 365 als ersten Einsatzbereich für Policy Governance, damit MSPs, interne IT-Teams und Governance-Verantwortliche dieselbe Evidence-Basis lesen.',
       featureAlt: 'Statische Tenantial Review-Board-Vorschau',
       workflowTitle:
-        'Ein <span class="text-yellow-500 dark:text-yellow-400">Review-Workflow</span> für evidenzbasierte Tenant-Governance.',
+        'Vom <span class="text-orange-500 dark:text-orange-300">beobachteten Zustand</span> zu Evidence, Review und Audit Trail.',
       tabs: [
         {
-          heading: 'Evidence Intake',
+          heading: 'Beobachten',
           content:
-            'Normalisiere Inventory-, Backup- und Snapshot-Kontext, damit Reviews mit einer lesbaren Sicht auf den beobachteten Policy-Zustand starten.',
+            'Starte mit dem beobachteten Microsoft-365-Status und einer lesbaren Sicht auf relevante Richtlinien, Konfigurationen und Verantwortlichkeiten.',
           svg: 'frame',
-          alt: 'Statische Tenantial Evidence-Intake-Vorschau',
+          alt: 'Statische Tenantial Observed-State-Vorschau',
           first: true,
         },
         {
-          heading: 'Decision Review',
+          heading: 'Evidence sammeln',
           content:
-            'Mache Drift Detection, Findings, Exceptions, Auditability und Review-Notizen sichtbar, bevor Administratoren die nächste Aktion wählen.',
-          svg: 'dashboard',
-          alt: 'Statische Tenantial Decision-Review-Vorschau',
+            'Halte Snapshots, Nachweise und Kontext so fest, dass spätere Reviews auf einer stabilen Evidence-Basis und nicht auf Erinnerung beruhen.',
+          svg: 'books',
+          alt: 'Statische Tenantial Evidence-Intake-Vorschau',
           second: true,
         },
         {
-          heading: 'Restore-Planung',
+          heading: 'Drift erkennen',
           content:
-            'Behandle Restore als preview-first Arbeit mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung.',
+            'Mache Unterschiede, Findings und Veränderungen sichtbar, bevor Teams überspringen, was überhaupt geprüft werden muss.',
           svg: 'verified',
-          alt: 'Statische Tenantial Restore-Planungs-Vorschau',
+          alt: 'Statische Tenantial Drift-Detection-Vorschau',
+        },
+        {
+          heading: 'Review durchführen',
+          content:
+            'Bringe MSPs, interne IT-Teams und Governance-Verantwortliche in denselben Review-Kontext aus Findings, Risiken, Exceptions und nächsten Schritten.',
+          svg: 'groups',
+          alt: 'Statische Tenantial Review-Board-Vorschau',
+        },
+        {
+          heading: 'Entscheidung vorbereiten',
+          content:
+            'Leite nachvollziehbare Entscheidungen für Freigaben, Ausnahmen oder kontrollierte Recovery-Arbeit aus Review, Evidence und Scope ab.',
+          svg: 'frame',
+          alt: 'Statische Tenantial Decision-Preparation-Vorschau',
+        },
+        {
+          heading: 'Audit Trail sichern',
+          content:
+            'Halte Begründung, akzeptierte Risiken und ausgewählte Aktionen so fest, dass spätere Audits nicht raten müssen, warum ein Schritt freigegeben wurde.',
+          svg: 'dashboard',
+          alt: 'Statische Tenantial Audit-Trail-Vorschau',
         },
       ],
+      audienceTitle: 'Für Teams, die Governance gemeinsam tragen',
+      audienceSubtitle:
+        'Tenantial adressiert Buyer und Operatoren, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.',
+      audiences: [
+        {
+          title: 'MSPs und Service-Teams',
+          content:
+            'Schaffe eine prüfbare Evidence-Basis für Tenant-Reviews, Change-Freigaben und kontrollierte Recovery-Gespräche über mehrere Kundenumgebungen hinweg.',
+        },
+        {
+          title: 'Interne IT- und Security-Teams',
+          content:
+            'Mache Microsoft-365-Richtlinien, Drift und Review-Entscheidungen lesbar, bevor kritische Änderungen in Produktion oder Ausnahmeprozesse gehen.',
+        },
+        {
+          title: 'Governance- und Audit-Verantwortliche',
+          content:
+            'Halte Findings, akzeptierte Risiken, Exceptions und Audit Trail so sichtbar, dass Entscheidungen später nachvollzogen statt rekonstruiert werden müssen.',
+        },
+      ],
+      boundaryTitle: 'Klare Grenzen statt überzogener Versprechen',
+      boundarySubtitle:
+        'Tenantial positioniert Policy Governance, nicht eine zweite Admin-Oberfläche oder approval-freie Automatisierung.',
+      boundaries: [
+        {
+          title: 'Kein Admin-Center-Klon',
+          content:
+            'Die öffentliche Website beschreibt Governance-Flows, Evidence und Reviews. Sie ersetzt keine produktive Microsoft-Adminoberfläche.',
+        },
+        {
+          title: 'Keine blinde Automation',
+          content:
+            'Drift, Findings, Recovery und Freigaben bleiben review- und bestätigungspflichtig statt autonomer Remediation.',
+        },
+        {
+          title: 'Kein Helpdesk- oder PSA-Ersatz',
+          content:
+            'Tenantial fokussiert Policy Governance, Entscheidungsgrundlagen und Auditierbarkeit, nicht Ticketabwicklung oder Support-SLAs.',
+        },
+      ],
+      finalCtaTitle: 'Den nächsten Schritt bewusst wählen',
+      finalCtaSubtitle:
+        'Starte mit einem Walkthrough, wenn du Microsoft-365-Governance, Provider-Grenzen oder Recovery-Readiness für deinen Kontext einordnen willst.',
+      finalPrimaryCta: 'Walkthrough anfragen',
+      finalSecondaryCta: 'Trust-Grenzen ansehen',
       faqTitle: 'Häufige<br />Fragen',
     },
     platform: {
       pageTitle: 'Plattform | Tenantial',
       metaDescription:
-        'Tenantial öffentliches Produktmodell für Microsoft-Tenant Backup-Evidence, Restore-Planung, Drift Detection, Findings, Auditability, Exceptions und Reviews.',
-      heading: 'Plattform-Review-Modell',
+        'Tenantial erklärt Policy Governance für Microsoft 365 mit beobachtetem Zustand, Evidence, Drift Detection, Governance Reviews, Audit Trail und kontrollierter Recovery-Planung.',
+      heading: 'Policy-Governance-Modell für Microsoft 365',
       subtitle:
-        'Tenantial ist auf Backup-Evidence, unveränderliche Policy-Snapshots, strukturierte Diffs, Drift Detection, Findings, Exceptions, Auditability, Governance-Reviews und vorsichtige Restore-Workflows für Microsoft-Tenant-Administratoren ausgerichtet.',
-      backupTitle: 'Backup- und Snapshot-Evidence',
+        'Tenantial beschreibt ein Governance-of-record-Modell für Microsoft 365. Beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail bleiben heute auf Microsoft 365 fokussiert; die Architektur bleibt provider-extensibel, ohne aktuelle Live-Unterstützung für andere Provider zu behaupten.',
+      focusTitle: 'Heutiger Fokus und künftige Richtung',
+      focusSubtitle:
+        'Die öffentliche Produktstory trennt bewusst zwischen aktuellem Microsoft-365-Fokus und provider-extensibler Zukunftsrichtung.',
+      focusCards: [
+        {
+          title: 'Aktueller Fokus: Microsoft 365',
+          content:
+            'Intune, Entra und weitere Microsoft-365-Policy-Domains werden als heutiger Governance-Kontext beschrieben, nicht als vollständige Liste künftiger Provider.',
+        },
+        {
+          title: 'Künftige Richtung: provider-extensibel',
+          content:
+            'Andere Provider können als Architektur- oder Roadmap-Richtung genannt werden, aber nicht als live unterstützte Integrationen oder verifizierte Workflows.',
+        },
+      ],
+      backupTitle: 'Beobachteter Zustand und Policy-Evidence',
       backupSubtitle:
-        'Administratoren brauchen einen reproduzierbaren Nachweis dessen, was beobachtet wurde, bevor entschieden wird, ob eine Änderung sicher ist. Tenantial rahmt Backup-Snapshots als Review-Evidence, nicht als versteckte Automation.',
+        'Teams brauchen einen reproduzierbaren Nachweis dessen, was beobachtet wurde, bevor entschieden wird, ob eine Änderung sicher ist. Tenantial rahmt Snapshots und Nachweise als Review-Evidence und nicht als versteckte Automation.',
       dashboardAlt: 'Statische Tenantial Inventory-Dashboard-Vorschau',
       evidenceAlt: 'Statische Tenantial Evidence-Review-Vorschau',
-      driftTitle: 'Drift Detection, Findings und Exceptions',
+      driftTitle: 'Drift, Findings, Review und Ausnahmebehandlung',
       driftSubtitle:
-        'Unterschiede und Findings sollen lesbare Entscheidungsarbeit werden. Exceptions, Evidence, Review-Notizen und Auditability halten die Begründung sichtbar, ohne zu behaupten, dass die öffentliche Website mit Live-Tenant-Daten verbunden ist.',
+        'Unterschiede und Findings sollen lesbare Entscheidungsarbeit werden. Exceptions, Review-Notizen und Audit Trail halten die Begründung sichtbar, ohne zu behaupten, dass die öffentliche Website mit Live-Tenant-Daten verbunden ist.',
       driftAlt: 'Statische Tenantial Drift-Workflow-Vorschau',
-      trustCta: 'Trust-Posture ansehen',
-      restoreTitle: 'Restore-Planung bleibt defensiv',
+      trustCta: 'Trust-Grenzen ansehen',
+      restoreTitle: 'Kontrollierte Recovery bleibt defensiv',
       restoreSubtitle:
-        'Restore-Pfade werden als preview-first Workflows mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung vor sensiblen Aktionen beschrieben.',
+        'Recovery- und Restore-Pfade werden als preview-first Workflows mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung vor sensiblen Aktionen beschrieben.',
       restoreAlt: 'Statische Tenantial Rollout-Readiness-Plan-Vorschau',
       rolloutCta: 'Rollout besprechen',
       boundaryTitle: 'Grenzen der öffentlichen Vorschau',
       boundarySubtitle:
         'Die Website nutzt statische Demo-Previews, um Richtung und visuelle Grundlage zu zeigen. Sie authentifiziert keine Besucher, liest keinen Microsoft Tenant, führt keine Operationen aus und speichert keine Tenant-Exporte.',
       stats: [
-        { stat: 'Statisch', description: 'Produkt-Previews' },
-        { stat: 'Preview', description: 'vor Restore-Ausführung' },
-        { stat: 'Review', description: 'vor kritischen Änderungen' },
+        { stat: 'Microsoft 365', description: 'heutiger Fokus' },
+        { stat: 'Provider-extensible', description: 'klar als Richtung markiert' },
+        { stat: 'Keine Live-Daten', description: 'auf der öffentlichen Website' },
       ],
-      mainStatTitle: '0',
+      mainStatTitle: 'Heute',
       mainStatSubTitle:
-        'Live-Tenant-Datensätze werden von dieser öffentlichen Website genutzt',
+        'Microsoft 365 ist der erste öffentliche Fokus der Produktstory',
     },
     pricingIntro: {
       pageTitle: 'Preise | Tenantial',
       metaDescription:
-        'Tenantial Preise nutzen konservative Evaluierungs- und Rollout-Gespräche statt sofortiger Zahlung oder Access-Claims.',
-      heading: 'Preise bleiben scoped',
+        'Tenantial Preise rahmen Policy-Governance-Evaluierung, Rollout-Planung und Trust-Review konservativ statt Sofortkauf oder Access-Claims.',
+      heading: 'Evaluation bleibt kontaktgeführt',
       subtitle:
-        'Tenantial behauptet auf der öffentlichen Website keine Sofortzahlung, keinen festen Paket-Zugang und keine automatische Tenant-Verbindung.',
+        'Tenantial beschreibt hier Evaluierungs-, Rollout- und Trust-Pfade für Policy Governance. Die öffentliche Website behauptet keine Sofortzahlung, keinen festen Paket-Zugang und keine automatische Tenant-Verbindung.',
     },
     contact: {
       pageTitle: 'Kontakt | Tenantial',
       metaDescription:
-        'Tenantial Walkthrough anfragen oder ein scoped Rollout-Gespräch starten. Die öffentliche Website sammelt keine Live-Tenant-Daten.',
+        'Tenantial Walkthrough anfragen, Provider-Grenzen einordnen oder ein scoped Rollout-Gespräch für Microsoft-365-Policy-Governance starten.',
       title: 'Kontakt zu Tenantial',
       subtitle:
-        'Fordere einen Walkthrough an oder starte ein scoped Rollout-Gespräch. Sende keine Secrets, Credentials oder Tenant-Exporte über diese öffentliche Website.',
+        'Fordere einen Walkthrough an oder starte ein scoped Rollout-Gespräch zu Policy Governance, Provider-Grenzen und Recovery-Readiness. Sende keine Secrets, Credentials oder Tenant-Exporte über diese öffentliche Website.',
       formTitle: 'Walkthrough-Anfrage vorbereiten',
       formSubtitle:
         'Dieses statische Formular sendet nicht an ein Backend. Nutze es, um Kontext vor einer E-Mail an Tenantial vorzubereiten.',
@@ -199,19 +280,19 @@ export const siteCopy: Record<Locale, any> = {
     trust: {
       pageTitle: 'Vertrauen | Tenantial',
       metaDescription:
-        'Tenantial öffentliche Trust-Posture mit konservativen Claims und klaren Grenzen für statische Previews.',
-      heading: 'Vertrauen beginnt mit klaren Grenzen',
+        'Tenantial öffentliche Trust-Haltung mit konservativen Claims, klaren Grenzen und Policy-Governance-Wortwahl ohne false assurance.',
+      heading: 'Vertrauen beginnt mit nachprüfbaren Grenzen',
       subtitle:
-        'Tenantial Public Copy vermeidet Customer-Logo-Proof, Third-Party-Endorsements, externe Assurance-Aussagen, Service-Level-Commitments und Recovery-Versprechen, solange sie nicht geliefert und geprüft wurden.',
+        'Tenantial spricht über Audit Trail, Review-Arbeit und kontrollierte Recovery-Planung, ohne Kundenlogo-Belege, externe Endorsements, Compliance-Zusagen oder Recovery-Versprechen zu behaupten, die nicht geliefert und geprüft wurden.',
       cta: 'Tenantial kontaktieren',
-      statsTitle: 'Public Website Posture',
+      statsTitle: 'Konservative Trust-Haltung',
       statsSubtitle:
-        'Die Website beschreibt eine vorsichtige Produktrichtung. Sie legt keine privaten Tenant-Daten offen, führt keine Tenant-Operationen aus und ist kein Support-Evidence-Portal.',
-      mainStatTitle: 'Statisch',
-      mainStatSubTitle: 'nur Produkt-Previews',
+        'Die Website beschreibt eine vorsichtige Produktrichtung für DACH- und Enterprise-Evaluierungen. Sie legt keine privaten Tenant-Daten offen, führt keine Tenant-Operationen aus und ist kein Support-Evidence-Portal.',
+      mainStatTitle: 'Review-first',
+      mainStatSubTitle: 'öffentliche Claims bleiben konservativ',
       stats: [
-        { stat: 'Kein', description: 'Customer-Logo-Proof' },
-        { stat: 'Kein', description: 'externer Endorsement-Claim' },
+        { stat: 'Keine', description: 'Compliance-Zusagen ohne Nachweis' },
+        { stat: 'Keine', description: 'Kundenlogo- oder Endorsement-Claims' },
         { stat: 'Keine', description: 'Live-Tenant-Verbindung' },
       ],
     },
@@ -251,11 +332,11 @@ export const siteCopy: Record<Locale, any> = {
   },
   en: {
     site: {
-      tagline: 'Evidence-first Microsoft tenant governance',
+      tagline: 'Policy governance for Microsoft 365',
       description:
-        'Tenantial helps Microsoft tenant administrators review policy evidence, snapshots, drift, findings, and restore plans before high-impact changes move forward.',
+        'Tenantial helps MSPs, internal IT teams, and governance reviewers turn observed state, policy evidence, drift, findings, reviews, audit trail, and controlled recovery planning into reviewable decisions for Microsoft 365.',
       descriptionShort:
-        'Evidence-first governance workflows for Microsoft tenant review, backup, drift, and restore planning.',
+        'Policy-governance workflows for Microsoft 365 with evidence, drift detection, review, audit trail, and controlled recovery planning.',
     },
     nav: [
       { name: 'Home', url: '/' },
@@ -286,9 +367,9 @@ export const siteCopy: Record<Locale, any> = {
           ],
         },
       ],
-      conversationTitle: 'Start a scoped conversation',
+      conversationTitle: 'Start a walkthrough or rollout conversation',
       conversationContent:
-        'Use the contact page or email for business context only. Do not send secrets, credentials, or tenant exports through the public website.',
+        'Use the contact page or email for business context, evaluation questions, and rollout scope. Do not send secrets, credentials, or tenant exports through the public website.',
       contactButton: 'Open contact page',
       copyrightSuffix: 'Public website content only.',
     },
@@ -296,97 +377,178 @@ export const siteCopy: Record<Locale, any> = {
       walkthrough: 'Request walkthrough',
     },
     home: {
-      pageTitle: 'Tenantial | Evidence-first Microsoft tenant governance',
+      pageTitle: 'Tenantial | Policy governance for Microsoft 365',
       metaDescription:
-        'Tenantial is evidence-first governance for Microsoft tenant configuration, with backup, restore, drift detection, findings, evidence, auditability, exceptions, and reviews.',
+        'Tenantial is policy governance for Microsoft 365: observed state, policy evidence, drift detection, reviews, decisions, audit trail, and controlled recovery planning in one reviewable operating model.',
       heroTitle:
-        'Evidence-first governance for <span class="text-yellow-500 dark:text-yellow-400">Microsoft tenant configuration</span>',
+        'Policy governance for <span class="text-yellow-500 dark:text-yellow-400">Microsoft 365</span> and modern cloud environments',
       heroSubtitle:
-        'Tenantial helps administrators review backup evidence, immutable snapshots, drift detection, findings, exceptions, auditability, and restore plans before high-impact changes move forward.',
+        'Tenantial shows how observed state, policy evidence, drift, review, decision, and audit trail become one evidence-first governance model. Microsoft 365 is the current focus; other providers remain clearly future direction.',
       primaryCta: 'Request walkthrough',
-      secondaryCta: 'Explore platform',
+      secondaryCta: 'View governance model',
       heroAlt: 'Static Tenantial governance dashboard preview',
-      featureTitle: 'Backup, restore, and drift detection with review context',
+      featureTitle: 'Start with the right product category',
       featureSubtitle:
-        'Tenantial keeps backup snapshots, findings, evidence, auditability, exceptions, and reviews visible so restore decisions stay preview-first. The public preview is static and does not connect to live tenant data.',
+        'Tenantial is not an Intune-only utility and not an admin-center clone. The platform frames Microsoft 365 as the first operating domain for policy governance so MSPs, internal IT teams, and governance reviewers can read the same evidence base.',
       featureAlt: 'Static Tenantial review board preview',
       workflowTitle:
-        'A <span class="text-yellow-500 dark:text-yellow-400">review workflow</span> for evidence-first tenant governance.',
+        'From <span class="text-orange-500 dark:text-orange-300">observed state</span> to evidence, review, and audit trail.',
       tabs: [
         {
-          heading: 'Evidence intake',
+          heading: 'Observe',
           content:
-            'Normalize inventory, backup, and snapshot context so reviews start from one readable view of observed policy state.',
+            'Start from readable Microsoft 365 policy state, ownership context, and the configuration boundaries that need review.',
           svg: 'frame',
-          alt: 'Static Tenantial evidence intake preview',
+          alt: 'Static Tenantial observed-state preview',
           first: true,
         },
         {
-          heading: 'Decision review',
+          heading: 'Collect evidence',
           content:
-            'Surface drift detection, findings, exceptions, auditability, and review notes before administrators choose the next action.',
-          svg: 'dashboard',
-          alt: 'Static Tenantial decision review preview',
+            'Keep snapshots, supporting notes, and policy evidence stable enough that later review does not depend on memory or screenshots alone.',
+          svg: 'books',
+          alt: 'Static Tenantial evidence intake preview',
           second: true,
         },
         {
-          heading: 'Restore planning',
+          heading: 'Detect drift',
           content:
-            'Treat restore as preview-first work with validation, conflict awareness, selective scope, and explicit confirmation.',
+            'Make differences, findings, and change signals visible before teams skip the question of what really needs review.',
           svg: 'verified',
-          alt: 'Static Tenantial restore planning preview',
+          alt: 'Static Tenantial drift detection preview',
+        },
+        {
+          heading: 'Run review',
+          content:
+            'Bring MSPs, internal IT teams, and governance stakeholders into the same review lane across findings, risk, exceptions, and next actions.',
+          svg: 'groups',
+          alt: 'Static Tenantial review board preview',
+        },
+        {
+          heading: 'Prepare decisions',
+          content:
+            'Turn review context into traceable approval, exception, or controlled recovery decisions instead of informal handoffs.',
+          svg: 'frame',
+          alt: 'Static Tenantial decision preparation preview',
+        },
+        {
+          heading: 'Preserve audit trail',
+          content:
+            'Keep the rationale, accepted risk, and selected action visible so later audit and governance work can follow the decision path.',
+          svg: 'dashboard',
+          alt: 'Static Tenantial audit trail preview',
         },
       ],
+      audienceTitle: 'For teams that share governance responsibility',
+      audienceSubtitle:
+        'Tenantial speaks to buyers and operators who need to align policy context, review work, and recovery readiness before change moves forward.',
+      audiences: [
+        {
+          title: 'MSPs and service teams',
+          content:
+            'Create a reviewable evidence base for tenant reviews, change approvals, and controlled recovery conversations across multiple customer environments.',
+        },
+        {
+          title: 'Internal IT and security teams',
+          content:
+            'Make Microsoft 365 policy posture, drift, and review decisions readable before high-impact changes move into production or exception handling.',
+        },
+        {
+          title: 'Governance and audit stakeholders',
+          content:
+            'Keep findings, accepted risk, exceptions, and audit trail visible so decisions can be inspected later instead of reconstructed under pressure.',
+        },
+      ],
+      boundaryTitle: 'Clear boundaries instead of inflated promises',
+      boundarySubtitle:
+        'Tenantial positions policy governance, not a second admin surface or approval-free automation.',
+      boundaries: [
+        {
+          title: 'Not an admin-center clone',
+          content:
+            'The public website explains governance flows, evidence, and review work. It does not replace a production Microsoft administration surface.',
+        },
+        {
+          title: 'No blind automation',
+          content:
+            'Drift, findings, recovery, and approvals remain review-driven and explicitly confirmed instead of framed as self-running remediation.',
+        },
+        {
+          title: 'Not a helpdesk or PSA replacement',
+          content:
+            'Tenantial focuses on policy governance, decision support, and auditability rather than ticket handling, service routing, or support SLAs.',
+        },
+      ],
+      finalCtaTitle: 'Choose the next step intentionally',
+      finalCtaSubtitle:
+        'Start with a walkthrough if you need to place Microsoft 365 governance, provider boundaries, or recovery readiness in your own operating context.',
+      finalPrimaryCta: 'Request walkthrough',
+      finalSecondaryCta: 'Review trust boundaries',
       faqTitle: 'Frequently<br />asked questions',
     },
     platform: {
       pageTitle: 'Platform | Tenantial',
       metaDescription:
-        'Tenantial public product model for Microsoft tenant backup evidence, restore planning, drift detection, findings, auditability, exceptions, and reviews.',
-      heading: 'Platform review model',
+        'Tenantial explains policy governance for Microsoft 365 with observed state, evidence, drift detection, governance reviews, audit trail, and controlled recovery planning.',
+      heading: 'Policy governance model for Microsoft 365',
       subtitle:
-        'Tenantial is positioned around backup evidence, immutable policy snapshots, structured diffs, drift detection, findings, exceptions, auditability, governance reviews, and cautious restore workflows for Microsoft tenant administrators.',
-      backupTitle: 'Backup and snapshot evidence',
+        'Tenantial describes a governance-of-record model for Microsoft 365. Observed state, policy evidence, drift, review, decision, and audit trail stay focused on Microsoft 365 today while the architecture remains provider-extensible without claiming live support elsewhere.',
+      focusTitle: 'Current focus and future direction',
+      focusSubtitle:
+        'The public story intentionally separates current Microsoft 365 scope from provider-extensible future direction.',
+      focusCards: [
+        {
+          title: 'Current focus: Microsoft 365',
+          content:
+            'Intune, Entra, and other Microsoft 365 policy domains are described as the current governance context, not as a promise of every future provider.',
+        },
+        {
+          title: 'Future direction: provider-extensible',
+          content:
+            'Other providers may be referenced as architecture or roadmap direction, but not as live integrations or verified operating workflows.',
+        },
+      ],
+      backupTitle: 'Observed state and policy evidence',
       backupSubtitle:
-        'Administrators need a reproducible record of what was observed before deciding whether a change is safe. Tenantial frames backup snapshots as review evidence, not as hidden automation.',
+        'Teams need a reproducible record of what was observed before deciding whether a change is safe. Tenantial frames snapshots and supporting evidence as review input, not hidden automation.',
       dashboardAlt: 'Static Tenantial inventory dashboard preview',
       evidenceAlt: 'Static Tenantial evidence review panel preview',
-      driftTitle: 'Drift detection, findings, and exceptions',
+      driftTitle: 'Drift, findings, review, and exception handling',
       driftSubtitle:
-        'Differences and findings should become readable decision work. Exceptions, evidence, review notes, and auditability keep the reasoning visible without claiming that the public website is connected to live tenant data.',
+        'Differences and findings should become readable decision work. Exceptions, review notes, and audit trail keep the reasoning visible without claiming that the public website is connected to live tenant data.',
       driftAlt: 'Static Tenantial drift workflow preview',
       trustCta: 'Review trust posture',
-      restoreTitle: 'Restore planning stays defensive',
+      restoreTitle: 'Controlled recovery stays defensive',
       restoreSubtitle:
-        'Restore paths are described as preview-first workflows with validation, conflict awareness, selective scope, and explicit confirmation before any sensitive action.',
+        'Recovery and restore paths are described as preview-first workflows with validation, conflict awareness, selective scope, and explicit confirmation before any sensitive action.',
       restoreAlt: 'Static Tenantial rollout readiness plan preview',
       rolloutCta: 'Discuss rollout',
       boundaryTitle: 'Public preview boundaries',
       boundarySubtitle:
         'The website uses static/demo previews to demonstrate the direction and visual foundation. It does not authenticate visitors, read a Microsoft tenant, execute operations, or store tenant exports.',
       stats: [
-        { stat: 'Static', description: 'product previews' },
-        { stat: 'Preview', description: 'before restore execution' },
-        { stat: 'Review', description: 'before high-impact changes' },
+        { stat: 'Microsoft 365', description: 'current focus' },
+        { stat: 'Provider-extensible', description: 'clearly marked as direction' },
+        { stat: 'No live data', description: 'on the public website' },
       ],
-      mainStatTitle: '0',
-      mainStatSubTitle: 'live tenant records used by this public website',
+      mainStatTitle: 'Today',
+      mainStatSubTitle: 'Microsoft 365 is the first public product focus',
     },
     pricingIntro: {
       pageTitle: 'Pricing | Tenantial',
       metaDescription:
-        'Tenantial pricing uses conservative evaluation and rollout conversation paths, not instant public payment or access claims.',
-      heading: 'Pricing stays scoped',
+        'Tenantial pricing frames policy-governance evaluation, rollout planning, and trust review conservatively instead of instant public payment or access claims.',
+      heading: 'Evaluation stays contact-led',
       subtitle:
-        'Tenantial does not claim instant payment, fixed package access, or automatic tenant connection from the public website.',
+        'Tenantial describes evaluation, rollout, and trust paths for policy governance here. The public website does not claim instant payment, fixed package access, or automatic tenant connection.',
     },
     contact: {
       pageTitle: 'Contact | Tenantial',
       metaDescription:
-        'Request a Tenantial walkthrough or start a scoped rollout conversation. The public website does not collect live tenant data.',
+        'Request a Tenantial walkthrough, review provider boundaries, or start a scoped rollout conversation for Microsoft 365 policy governance.',
       title: 'Contact Tenantial',
       subtitle:
-        'Request a walkthrough or start a scoped rollout conversation. Do not send secrets, credentials, or tenant exports through this public website.',
+        'Request a walkthrough or start a scoped rollout conversation about policy governance, provider boundaries, and recovery readiness. Do not send secrets, credentials, or tenant exports through this public website.',
       formTitle: 'Draft a walkthrough request',
       formSubtitle:
         'This static form does not submit to a backend. Use it to draft context before emailing Tenantial.',
@@ -414,19 +576,19 @@ export const siteCopy: Record<Locale, any> = {
     trust: {
       pageTitle: 'Trust | Tenantial',
       metaDescription:
-        'Tenantial public trust posture with conservative claims and clear static preview boundaries.',
-      heading: 'Trust starts with clear boundaries',
+        'Tenantial public trust posture with conservative claims, clear boundaries, and policy-governance wording without false assurance.',
+      heading: 'Trust starts with reviewable boundaries',
       subtitle:
-        'Tenantial public copy avoids customer-logo proof, third-party endorsement language, external assurance statements, service-level commitments, and recovery promises unless supplied and reviewed.',
+        'Tenantial talks about audit trail, review work, and controlled recovery planning without making customer-proof, endorsement, compliance, or recovery claims that have not been supplied and reviewed.',
       cta: 'Contact Tenantial',
-      statsTitle: 'Public website posture',
+      statsTitle: 'Conservative trust posture',
       statsSubtitle:
-        'The website describes a cautious product direction. It does not expose private tenant data, run tenant operations, or act as a support evidence portal.',
-      mainStatTitle: 'Static',
-      mainStatSubTitle: 'product previews only',
+        'The website describes a cautious product direction for DACH and enterprise evaluators. It does not expose private tenant data, run tenant operations, or act as a support evidence portal.',
+      mainStatTitle: 'Review-first',
+      mainStatSubTitle: 'public claims stay conservative',
       stats: [
-        { stat: 'No', description: 'customer-logo proof' },
-        { stat: 'No', description: 'external endorsement claim' },
+        { stat: 'No', description: 'unsupported compliance claims' },
+        { stat: 'No', description: 'customer-proof or endorsement claims' },
         { stat: 'No', description: 'live tenant connection' },
       ],
     },
@@ -467,54 +629,78 @@ export const siteCopy: Record<Locale, any> = {
 export const featuresByLocale: Record<Locale, Feature[]> = {
   de: [
     {
-      heading: 'Backup-Evidence',
+      heading: 'Policy-Evidence',
       content:
-        'Prüfe beobachtete Policy-Metadaten und Backup-Snapshots aus einer lesbaren Quelle, bevor Entscheidungen beginnen.',
+        'Führe beobachtete Richtlinien, Snapshots und Kontext in einer lesbaren Evidence-Basis zusammen, bevor Governance-Entscheidungen beginnen.',
       svg: 'frame',
     },
     {
-      heading: 'Restore-Planung',
+      heading: 'Drift und Veränderungssignale',
       content:
-        'Vergleiche unveränderliche Snapshots und plane Restore-Arbeit mit Validierung, selektivem Scope und explizitem Review.',
+        'Mache Drift, Findings und Unterschiede sichtbar, bevor Teams über Freigaben, Ausnahmen oder kontrollierte Recovery-Arbeit sprechen.',
       svg: 'dashboard',
     },
     {
-      heading: 'Drift Detection',
+      heading: 'Governance-Reviews',
       content:
-        'Verwandle Unterschiede, Findings und Evidence in lesbare Review-Arbeit, bevor Administratoren Änderungen entscheiden.',
+        'Ordne MSPs, interne IT-Teams und Governance-Verantwortliche um dieselbe Review-Grundlage statt um isolierte Tool-Sichten herum.',
       svg: 'verified',
     },
     {
-      heading: 'Auditability und Exceptions',
+      heading: 'Kontrollierte Recovery',
       content:
-        'Halte Exceptions, Review-Notizen und Auditability sichtbar, damit Entscheidungen zuordenbar bleiben.',
-      svg: 'checkCircle',
+        'Plane Restore und Recovery defensiv mit Preview, Validierung, selektivem Scope und expliziter Bestätigung statt mit Vollautomationsversprechen.',
+      svg: 'tools',
+    },
+    {
+      heading: 'Provider-Readiness',
+      content:
+        'Halte Microsoft 365 als heutigen Fokus klar und beschreibe weitere Provider nur als Architektur- oder Roadmap-Richtung.',
+      svg: 'frame',
+    },
+    {
+      heading: 'Decision Traceability',
+      content:
+        'Verknüpfe Findings, Exceptions, akzeptierte Risiken und Audit Trail so, dass Entscheidungen später prüfbar bleiben.',
+      svg: 'dashboard',
     },
   ],
   en: [
     {
-      heading: 'Backup evidence',
+      heading: 'Policy evidence',
       content:
-        'Review observed policy metadata and backup snapshots from one readable source before decisions start.',
+        'Bring observed policy state, snapshots, and supporting context into one readable evidence base before governance decisions begin.',
       svg: 'frame',
     },
     {
-      heading: 'Restore planning',
+      heading: 'Drift and change signals',
       content:
-        'Compare immutable snapshots and plan restore work with validation, selective scope, and explicit review.',
+        'Make drift, findings, and differences visible before teams talk about approval, exceptions, or controlled recovery work.',
       svg: 'dashboard',
     },
     {
-      heading: 'Drift detection',
+      heading: 'Governance reviews',
       content:
-        'Turn differences, findings, and evidence into readable review work before administrators decide what to change.',
+        'Align MSPs, internal IT teams, and governance stakeholders around the same review lane instead of isolated tool views.',
       svg: 'verified',
     },
     {
-      heading: 'Auditability and exceptions',
+      heading: 'Controlled recovery',
       content:
-        'Keep exceptions, review notes, and auditability visible so decisions stay attributable.',
-      svg: 'checkCircle',
+        'Plan restore and recovery defensively with preview, validation, selective scope, and explicit confirmation instead of automation promises.',
+      svg: 'tools',
+    },
+    {
+      heading: 'Provider readiness',
+      content:
+        'Keep Microsoft 365 explicit as the current focus while describing other providers only as architecture or roadmap direction.',
+      svg: 'frame',
+    },
+    {
+      heading: 'Decision traceability',
+      content:
+        'Connect findings, exceptions, accepted risk, and audit trail so later decisions remain inspectable.',
+      svg: 'dashboard',
     },
   ],
 };
@@ -523,10 +709,10 @@ export const pricingByLocale: Record<Locale, Pricing> = {
   de: {
     title: 'Evaluierungs- und Rollout-Optionen',
     subTitle:
-      'Kommerzielle Pakete bleiben auf der öffentlichen Website bewusst konservativ. Es wird kein Sofortkauf oder fester Access-Plan behauptet.',
+      'Kommerzielle Pakete bleiben auf der öffentlichen Website bewusst konservativ. Es wird kein Sofortkauf, keine Subscription-Aktivierung und kein fester Access-Plan behauptet.',
     badge: 'Scoped',
     thirdOption: 'Brauchst du ein engeres Evaluierungsgespräch?',
-    btnText: 'Tenantial kontaktieren',
+    btnText: 'Evaluierung besprechen',
     starterKit: {
       name: 'Evaluation',
       description: 'Für Teams, die Fit vor einer Rollout-Zusage prüfen.',
@@ -560,10 +746,10 @@ export const pricingByLocale: Record<Locale, Pricing> = {
   en: {
     title: 'Evaluation and rollout options',
     subTitle:
-      'Commercial packaging is intentionally conservative on the public website. No instant payment path or fixed access package is implied.',
+      'Commercial packaging is intentionally conservative on the public website. No instant payment path, subscription activation, or fixed access package is implied.',
     badge: 'Scoped',
     thirdOption: 'Need a narrower evaluation conversation?',
-    btnText: 'Contact Tenantial',
+    btnText: 'Discuss evaluation',
     starterKit: {
       name: 'Evaluation',
       description: 'For teams reviewing fit before any rollout commitment.',
@@ -603,7 +789,12 @@ export const faqsByLocale: Record<Locale, FaqGroup> = {
       {
         question: 'Was hilft Tenantial Teams zu verstehen?',
         answer:
-          'Tenantial ist auf Backup-Evidence, Restore-Planung, Drift Detection, Findings, Auditability, Exceptions und Reviews für Microsoft-Tenant-Konfiguration ausgerichtet.',
+          'Tenantial erklärt Policy Governance für Microsoft 365: beobachteter Zustand, Evidence, Drift, Review, Entscheidung, Audit Trail und kontrollierte Recovery-Planung in einem gemeinsamen Operating Model.',
+      },
+      {
+        question: 'Ist Microsoft 365 der einzige relevante Kontext?',
+        answer:
+          'Microsoft 365 ist heute der erste öffentliche Fokus. Weitere Provider können als Architektur- oder Roadmap-Richtung erwähnt werden, aber nicht als live unterstützte Integrationen.',
       },
       {
         question:
@@ -612,14 +803,9 @@ export const faqsByLocale: Record<Locale, FaqGroup> = {
           'Nein. Produkt-Previews und Beispiele sind statische Demonstrationen und authentifizieren keine Besucher oder lesen Tenant-Daten.',
       },
       {
-        question: 'Wird Restore als automatisches Ergebnis dargestellt?',
+        question: 'Ist Tenantial für MSPs und interne IT-Teams gedacht?',
         answer:
-          'Nein. Tenantial beschreibt Restore als vorsichtigen Workflow mit Preview, Validierung, selektivem Scope, expliziter Bestätigung und Review-Kontext.',
-      },
-      {
-        question: 'Veröffentlicht Tenantial hier Customer Proof?',
-        answer:
-          'Ohne gelieferte und geprüfte Evidence werden keine Kundenlogos, Third-Party-Endorsements, externen Assurance-Aussagen, Service-Level-Commitments oder Recovery-Versprechen veröffentlicht.',
+          'Ja. Die öffentliche Positionierung spricht MSPs, interne IT-, Security- und Governance-Teams an, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.',
       },
     ],
   },
@@ -629,7 +815,12 @@ export const faqsByLocale: Record<Locale, FaqGroup> = {
       {
         question: 'What does Tenantial help teams understand?',
         answer:
-          'Tenantial is positioned around backup evidence, restore planning, drift detection, findings, auditability, exceptions, and reviews for Microsoft tenant configuration.',
+          'Tenantial explains policy governance for Microsoft 365: observed state, evidence, drift, review, decisions, audit trail, and controlled recovery planning in one operating model.',
+      },
+      {
+        question: 'Is Microsoft 365 the only relevant context?',
+        answer:
+          'Microsoft 365 is the current public focus. Other providers may be referenced as architecture or roadmap direction, but not as live supported integrations.',
       },
       {
         question: 'Does this public website connect to a live tenant?',
@@ -637,14 +828,9 @@ export const faqsByLocale: Record<Locale, FaqGroup> = {
           'No. Product previews and examples are static demonstrations and do not authenticate visitors or read tenant data.',
       },
       {
-        question: 'Is restore positioned as an automatic outcome?',
+        question: 'Is Tenantial meant for MSPs and internal IT teams?',
         answer:
-          'No. Tenantial describes restore as a cautious workflow with preview, validation, selective scope, explicit confirmation, and review context.',
-      },
-      {
-        question: 'Does Tenantial publish customer proof here?',
-        answer:
-          'No customer logos, third-party endorsements, external assurance statements, service-level commitments, or recovery promises are published without supplied and reviewed evidence.',
+          'Yes. The public positioning speaks to MSPs, internal IT, security, and governance teams that need to align policy context, review work, and recovery readiness.',
       },
     ],
   },

apps/website/tests/smoke/interaction.spec.ts

@@ -33,14 +33,14 @@ test('theme toggle keeps page content visible', async ({ page }) => {
   await page.locator('button[aria-label="Dark Theme Toggle"]:visible').click();
   await expect(
     page.getByRole('heading', {
-      name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/,
+      name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/,
     })
   ).toBeVisible();
 
   await page.locator('button[aria-label="Light Theme Toggle"]:visible').click();
   await expect(
     page.getByRole('heading', {
-      name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/,
+      name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/,
     })
   ).toBeVisible();
 });
@@ -54,7 +54,7 @@ test('homepage mobile first viewport remains readable', async ({
   await page.goto('/');
 
   const heading = page.getByRole('heading', {
-    name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/i,
+    name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i,
   });
   await expect(heading).toBeVisible();
 
@@ -154,7 +154,7 @@ test('language picker switches between German default and English routes', async
 
   await expect(page).toHaveURL(/\/en\/platform\/?$/);
   await expect(
-    page.getByRole('heading', { name: /Platform review model/i })
+    page.getByRole('heading', { name: /Policy governance model for Microsoft 365/i })
   ).toBeVisible();
 
   await page.getByLabel('Sprache wechseln').click();
@@ -162,6 +162,6 @@ test('language picker switches between German default and English routes', async
 
   await expect(page).toHaveURL(/\/platform\/?$/);
   await expect(
-    page.getByRole('heading', { name: /Plattform-Review-Modell/i })
+    page.getByRole('heading', { name: /Policy-Governance-Modell für Microsoft 365/i })
   ).toBeVisible();
 });

apps/website/tests/smoke/public-routes.spec.ts

@@ -20,24 +20,24 @@ import { globby } from 'globby';
 
 const routeMetadata = {
   '/': {
-    title: /Tenantial.*Evidenzbasierte Microsoft-Tenant-Governance/i,
-    description: /evidenzbasierte Governance/i,
+    title: /Tenantial.*Policy Governance für Microsoft 365/i,
+    description: /Policy Governance für Microsoft 365/i,
   },
   '/platform': {
     title: /Plattform \| Tenantial/i,
-    description: /öffentliches Produktmodell/i,
+    description: /Policy Governance|Microsoft 365/i,
   },
   '/pricing': {
     title: /Preise \| Tenantial/i,
-    description: /Evaluierungs.*Rollout/i,
+    description: /Policy-Governance-Evaluierung|Rollout-Planung/i,
   },
   '/contact': {
     title: /Kontakt \| Tenantial/i,
-    description: /Walkthrough.*Rollout/i,
+    description: /Walkthrough|Provider-Grenzen|Policy-Governance/i,
   },
   '/trust': {
     title: /Vertrauen \| Tenantial/i,
-    description: /Trust-Posture.*statische.*Previews/i,
+    description: /Trust-Haltung|konservativen Claims|Policy-Governance/i,
   },
   '/legal': {
     title: /Rechtliches \| Tenantial/i,
@@ -57,44 +57,43 @@ const routeMetadata = {
   },
   '/welcome-to-docs/': {
     title: /Tenantial Docs/i,
-    description: /Microsoft-Tenant-Governance-Modell/i,
+    description: /Policy-Governance-Modell für Microsoft 365/i,
   },
   '/guides/intro/': {
     title: /Einführung in Tenantial/i,
-    description: /Microsoft-Tenant-Governance-Modell/i,
+    description: /Policy-Governance-Modell für Microsoft 365/i,
   },
   '/guides/getting-started/': {
     title: /Getting Started/i,
-    description: /Tenantial Walkthrough/i,
+    description: /Tenant-Governance-Problem|Tenantial Walkthrough/i,
   },
   '/guides/first-project-checklist/': {
     title: /Evaluierungscheckliste/i,
-    description: /frühe Tenantial-Evaluierung/i,
+    description: /frühe Tenantial-Evaluierung|Checkliste/i,
   },
   '/platform/evidence-review/': {
     title: /Evidence Review/i,
-    description: /Evidence-Review-Workflows/i,
+    description: /Policy-Governance-Modell|Evidence-Review-Workflows/i,
   },
   '/en/': {
-    title: /Tenantial.*Evidence-first Microsoft tenant governance/i,
-    description:
-      /evidence-first governance for Microsoft tenant configuration/i,
+    title: /Tenantial.*Policy governance for Microsoft 365/i,
+    description: /policy governance for Microsoft 365/i,
   },
   '/en/platform': {
     title: /Platform \| Tenantial/i,
-    description: /public product model for Microsoft tenant/i,
+    description: /policy governance|Microsoft 365/i,
   },
   '/en/pricing': {
     title: /Pricing \| Tenantial/i,
-    description: /evaluation and rollout conversation paths/i,
+    description: /policy-governance evaluation|rollout planning/i,
   },
   '/en/contact': {
     title: /Contact \| Tenantial/i,
-    description: /walkthrough.*scoped rollout conversation/i,
+    description: /walkthrough|provider boundaries|policy governance/i,
   },
   '/en/trust': {
     title: /Trust \| Tenantial/i,
-    description: /conservative claims.*static preview boundaries/i,
+    description: /conservative claims|false assurance|policy-governance/i,
   },
   '/en/legal': {
     title: /Legal \| Tenantial/i,
@@ -114,23 +113,23 @@ const routeMetadata = {
   },
   '/en/welcome-to-docs/': {
     title: /Tenantial Docs/i,
-    description: /evidence-first Microsoft tenant governance model/i,
+    description: /policy-governance model for Microsoft 365/i,
   },
   '/en/guides/intro/': {
     title: /Introduction to Tenantial/i,
-    description: /evidence-first Microsoft tenant governance model/i,
+    description: /policy-governance model for Microsoft 365/i,
   },
   '/en/guides/getting-started/': {
     title: /Getting Started/i,
-    description: /Tenantial walkthrough/i,
+    description: /Tenantial walkthrough|governance problem/i,
   },
   '/en/guides/first-project-checklist/': {
     title: /Evaluation Checklist/i,
-    description: /conservative checklist for early Tenantial evaluation/i,
+    description: /conservative checklist|early Tenantial evaluation/i,
   },
   '/en/platform/evidence-review/': {
     title: /Evidence Review/i,
-    description: /Tenantial evidence review workflows/i,
+    description: /policy-governance model|evidence-review workflows/i,
   },
 } as const;
 
@@ -150,7 +149,7 @@ test('homepage first viewport explains core Tenantial capabilities', async ({
   await page.goto('/');
 
   const heading = page.getByRole('heading', {
-    name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/i,
+    name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i,
   });
   await expect(heading).toBeVisible();
 
@@ -160,8 +159,11 @@ test('homepage first viewport explains core Tenantial capabilities', async ({
     page.getByRole('link', { name: /Walkthrough anfragen/i }).first()
   ).toHaveAttribute('href', '/contact');
   await expect(
-    page.getByRole('link', { name: /Plattform ansehen/i }).first()
+    page.getByRole('link', { name: /Governance-Modell ansehen/i }).first()
   ).toHaveAttribute('href', '/platform');
+  await expect(
+    page.getByRole('link', { name: /Trust-Grenzen ansehen/i }).last()
+  ).toHaveAttribute('href', '/trust');
   await expectCoreCapabilitiesVisible(page);
 });
 
@@ -171,10 +173,11 @@ test('/platform explains the public product model without internal runtime terms
   await page.goto('/platform');
 
   await expect(
-    page.getByRole('heading', { name: /Plattform-Review-Modell/i })
+    page.getByRole('heading', { name: /Policy-Governance-Modell für Microsoft 365/i })
   ).toBeVisible();
   await expectCoreCapabilitiesVisible(page);
-  await expect(page.locator('body')).toContainText(/statische Demo-Previews/i);
+  await expect(page.locator('body')).toContainText(/Aktueller Fokus: Microsoft 365/i);
+  await expect(page.locator('body')).toContainText(/provider-extensible|provider-extensibler/i);
   await expect(page.locator('body')).toContainText(
     /authentifiziert keine Besucher, liest keinen Microsoft Tenant, führt keine Operationen aus und speichert keine Tenant-Exporte/i
   );
@@ -262,7 +265,7 @@ for (const route of redirectRoutes) {
     await expect(page).toHaveURL(new RegExp(`${expected.target}/?$`));
     await expect(
       page.getByRole('heading', {
-        name: /Plattform-Review-Modell|Platform review model/,
+          name: /Policy-Governance-Modell für Microsoft 365|Policy governance model for Microsoft 365/,
       })
     ).toBeVisible();
   });

apps/website/tests/smoke/smoke-helpers.ts

@@ -87,7 +87,23 @@ const forbiddenPublicPatterns = [
   { label: 'Microsoft certification claim', pattern: /Microsoft certified/i },
   { label: 'recovery guarantee', pattern: /guaranteed recovery/i },
   { label: 'compliance guarantee', pattern: /guaranteed compliance/i },
+  { label: 'Intune-only tool claim', pattern: /Intune Management Tool/i },
+  { label: 'backup-tool claim', pattern: /Intune backup tool/i },
+  { label: 'DSGVO compliance claim', pattern: /DSGVO compliant/i },
+  { label: 'GDPR compliance claim', pattern: /GDPR compliant/i },
+  { label: 'ISO certified claim', pattern: /ISO certified/i },
+  { label: 'Google supported claim', pattern: /Google supported/i },
+  { label: 'AWS supported claim', pattern: /AWS supported/i },
+  { label: 'automatic restore claim', pattern: /automatic restore/i },
+  { label: 'autonomous remediation claim', pattern: /autonomous remediation/i },
+  { label: 'neutral SaaS residue', pattern: /neutral SaaS visual/i },
+  { label: 'lorem ipsum residue', pattern: /lorem ipsum/i },
   { label: 'fake checkout CTA', pattern: /\b(buy now|checkout)\b/i },
+  { label: 'fake newsletter CTA', pattern: /\b(subscribe|newsletter)\b/i },
+  {
+    label: 'fake subscription CTA',
+    pattern: /\b(pay now|start subscription|activate subscription)\b/i,
+  },
   {
     label: 'fake trial CTA',
     pattern: /\b(start free trial|create account)\b/i,
@@ -163,14 +179,14 @@ export async function expectCoreCapabilitiesVisible(page: Page): Promise<void> {
   const text = (await page.locator('body').innerText()).toLowerCase();
 
   for (const terms of [
-    ['backup'],
-    ['restore'],
-    ['drift detection', 'drift'],
-    ['findings'],
+    ['policy governance', 'policy-governance'],
+    ['microsoft 365'],
     ['evidence'],
-    ['auditability'],
-    ['exceptions'],
+    ['drift detection', 'drift'],
     ['reviews', 'review'],
+    ['audit trail', 'auditability'],
+    ['controlled recovery', 'recovery', 'restore'],
+    ['provider', 'future direction', 'roadmap direction'],
   ]) {
     expect(
       terms.some(term => text.includes(term)),

specs/404-public-content-messaging/checklists/requirements.md

@@ -0,0 +1,39 @@
+# Specification Quality Checklist: Public Website Positioning & Content Architecture
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+
+**Created**: 2026-05-25
+
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Validation pass 1 completed on 2026-05-25.
+- No `[NEEDS CLARIFICATION]` markers remain; the supplied positioning, provider posture, and trust boundaries were specific enough to avoid open questions.
+- Repository/workspace contract references and validation commands are intentional delivery guards, not framework-selection leakage.
+- Existing downstream planning artifacts under `specs/404-public-content-messaging/` predate this refreshed spec and should be reconciled before implementation continues.

specs/404-public-content-messaging/contracts/public-content-contract.md

@@ -0,0 +1,161 @@
+# Public Website Positioning Contract: Spec 404
+
+This feature has no REST, GraphQL, Laravel, Filament, Livewire, Microsoft Graph, database, queue, job, policy, RBAC, or product runtime API contract.
+
+The contract is the public static website behavior that reviewers and smoke checks must verify.
+
+## Core Public Routes
+
+The following default routes must render intentionally and expose Tenantial-specific content, metadata, and CTAs:
+
+- `/`
+- `/platform`
+- `/pricing`
+- `/contact`
+- `/trust`
+- `/legal`
+- `/privacy`
+- `/terms`
+- `/imprint`
+- `/welcome-to-docs/`
+- `/guides/intro/`
+- `/guides/getting-started/`
+- `/guides/first-project-checklist/`
+- `/platform/evidence-review/`
+
+The following English mirrors must remain consistent where they are intentionally exposed:
+
+- `/en/`
+- `/en/platform`
+- `/en/pricing`
+- `/en/contact`
+- `/en/trust`
+- `/en/legal`
+- `/en/privacy`
+- `/en/terms`
+- `/en/imprint`
+- `/en/welcome-to-docs/`
+- `/en/guides/intro/`
+- `/en/guides/getting-started/`
+- `/en/guides/first-project-checklist/`
+- `/en/platform/evidence-review/`
+
+Redirect-only aliases such as `/product` must continue to resolve intentionally and must not become a second competing product story.
+
+## Homepage Positioning Contract
+
+The homepage must satisfy:
+
+- the hero clearly identifies Tenantial as policy governance for Microsoft 365 and modern cloud environments, or an equivalent policy-governance phrasing
+- Microsoft 365 is presented as the first focus without collapsing the category to Intune-only messaging
+- provider-extensible wording is allowed only as design or future direction, not live-support proof
+- a trust teaser introduces auditability, evidence history, role-based access, review trails, or DACH evaluation readiness without false assurance
+- an operating-model section makes the flow from observed state to evidence, detection, review, decision, and audit trail explicit
+- a capability section explains policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability rather than a narrow feature list
+- audience messaging reaches MSPs, internal IT teams, and governance-minded evaluators, not only endpoint administrators
+- a boundaries section makes clear that Tenantial is not an admin-center clone, not blind automation, and not a helpdesk or PSA replacement
+- the final CTA offers a concrete next step with an intentional destination
+
+## `/platform` Governance-Model Contract
+
+The public `/platform` route must satisfy:
+
+- explains the governance model more deeply than the homepage
+- connects evidence, findings, drift, review, accepted risks or exceptions, controlled recovery, and audit trail into one public product story
+- keeps Microsoft 365 first focus without promising unsupported providers as live integrations
+- frames previews, screenshots, or product-like examples as static/demo/illustrative where needed
+- does not import, inspect, or cite `apps/platform` as an implementation source
+- does not imply that the public website connects to a provider, runs Microsoft Graph, or shows live tenant/customer data
+
+## Provider Posture Contract
+
+Public provider/domain wording must satisfy:
+
+- Microsoft 365 is the current public focus
+- Intune is one Microsoft 365 policy domain, not the umbrella product category
+- Entra or other Microsoft domains may be described only when consistent with current route truth
+- Google, AWS, and other non-Microsoft providers may appear only as architecture direction, future direction, or provider-extensible wording unless current support is verified
+- roadmap or architecture-direction references must be clearly labeled as such
+
+## Trust And Claim Guardrail Contract
+
+Public copy must avoid unsupported claims about:
+
+- German hosting
+- DSGVO or GDPR compliance
+- AVV or TOM availability
+- ISO, BSI, NIS2, or similar certification
+- Microsoft endorsement or partnership
+- no customer data stored
+- automatic restore, autonomous remediation, self-healing, or approval-free automation
+- fake customer logos, fake testimonials, fake case studies, or fake compliance badges
+
+Trust, FAQ, footer, and legal-adjacent copy should explain product boundaries calmly and conservatively without adding fake proof or fake workflows.
+
+## Navigation And CTA Contract
+
+Every public navigation item, CTA, footer link, docs link, and visible form-like control must satisfy:
+
+- resolves to an intentional route, anchor, static asset, `mailto:` link, or legitimate external URL
+- no public `href="#"` placeholders
+- no navigation labels that imply production-ready pages which do not exist
+- primary CTAs lead to contact, walkthrough, demo discussion, or another real next step
+- secondary CTAs lead to product explanation, trust review, pricing review, or docs review
+- localized routes remain in the current locale where a localized mirror exists
+- labels avoid login, signup, account creation, checkout, subscription, instant provisioning, self-serve billing, or automated scheduling implications unless those workflows exist
+
+## Metadata Contract
+
+Each rendered canonical route must provide:
+
+- Tenantial-specific page title and description
+- policy-governance positioning rather than Intune-only framing
+- route-appropriate canonical, Open Graph, and Twitter summary values
+- no ScrewFast, construction, hardware, manufacturing, template, TenantAtlas, TenantPilot, or TenantCTRL residue in public metadata
+- no unsupported provider, trust, proof, or automation claims in title, description, Open Graph, Twitter, schema, or docs metadata
+- sitemap and robots behavior preserved from the launch-readiness baseline unless a website-scope correction is documented
+
+## Docs Exposure Contract
+
+Exposed docs routes must:
+
+- contain intentional Tenantial-specific content or be hidden from public navigation
+- reinforce the same policy-governance and claim-safe posture as the marketing routes
+- avoid placeholder theme content and unsupported product behavior claims
+- avoid support, legal, provider, compliance, or recovery commitments not supplied by current product/business truth
+- remain clearly separate from `apps/platform` implementation documentation unless a future spec changes scope
+
+## Product Preview Contract
+
+Static product previews must:
+
+- be framed as illustrative, static, or demo content where needed
+- avoid implying live tenant/customer/provider data
+- avoid internal Laravel/Filament implementation details
+- avoid turning visual labels into runtime product taxonomy
+- communicate meaning through wording and labeling, not color alone
+
+## Browser And Accessibility Contract
+
+Validated public routes must:
+
+- avoid body-level horizontal overflow on representative desktop and mobile viewports
+- keep primary navigation, CTAs, footer links, FAQ controls, and visible controls keyboard reachable
+- show visible focus states for interactive elements
+- remain understandable with reduced motion
+- keep primary content and links usable if JavaScript fails where reasonably possible for a static marketing site
+
+## Scope Contract
+
+Implementation and validation must not touch:
+
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`
+- Laravel providers, migrations, policies, jobs, queues, database, Filament resources, Livewire components, Blade views, tenant/workspace/RBAC code, Microsoft Graph code, or AuditLog behavior
+
+Scope proof command:
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short -- apps/platform
+```
+
+The command must print no output.

specs/404-public-content-messaging/data-model.md

@@ -0,0 +1,145 @@
+# Data Model: Public Website Positioning & Content Architecture
+
+This feature introduces no database tables, product runtime models, persisted entities, enums, status families, provider contracts, or shared product taxonomy.
+
+The records below are planning and validation concepts for static website artifacts only.
+
+## Public Positioning Surface
+
+Represents one intentional public route, docs route, navigation/footer surface, or shared metadata surface affected by the positioning pass.
+
+**Fields**
+
+- `surfaceId`: stable identifier such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, `footer`, or `site-meta`
+- `path`: public route path when the surface maps to a URL
+- `locale`: default German, English mirror, shared, or locale-neutral
+- `sourceArea`: shared copy file, route wrapper, page component, docs content, metadata component, navigation/footer component, or smoke expectation
+- `audienceIntent`: first-time visitor, MSP evaluator, internal IT evaluator, governance reviewer, or site maintainer
+- `surfaceRole`: hero, operating model, capability section, provider posture, trust teaser, boundary section, CTA surface, docs surface, or route metadata
+- `status`: needs audit, needs rewrite, accepted, hidden from navigation, or removed
+
+**Validation Rules**
+
+- Every exposed core public route must have intentional Tenantial-specific content.
+- Homepage surfaces must support policy-governance category clarity and an operating-model narrative.
+- `/platform` must explain the governance model more deeply than the homepage.
+- No positioning surface may import, reference, or depend on `apps/platform`.
+
+## Messaging Claim
+
+Represents visible copy or metadata that could create a product, provider, trust, pricing, legal, proof, or workflow claim.
+
+**Fields**
+
+- `surfaceId`: related public positioning surface
+- `claimText`: reviewed phrase or summary of the phrase
+- `claimCategory`: product category, provider posture, trust, pricing, restore, automation, compliance, endorsement, social proof, preview framing, or workflow expectation
+- `proofStatus`: verified, conservative positioning, architecture direction, illustrative/static, unsupported, or remove
+- `riskLevel`: low, medium, high
+- `requiredAction`: keep, rewrite, remove, hide, or verify proof
+
+**Validation Rules**
+
+- Unsupported provider, certification, compliance, hosting, endorsement, and customer-proof claims must be removed or rewritten.
+- Restore and automation language must avoid autonomous remediation or guaranteed recovery.
+- Trust language must stop at evaluation readiness, auditability, evidence history, review trails, and role-based access unless proof exists.
+- Public copy must not imply that the website connects to or displays live provider/customer data.
+
+## Provider Posture Entry
+
+Represents one provider or policy-domain reference that may appear in public copy.
+
+**Fields**
+
+- `providerOrDomain`: Microsoft 365, Intune, Entra, Conditional Access, SharePoint, OneDrive sharing, Enterprise Apps, Service Principals, Google Workspace, AWS, or other domain wording
+- `publicStatus`: current focus, example domain, roadmap domain, architecture direction, or disallowed claim
+- `allowedLabel`: Microsoft 365 first, one policy domain, planned, roadmap domain, architecture direction, or omit
+- `guardrail`: exact wording or implication that must be avoided
+- `relatedSurfaces`: homepage, platform, docs, metadata, trust, or pricing surfaces where the reference appears
+
+**Validation Rules**
+
+- Microsoft 365 is the current public focus.
+- Intune may appear only as one Microsoft 365 policy domain.
+- Non-Microsoft providers may appear only as architecture direction or future direction when not verified.
+- Public wording must not imply current live support where none exists.
+
+## Operating Model Step
+
+Represents one step in the public governance operating model.
+
+**Fields**
+
+- `stepId`: observe, evidence, detect, review, decide, audit
+- `displayLabel`: localized section label for the step
+- `goal`: what the step explains to a visitor
+- `supportingConcepts`: evidence, findings, drift, exceptions, accepted risks, next actions, or audit trail elements
+- `relatedSurfaces`: homepage, platform, docs, or metadata summaries where the step appears
+
+**Validation Rules**
+
+- The homepage operating model must contain a complete sequence from observed state to audit trail.
+- Step labels must remain understandable to public evaluators and not degrade into implementation vocabulary.
+- Each step must add meaning rather than repeat the prior step.
+
+## CTA Intent
+
+Represents a visible CTA, navigation item, footer link, or docs/action link.
+
+**Fields**
+
+- `label`: visible link or CTA text
+- `sourceSurface`: route, shared component, footer, docs nav, or metadata-adjacent surface where the CTA appears
+- `target`: route, anchor, static asset, `mailto:` link, or legitimate external URL
+- `intentFamily`: primary contact/demo, secondary product explanation, trust review, docs review, pricing/evaluation, or navigation
+- `workflowImplied`: walkthrough request, contact request, product education, trust review, pricing discussion, docs review, login, signup, checkout, account creation, self-serve billing, or automated scheduling
+- `supported`: yes or no
+
+**Validation Rules**
+
+- Public CTAs must resolve to intentional targets and must not use `href="#"`.
+- CTA labels must not imply unavailable login, signup, checkout, account creation, self-serve billing, or automated scheduling workflows.
+- Primary CTA language should remain consistent across core public routes.
+
+## Route Metadata
+
+Represents public route title, description, canonical, and search/social-facing metadata.
+
+**Fields**
+
+- `path`: public route path
+- `title`: route-specific page title
+- `description`: route-specific page description
+- `canonicalPolicy`: canonical self, localized alternate, redirect-only, or hidden
+- `socialSummary`: Open Graph/Twitter-facing summary
+- `positioningStatus`: aligned, needs rewrite, or blocked
+- `claimStatus`: conservative, needs rewrite, or blocked
+
+**Validation Rules**
+
+- Core public route metadata must reinforce policy-governance positioning and Microsoft 365 first focus.
+- Metadata must remain Tenantial-specific and residue-free.
+- Metadata must avoid unsupported provider, compliance, trust, or automation claims.
+- Sitemap and robots behavior from the launch-readiness baseline must remain intact unless a website-scope correction is required.
+
+## Relationships
+
+- A `Public Positioning Surface` may contain many `Messaging Claim`, `Provider Posture Entry`, `Operating Model Step`, `CTA Intent`, and `Route Metadata` review points.
+- A `Provider Posture Entry` may appear on multiple public positioning surfaces, but each appearance must preserve the same current-versus-future public status.
+- An `Operating Model Step` may appear on the homepage, `/platform`, and docs surfaces, with the homepage carrying concise explanation and `/platform` carrying deeper detail.
+- A `CTA Intent` belongs to one source surface and targets one intentional route, anchor, asset, or legitimate external URL.
+- `Route Metadata` belongs to one public route and must be reviewed alongside the visible copy for that same route.
+
+## State Transitions
+
+No product runtime state transitions are introduced.
+
+Implementation review may move planning concepts through this non-product workflow:
+
+```text
+identified -> audited -> rewritten -> validated
+identified -> hidden-from-navigation -> validated
+identified -> removed -> validated
+```
+
+These are task/review states only and must not become product runtime status families.

specs/404-public-content-messaging/plan.md

@@ -0,0 +1,229 @@
+# Implementation Plan: Public Website Positioning & Content Architecture
+
+**Branch**: `404-public-content-messaging` | **Date**: 2026-05-25 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
+**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
+
+## Summary
+
+Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 as the first focus and provider-extensible language kept explicitly future-safe. The implementation will stay inside `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` and reuse the existing Astro route/content architecture: locale-keyed copy in `src/data_files/site-copy.ts`, thin route wrappers in `src/pages`, shared page components in `src/components/pages`, metadata through `MainLayout` and `Meta`, and the current Playwright smoke suite for route, link, claim, and metadata validation.
+
+## Technical Context
+
+**Language/Version**: TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0
+**Primary Dependencies**: Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwright
+**Storage**: N/A - static website content and generated build output only; no database or product persistence
+**Testing**: Astro build via `corepack pnpm build:website`, existing Playwright smoke tests under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`, targeted static claim scans
+**Validation Lanes**: website build, public smoke, manual browser review, static claim scan, whitespace check, `apps/platform` scope check
+**Target Platform**: Static Astro public website deployed from `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`, with German default routes and `/en/...` mirrors
+**Project Type**: Web - standalone Astro public website inside a monorepo
+**Performance Goals**: No body-level horizontal overflow on validated desktop/mobile routes; primary navigation and CTAs stay readable and reachable; metadata and canonical routes stay intentional
+**Constraints**: Runtime/source changes are scoped to `apps/website`; preserve root package script names, website package name `@tenantatlas/website`, `WEBSITE_PORT`, and `apps/*` workspace conventions; no `apps/platform` changes; no fake trust/provider claims; no placeholder links; no auth/API/database/runtime coupling
+**Scale/Scope**: Core public pages `/`, `/platform`, `/pricing`, `/trust`, `/contact`, legal pages, exposed docs routes, locale mirrors, navigation/footer surfaces, route metadata, and smoke expectations
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no operator-facing surface change; public website positioning workflow only
+- **Native vs custom classification summary**: custom Astro public website; no Filament/Blade/admin surface
+- **Shared-family relevance**: public navigation, CTA language, metadata, docs exposure, and smoke helper patterns
+- **State layers in scope**: localized static page content, navigation/footer data, route metadata, docs content, smoke expectations
+- **Audience modes in scope**: public visitor, MSP evaluator, internal IT evaluator, DACH trust reviewer
+- **Decision/diagnostic/raw hierarchy plan**: public copy stays decision-first for visitors; diagnostics and proof boundaries are explained plainly rather than exposed as raw runtime detail
+- **Raw/support gating plan**: N/A - no operator support/raw evidence surface
+- **One-primary-action / duplicate-truth control**: each primary route keeps one clear next step, typically contact or deeper product explanation, while repeated or competing CTA language is normalized
+- **Handling modes by drift class or surface**: public claim, placeholder-link, and navigation drift are review-mandatory inside this feature; `apps/platform` drift is a hard stop
+- **Repository-signal treatment**: website-source and website-smoke changes are expected; any platform/runtime drift is exception-required and out of scope
+- **Special surface test profiles**: N/A - public website only
+- **Required tests or manual smoke**: public smoke, static claim scan, and manual desktop/mobile browser review
+- **Exception path and spread control**: none
+- **Active feature PR close-out entry**: Smoke Coverage
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes
+- **Systems touched**: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`
+- **Shared abstractions reused**: locale-keyed `siteCopy`, thin route wrappers in `src/pages`, `MainLayout.astro`, `Meta.astro`, `localizeHref()` and locale helpers, shared Navbar/Footer components, Playwright smoke helper patterns for forbidden claims and placeholder links
+- **New abstraction introduced? why?**: none
+- **Why the existing abstraction was sufficient or insufficient**: The current website already centralizes copy, navigation, metadata, and smoke assertions. Spec 404 needs a better narrative and stricter claim posture, not a new framework.
+- **Bounded deviation / spread control**: no new abstraction; bounded cleanup of stale helpers such as German-only `navigation.ts` usage is allowed if needed to keep copy and route logic aligned
+
+## OperationRun UX Impact
+
+- **Touches OperationRun start/completion/link UX?**: no
+- **Central contract reused**: N/A
+- **Delegated UX behaviors**: N/A
+- **Surface-owned behavior kept local**: N/A
+- **Queued DB-notification policy**: N/A
+- **Terminal notification path**: N/A
+- **Exception path**: none
+
+## Provider Boundary & Portability Fit
+
+- **Shared provider/platform boundary touched?**: yes
+- **Provider-owned seams**: public Microsoft 365 wording, Intune as one example domain, any roadmap/provider-direction examples in public copy
+- **Platform-core seams**: none; no runtime platform contracts, provider contracts, or shared persistence truth change
+- **Neutral platform terms / contracts preserved**: policy governance, cloud policy governance, managed environment, provider connection, policy evidence, drift detection, findings, exceptions, accepted risks, decision summary, audit trail, controlled recovery, provider readiness
+- **Retained provider-specific semantics and why**: Microsoft 365 remains the first public focus because that is current product truth; Intune is retained only as one Microsoft 365 policy domain and not the umbrella category
+- **Bounded extraction or follow-up path**: follow-up-spec for a broader public provider/domain taxonomy if future route or copy work needs a richer current-versus-planned matrix
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+- Inventory-first: PASS - no inventory, snapshots, backups, or source-of-truth runtime behavior changes
+- Read/write separation: PASS - no write/change behavior is introduced
+- Graph contract path: PASS - no Microsoft Graph calls or contract-registry changes
+- Deterministic capabilities: PASS - no capability derivation or resolver changes
+- RBAC-UX: PASS - no `/admin`, `/system`, tenant context, workspace context, authorization, or capability behavior changes
+- Workspace isolation: PASS - no workspace data or workspace-scoped route behavior changes
+- RBAC-UX destructive-like actions: PASS - no destructive actions
+- RBAC-UX global search: PASS - no Filament or global-search changes
+- Tenant isolation: PASS - no tenant data, tenant reads, or tenant routes
+- Run observability: PASS - no long-running, remote, queued, or scheduled product work
+- OperationRun start UX: PASS - no OperationRun behavior
+- Ops-UX 3-surface feedback: PASS - no OperationRun notifications or lifecycle output
+- Ops-UX lifecycle: PASS - no `OperationRun.status` or `OperationRun.outcome` changes
+- Ops-UX summary counts: PASS - no summary-count semantics
+- Ops-UX guards: PASS - no Ops-UX guard changes
+- Ops-UX system runs: PASS - no system-run behavior
+- Automation: PASS - no queue, retry, lock, idempotency, or backoff behavior
+- Data minimization: PASS - public static copy and metadata only; no secrets, tokens, or tenant data
+- Test governance (TEST-GOV-001): PASS - browser/static classification is explicit, uses existing website lanes, and introduces no hidden Laravel/Filament/provider/database setup cost
+- Proportionality (PROP-001): PASS - website-local narrative and metadata updates only; no new product structure or semantic machinery
+- No premature abstraction (ABSTR-001): PASS - no new factories, registries, resolvers, strategies, interfaces, or pipelines
+- Persisted truth (PERSIST-001): PASS - no new persisted product truth or artifacts beyond existing static build output
+- Behavioral state (STATE-001): PASS - no new product states, statuses, or reason families
+- UI semantics (UI-SEM-001): PASS - public copy and labels remain local presentation, not a shared semantic framework
+- Shared pattern first (XCUT-001): PASS - existing shared website copy, layout, metadata, navigation, and smoke helpers are reused
+- Provider boundary (PROV-001): PASS - public provider vocabulary is explicitly bounded to positioning only; no platform-core coupling is added
+- V1 explicitness / few layers (V1-EXP-001, LAYER-001): PASS - direct website-local edits only
+- Spec discipline / bloat check (SPEC-DISC-001, BLOAT-001): PASS - no enum, DTO, presenter, persisted entity, interface, registry, resolver, or taxonomy is introduced
+- Badge semantics (BADGE-001): PASS - no shared badge/status taxonomy changes
+- Filament-native UI (UI-FIL-001): PASS - no Filament UI
+- UI/UX surface taxonomy: PASS - no operator-facing surface
+- Decision-first operating model: PASS - public visitor decision flow is improved, but no operator decision surface is added
+- Audience-aware disclosure: PASS - trust/proof boundaries are stated conservatively without exposing operator/raw evidence surfaces
+- UI/UX inspect model: PASS - no operator list/detail surface
+- UI/UX action hierarchy: PASS - no Filament actions or admin action surfaces
+- UI/UX scope, truth, and naming: PASS - public category language, provider posture, and CTA vocabulary stay honest and non-implementation-first
+- UI/UX placeholder ban: PASS - placeholder links and fake pages are explicitly banned by this feature
+- UI naming: PASS - public CTA labels map to real next steps and avoid unsupported workflow verbs
+- Operator surfaces: PASS - no `/admin` surface changes
+- Filament UI Action Surface Contract: PASS - no Filament Resource/RelationManager/Page changes
+- Filament UI UX-001: PASS - no Filament screen changes
+- Action-surface discipline: PASS - no operator action surface changes
+- UI review workflow: PASS - website-specific shared patterns and public validation responsibilities stay explicit without widening into platform scope
+
+**Initial Gate Result**: PASS - no constitution violations or unresolved clarifications.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: Browser/static website
+- **Affected validation lanes**: website build, public smoke, manual browser review, static claim scan, whitespace/scope checks
+- **Why this lane mix is the narrowest sufficient proof**: The feature changes public copy, route metadata, CTA intent, navigation exposure, and claim discipline. Laravel/Pest/Filament lanes would not prove the changed behavior.
+- **Narrowest proving command(s)**: `cd /Users/ahmeddarrazi/Documents/projects/wt-website && corepack pnpm build:website`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git diff --check`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short -- apps/platform`
+- **Fixture / helper / factory / seed / context cost risks**: none - no database, provider, workspace, membership, session, queue, Sail, Laravel, Filament, or Livewire setup
+- **Expensive defaults or shared helper growth introduced?**: no
+- **Heavy-family additions, promotions, or visibility changes**: none - existing Playwright smoke remains explicit and website-local
+- **Surface-class relief / special coverage rule**: N/A - public website
+- **Closing validation and reviewer handoff**: Reviewers should rely on website build, Playwright smoke, static claim scan, desktop/mobile manual review, and `apps/platform` untouched confirmation. If copy changes add new public docs or navigation surfaces, smoke route allowlists and metadata expectations must be updated in the same feature.
+- **Budget / baseline / trend follow-up**: none expected
+- **Review-stop questions**: lane fit, claim drift, placeholder-link drift, route-exposure drift, hidden platform coupling
+- **Escalation path**: document-in-feature
+- **Active feature PR close-out entry**: Smoke Coverage
+- **Why no dedicated follow-up spec is needed**: The validation cost remains local to this public website positioning pass unless future website work creates a recurring release-governance problem.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+│   └── public-content-contract.md
+└── tasks.md
+```
+
+### Source Code (repository root)
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/
+├── astro.config.mjs
+├── package.json
+├── playwright.config.ts
+├── process-html.mjs
+├── public/
+├── src/
+│   ├── components/
+│   │   ├── pages/
+│   │   └── sections/
+│   ├── content/
+│   │   ├── docs/
+│   │   ├── blog/
+│   │   ├── insights/
+│   │   └── products/
+│   ├── data_files/
+│   ├── layouts/
+│   ├── pages/
+│   │   └── en/
+│   └── utils/
+└── tests/
+    └── smoke/
+```
+
+**Structure Decision**: Use the existing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` Astro application and its current localized route/component/content organization. Do not create new base folders and do not touch `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| None | N/A | N/A |
+
+## Proportionality Review
+
+- **Current operator problem**: Public evaluators and reviewers still receive the wrong product category and an incomplete governance narrative from the current website.
+- **Existing structure is insufficient because**: The website foundation is already stable, but its public copy, metadata, navigation, and trust/provider boundaries do not yet express the intended policy-governance positioning.
+- **Narrowest correct implementation**: Update the existing website-local copy system, page hierarchy, docs exposure, metadata, and smoke expectations inside `apps/website` only.
+- **Ownership cost created**: Ongoing maintenance of public positioning copy, provider/trust claim guardrails, and smoke expectations for emitted public routes.
+- **Alternative intentionally rejected**: A broad website redesign, a new content system, and any `apps/platform`-linked implementation or provider runtime work.
+- **Release truth**: Current-release public website positioning truth.
+
+## Phase 0 Research
+
+Research output is captured in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md`.
+
+**Resolved clarifications**:
+
+- The active website remains the existing Astro 6 app in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`; no framework decision is needed.
+- Core public routes are thin wrappers that delegate to shared page components in `src/components/pages`.
+- The primary copy, navigation, CTA labels, and per-route metadata are centralized in `src/data_files/site-copy.ts`.
+- German default routes and `/en/...` mirrors share the same content source through locale-keyed records rather than separate content systems.
+- `/product` is a redirect alias to `/platform`, so the governance model should stay anchored to `/platform` and not a second product page.
+- Existing Playwright smoke helpers already cover rendered routes, redirect aliases, placeholder-link bans, forbidden public residue, metadata, and mobile/keyboard/overflow checks.
+- Public docs routes are intentionally emitted and must stay aligned with the same positioning/claim contract as the core marketing pages.
+- No REST, GraphQL, database, queue, Laravel, Filament, Livewire, or provider-runtime contract is required for this feature.
+
+## Phase 1 Design
+
+Design output is captured in:
+
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md`
+
+The design treats public route behavior, messaging claims, provider posture, CTAs, operating-model sections, and route metadata as the contract. No REST, GraphQL, database, Laravel, Filament, Livewire, Microsoft Graph, queue, job, RBAC, or runtime platform contract is introduced.
+
+## Post-Design Constitution Check
+
+**Post-Design Gate Result**: PASS
+
+- Phase 1 remains website-local and scoped to `apps/website`.
+- All clarification markers are resolved.
+- No product persistence, abstraction, status family, provider runtime seam, OperationRun behavior, RBAC behavior, or Filament behavior is introduced.
+- Shared-pattern reuse stays within the existing website copy/layout/metadata/smoke system.
+- Provider vocabulary remains bounded to public positioning only.
+- Validation remains explicit and limited to website build, smoke, claim scans, and scope checks.
+- Agent context must be updated with the current plan outputs before implementation continues.

specs/404-public-content-messaging/quickstart.md

@@ -0,0 +1,170 @@
+# Quickstart: Spec 404 Public Website Positioning & Content Architecture
+
+## Scope
+
+Work only in:
+
+```bash
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website
+/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging
+```
+
+Do not touch:
+
+```bash
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform
+```
+
+## Verify Current Repo Truth First
+
+Run the required repo checks before editing:
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && pwd
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short --branch
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && find apps/website -maxdepth 3 -type f | sort | sed -n '1,160p'
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat package.json
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat pnpm-workspace.yaml
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat apps/website/package.json
+```
+
+## Install Dependencies If Needed
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && corepack pnpm install
+```
+
+## Run The Website Locally
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm dev:website
+```
+
+Open:
+
+```text
+http://127.0.0.1:4321
+```
+
+## Read-Only Content Audit
+
+Review public content sources before editing:
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && rg -n "Policy Governance|Microsoft 365|provider-extensible|Intune|Google|AWS|DSGVO|GDPR|AVV|TOM|ISO|BSI|automatic restore|autonomous remediation|href=\"#\"|lorem ipsum|ScrewFast|TenantAtlas|TenantPilot|TenantCTRL" apps/website/src apps/website/public
+```
+
+Audit these content surfaces first:
+
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/ContactPage.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`
+
+## Content Review Checklist
+
+For the homepage:
+
+- hero identifies Tenantial as policy governance and Microsoft 365 first
+- provider-extensible language stays future-safe and does not claim live non-Microsoft support
+- operating-model section covers observe, evidence, detect, review, decide, and audit
+- capability framing emphasizes policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability
+- audience and boundary sections add meaning instead of repeating the hero
+- CTAs match real buyer-stage destinations
+
+For `/platform`:
+
+- explains the governance model more deeply than the homepage
+- keeps Microsoft 365 first focus without collapsing back to Intune-only framing
+- frames previews as static/demo/illustrative where needed
+- does not cite or depend on `apps/platform`
+- does not imply live provider connection, Graph execution, or live tenant/customer data
+
+For pricing/evaluation:
+
+- remains contact-led and scoped
+- avoids checkout, subscription activation, self-serve billing, account creation, or unsupported entitlement claims
+- CTAs resolve to `/contact` or another intentional target
+
+For trust/FAQ/footer/legal-adjacent content:
+
+- no unsupported German hosting, DSGVO/GDPR, AVV/TOM, ISO/BSI/NIS2, endorsement, or customer-proof claims
+- no fake logos, testimonials, or compliance badges
+- no autonomous remediation or automatic restore claims
+- no public website live-data implication
+
+## Build Validation
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && corepack pnpm build:website
+```
+
+## Smoke Validation
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke
+```
+
+## Static Claim And Scope Validation
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && git diff --check
+cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short -- apps/platform
+```
+
+The `apps/platform` command must print no output.
+
+## Manual Browser Review
+
+Review these routes in desktop and mobile widths:
+
+- `/`
+- `/platform`
+- `/pricing`
+- `/contact`
+- `/trust`
+- `/legal`
+- `/privacy`
+- `/terms`
+- `/imprint`
+- `/welcome-to-docs/`
+- `/guides/intro/`
+- `/guides/getting-started/`
+- `/guides/first-project-checklist/`
+- `/platform/evidence-review/`
+
+Check:
+
+- the homepage hero no longer frames the product as Intune-only
+- the public category is policy governance and Microsoft 365 first
+- provider-extensible wording does not imply live Google/AWS support
+- the operating model is visible and coherent
+- Intune appears only as one domain when named
+- trust copy does not overclaim compliance, hosting, certification, or automation
+- CTAs are concrete and intentional
+- no `href="#"` placeholders are visible or emitted
+- no forbidden residue terms appear in visible copy or metadata
+- keyboard users can reach navigation, CTAs, footer links, FAQ controls, and visible controls
+- visible focus states are present
+- no body-level horizontal overflow occurs
+
+## Handoff
+
+Implementation summary must document:
+
+- changed public routes and shared copy surfaces
+- provider-posture and claim-safety decisions
+- CTA and navigation changes
+- metadata changes
+- validation commands and outcomes
+- deferred follow-up work for later public website specs
+- `apps/platform` untouched confirmation

specs/404-public-content-messaging/research.md

@@ -0,0 +1,91 @@
+# Phase 0 Research: Public Website Positioning & Content Architecture
+
+## Decision: Keep the existing Astro website foundation and shared copy architecture
+
+**Rationale**: The active website is already a standalone Astro app at `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` with Starlight docs, locale-aware route mirrors, shared page components, centralized route copy in `src/data_files/site-copy.ts`, and Playwright smoke coverage. Spec 404 is a positioning and content-architecture pass, not a rebuild.
+
+**Alternatives considered**:
+
+- Rebuild the public website foundation: rejected by scope and unnecessary after Specs 400-403.
+- Introduce a new content framework or CMS: rejected because this feature needs narrative clarity, not another authoring layer.
+- Use `apps/platform` as a content source: rejected because the public `/platform` route is static website positioning and `apps/platform` is explicitly out of scope.
+
+## Decision: Treat public route behavior, messaging claims, CTAs, and metadata as the contract
+
+**Rationale**: The feature introduces no API endpoints or runtime entities. The behavior that matters is expressed through public routes, visible copy, navigation/footer exposure, metadata, docs exposure, CTA targets, and emitted static output.
+
+**Alternatives considered**:
+
+- Generate OpenAPI or GraphQL contracts: rejected because the public website exposes no feature API.
+- Model messaging states as persisted product data: rejected because it would create unnecessary taxonomy or persistence.
+- Leave behavior implicit in review comments: rejected because the later implementation and smoke updates need stable, explicit rules.
+
+## Decision: Use a homepage operating model instead of an Intune-first feature list
+
+**Rationale**: The homepage needs to explain the product through an operating model that runs from observed state to evidence, detection, review, decision, and audit trail. That structure supports the intended category better than a narrow feature list or backup-tool framing.
+
+**Alternatives considered**:
+
+- Keep the existing feature-list emphasis: rejected because it allows the product to collapse back to an Intune-only or backup-only impression.
+- Lead with pricing or generic SaaS value claims: rejected because category clarity and trust-safe positioning must come first.
+- Defer narrative changes until visual polish: rejected because later layout decisions should follow stable section intent.
+
+## Decision: Make `/platform` the deeper governance-model page and keep `/product` as the redirect alias
+
+**Rationale**: The current route structure already redirects `/product` to `/platform`. The deeper explanation of the governance model should therefore live on `/platform` and explain Microsoft 365 first focus, evidence workflows, drift/finding review, controlled recovery, and auditability as one public model.
+
+**Alternatives considered**:
+
+- Maintain two competing product explanation pages: rejected because it would fragment the public story.
+- Mirror homepage copy on `/platform`: rejected because the route should go deeper than the homepage.
+- Reference internal admin implementation details: rejected because the public route must not imply Laravel/Filament/Livewire/runtime coupling.
+
+## Decision: Keep Microsoft 365 as the first focus and bound provider-extensible claims explicitly
+
+**Rationale**: The current product truth supports Microsoft 365-first positioning. The website may say the platform is provider-extensible by design, but current-route copy must keep Google, AWS, and other providers in future/architecture-direction territory only.
+
+**Alternatives considered**:
+
+- Present the product as Intune-only: rejected because it narrows the intended category too far.
+- Present the product as broadly provider-agnostic today: rejected because current support truth does not justify it.
+- Avoid provider posture entirely: rejected because the spec requires safe provider-extensible framing.
+
+## Decision: Build trust through restrained claims and explicit boundaries
+
+**Rationale**: No verified German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, Microsoft endorsement, or no-customer-data claim has been supplied. The trust posture should therefore speak about auditability, evidence history, review trails, role-based access, and DACH evaluation readiness without crossing into false assurance.
+
+**Alternatives considered**:
+
+- Use aspirational trust claims to sound enterprise-ready: rejected because it creates legal and commercial risk.
+- Remove trust language entirely: rejected because evaluators still need a clear, honest trust posture.
+- Hide boundaries and hope later trust pages fix them: rejected because public pages need safe wording now.
+
+## Decision: Reuse the current smoke suite and augment it with claim scans rather than inventing new test families
+
+**Rationale**: The existing Playwright smoke helpers already validate rendered routes, placeholder-link bans, forbidden public residue, metadata, redirects, mobile navigation, keyboard reachability, and overflow. Those checks, plus a targeted static grep scan for newly forbidden terms, are the narrowest sufficient validation.
+
+**Alternatives considered**:
+
+- Run Laravel/Pest/Filament tests: rejected because this feature does not touch `apps/platform`.
+- Add a new website-only test framework: rejected because the current smoke suite already covers the needed route and claim surfaces.
+- Rely only on manual copy review: rejected because emitted output, links, and metadata also need executable proof.
+
+## Decision: Keep docs and locale mirrors intentional and in sync with the positioning contract
+
+**Rationale**: The public website exposes docs routes under both the default locale and `/en/...` mirrors, and both route families are driven by shared content/copy organization. Public docs and locale mirrors therefore need the same claim discipline and route-intent review as the core marketing pages.
+
+**Alternatives considered**:
+
+- Treat docs exposure as separate from positioning: rejected because public docs influence buyer understanding and indexing.
+- Update only German default routes: rejected because `/en/...` pages share the same positioning responsibility.
+- Hide all docs routes temporarily: rejected unless specific routes are found to be unready during implementation.
+
+## Current Source Observations
+
+- Core marketing routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages` are thin wrappers around shared components in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages`.
+- Navigation labels, CTA labels, page titles, and page descriptions are centralized in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`.
+- Metadata flows through `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`.
+- Locale routing is mirrored under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` using shared component and copy sources.
+- Starlight docs content lives under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` and is publicly rendered.
+- Existing smoke coverage lives under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke` and already includes forbidden public pattern detection, placeholder-link detection, metadata checks, and mobile/keyboard/overflow checks.
+- Placeholder collections still exist under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/blog`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/insights`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/products`; public exposure must remain intentional and route-safe.

specs/404-public-content-messaging/spec.md

@@ -0,0 +1,291 @@
+# Feature Specification: Public Website Positioning & Content Architecture
+
+**Feature Branch**: `404-public-content-messaging`
+
+**Created**: 2026-05-25
+
+**Status**: Draft
+
+**Input**: User description: "Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 first positioning, provider-extensible direction, an Observe-to-Audit operating model, and strict public claim discipline."
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: The public website still risks framing Tenantial as an Intune backup utility, a narrow Microsoft admin tool, or generic SaaS copy instead of the intended governance-of-record platform.
+- **Today's failure**: Visitors can leave with the wrong category, miss the governance operating model, or infer unsupported provider, compliance, trust, or automation claims from incomplete positioning.
+- **User-visible improvement**: Public visitors can understand Tenantial as a policy governance platform, see Microsoft 365 as the first focus without collapsing the story to Intune, and follow a clear evidence-review-decision narrative.
+- **Smallest enterprise-capable version**: Refresh public website copy hierarchy, terminology, metadata, navigation labels, CTA language, and claim guardrails inside `apps/website` only, without changing platform runtime behavior.
+- **Explicit non-goals**: No `apps/platform` changes, no shared auth or API coupling, no CMS, no provider implementation work, no detailed legal or trust proofs, no fake social proof, no fake certifications, and no website-wide visual-system rewrite beyond what content hierarchy requires.
+- **Permanent complexity imported**: No persisted models, services, enums, or runtime workflows. The durable complexity is limited to public positioning rules, provider-claim guardrails, trust-claim guardrails, and route-level content architecture.
+- **Why now**: Launch-readiness and later visual productization depend on a stable public narrative; polishing layout first would optimize around the wrong product story.
+- **Why not local**: The mispositioning spans hero copy, operating-model sections, capability framing, navigation, metadata, trust language, CTA labels, and supporting route hierarchy.
+- **Approval class**: Core Enterprise.
+- **Red flags triggered**: Public category ambiguity; provider-claim risk; compliance/trust overclaim risk; narrow Intune-only framing risk.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12**
+- **Decision**: approve.
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace.
+- **Primary Routes**: `/`, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs navigation, public metadata, public CTA surfaces, and any shared marketing copy/configuration that drives those routes.
+- **Data Ownership**: No tenant-owned or workspace-owned records are created, changed, or read. This is public website content only.
+- **RBAC**: Not applicable. The affected surfaces are public marketing and product-positioning pages.
+
+For canonical-view specs, the spec MUST define:
+
+- **Default filter behavior when tenant-context is active**: N/A - no tenant-context or canonical platform view is introduced.
+- **Explicit entitlement checks preventing cross-tenant leakage**: N/A - no tenant data, workspace data, or authenticated platform state is involved.
+
+## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
+
+- **Cross-cutting feature?**: yes, within public website content surfaces.
+- **Interaction class(es)**: public navigation, homepage section hierarchy, CTA labels, capability cards, trust teaser language, route metadata, and public route discovery.
+- **Systems touched**: `apps/website` pages, shared marketing content/configuration, route metadata, public navigation/footer surfaces, and any public docs route exposure.
+- **Existing pattern(s) to extend**: The public website foundation from Specs 400-403 and the current shared content/layout organization inside `apps/website`.
+- **Shared contract / presenter / builder / renderer to reuse**: Existing website route and content composition; no new runtime contract is required.
+- **Why the existing shared path is sufficient or insufficient**: The current website substrate is sufficient to carry the revised narrative, but its public copy hierarchy is not yet aligned to the intended product category or claim discipline.
+- **Allowed deviation and why**: Bounded copy, metadata, navigation, and content-hierarchy updates are allowed. Broad redesign, trust-surface expansion, and provider-taxonomy expansion are deferred follow-up work.
+- **Consistency impact**: Product category language, Microsoft-first wording, provider-extensible wording, operating-model labels, trust-safe wording, and CTA intent must remain aligned across public routes.
+- **Review focus**: Reviewers must verify that no page reintroduces Intune-only framing, unsupported provider claims, unsupported compliance claims, fake proof, placeholder links, or `apps/platform` coupling.
+
+## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*
+
+N/A - no OperationRun start, completion, queue, notification, or deep-link behavior is touched.
+
+## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
+
+- **Shared provider/platform boundary touched?**: yes, at public positioning and vocabulary level only.
+- **Boundary classification**: mixed public-positioning vocabulary; no runtime provider seam changes.
+- **Seams affected**: Public category language, Microsoft-first wording, provider-extensible wording, current-versus-future provider/domain labels, and homepage capability framing.
+- **Neutral platform terms preserved or introduced**: Policy governance, cloud policy governance, managed environment, provider connection, policy evidence, drift detection, findings, exceptions, accepted risks, review packs, decision summary, audit trail, controlled recovery, and provider readiness.
+- **Provider-specific semantics retained and why**: Microsoft 365 remains the first public focus because that is the current product truth. Intune may be described only as one Microsoft 365 policy domain. Google, AWS, and other providers remain future direction only.
+- **Why this does not deepen provider coupling accidentally**: The feature changes public positioning only. It does not change provider contracts, platform-core taxonomies, provider runtime logic, or supported-integration truth.
+- **Follow-up path**: A later public provider/domain taxonomy feature can expand current-versus-planned labeling without changing this positioning baseline.
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+N/A - no operator-facing platform surface is changed. This feature changes public website content surfaces only.
+
+## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing decision surface is added or materially changed.
+
+## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing detail or status surface is added or materially changed.
+
+## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing list, detail, queue, audit, config, or report surface is added or materially changed.
+
+## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing page or workflow is added or materially refactored.
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no.
+- **New persisted entity/table/artifact?**: no.
+- **New abstraction?**: no.
+- **New enum/state/reason family?**: no.
+- **New cross-domain UI framework/taxonomy?**: no.
+- **Current operator problem**: Public evaluators, MSPs, and internal IT teams do not yet get a stable product category or governance operating model from the website.
+- **Existing structure is insufficient because**: Specs 400-403 established website foundation and launch safety, but they did not finalize a public positioning architecture for policy governance, provider posture, or safe trust language.
+- **Narrowest correct implementation**: Rework public copy, hierarchy, navigation, metadata, terminology, and claim guardrails in `apps/website` only.
+- **Ownership cost**: Future public pages and website edits must preserve the same positioning contract, provider posture, and trust-safe wording.
+- **Alternative intentionally rejected**: Broad visual redesign and detailed trust/legal expansion were rejected because they would deepen scope before the public narrative is stable.
+- **Release truth**: Current-release public positioning truth, with later follow-up work for detailed trust, provider taxonomy, and use-case expansion.
+
+### Compatibility posture
+
+This feature assumes a pre-production public website content environment.
+
+Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
+
+Canonical replacement is preferred over preservation.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: Browser/static public website validation.
+- **Validation lane(s)**: fast-feedback and public smoke.
+- **Why this classification and these lanes are sufficient**: The feature changes public content, metadata, navigation, CTA wording, and claim discipline; website build, smoke, and targeted static claim scans are the narrowest proof that the public output remains correct.
+- **New or expanded test families**: none required beyond existing website validation and targeted static content scans.
+- **Fixture / helper cost impact**: none.
+- **Heavy-family visibility / justification**: none.
+- **Special surface test profile**: N/A.
+- **Standard-native relief or required special coverage**: Homepage desktop/mobile review, public route smoke, placeholder-link scan, claim scan, and `apps/platform` untouched confirmation are sufficient.
+- **Reviewer handoff**: Reviewers must confirm product category clarity, operating-model visibility, provider-safe wording, trust-safe wording, honest navigation/CTAs, and zero `apps/platform` drift.
+- **Budget / baseline / trend impact**: none expected.
+- **Escalation needed**: none.
+- **Active feature PR close-out entry**: Smoke Coverage.
+- **Planned validation commands**: `corepack pnpm build:website`; `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `git diff --check`; `git status --short -- apps/platform`.
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Recognize The Right Product Category (Priority: P1)
+
+A first-time visitor opens the homepage and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility.
+
+**Why this priority**: If the product category is wrong, every later page and CTA inherits the wrong expectation.
+
+**Independent Test**: Read the hero and the next section on the homepage without relying on internal product knowledge.
+
+**Acceptance Scenarios**:
+
+1. **Given** a visitor opens `/`, **When** they read the hero and supporting line, **Then** they can describe Tenantial as policy governance rather than an Intune backup or helpdesk tool.
+2. **Given** a visitor reads the first screen and adjacent positioning copy, **When** they summarize the product, **Then** they mention Microsoft 365 first focus and evidence-based governance.
+3. **Given** Intune appears in the copy, **When** the visitor reads the surrounding text, **Then** Intune is understood as one policy domain rather than the full product category.
+
+---
+
+### User Story 2 - Follow The Governance Operating Model (Priority: P1)
+
+A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail.
+
+**Why this priority**: The operating model is the clearest way to explain the product without reducing it to a feature list.
+
+**Independent Test**: Read homepage section titles and core section summaries in order from top to bottom.
+
+**Acceptance Scenarios**:
+
+1. **Given** a visitor scans the homepage, **When** they reach the operating-model section, **Then** they can identify the flow from observed state to audit trail.
+2. **Given** the capability section is visible, **When** the visitor reads the cards, **Then** the story focuses on evidence, drift, reviews, controlled recovery, provider readiness, and decision traceability rather than raw feature enumeration.
+3. **Given** the visitor compares the operating-model section with the hero, **When** they continue down the page, **Then** each section adds new meaning instead of repeating the same claim.
+
+---
+
+### User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2)
+
+A security-conscious evaluator can see Microsoft 365 as the current focus, provider extensibility as future-safe direction, and clear boundaries about what the product is not.
+
+**Why this priority**: Provider posture and boundary language strongly influence trust, scope expectations, and commercial qualification.
+
+**Independent Test**: Read the homepage and the primary supporting product page without referencing implementation notes.
+
+**Acceptance Scenarios**:
+
+1. **Given** a visitor reads the Microsoft-first section, **When** they review provider/domain examples, **Then** current focus and future direction are clearly separated.
+2. **Given** the visitor reads boundary language, **When** they compare Tenantial to an admin center, helpdesk, PSA, or blind automation tool, **Then** those categories are clearly rejected.
+3. **Given** a visitor looks for Google, AWS, or other non-Microsoft provider claims, **When** they review the page, **Then** they find only architecture-direction or provider-extensible wording, not live-support claims.
+
+---
+
+### User Story 4 - Trust The Site Without False Assurance (Priority: P2)
+
+A DACH or enterprise evaluator reads the trust teaser, metadata, and CTA surfaces and sees conservative, honest claims.
+
+**Why this priority**: The website must invite evaluation without overpromising compliance, hosting, or automation.
+
+**Independent Test**: Review hero copy, trust teaser, supporting sections, metadata, navigation links, and CTAs on primary public routes.
+
+**Acceptance Scenarios**:
+
+1. **Given** no verified legal or certification proof is provided, **When** trust-related copy is reviewed, **Then** it avoids claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or zero customer data storage.
+2. **Given** public CTAs and navigation are present, **When** a visitor interacts with them, **Then** every visible link resolves to a real route or intentional page state and no `href="#"` placeholders remain.
+3. **Given** restore, remediation, and automation language appears, **When** the copy is reviewed, **Then** it speaks about controlled recovery and approval-ready follow-up rather than autonomous remediation or automatic restore.
+
+### Edge Cases
+
+- If provider-extensible wording appears near provider examples, it must not imply that Google, AWS, or other providers are live today.
+- If Intune is named in the hero, capability copy, or domain examples, it must remain one policy domain and not become the umbrella category.
+- If trust or DACH language is added, it must stop at auditability, evidence, review trail, role-based access, or evaluation readiness unless verified legal claims exist.
+- If a navigation label suggests a page that does not exist or is not ready, the route must be omitted or replaced with an intentional limited page that matches current website conventions.
+- If the site mixes German and English copy, the mix must be intentional and not look like mockup residue.
+- If supporting routes mention roadmap domains, the copy must clearly label them as planned or architecture direction.
+- If metadata compresses the message, it must still preserve policy-governance positioning and avoid Intune-only framing.
+- If previews, screenshots, or status-like content appear, they must not imply live customer/provider data unless explicitly verified.
+
+## Requirements *(mandatory)*
+
+### Assumptions
+
+- Specs 400-403 provide the current public website foundation and launch-readiness baseline.
+- `apps/website` is the only application scope for this feature.
+- The workspace contracts that matter to the website remain the root script names, website package name `@tenantatlas/website`, `WEBSITE_PORT`, and `apps/*` pnpm workspace convention.
+- No verified Google, AWS, or other non-Microsoft provider support has been supplied as current product truth.
+- No verified claim exists yet for German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or "no customer data stored" messaging.
+- Detailed DACH trust, Datenschutz, hosting, legal, and security evidence belongs to a later trust-focused feature rather than this positioning feature.
+- `apps/platform` is out of scope and must remain untouched.
+
+### Functional Requirements
+
+#### Scope And Workspace Contracts
+
+- **FR-001**: The implementation MUST remain scoped to `apps/website` and directly related website workspace-contract files only.
+- **FR-002**: The implementation MUST NOT modify `apps/platform` runtime, routes, auth, database, Filament, Livewire, or provider code.
+- **FR-003**: The implementation MUST NOT add platform API calls, shared auth/session coupling, database dependencies, or route dependencies from the public website to `apps/platform`.
+- **FR-004**: The implementation MUST preserve the root package script names, website package name `@tenantatlas/website`, `WEBSITE_PORT` convention, and `apps/*` pnpm workspace contract.
+- **FR-005**: Before execution, the implementation MUST verify current repo truth for root scripts, website scripts, and website source structure instead of assuming a fixed file layout.
+- **FR-006**: The feature MUST NOT introduce a CMS, fake placeholder pages, fake customer proof, fake certifications, or fake trust artifacts.
+
+#### Positioning Contract
+
+- **FR-007**: The public website MUST position Tenantial primarily as a Policy Governance Platform or an equivalent cloud policy governance phrasing.
+- **FR-008**: The public website MUST NOT primarily position Tenantial as an Intune backup tool, Intune management tool, Microsoft admin center replacement, helpdesk, PSA platform, compliance certification platform, or autonomous remediation platform.
+- **FR-009**: Homepage and metadata copy MUST communicate Microsoft 365 as the first product focus.
+- **FR-010**: Intune MAY appear in public copy only as one Microsoft 365 policy domain, not as the product category.
+- **FR-011**: Public copy MAY describe the product as provider-extensible by design or future-ready beyond a single admin center.
+- **FR-012**: Public copy MUST NOT present Google, AWS, or other non-Microsoft providers as live supported integrations unless verified current product truth exists.
+
+#### Provider Posture Rules
+
+- Microsoft 365 is the current public product focus.
+- Intune is one Microsoft 365 policy domain.
+- Entra or Conditional Access may be described as Microsoft 365 governance domains only when consistent with current website truth.
+- SharePoint, OneDrive sharing, enterprise apps, service principals, Google, AWS, and other providers may appear only as roadmap or architecture-direction language when they are not current product truth.
+
+#### Homepage Content Architecture
+
+- **FR-013**: The homepage MUST explain what Tenantial governs and why evidence-based governance matters.
+- **FR-014**: The homepage hero MUST communicate policy governance, Microsoft 365 first focus, and provider-extensible direction in one screen.
+- **FR-015**: The homepage MUST include a trust teaser or equivalent light trust surface that speaks about auditability, evidence history, role-based access, review trail, or DACH evaluation readiness without overclaiming legal or certification status.
+- **FR-016**: The homepage MUST include an operating-model section that covers observed state, evidence, detection, review, decision, and audit trail.
+- **FR-017**: The homepage MUST shift capability framing away from narrow Intune feature language and toward policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability.
+- **FR-018**: The homepage MUST include a Microsoft 365 first section or equivalent explanation that is concrete without collapsing the product into Intune-only positioning.
+- **FR-019**: The homepage MUST include concise audience messaging for MSPs and internal IT teams or an equivalent audience split that matches public commercial intent.
+- **FR-020**: The homepage MUST include clear boundary language that Tenantial is a governance and evidence layer, not an admin-center clone, not blind automation, and not a helpdesk or PSA replacement.
+- **FR-021**: The homepage MUST end with concrete CTA language tied to real destinations or deliberate in-page navigation.
+
+#### Supporting Route And Navigation Requirements
+
+- **FR-022**: Supporting public routes such as `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs navigation MUST reinforce the same positioning contract as the homepage.
+- **FR-023**: If public navigation labels are adjusted, they MUST use honest labels such as `Platform`, `Use Cases`, `Trust`, `Docs`, `Pricing`, and `Contact`, or equivalent labels that match available route truth.
+- **FR-024**: Navigation and CTA surfaces MUST NOT contain `href="#"` placeholders or production-looking links to content that does not exist.
+- **FR-025**: If a route does not exist or lacks real content, it MUST be omitted from navigation or represented with an intentionally limited page consistent with current website conventions.
+- **FR-026**: `/platform` or the primary supporting product route MUST explain the governance model more deeply than the homepage while remaining clearly public and non-runtime-coupled.
+
+#### Metadata And Terminology
+
+- **FR-027**: Homepage metadata MUST position Tenantial as policy governance for Microsoft 365 and avoid Intune-only framing.
+- **FR-028**: Public metadata and visible copy MUST stay aligned on policy governance, evidence, review, decision, and auditability rather than raw feature lists.
+- **FR-029**: Preferred public terminology MUST emphasize policy governance, managed environments, provider connections, policy evidence, drift detection, findings, exceptions, accepted risks, decision summaries, audit trail, controlled recovery, and provider readiness or equivalent governance language.
+- **FR-030**: Restore terminology MUST prefer controlled recovery, restore readiness, or recovery planning over blind rollback or guaranteed restore language.
+- **FR-031**: Public copy MUST remain consistent in route language and avoid accidental English/German mockup residue.
+
+#### Claim Guardrails
+
+- **FR-032**: Public copy MUST NOT claim Google support, AWS support, multi-cloud support today, provider-agnostic execution today, or provider-agnostic restore unless verified.
+- **FR-033**: Public copy MUST NOT claim DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, German hosting, Microsoft endorsement, or "no customer data stored" unless verified.
+- **FR-034**: Public copy MUST NOT claim autonomous remediation, automatic restore, self-healing, or approval-free automation.
+- **FR-035**: Public copy MUST NOT include fake customer logos, fake testimonials, fake compliance badges, lorem ipsum, neutral-SaaS residue, or other placeholder artifacts in emitted public output.
+- **FR-036**: If roadmap or architecture-direction language is used, it MUST be clearly separated from currently available product focus.
+
+#### Validation And Reporting
+
+- **FR-037**: The implementation MUST use only scripts that actually exist in the workspace root or `apps/website/package.json`.
+- **FR-038**: Validation MUST include a website build check using the existing workspace scripts.
+- **FR-039**: Validation MUST include a website smoke or browser check if local preview/test support exists.
+- **FR-040**: Validation MUST include a static scan for placeholder links and forbidden public claims in website source and committed public output when applicable.
+- **FR-041**: Completion reporting MUST document changed public surfaces, commands run, pass/fail results, deferred follow-up work, and confirmation that `apps/platform` remained untouched.
+
+## Success Criteria *(mandatory)*
+
+- **SC-001**: A reviewer can describe Tenantial from the homepage hero and next section as a policy governance platform for Microsoft 365 without calling it an Intune-only or backup-only tool.
+- **SC-002**: Homepage copy presents a clear six-step governance narrative from observed state to audit trail that a reviewer can list in order from the rendered page.
+- **SC-003**: Intune appears only as one example domain in homepage/supporting copy and does not appear as the primary product category in visible headings or metadata.
+- **SC-004**: Provider-extensible language appears without any unverified live-support claim for Google, AWS, or other non-Microsoft providers.
+- **SC-005**: Trust-related public copy contains zero unverified claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, certifications, or autonomous remediation/recovery.
+- **SC-006**: Navigation and CTA surfaces contain zero placeholder destinations, and every visible CTA leads to a concrete next step or real route.
+- **SC-007**: MSP/internal IT/governance-evaluator messaging is visible on the public site without reducing the target audience to endpoint administrators alone.
+- **SC-008**: Homepage metadata and primary supporting routes consistently reinforce policy-governance positioning, Microsoft 365 first focus, and evidence/review language.
+- **SC-009**: No `apps/platform` files are modified as part of the feature.
+- **SC-010**: Public website validation completes successfully, or any failure is explicitly documented as pre-existing.

specs/404-public-content-messaging/tasks.md

@@ -0,0 +1,184 @@
+# Tasks: Public Website Positioning & Content Architecture
+
+**Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/`
+**Prerequisites**: [plan.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md), [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md), [research.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md), [data-model.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md), [public-content-contract.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md), [quickstart.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md)
+
+**Tests**: This feature remains in the browser/static website lane. Reuse the existing Astro build, Playwright public smoke suite, targeted static claim scans, and manual browser review under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`. Do not add Pest, Laravel, Filament, Livewire, database, Sail, Microsoft Graph, queue, job, policy, RBAC, or `apps/platform` coverage.
+
+## Phase 1: Setup
+
+**Purpose**: Establish the exact website-only scope and current public-content baseline before editing.
+
+- [x] T001 Confirm repo-truth inputs by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/package.json`, `/Users/ahmeddarrazi/Documents/projects/wt-website/pnpm-workspace.yaml`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/package.json`
+- [x] T002 [P] Inventory homepage and platform content sources in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro`
+- [x] T003 [P] Inventory navigation, footer, metadata, and localization surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en`
+- [x] T004 [P] Inventory docs, placeholder collections, and supporting route content in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/blog`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/insights`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/products`
+- [x] T005 [P] Inventory current smoke coverage and forbidden-pattern guards in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts`
+
+---
+
+## Phase 2: Foundational
+
+**Purpose**: Normalize shared positioning, metadata, and validation rules before user-story work.
+
+**Critical**: Complete this phase before user-story implementation.
+
+- [x] T006 Define the shared policy-governance vocabulary, Microsoft 365 first phrasing, provider-extensible guardrails, and CTA intent rules in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T007 Normalize shared site title, base description, and route-level metadata defaults in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`
+- [x] T008 Review and correct stale localized navigation helpers or route-link utilities in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/i18n.ts`
+- [x] T009 Refresh forbidden-pattern coverage and public-route expectations for policy-governance, provider, and trust guardrails in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`
+- [x] T010 Confirm the foundational scope still excludes `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform` by checking from `/Users/ahmeddarrazi/Documents/projects/wt-website`
+
+**Checkpoint**: Shared positioning rules, metadata defaults, and smoke guardrails are ready for independently testable story work.
+
+---
+
+## Phase 3: User Story 1 - Recognize The Right Product Category (Priority: P1) MVP
+
+**Goal**: A first-time visitor opens `/` and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility.
+
+**Independent Test**: Read the hero and the next homepage section without relying on internal product knowledge; the product is clearly described as policy governance with Microsoft 365 as the first focus.
+
+- [x] T011 [US1] Rewrite homepage hero headline, body, supporting line, and primary/secondary CTA copy in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T012 [US1] Update homepage category-proof and first supporting-section copy so Microsoft 365 first and evidence-based governance are explicit in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T013 [US1] Add explicit audience messaging for MSPs and internal IT teams in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+- [x] T014 [US1] Add a concrete end-of-homepage CTA with a real route or deliberate in-page target in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+- [x] T015 [US1] Adapt homepage rendering to the new category, audience, and CTA copy without widening layout scope in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+- [x] T016 [P] [US1] Align supporting highlights and FAQ prompts with the new product category in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json`
+- [x] T017 [US1] Validate User Story 1 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` using the rendered homepage routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/index.astro` to confirm category framing, audience messaging, and terminal CTA intent
+
+**Checkpoint**: User Story 1 is independently shippable as the MVP.
+
+---
+
+## Phase 4: User Story 2 - Follow The Governance Operating Model (Priority: P1)
+
+**Goal**: A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail.
+
+**Independent Test**: Read homepage section titles and core summaries in order from top to bottom; the operating-model flow is clear and each section adds new meaning.
+
+- [x] T018 [US2] Rewrite the homepage operating-model sequence and section summaries around observe, evidence, detect, review, decide, and audit in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T019 [US2] Update homepage section ordering and block composition for the new operating-model narrative in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+- [x] T020 [P] [US2] Refresh homepage capability cards for policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json`
+- [x] T021 [P] [US2] Update the docs landing and intro narrative to reflect the same governance model in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/welcome-to-docs.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/welcome-to-docs.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/intro.mdx`
+- [x] T022 [US2] Validate User Story 2 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing the operating-model and capability sections in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+
+**Checkpoint**: User Story 2 is independently shippable once the homepage operating model reads coherently.
+
+---
+
+## Phase 5: User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2)
+
+**Goal**: A security-conscious evaluator can see Microsoft 365 as the current focus, provider-extensible direction as future-safe, and clear boundaries about what the product is not.
+
+**Independent Test**: Read the homepage and `/platform`; current Microsoft focus, future provider direction, and non-admin-center/non-helpdesk boundaries are all explicit without live-support claims for other providers.
+
+- [x] T023 [US3] Rewrite the Microsoft 365 first section and provider/domain labeling rules in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T024 [US3] Update `/platform` copy to separate current Microsoft focus from future provider direction and to reinforce product boundaries in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T025 [P] [US3] Align public docs provider-boundary explanations with the same current-versus-future posture in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/intro.mdx`
+- [x] T026 [P] [US3] Review navigation and footer labels so route exposure stays honest for platform, docs, trust, pricing, and contact surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`
+- [x] T027 [US3] Validate User Story 3 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro`
+
+**Checkpoint**: User Story 3 is independently shippable once provider posture and boundaries are clear and safe.
+
+---
+
+## Phase 6: User Story 4 - Trust The Site Without False Assurance (Priority: P2)
+
+**Goal**: A DACH or enterprise evaluator reads the trust teaser, metadata, navigation, and CTA surfaces and sees conservative, honest claims.
+
+**Independent Test**: Review `/trust`, `/pricing`, `/contact`, homepage trust surfaces, and metadata; there are no false assurance, placeholder-link, or autonomous-remediation claims.
+
+- [x] T028 [US4] Rewrite the trust teaser, trust page copy, and trust-adjacent CTA language for conservative claims in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [x] T029 [US4] Update homepage, platform, pricing, and trust metadata to remove false assurance and preserve policy-governance wording in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts`
+- [x] T030 [P] [US4] Review conservative trust, contact-led evaluation, and legal-adjacent rendering in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/ContactPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/LegalPage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TextPage.astro`
+- [x] T031 [P] [US4] Update docs and checklist content to avoid false provider/compliance/automation assurance in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/first-project-checklist.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/getting-started.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/first-project-checklist.mdx`
+- [x] T032 [US4] Update smoke and interaction expectations for trust-safe links, metadata, and placeholder-free CTAs in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts`
+- [x] T033 [US4] Validate User Story 4 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` and `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/trust.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/pricing.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/contact.astro`
+
+**Checkpoint**: User Story 4 is independently shippable once trust-sensitive surfaces remain honest and placeholder-free.
+
+---
+
+## Final Phase: Polish And Cross-Cutting Concerns
+
+**Purpose**: Complete localization parity, route exposure review, browser/static validation, and implementation handoff.
+
+- [x] T034 [P] Review German default and English mirror parity for all changed marketing routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en`
+- [x] T035 [P] Reconcile exposed docs/navigation and redirect behavior with the updated positioning contract in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/product.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/products/index.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/product.astro`
+- [x] T036 [P] Review dominant next-step CTA intent across the homepage, platform, pricing, trust, contact, footer, and exposed docs routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`
+- [x] T037 [P] Run the targeted static claim scan from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` against `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public`
+- [x] T038 Run website build validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `corepack pnpm build:website`
+- [x] T039 Run public smoke validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`
+- [x] T040 Run whitespace validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git diff --check`
+- [x] T041 Run scope validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git status --short -- apps/platform`
+- [x] T042 Perform the manual desktop/mobile browser review described in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` for `/`, `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs routes
+- [x] T043 Prepare the final implementation handoff with changed surfaces, provider/trust guardrail decisions, validation results, follow-up specs, and `apps/platform` untouched confirmation from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md`
+
+---
+
+## Dependencies
+
+**Phase Dependencies**
+
+Setup must complete before Foundational. Foundational must complete before any user story. User Stories 1 and 2 are the P1 path and should land before provider/trust refinement. User Story 3 depends on the shared category and operating-model vocabulary from earlier phases. User Story 4 depends on the shared provider, CTA, metadata, and navigation decisions so trust-safe wording does not drift from the rest of the site.
+
+**User Story Dependencies**
+
+- **US1**: Depends on Phase 2 only.
+- **US2**: Depends on Phase 2 and benefits from US1 category vocabulary.
+- **US3**: Depends on Phase 2 and benefits from US1-US2 shared narrative.
+- **US4**: Depends on Phase 2 and benefits from US1-US3 provider, metadata, and navigation decisions.
+
+**MVP Scope**
+
+Complete Phase 1, Phase 2, and Phase 3 (US1) for the smallest independently reviewable increment. Phase 4 (US2) is the immediate next increment once the product category is fixed.
+
+---
+
+## Parallel Execution Examples
+
+**After Phase 2**
+
+```text
+US1 supporting-surface work can run in parallel after the main homepage copy settles:
+- T015 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro
+- T016 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json
+
+US2 operating-model support work can run in parallel once the sequence is defined:
+- T020 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json
+- T021 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/welcome-to-docs.mdx and related intro mirrors
+```
+
+**Provider And Trust**
+
+```text
+US3 and US4 can progress on different files once shared vocabulary is stable:
+- T025 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx and related mirrors
+- T030 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro, PricingPage.astro, ContactPage.astro, LegalPage.astro, and TextPage.astro
+- T031 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx and related checklist mirrors
+```
+
+**Final Validation**
+
+```text
+Cross-cutting closeout can run in parallel before the final command sequence:
+- T034 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en
+- T035 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs and redirect route files
+- T036 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro, and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs
+- T037 from /Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md against /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public
+```
+
+---
+
+## Implementation Strategy
+
+1. Finish setup and foundational vocabulary/metadata/smoke guardrails before page-level rewrites.
+2. Ship the MVP by fixing homepage category framing in US1.
+3. Layer the operating-model narrative in US2 before broadening provider posture in US3.
+4. Complete trust-safe metadata, docs, and CTA coverage in US4 after the shared category and provider story settle.
+5. Finish with localization parity, route-exposure review, static claim scans, build, smoke, manual browser review, and scope validation.
+
+## Test Governance Notes
+
+The declared test purpose is Browser/static website. The affected validation lanes are website build, Playwright public smoke, targeted static claim scans, manual browser review, whitespace validation, and `apps/platform` scope validation. No Pest, Laravel, Filament, Livewire, database, provider, workspace, membership, session, queue, Sail, or heavy-governance setup is introduced. No dedicated follow-up spec is needed unless repeated public-website release validation becomes a recurring governance problem.