feat(website): tighten homepage messaging and trust flow (#398)

## Summary
- tighten homepage messaging, hero support copy, trust teaser flow, and CTA routing for the website public-content rollout
- align shared website copy, smoke expectations, and spec 404 artifacts with the latest messaging pass
- replace the previously closed PR for `404-public-content-messaging`

## Commits
- `44d27395` feat(website): tighten homepage messaging and trust flow
- `1ddbd28b` feat(website): refine public content messaging rollout

## Validation
- `git diff --check`

## Notes
- local Playwright MCP output remains untracked and was not included

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #398

.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

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

@@ -2,18 +2,12 @@
 import MainLayout from '@/layouts/MainLayout.astro';
 import HeroSection from '@components/sections/landing/HeroSection.astro';
 import FeaturesGeneral from '@components/sections/features/FeaturesGeneral.astro';
-import FeaturesNavs from '@components/sections/features/FeaturesNavs.astro';
+import PrimaryCTA from '@components/ui/buttons/PrimaryCTA.astro';
-import PricingSection from '@components/sections/pricing/PricingSection.astro';
+import SecondaryCTA from '@components/ui/buttons/SecondaryCTA.astro';
-import FAQ from '@components/sections/misc/FAQ.astro';
 import heroImage from '@images/tenantial-dashboard.avif';
 import featureImage from '@images/tenantial-review-board.avif';
-import reviewImage from '@images/tenantial-evidence-intake.avif';
-import evidenceImage from '@images/tenantial-decision-review.avif';
-import governanceImage from '@images/tenantial-restore-plan.avif';
 import {
-  faqsByLocale,
   featuresByLocale,
-  pricingByLocale,
   siteCopy,
 } from '@data/site-copy';
 import { localizeHref, type Locale } from '@/i18n';
@@ -25,10 +19,6 @@ interface Props {
 }
 
 const copy = siteCopy[locale].home;
-const tabs = copy.tabs.map((tab: any, index: number) => ({
-  ...tab,
-  src: [reviewImage, evidenceImage, governanceImage][index],
-}));
 ---
 
 <MainLayout
@@ -45,6 +35,7 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({
     secondaryBtn={copy.secondaryCta}
     secondaryBtnURL={localizeHref('/platform', locale)}
     withReview={false}
+    supportingLine={copy.supportingLine}
     src={heroImage}
     alt={copy.heroAlt}
   />
@@ -57,9 +48,104 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({
     features={featuresByLocale[locale]}
   />
 
-  <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>
 
-  <PricingSection pricing={pricingByLocale[locale]} locale={locale} />
+    <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>
 
-  <FAQ title={copy.faqTitle} faqs={faqsByLocale[locale]} />
+  <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>
+
+  <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="grid gap-8 border-y border-neutral-300 py-10 lg:grid-cols-[minmax(0,0.9fr)_minmax(0,1.1fr)] lg:items-center lg:py-14 dark:border-neutral-700">
+      <div>
+        <h2 class="text-2xl font-bold text-balance text-neutral-800 md:text-3xl dark:text-neutral-200">
+          {copy.trustTeaserTitle}
+        </h2>
+        <p class="mt-3 max-w-prose text-pretty text-neutral-600 md:text-lg dark:text-neutral-400">
+          {copy.trustTeaserSubtitle}
+        </p>
+      </div>
+
+      <ul class="grid gap-3">
+        {
+          copy.trustPoints.map((point: string) => (
+            <li class="rounded-2xl border border-neutral-300 bg-neutral-100/70 px-5 py-4 text-sm font-medium text-neutral-700 dark:border-neutral-700 dark:bg-white/[0.04] dark:text-neutral-300">
+              {point}
+            </li>
+          ))
+        }
+      </ul>
+    </div>
+  </section>
+
+  <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('/platform', 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/landing/HeroSection.astro

@@ -9,6 +9,7 @@ import ReviewComponent from '@components/ui/blocks/ReviewComponent.astro';
 const {
   title,
   subTitle,
+  supportingLine,
   primaryBtn,
   primaryBtnURL,
   secondaryBtn,
@@ -25,6 +26,7 @@ const {
 interface Props {
   title: string;
   subTitle?: string;
+  supportingLine?: string;
   primaryBtn?: string;
   primaryBtnURL?: string;
   secondaryBtn?: string;
@@ -62,6 +64,13 @@ interface Props {
         </p>
       )
     }
+    {
+      supportingLine && (
+        <p class="mt-4 max-w-2xl text-sm font-semibold leading-6 text-neutral-800 dark:text-neutral-300">
+          {supportingLine}
+        </p>
+      )
+    }
     {
       /* Action Button Section: This section includes two CTAs with their own styles and URL */
     }

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">
+<div class="min-w-0 lg:pe-6 xl:pe-12">
-  <p class="text-6xl leading-10 font-bold text-orange-400 dark:text-orange-300">
+  <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>
+<div class="min-w-0">
-  <p class="text-3xl font-bold text-orange-400 dark:text-orange-300">{title}</p>
+  <p class="text-3xl font-bold break-words text-balance text-orange-400 dark:text-orange-300">
-  <p class="mt-1 text-neutral-600 dark:text-neutral-400">{subTitle}</p>
+    {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">
+  <span class="flex items-start gap-5">
-    <slot />
+    <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/content/docs/en/guides/first-project-checklist.mdx

@@ -9,8 +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

@@ -11,9 +11,11 @@ Start with a scoped conversation about the tenant governance problem you want to
 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 evidence-first Microsoft tenant governance. Public materials explain how observed inventory, immutable policy snapshots, drift review, findings, exceptions, auditability, and defensive restore planning fit together as one reviewable product model.
+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 observed state and policy evidence are collected and normalized for review.
-- How snapshots support comparison and restore planning.
+- How drift, findings, and review work lead into a traceable decision.
-- How drift, findings, and exceptions make decisions attributable.
+- How Microsoft 365 as the current focus is separated from provider-extensible future direction.
-- How restore is treated as preview-first work with validation, selective scope, and explicit confirmation.
+- 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. This note describes static product concepts and no live tenant connection.
+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.
+- Observed state is the starting point for review work.
-- Snapshots are explicit records for comparison and planning.
+- Policy evidence and snapshots become explicit records for comparison and planning.
-- Drift and findings become review work.
+- Drift and findings turn into visible review work instead of background diagnostics.
-- Exceptions and audit notes keep decisions attributable.
+- Decisions, exceptions, and accepted risk stay attributable through audit trail.
-- Restore is planned through preview, validation, selective scope, and explicit confirmation without promising recovery success.
+- 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, findings, auditability, 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">
+  <Card title="Operating model" icon="document">
-    Understand the public product model before planning a rollout conversation.
+    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">
+  <Card title="Provider and trust boundaries" icon="seti:terraform">
-    Review how Tenantial frames inventory evidence, snapshots, drift, findings, exceptions, reviews, and restore planning.
+    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,8 +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

@@ -11,9 +11,11 @@ Starte mit einem scoped Gespräch über das Tenant-Governance-Problem, das gelö
 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 evidence-first Microsoft-Tenant-Governance ausgerichtet. Öffentliche Materialien erklären, wie beobachtetes Inventory, unveränderliche Policy-Snapshots, Drift Review, Findings, Exceptions, Auditability und defensive Restore-Planung als ein prüfbares Produktmodell zusammenhängen.
+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 beobachteter Zustand und Policy-Evidence für Reviews gesammelt und normalisiert werden.
-- Wie Snapshots Vergleich und Restore-Planung unterstützen.
+- Wie Drift, Findings und Review-Arbeit zu einer nachvollziehbaren Entscheidung führen.
-- Wie Drift, Findings und Exceptions Entscheidungen zuordenbar machen.
+- Wie Microsoft 365 als aktueller Fokus von provider-extensibler Zukunftsrichtung getrennt wird.
-- Wie Restore als preview-first Arbeit mit Validierung, selektivem Scope und expliziter Bestätigung behandelt 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. Die Notiz beschreibt statische Produktkonzepte und keine Live-Tenant-Verbindung.
+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.
+- Beobachteter Zustand ist der Ausgangspunkt für Review-Arbeit.
-- Snapshots sind explizite Records für Vergleich und Planung.
+- Policy-Evidence und Snapshots werden als explizite Records für Vergleich und Planung festgehalten.
-- Drift und Findings werden zu Review-Arbeit.
+- Drift und Findings werden zu sichtbarer Review-Arbeit statt zu stiller Hintergrunddiagnose.
-- Exceptions und Audit-Notizen halten Entscheidungen zuordenbar.
+- Entscheidungen, Ausnahmen und akzeptierte Risiken bleiben über Audit Trail nachvollziehbar.
-- Restore wird über Preview, Validierung, selektiven Scope und explizite Bestätigung geplant, ohne Recovery-Erfolg zu versprechen.
+- 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, Findings, Auditability 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">
+  <Card title="Operating Model" icon="document">
-    Verstehe das öffentliche Produktmodell, bevor ein Rollout-Gespräch geplant wird.
+    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">
+  <Card title="Provider- und Trust-Grenzen" icon="seti:terraform">
-    Prüfe, wie Tenantial Inventory Evidence, Snapshots, Drift, Findings, Exceptions, Reviews und Restore-Planung rahmt.
+    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: 'Microsoft 365 Policies unter Kontrolle bringen',
   description:
-    'Tenantial hilft Microsoft-Tenant-Teams, Policy-Evidence, Snapshots, Drift, Findings, Exceptions, Auditability und Restore-Pläne in prüfbare Entscheidungen zu übersetzen.',
+    'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.',
   description_short:
-    'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Review, Backup, Drift, Findings und Restore-Planung.',
+    'Microsoft 365 Governance mit Policy-Drift, versionierten Backups, Evidence, Reviews und kontrollierter Recovery-Vorbereitung.',
   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}: Microsoft 365 Policies unter Kontrolle bringen`,
   description:
-    'Prüfe Tenant Inventory, Snapshots, Drift, Findings, Evidence, Exceptions und Restore-Pläne mit konservativen, auditfreundlichen Workflows.',
+    'Policy-Drift früh erkennen, Konfigurationsstände versioniert sichern und auditfähige Evidence für Reviews, Changes und kontrollierte Recovery vorbereiten.',
   image: ogImageSrc,
 };
 

apps/website/src/data_files/faqs.json

@@ -3,19 +3,19 @@
   "faqs": [
     {
       "question": "What does Tenantial help teams understand?",
-      "answer": "Tenantial explains backup evidence, restore planning, drift detection, findings, evidence, auditability, exceptions, and reviews as one governance model 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?",
+      "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, without promising recovery success."
+      "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."
-    },
-    {
-      "question": "Does Tenantial publish customer evidence here?",
-      "answer": "No customer logos, third-party endorsements, external assurance statements, service-level commitments, or recovery promises are published without supplied and reviewed evidence."
     }
   ]
 }

apps/website/src/data_files/features.json

@@ -1,22 +1,32 @@
 [
   {
-    "heading": "Backup evidence",
+    "heading": "Policy evidence",
-    "content": "Review observed policy metadata and backup snapshots from one readable source before governance decisions start.",
+    "content": "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 rather than automatic recovery promises.",
+    "content": "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 whether anything should change.",
+    "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",
+    "heading": "Controlled recovery",
-    "content": "Keep exceptions, review notes, and auditability visible so decisions stay attributable and conservative.",
+    "content": "Plan restore and recovery defensively with preview, validation, selective scope, and explicit confirmation instead of automation promises.",
-    "svg": "checkCircle"
+    "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/site-copy.ts

@@ -35,11 +35,11 @@ type FaqGroup = {
 export const siteCopy: Record<Locale, any> = {
   de: {
     site: {
-      tagline: 'Evidenzbasierte Microsoft-Tenant-Governance',
+      tagline: 'Microsoft 365 Policies unter Kontrolle bringen',
       description:
-        'Tenantial hilft Microsoft-Tenant-Teams, Policy-Evidence, Snapshots, Drift, Findings, Exceptions, Auditability und Restore-Pläne in prüfbare Entscheidungen zu übersetzen.',
+        'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.',
       descriptionShort:
-        'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Reviews, Backup, Drift, Findings und Restore-Planung.',
+        'Microsoft 365 Governance mit Policy-Drift, versionierten Backups, Evidence, Reviews und kontrollierter Recovery-Vorbereitung.',
     },
     nav: [
       { name: 'Start', url: '/' },
@@ -80,98 +80,142 @@ export const siteCopy: Record<Locale, any> = {
       walkthrough: 'Walkthrough anfragen',
     },
     home: {
-      pageTitle: 'Tenantial | Evidenzbasierte Microsoft-Tenant-Governance',
+      pageTitle: 'Tenantial | Microsoft 365 Policies unter Kontrolle bringen',
       metaDescription:
-        'Tenantial ist evidenzbasierte Governance für Microsoft-Tenant-Konfiguration mit Backup, Restore, Drift Detection, Findings, Evidence, Auditability, Exceptions und Reviews.',
+        'Policy-Drift früh erkennen, Konfigurationsstände versioniert sichern und auditfähige Evidence für Reviews, Changes und kontrollierte Recovery vorbereiten.',
       heroTitle:
-        'Evidenzbasierte Governance für <span class="text-yellow-500 dark:text-yellow-400">Microsoft-Tenant-Konfiguration</span>',
+        '<span class="text-yellow-500 dark:text-yellow-400">Microsoft 365 Policies</span> unter Kontrolle bringen.',
       heroSubtitle:
-        'Tenantial macht Backup, Restore, Drift Detection, Findings, Evidence, Exceptions, Auditability und Reviews zu einem prüfbaren Governance-Modell, bevor kritische Änderungen entschieden werden.',
+        'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.',
-      primaryCta: 'Walkthrough anfragen',
+      supportingLine:
-      secondaryCta: 'Produktmodell ansehen',
+        'Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen.',
+      primaryCta: 'Demo buchen',
+      secondaryCta: 'Plattform ansehen',
       heroAlt: 'Statische Tenantial Governance-Dashboard-Vorschau',
-      featureTitle: 'Vom beobachteten Zustand zur Review-Entscheidung',
+      featureTitle:
+        'Wenn Microsoft 365 Policies driften, reicht ein Admin Center nicht aus.',
       featureSubtitle:
-        'Tenantial hält Backup-Snapshots, Findings, Evidence, Auditability, Exceptions und Reviews als statischen Produktkontext sichtbar, damit Restore-Entscheidungen preview-first, nachvollziehbar und nicht als blinde Automation erscheinen.',
+        'Tenantial zeigt, was sich geändert hat, welche Konfigurationen abgesichert sind, welche Evidence vorliegt und welche Findings vor dem nächsten Review geklärt werden müssen.',
       featureAlt: 'Statische Tenantial Review-Board-Vorschau',
-      workflowTitle:
+      audienceTitle: 'Eine belastbare Wahrheit für MSPs, IT und Audit.',
-        'Vom <span class="text-yellow-500 dark:text-yellow-400">Snapshot</span> zur Review-Entscheidung.',
+      audienceSubtitle:
-      tabs: [
+        'Tenantial verbindet technische Konfigurationsdaten mit Evidence, Findings und Reviews - damit Operatoren, Security-Verantwortliche und Auditoren nicht aus Screenshots, Excel-Listen oder Bauchgefühl entscheiden.',
+      audiences: [
         {
-          heading: 'Evidence erfassen',
+          title: 'MSP Operatoren',
           content:
-            'Normalisiere Inventory-, Backup- und Snapshot-Kontext, damit Reviews mit einer lesbaren Sicht auf den beobachteten Policy-Zustand starten.',
+            'Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.',
-          svg: 'frame',
-          alt: 'Statische Tenantial Evidence-Intake-Vorschau',
-          first: true,
         },
         {
-          heading: 'Findings prüfen',
+          title: 'Enterprise IT',
           content:
-            'Mache Drift Detection, Findings, Exceptions, Auditability und Review-Notizen sichtbar, bevor Administratoren die nächste Aktion wählen.',
+            'Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren.',
-          svg: 'dashboard',
-          alt: 'Statische Tenantial Decision-Review-Vorschau',
-          second: true,
         },
         {
-          heading: 'Restore-Planung',
+          title: 'Security & Audit',
           content:
-            'Behandle Restore als preview-first Arbeit mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung.',
+            'Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen.',
-          svg: 'verified',
-          alt: 'Statische Tenantial Restore-Planungs-Vorschau',
         },
       ],
+      boundaryTitle: 'Gebaut für Governance. Nicht für blinde Automatisierung.',
+      boundarySubtitle:
+        'Tenantial ersetzt nicht das Microsoft Admin Center. Es ergänzt es um die Schicht, die Enterprise-Teams im Alltag fehlt: Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen.',
+      boundaries: [
+        {
+          title: 'Versionierung statt Momentaufnahme',
+          content:
+            'Policy-Zustände bleiben historisch vergleichbar, damit Changes und Review-Fragen nicht aus Screenshots rekonstruiert werden müssen.',
+        },
+        {
+          title: 'Evidence statt Bauchgefühl',
+          content:
+            'Findings, Accepted Risks und Review Packs bringen Security, IT und Audit auf dieselbe belastbare Datenbasis.',
+        },
+        {
+          title: 'Recovery vor Ausführung bewerten',
+          content:
+            'Restore- und Recovery-Fragen werden mit Scope, Risiko und Evidence bewertet, bevor Änderungen ausgeführt werden.',
+        },
+      ],
+      trustTeaserTitle: 'Evidence, Findings und Review Packs für nachvollziehbare Entscheidungen.',
+      trustTeaserSubtitle:
+        'Tenantial bündelt Policy-Zustände, Findings, Accepted Risks und Follow-ups zu Review Packs, die Kundentermine, interne Audits und Recovery-Entscheidungen mit belastbarem Kontext vorbereiten.',
+      trustPoints: [
+        'Nachvollziehbarer Audit Trail für Changes und Accepted Risks',
+        'Review Packs für Kundentermine und interne Audits',
+        'Rollenbewusster Governance-Kontext für Operatoren, Security und Audit',
+      ],
+      finalCtaTitle: 'Bereit, Microsoft 365 Governance messbar zu machen?',
+      finalCtaSubtitle:
+        'Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt.',
+      finalPrimaryCta: 'Demo buchen',
+      finalSecondaryCta: 'Plattform 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.',
+        'Tenantial erklärt Policy Governance für Microsoft 365 mit beobachtetem Zustand, Evidence, Drift Detection, Governance Reviews, Audit Trail und kontrollierter Recovery-Planung.',
-      heading: 'Öffentliches Produktmodell',
+      heading: 'Policy-Governance-Modell für Microsoft 365',
       subtitle:
-        'Tenantial beschreibt ein Governance-of-record-Modell für Microsoft-Tenant-Konfiguration: Backup-Evidence, unveränderliche Policy-Snapshots, strukturierte Diffs, Drift Detection, Findings, Exceptions, Auditability, Governance-Reviews und vorsichtige Restore-Planung.',
+        'Tenantial ergänzt Microsoft Admin Center um Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen. Microsoft 365 ist der erste Markt; weitere Policy-Domänen bleiben klar als vorbereitete Richtung eingeordnet.',
-      backupTitle: 'Backup- und Snapshot-Evidence',
+      focusTitle: 'Heutiger Fokus und künftige Richtung',
+      focusSubtitle:
+        'Die öffentliche Produktstory trennt bewusst zwischen aktuellem Microsoft-365-Fokus und vorbereiteten weiteren Policy-Domänen.',
+      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: weitere Policy-Domänen',
+          content:
+            'Weitere Policy-Domänen 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 und 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-Grenzen ansehen',
-      restoreTitle: 'Restore-Planung bleibt defensiv',
+      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: 'Microsoft 365', description: 'heutiger Fokus' },
-        { stat: 'Preview', description: 'vor Restore-Ausführung' },
+        { stat: 'Weitere Domänen', description: 'klar als Richtung markiert' },
-        { stat: 'Review', description: 'vor kritischen Änderungen' },
+        { 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.',
+        'Tenantial Preise rahmen Policy-Governance-Evaluierung, Rollout-Planung und Trust-Review konservativ statt Sofortkauf oder Access-Claims.',
       heading: 'Evaluation bleibt kontaktgeführt',
       subtitle:
-        'Tenantial beschreibt hier Evaluierungs- und Rollout-Pfade. Die öffentliche Website behauptet 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 +243,19 @@ export const siteCopy: Record<Locale, any> = {
     trust: {
       pageTitle: 'Vertrauen | Tenantial',
       metaDescription:
-        'Tenantial öffentliche Vertrauensposition mit konservativen Claims und klaren Grenzen für statische Produktvorschauen.',
+        'Tenantial Trust-Haltung für Microsoft-365-Policy-Governance mit auditfähiger Evidence, klaren Grenzen, nachvollziehbaren Reviews und kontrollierter Recovery-Vorbereitung.',
-      heading: 'Vertrauen beginnt mit klaren Grenzen',
+      heading: 'Vertrauen beginnt mit nachprüfbaren Grenzen',
       subtitle:
-        'Tenantial vermeidet Kundenlogo-Belege, externe Endorsements, externe Assurance-Aussagen, Service-Level-Zusagen und Recovery-Versprechen, solange sie nicht geliefert und geprüft wurden.',
+        'Tenantial macht sichtbar, welche Evidence vorliegt, welche Findings geklärt sind, welche Risiken akzeptiert wurden und welche Recovery-Fragen vor einer Änderung bewertet werden müssen.',
       cta: 'Tenantial kontaktieren',
-      statsTitle: 'Öffentliche Website-Grenzen',
+      statsTitle: 'Trust für prüfbare Reviews',
       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.',
+        'Review Packs, Audit Trail und klare Zuständigkeiten helfen MSPs, Enterprise IT und Security-Teams, Entscheidungen auf belastbarem Kontext statt auf Momentaufnahmen zu treffen.',
-      mainStatTitle: 'Statisch',
+      mainStatTitle: 'Review-first',
-      mainStatSubTitle: 'nur Produkt-Previews',
+      mainStatSubTitle: 'Evidence, Findings und Entscheidungen bleiben nachvollziehbar',
       stats: [
-        { stat: 'Keine', description: 'Kundenlogo-Belege' },
+        { stat: 'Keine', description: 'Compliance-Zusagen ohne Nachweis' },
-        { stat: 'Keine', description: 'externen Endorsements' },
+        { stat: 'Keine', description: 'Kundenlogo- oder Endorsement-Claims' },
         { stat: 'Keine', description: 'Live-Tenant-Verbindung' },
       ],
     },
@@ -251,11 +295,11 @@ export const siteCopy: Record<Locale, any> = {
   },
   en: {
     site: {
-      tagline: 'Evidence-first Microsoft tenant governance',
+      tagline: 'Bring Microsoft 365 policies under control',
       description:
-        'Tenantial helps Microsoft tenant teams turn policy evidence, snapshots, drift, findings, exceptions, auditability, and restore plans into reviewable decisions.',
+        'Tenantial helps MSPs and enterprise IT teams detect policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.',
       descriptionShort:
-        'Evidence-first governance workflows for Microsoft tenant review, backup, drift, findings, and restore planning.',
+        'Microsoft 365 governance with policy drift, versioned backups, evidence, reviews, and controlled recovery preparation.',
     },
     nav: [
       { name: 'Home', url: '/' },
@@ -296,97 +340,141 @@ export const siteCopy: Record<Locale, any> = {
       walkthrough: 'Request walkthrough',
     },
     home: {
-      pageTitle: 'Tenantial | Evidence-first Microsoft tenant governance',
+      pageTitle: 'Tenantial | Bring Microsoft 365 policies under control',
       metaDescription:
-        'Tenantial is evidence-first governance for Microsoft tenant configuration, with backup, restore, drift detection, findings, evidence, auditability, exceptions, and reviews.',
+        'Detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and controlled recovery.',
       heroTitle:
-        'Evidence-first governance for <span class="text-yellow-500 dark:text-yellow-400">Microsoft tenant configuration</span>',
+        'Bring <span class="text-yellow-500 dark:text-yellow-400">Microsoft 365 policies</span> under control.',
       heroSubtitle:
-        'Tenantial turns backup, restore, drift detection, findings, evidence, exceptions, auditability, and reviews into a governance model before high-impact changes move forward.',
+        'Tenantial helps MSPs and enterprise IT teams detect policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.',
-      primaryCta: 'Request walkthrough',
+      supportingLine:
-      secondaryCta: 'View product model',
+        'Built for Microsoft 365 governance - with Intune as the first strong policy focus and a model prepared for further policy domains.',
+      primaryCta: 'Book a demo',
+      secondaryCta: 'View platform',
       heroAlt: 'Static Tenantial governance dashboard preview',
-      featureTitle: 'From observed state to reviewable decisions',
+      featureTitle:
+        'When Microsoft 365 policies drift, an admin center is not enough.',
       featureSubtitle:
-        'Tenantial keeps backup snapshots, findings, evidence, auditability, exceptions, and reviews visible as static product context, so restore decisions stay preview-first, attributable, and never positioned as hidden automation.',
+        'Tenantial shows what changed, which configurations are protected, which evidence exists, and which findings need to be resolved before the next review.',
       featureAlt: 'Static Tenantial review board preview',
-      workflowTitle:
+      audienceTitle: 'One reliable truth for MSPs, IT, and audit.',
-        'From <span class="text-yellow-500 dark:text-yellow-400">snapshot</span> to review decision.',
+      audienceSubtitle:
-      tabs: [
+        'Tenantial connects technical configuration data with evidence, findings, and reviews so operators, security owners, and auditors do not decide from screenshots, spreadsheets, or gut feel.',
+      audiences: [
         {
-          heading: 'Evidence intake',
+          title: 'MSP operators',
           content:
-            'Normalize inventory, backup, and snapshot context so reviews start from one readable view of observed policy state.',
+            'Monitor, compare, and prepare multiple customer environments for controlled reviews.',
-          svg: 'frame',
-          alt: 'Static Tenantial evidence intake preview',
-          first: true,
         },
         {
-          heading: 'Decision review',
+          title: 'Enterprise IT',
           content:
-            'Surface drift detection, findings, exceptions, auditability, and review notes before administrators choose the next action.',
+            'Document changes, drift, and recovery risks in a traceable way.',
-          svg: 'dashboard',
-          alt: 'Static Tenantial decision review preview',
-          second: true,
         },
         {
-          heading: 'Restore planning',
+          title: 'Security & Audit',
           content:
-            'Treat restore as preview-first work with validation, conflict awareness, selective scope, and explicit confirmation.',
+            'Turn evidence, findings, and accepted risks into reviewable material.',
-          svg: 'verified',
-          alt: 'Static Tenantial restore planning preview',
         },
       ],
+      boundaryTitle: 'Built for governance. Not blind automation.',
+      boundarySubtitle:
+        'Tenantial does not replace Microsoft Admin Center. It adds the layer enterprise teams miss in daily work: versioning, evidence, drift visibility, review context, and auditable decisions.',
+      boundaries: [
+        {
+          title: 'Versioning beyond snapshots',
+          content:
+            'Policy states remain historically comparable so changes and review questions do not need to be rebuilt from screenshots.',
+        },
+        {
+          title: 'Evidence beyond gut feel',
+          content:
+            'Findings, accepted risks, and review packs bring security, IT, and audit onto the same reliable data basis.',
+        },
+        {
+          title: 'Recovery evaluated before execution',
+          content:
+            'Restore and recovery questions are assessed with scope, risk, and evidence before changes are executed.',
+        },
+      ],
+      trustTeaserTitle: 'Evidence, findings, and review packs for traceable decisions.',
+      trustTeaserSubtitle:
+        'Tenantial brings policy state, findings, accepted risks, and follow-ups into review packs that prepare customer meetings, internal audits, and recovery decisions with reliable context.',
+      trustPoints: [
+        'Traceable audit trail for changes and accepted risks',
+        'Review packs for customer meetings and internal audits',
+        'Role-aware governance context for operators, security, and audit',
+      ],
+      finalCtaTitle: 'Ready to make Microsoft 365 governance measurable?',
+      finalCtaSubtitle:
+        'See in a focused demo how Tenantial brings policy drift, backups, evidence, and reviews into a controlled governance process.',
+      finalPrimaryCta: 'Book a demo',
+      finalSecondaryCta: 'View platform',
       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.',
+        'Tenantial explains policy governance for Microsoft 365 with observed state, evidence, drift detection, governance reviews, audit trail, and controlled recovery planning.',
-      heading: 'Public product model',
+      heading: 'Policy governance model for Microsoft 365',
       subtitle:
-        'Tenantial describes a governance-of-record model for Microsoft tenant configuration: backup evidence, immutable policy snapshots, structured diffs, drift detection, findings, exceptions, auditability, governance reviews, and cautious restore planning.',
+        'Tenantial complements Microsoft Admin Center with versioning, evidence, drift visibility, review context, and auditable decisions. Microsoft 365 is the first market; further policy domains stay clearly framed as prepared direction.',
-      backupTitle: 'Backup and snapshot evidence',
+      focusTitle: 'Current focus and future direction',
+      focusSubtitle:
+        'The public story intentionally separates current Microsoft 365 scope from prepared future policy domains.',
+      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: further policy domains',
+          content:
+            'Further policy domains 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 and 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: 'Microsoft 365', description: 'current focus' },
-        { stat: 'Preview', description: 'before restore execution' },
+        { stat: 'Further domains', description: 'clearly marked as direction' },
-        { stat: 'Review', description: 'before high-impact changes' },
+        { stat: 'No live data', description: 'on the public website' },
       ],
-      mainStatTitle: '0',
+      mainStatTitle: 'Today',
-      mainStatSubTitle: 'live tenant records used by this public website',
+      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.',
+        '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 describes evaluation and rollout paths here. The public website does not claim instant payment, fixed package access, or automatic tenant connection.',
+        '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 +502,19 @@ export const siteCopy: Record<Locale, any> = {
     trust: {
       pageTitle: 'Trust | Tenantial',
       metaDescription:
-        'Tenantial public trust posture with conservative claims and clear static preview boundaries.',
+        'Tenantial trust posture for Microsoft 365 policy governance with audit-ready evidence, clear boundaries, traceable reviews, and controlled recovery preparation.',
-      heading: 'Trust starts with clear boundaries',
+      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 shows which evidence exists, which findings are resolved, which risks have been accepted, and which recovery questions need assessment before a change.',
       cta: 'Contact Tenantial',
-      statsTitle: 'Public website posture',
+      statsTitle: 'Trust for review-ready governance',
       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.',
+        'Review packs, audit trail, and clear ownership help MSPs, enterprise IT, and security teams make decisions from reliable context instead of point-in-time screenshots.',
-      mainStatTitle: 'Static',
+      mainStatTitle: 'Review-first',
-      mainStatSubTitle: 'product previews only',
+      mainStatSubTitle: 'evidence, findings, and decisions stay traceable',
       stats: [
-        { stat: 'No', description: 'customer-logo proof' },
+        { stat: 'No', description: 'unsupported compliance claims' },
-        { stat: 'No', description: 'external endorsement claim' },
+        { stat: 'No', description: 'customer-proof or endorsement claims' },
         { stat: 'No', description: 'live tenant connection' },
       ],
     },
@@ -467,54 +555,78 @@ export const siteCopy: Record<Locale, any> = {
 export const featuresByLocale: Record<Locale, Feature[]> = {
   de: [
     {
-      heading: 'Backup-Evidence',
+      heading: 'Policy-Drift erkennen',
       content:
-        'Prüfe beobachtete Policy-Metadaten und Backup-Snapshots aus einer lesbaren Quelle, bevor Governance-Entscheidungen beginnen.',
+        'Abweichungen zwischen erwarteter und tatsächlicher Konfiguration sichtbar machen.',
       svg: 'frame',
     },
     {
-      heading: 'Restore-Planung',
+      heading: 'Backups & Versionen behalten',
       content:
-        'Vergleiche unveränderliche Snapshots und plane Restore-Arbeit mit Validierung, selektivem Scope und explizitem Review statt Recovery-Versprechen.',
+        'Policy-Zustände nachvollziehbar sichern und Änderungen historisch vergleichbar machen.',
       svg: 'dashboard',
     },
     {
-      heading: 'Drift Detection',
+      heading: 'Auditfähige Reviews vorbereiten',
       content:
-        'Verwandle Unterschiede, Findings und Evidence in lesbare Review-Arbeit, bevor Administratoren entscheiden, ob etwas geändert werden sollte.',
+        'Findings, Evidence, Accepted Risks und Review Packs für Kundentermine und interne Audits bündeln.',
       svg: 'verified',
     },
     {
-      heading: 'Auditability und Exceptions',
+      heading: 'Recovery kontrolliert vorbereiten',
       content:
-        'Halte Exceptions, Review-Notizen und Auditability sichtbar, damit Entscheidungen zuordenbar und konservativ bleiben.',
+        'Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden.',
-      svg: 'checkCircle',
+      svg: 'tools',
+    },
+    {
+      heading: 'Provider-Berechtigungen transparent machen',
+      content:
+        'Microsoft Graph und Provider-Zugriffe verständlich erklären, prüfen und capability-orientiert einordnen.',
+      svg: 'frame',
+    },
+    {
+      heading: 'Entscheidungen nachvollziehbar machen',
+      content:
+        'Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen.',
+      svg: 'dashboard',
     },
   ],
   en: [
     {
-      heading: 'Backup evidence',
+      heading: 'Detect policy drift',
       content:
-        'Review observed policy metadata and backup snapshots from one readable source before governance decisions start.',
+        'Make deviations between expected and actual configuration visible.',
       svg: 'frame',
     },
     {
-      heading: 'Restore planning',
+      heading: 'Keep backups & versions',
       content:
-        'Compare immutable snapshots and plan restore work with validation, selective scope, and explicit review rather than automatic recovery promises.',
+        'Preserve policy states in a traceable way and compare changes historically.',
       svg: 'dashboard',
     },
     {
-      heading: 'Drift detection',
+      heading: 'Prepare audit-ready reviews',
       content:
-        'Turn differences, findings, and evidence into readable review work before administrators decide whether anything should change.',
+        'Bundle findings, evidence, accepted risks, and review packs for customer meetings and internal audits.',
       svg: 'verified',
     },
     {
-      heading: 'Auditability and exceptions',
+      heading: 'Prepare controlled recovery',
       content:
-        'Keep exceptions, review notes, and auditability visible so decisions stay attributable and conservative.',
+        'Assess restore and recovery questions with scope, risk, and evidence before changes are executed.',
-      svg: 'checkCircle',
+      svg: 'tools',
+    },
+    {
+      heading: 'Make provider permissions transparent',
+      content:
+        'Explain, verify, and classify Microsoft Graph and provider access by capability.',
+      svg: 'frame',
+    },
+    {
+      heading: 'Make decisions traceable',
+      content:
+        'Put findings, exceptions, accepted risks, and follow-ups into a reviewable governance context.',
+      svg: 'dashboard',
     },
   ],
 };
@@ -603,7 +715,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 hilft Teams, Microsoft 365 Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.',
+      },
+      {
+        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 +729,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.',
+          'Ja. Die öffentliche Positionierung spricht MSPs, interne IT-, Security- und Governance-Teams an, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.',
-      },
-      {
-        question: 'Veröffentlicht Tenantial hier Kundenbelege?',
-        answer:
-          'Ohne gelieferte und geprüfte Evidence werden keine Kundenlogos, externen Endorsements, externen Assurance-Aussagen, Service-Level-Zusagen oder Recovery-Versprechen veröffentlicht.',
       },
     ],
   },
@@ -629,7 +741,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 helps teams detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.',
+      },
+      {
+        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 +754,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.',
+          'Yes. The public positioning speaks to MSPs, internal IT, security, and governance teams that need to align policy context, review work, and recovery readiness.',
-      },
-      {
-        question: 'Does Tenantial publish customer evidence here?',
-        answer:
-          'No customer logos, third-party endorsements, external assurance statements, service-level commitments, or recovery promises are published without supplied and reviewed evidence.',
       },
     ],
   },

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: /Microsoft 365 Policies unter Kontrolle bringen/,
     })
   ).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: /Microsoft 365 Policies unter Kontrolle bringen/,
     })
   ).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: /Microsoft 365 Policies unter Kontrolle bringen/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: /Public product 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: /Öffentliches Produktmodell/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,
+    title: /Tenantial.*Microsoft 365 Policies unter Kontrolle bringen/i,
-    description: /evidenzbasierte Governance/i,
+    description: /Policy-Drift früh erkennen|Konfigurationsstände versioniert sichern/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: /Vertrauensposition.*konservativen Claims.*statische Produktvorschauen/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,
+    title: /Tenantial.*Bring Microsoft 365 policies under control/i,
-    description:
+    description: /Detect Microsoft 365 policy drift early|versioned configuration backups/i,
-      /evidence-first governance for Microsoft tenant configuration/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: /trust posture|policy governance|review/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,17 +149,20 @@ 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: /Microsoft 365 Policies unter Kontrolle bringen/i,
   });
   await expect(heading).toBeVisible();
 
   const box = await heading.boundingBox();
   expect(box?.y ?? Number.POSITIVE_INFINITY).toBeLessThan(420);
   await expect(
-    page.getByRole('link', { name: /Walkthrough anfragen/i }).first()
+    page.getByRole('link', { name: /Demo buchen/i }).first()
   ).toHaveAttribute('href', '/contact');
   await expect(
-    page.getByRole('link', { name: /Produktmodell ansehen/i }).first()
+    page.getByRole('link', { name: /Plattform ansehen/i }).first()
+  ).toHaveAttribute('href', '/platform');
+  await expect(
+    page.getByRole('link', { name: /Plattform ansehen/i }).last()
   ).toHaveAttribute('href', '/platform');
   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: /Öffentliches Produktmodell/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(/weitere Policy-Domänen|Weitere Domänen/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: /Öffentliches Produktmodell|Public product model/,
+          name: /Policy-Governance-Modell für Microsoft 365|Policy governance model for Microsoft 365/,
       })
     ).toBeVisible();
   });

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

@@ -87,6 +87,17 @@ 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 },
   {
@@ -168,14 +179,14 @@ export async function expectCoreCapabilitiesVisible(page: Page): Promise<void> {
   const text = (await page.locator('body').innerText()).toLowerCase();
 
   for (const terms of [
-    ['backup'],
+    ['policy governance', 'policy-governance', 'governance'],
-    ['restore'],
+    ['microsoft 365'],
-    ['drift detection', 'drift'],
-    ['findings'],
     ['evidence'],
-    ['auditability'],
+    ['drift detection', 'policy-drift', 'drift'],
-    ['exceptions'],
     ['reviews', 'review'],
+    ['audit trail', 'auditability'],
+    ['controlled recovery', 'recovery', 'restore'],
+    ['provider', 'policy-domänen', 'policy domains', 'further policy domains'],
   ]) {
     expect(
       terms.some(term => text.includes(term)),

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

@@ -1,8 +1,8 @@
-# Specification Quality Checklist: `apps/website` Public Content Architecture & Messaging
+# Specification Quality Checklist: Public Website Positioning & Content Architecture
 
 **Purpose**: Validate specification completeness and quality before proceeding to planning
 
-**Created**: 2026-05-22
+**Created**: 2026-05-25
 
 **Feature**: [spec.md](../spec.md)
 
@@ -33,6 +33,7 @@ ## Feature Readiness
 
 ## Notes
 
-- Validation pass 1 completed on 2026-05-22.
+- Validation pass 1 completed on 2026-05-25.
-- No `[NEEDS CLARIFICATION]` markers were needed; the spec uses the user's explicit scope and conservative defaults.
+- No `[NEEDS CLARIFICATION]` markers remain; the supplied positioning, provider posture, and trust boundaries were specific enough to avoid open questions.
-- Repository validation commands are listed as delivery checks; product requirements remain focused on public content, buyer understanding, CTA consistency, and claim safety.
+- 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

@@ -1,12 +1,12 @@
-# Public Content Contract: Spec 404 Content Architecture & Messaging
+# 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 content behavior that reviewers and smoke tests must verify.
+The contract is the public static website behavior that reviewers and smoke checks must verify.
 
 ## Core Public Routes
 
-The following German default routes must render intentionally and expose Tenantial-specific content, metadata, and CTAs:
+The following default routes must render intentionally and expose Tenantial-specific content, metadata, and CTAs:
 
 - `/`
 - `/platform`
@@ -23,7 +23,7 @@ ## Core Public Routes
 - `/guides/first-project-checklist/`
 - `/platform/evidence-review/`
 
-The following English route mirrors must remain consistent where they are intentionally exposed:
+The following English mirrors must remain consistent where they are intentionally exposed:
 
 - `/en/`
 - `/en/platform`
@@ -40,96 +40,100 @@ ## Core Public Routes
 - `/en/guides/first-project-checklist/`
 - `/en/platform/evidence-review/`
 
-## Homepage Messaging Contract
+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:
 
-- hero copy identifies Tenantial as evidence-first governance for Microsoft tenant configuration
+- the hero clearly identifies Tenantial as policy governance for Microsoft 365 and modern cloud environments, or an equivalent policy-governance phrasing
-- first two homepage sections allow a reviewer to name at least three of backup, restore, drift, findings, evidence, audit trail, exceptions, and reviews
+- Microsoft 365 is presented as the first focus without collapsing the category to Intune-only messaging
-- section headings read as a coherent sequence from product category to buyer problem to operating model to capability proof to evaluation
+- provider-extensible wording is allowed only as design or future direction, not live-support proof
-- each major section adds distinct meaning rather than repeating the same product claim
+- a trust teaser introduces auditability, evidence history, role-based access, review trails, or DACH evaluation readiness without false assurance
-- CTAs match the visitor's likely decision stage
+- an operating-model section makes the flow from observed state to evidence, detection, review, decision, and audit trail explicit
-- homepage copy stays suitable for later Spec 405 spacing and visual polish
+- 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` Product-Model Contract
+## `/platform` Governance-Model Contract
 
 The public `/platform` route must satisfy:
 
-- explains backup, restore, drift, findings, evidence, auditability, exceptions, and reviews as one operating model
+- explains the governance model more deeply than the homepage
-- explains Tenantial as governance-of-record, not helpdesk, device-action, or blind automation
+- connects evidence, findings, drift, review, accepted risks or exceptions, controlled recovery, and audit trail into one public product story
-- frames product-like previews as static/demo/illustrative where needed
+- 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 Microsoft tenant, runs Microsoft Graph calls, or shows live tenant data
+- does not imply that the public website connects to a provider, runs Microsoft Graph, or shows live tenant/customer data
 
-## Pricing And Evaluation Contract
+## Provider Posture Contract
 
-Pricing and evaluation copy on `/pricing` and homepage evaluation surfaces must satisfy:
+Public provider/domain wording must satisfy:
 
-- commercial language is contact-led and framed around evaluation, rollout scope, or scoped conversation
+- Microsoft 365 is the current public focus
-- no checkout, instant subscription activation, self-serve billing, account creation, or fixed unsupported entitlement claims
+- Intune is one Microsoft 365 policy domain, not the umbrella product category
-- managed rollout language reads as a scoped commercial conversation rather than a fake fixed plan
+- Entra or other Microsoft domains may be described only when consistent with current route truth
-- pricing/evaluation CTAs route to `/contact` or another intentional route/anchor
+- Google, AWS, and other non-Microsoft providers may appear only as architecture direction, future direction, or provider-extensible wording unless current support is verified
-- visual language requirements are limited to content clarity; broad layout polish remains Spec 405
+- roadmap or architecture-direction references must be clearly labeled as such
 
-## Trust, FAQ, Footer, And Legal-Adjacent Contract
+## Trust And Claim Guardrail Contract
 
-Trust-sensitive public copy must avoid unsupported:
+Public copy must avoid unsupported claims about:
 
-- SOC 2, ISO, or other certification claims
+- German hosting
-- Microsoft endorsement or partnership claims
+- DSGVO or GDPR compliance
-- compliance guarantees
+- AVV or TOM availability
-- recovery guarantees
+- ISO, BSI, NIS2, or similar certification
-- uptime guarantees
+- Microsoft endorsement or partnership
-- fake customer logos
+- no customer data stored
-- fake testimonials
+- automatic restore, autonomous remediation, self-healing, or approval-free automation
-- fake "trusted by" claims
+- fake customer logos, fake testimonials, fake case studies, or fake compliance badges
-- real customer evidence implications
-- public website live-tenant-data implications
 
-FAQ and footer copy must close the page intentionally without adding fake workflows, fake proof, or unsupported support commitments.
+Trust, FAQ, footer, and legal-adjacent copy should explain product boundaries calmly and conservatively without adding fake proof or fake workflows.
 
-## CTA Contract
+## Navigation And CTA Contract
 
-Every public CTA, navigation item, footer link, docs link, and visible form-like control must satisfy:
+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
+- resolves to an intentional route, anchor, static asset, `mailto:` link, or legitimate external URL
 - no public `href="#"` placeholders
-- primary contact/demo paths route to `/contact` or an intentional contact section
+- no navigation labels that imply production-ready pages which do not exist
-- secondary educational paths route to product, pricing, trust, docs, or legal explanations
+- primary CTAs lead to contact, walkthrough, demo discussion, or another real next step
-- localized public links remain in the current locale where a localized route exists
+- secondary CTAs lead to product explanation, trust review, pricing review, or docs review
-- labels avoid login, signup, account creation, checkout, subscription, instant provisioning, automated scheduling, or guaranteed backend submission implications unless those workflows exist
+- localized routes remain in the current locale where a localized mirror exists
-- CTA language is normalized by intent family before individual labels are rewritten
+- 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
+- Tenantial-specific page title and description
-- Tenantial-specific page 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 proof claims in title, description, Open Graph, Twitter, schema, or docs 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 Spec 403 unless a website-scope correction is documented
+- 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
-- avoid placeholder theme content
+- reinforce the same policy-governance and claim-safe posture as the marketing routes
-- avoid unsupported product behavior claims
+- avoid placeholder theme content and unsupported product behavior claims
-- avoid support, legal, integration, compliance, or recovery commitments not supplied by the product/business
+- avoid support, legal, provider, compliance, or recovery commitments not supplied by current product/business truth
-- keep public docs separate from `apps/platform` implementation documentation unless a future spec explicitly changes scope
+- 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 data
+- avoid implying live tenant/customer/provider data
 - avoid internal Laravel/Filament implementation details
-- avoid turning visual labels into product runtime taxonomy
+- avoid turning visual labels into runtime product taxonomy
-- communicate meaning through text or labels, not color alone
+- communicate meaning through wording and labeling, not color alone
 
 ## Browser And Accessibility Contract
 

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

@@ -1,112 +1,109 @@
-# Data Model: `apps/website` Public Content Architecture & Messaging
+# 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 Content Surface
+## Public Positioning Surface
 
-Represents an intentional public page, docs page, navigation area, footer area, FAQ area, or metadata surface affected by this content architecture pass.
+Represents one intentional public route, docs route, navigation/footer surface, or shared metadata surface affected by the positioning pass.
 
 **Fields**
 
-- `surfaceId`: stable human-readable identifier, such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, or `footer`
+- `surfaceId`: stable identifier such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, `footer`, or `site-meta`
-- `path`: public URL path when the surface maps to a route
+- `path`: public route path when the surface maps to a URL
-- `locale`: German default, English mirror, shared, or locale-neutral
+- `locale`: default German, English mirror, shared, or locale-neutral
-- `sourceArea`: page, shared data file, component, docs content, metadata, navigation, footer, or smoke expectation
+- `sourceArea`: shared copy file, route wrapper, page component, docs content, metadata component, navigation/footer component, or smoke expectation
-- `audienceIntent`: first-time visitor, buyer evaluator, security-conscious reviewer, or site owner/reviewer
+- `audienceIntent`: first-time visitor, MSP evaluator, internal IT evaluator, governance reviewer, or site maintainer
-- `sectionRole`: category definition, problem framing, operating model, capability explanation, evaluation, trust, FAQ, legal-adjacent, or closing CTA
+- `surfaceRole`: hero, operating model, capability section, provider posture, trust teaser, boundary section, CTA surface, docs surface, or route metadata
-- `readiness`: needs audit, needs rewrite, accepted, or hidden from navigation
+- `status`: needs audit, needs rewrite, accepted, hidden from navigation, or removed
 
 **Validation Rules**
 
-- Every exposed core public page must have intentional Tenantial-specific content.
+- Every exposed core public route must have intentional Tenantial-specific content.
-- Homepage surfaces must support a coherent narrative from product category to evaluation.
+- Homepage surfaces must support policy-governance category clarity and an operating-model narrative.
-- `/platform` surfaces must explain the public product model more deeply than the homepage.
+- `/platform` must explain the governance model more deeply than the homepage.
-- Surfaces must not import, reference, or depend on `apps/platform`.
+- No positioning surface may import, reference, or depend on `apps/platform`.
 
 ## Messaging Claim
 
-Represents visible copy or metadata that could create a product, trust, pricing, legal, proof, or workflow claim.
+Represents visible copy or metadata that could create a product, provider, trust, pricing, legal, proof, or workflow claim.
 
 **Fields**
 
-- `surfaceId`: related public content surface
+- `surfaceId`: related public positioning surface
 - `claimText`: reviewed phrase or summary of the phrase
-- `claimCategory`: product positioning, trust, pricing, restore, audit, compliance, Microsoft relationship, social proof, preview framing, or workflow expectation
+- `claimCategory`: product category, provider posture, trust, pricing, restore, automation, compliance, endorsement, social proof, preview framing, or workflow expectation
-- `proofStatus`: verified, conservative positioning, illustrative/static, unsupported, or remove
+- `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 SOC 2, ISO, Microsoft endorsement, compliance guarantee, recovery guarantee, uptime guarantee, and customer-proof claims must be removed or rewritten.
+- Unsupported provider, certification, compliance, hosting, endorsement, and customer-proof claims must be removed or rewritten.
-- Restore language must avoid guaranteed recovery or automatic success.
+- Restore and automation language must avoid autonomous remediation or guaranteed recovery.
-- Audit/evidence language must avoid legal sufficiency, certification, and guaranteed compliance.
+- 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 Microsoft tenant data.
+- Public copy must not imply that the website connects to or displays live provider/customer data.
 
-## CTA Intent
+## Provider Posture Entry
 
-Represents a visible CTA, navigation item, footer link, docs link, or form-like public action.
+Represents one provider or policy-domain reference that may appear in public copy.
 
 **Fields**
 
-- `label`: visible CTA or link text
+- `providerOrDomain`: Microsoft 365, Intune, Entra, Conditional Access, SharePoint, OneDrive sharing, Enterprise Apps, Service Principals, Google Workspace, AWS, or other domain wording
-- `sourceSurface`: page, component, footer, docs nav, or metadata-adjacent content area where the CTA appears
+- `publicStatus`: current focus, example domain, roadmap domain, architecture direction, or disallowed claim
-- `target`: route, anchor, static asset, mailto link, or legitimate external URL
+- `allowedLabel`: Microsoft 365 first, one policy domain, planned, roadmap domain, architecture direction, or omit
-- `intentFamily`: primary contact/demo, secondary product explanation, pricing evaluation, trust/legal review, docs review, or navigation
+- `guardrail`: exact wording or implication that must be avoided
-- `workflowImplied`: contact request, product education, pricing discussion, trust review, docs review, login, signup, checkout, subscription, account creation, automated scheduling, or backend submission
+- `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 routes or anchors.
+- Public CTAs must resolve to intentional targets and must not use `href="#"`.
-- Public CTAs must not use `href="#"`.
+- CTA labels must not imply unavailable login, signup, checkout, account creation, self-serve billing, or automated scheduling workflows.
-- CTAs must not imply unavailable login, signup, checkout, account creation, instant provisioning, self-serve billing, automated scheduling, or guaranteed backend submission workflows.
+- Primary CTA language should remain consistent across core public routes.
-- Primary action language should remain consistent across pages.
-
-## Product Capability Narrative
-
-Represents one Tenantial capability concept that must be explained safely in public copy.
-
-**Fields**
-
-- `capability`: backup, restore, drift, findings, evidence, auditability, exceptions, reviews, or restore planning
-- `homepageRole`: category proof, short capability mention, or omitted
-- `platformRole`: detailed operating-model explanation, static preview explanation, or related capability
-- `claimBoundary`: words or implications to avoid
-- `relatedSurfaces`: public pages or docs surfaces where the capability appears
-
-**Validation Rules**
-
-- Homepage copy must mention enough capabilities for product category clarity without repeating the same claims across sections.
-- `/platform` must explain the capabilities as one operating model.
-- Drift and finding copy must emphasize reviewability and operator decision-making instead of automatic remediation.
-- Capability language must remain public positioning, not runtime guarantee.
-
-## Static Preview Reference
-
-Represents product-like static/demo content shown or referenced on public pages.
-
-**Fields**
-
-- `surfaceId`: related route or component
-- `previewName`: human-readable preview name
-- `framingCopy`: text that identifies the preview as static, illustrative, or demo where needed
-- `capabilityShown`: backup, restore, drift, findings, evidence, auditability, exceptions, reviews, or related product positioning
-- `dataProvenance`: static/demo only
-- `claimRisk`: whether the preview could imply live tenant data, real customer evidence, or active provider integration
-
-**Validation Rules**
-
-- Preview content must not imply live tenant data.
-- Preview status-like values must not become shared product taxonomy.
-- Preview copy must not rely on color alone for meaning where status-like information is shown.
-- Preview wording must avoid internal Laravel/Filament implementation details.
 
 ## Route Metadata
 
-Represents public route title, description, canonical, social, and search-facing metadata.
+Represents public route title, description, canonical, and search/social-facing metadata.
 
 **Fields**
 
@@ -115,22 +112,23 @@ ## Route Metadata
 - `description`: route-specific page description
 - `canonicalPolicy`: canonical self, localized alternate, redirect-only, or hidden
 - `socialSummary`: Open Graph/Twitter-facing summary
-- `residueStatus`: clean, needs review, or blocked
+- `positioningStatus`: aligned, needs rewrite, or blocked
 - `claimStatus`: conservative, needs rewrite, or blocked
 
 **Validation Rules**
 
-- Core public route titles and descriptions must reflect the revised messaging.
+- 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 claims just like visible page copy.
+- Metadata must avoid unsupported provider, compliance, trust, or automation claims.
-- Sitemap and robots behavior from Spec 403 must remain intact unless explicitly corrected within website scope.
+- Sitemap and robots behavior from the launch-readiness baseline must remain intact unless a website-scope correction is required.
 
 ## Relationships
 
-- A `Public Content Surface` may contain many `Messaging Claim`, `CTA Intent`, `Product Capability Narrative`, `Static Preview Reference`, and `Route Metadata` review points.
+- A `Public Positioning Surface` may contain many `Messaging Claim`, `Provider Posture Entry`, `Operating Model Step`, `CTA Intent`, and `Route Metadata` review points.
-- A `CTA Intent` belongs to one source surface and targets one intentional route, anchor, static asset, or legitimate external URL.
+- A `Provider Posture Entry` may appear on multiple public positioning surfaces, but each appearance must preserve the same current-versus-future public status.
-- A `Product Capability Narrative` may appear on multiple public content surfaces, with the homepage carrying concise positioning and `/platform` carrying deeper explanation.
+- An `Operating Model Step` may appear on the homepage, `/platform`, and docs surfaces, with the homepage carrying concise explanation and `/platform` carrying deeper detail.
-- `Route Metadata` belongs to one public route and must be reviewed with the visible copy for the same route.
+- 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
 

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

@@ -1,220 +1,216 @@
-# Implementation Plan: `apps/website` Public Content Architecture & Messaging
+# Implementation Plan: Public Website Sales Copy & Positioning Rewrite
 
-**Branch**: `404-public-content-messaging` | **Date**: 2026-05-22 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
+**Branch**: `404-public-content-messaging`
-**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
+**Date**: 2026-05-25
+**Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
 
 ## Summary
 
-Stabilize Tenantial's public website messaging before later visual rhythm work. The implementation stays inside `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` and updates public copy, section intent, CTA language, route metadata, trust/pricing/contact wording, FAQ/footer messaging, and exposed docs navigation/content so the site communicates evidence-first Microsoft tenant governance without unsupported claims or runtime workflow implications.
+This plan turns Spec 404 into a website-copy refactoring plan, not an architecture plan. The goal is to guide a later implementation that rewrites public Tenantial website copy toward B2B SaaS, cybersecurity, and IT-operations outcomes for MSPs, Enterprise IT, Security, and Audit.
 
-## Technical Context
+This implementation renders the approved homepage sales copy in `apps/website` while keeping platform/backend/runtime scope untouched.
 
-**Language/Version**: TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0
+## Scope Decision
-**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, docs content, route metadata, and generated build output only; no database or product persistence
-**Testing**: Astro check/build plus Playwright smoke tests under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`
-**Validation Lanes**: website build, public smoke, manual browser/content review, whitespace check, `apps/platform` scope check
-**Target Platform**: Static Astro public website deployed from `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`, with public site URL `https://tenantial.com`
-**Project Type**: Web - standalone Astro public website inside monorepo
-**Performance Goals**: Public routes remain static-buildable; validated desktop/mobile routes retain no body-level horizontal overflow; content remains understandable without requiring unavailable backend workflows
-**Constraints**: Runtime/source changes are scoped to `apps/website`; Spec Kit artifacts live under `specs/404-public-content-messaging`; preserve Spec 402 ScrewFast-derived substrate and Spec 403 launch-readiness safety; do not add backend contact/demo workflow, authentication, billing, Microsoft Graph, Laravel, Filament, Livewire, database, queue, job, provider, policy, RBAC, or `apps/platform` changes
-**Scale/Scope**: Public content architecture pass for homepage, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs routes, route metadata, navigation, FAQ, footer, CTA labels, static/demo preview framing, and claim-safety review
 
-## UI / Surface Guardrail Plan
+- **404 path found**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging`
+- **Decision**: This is the Public Website Sales Copy & Positioning Spec because the branch, folder name, prior title, and existing content all target public website messaging, homepage hierarchy, provider/trust wording, metadata, and `apps/website`.
+- **Spec artifact scope**: `spec.md`, `plan.md`, and `tasks.md`
+- **Website implementation scope**: `apps/website` source files and website smoke-test expectations needed for the homepage copy rewrite
+- **Explicitly out of scope now**: `apps/platform`, root package/workspace contracts, build output, runtime config, generated assets, dependencies, backend code, provider integrations, and unsupported trust/certification claims
 
-- **Guardrail scope**: no admin/operator-facing product surface change; public website content and messaging guardrail only
+## Repo Verification
-- **Native vs custom classification summary**: ScrewFast-derived Astro website; no Filament/Blade/admin surface
-- **Shared-family relevance**: none for Laravel/Filament shared interaction families; website-local public navigation/CTA/content families remain in scope
-- **State layers in scope**: static page content, docs content, public route metadata, navigation/footer link data, preview framing copy, Playwright smoke expectations
-- **Audience modes in scope**: public visitor, buyer/reviewer, security-conscious evaluator, site owner/reviewer; no authenticated operator/MSP/support-platform modes
-- **Decision/diagnostic/raw hierarchy plan**: public copy must be buyer-decision-first; internal implementation diagnostics stay out of visible copy; static/demo preview context is disclosed where needed
-- **Raw/support gating plan**: N/A - no raw/support product evidence surface
-- **One-primary-action / duplicate-truth control**: primary CTAs should stay contact-led; secondary CTAs should point to explanatory pages; repeated claims should be consolidated so each section adds new meaning
-- **Handling modes by drift class or surface**: public copy/CTA/claim drift is review-mandatory inside this feature; platform/admin drift is a hard stop
-- **Repository-signal treatment**: `apps/platform` changes are a hard stop; public website source/output changes are reviewed only inside website scope
-- **Special surface test profiles**: N/A - not a Filament surface
-- **Required tests or manual smoke**: public smoke plus manual review of homepage narrative, `/platform` product model, pricing/trust/contact claim posture, CTA targets, metadata, light/dark/mobile/desktop, and keyboard reachability
-- **Exception path and spread control**: none
-- **Active feature PR close-out entry**: Smoke Coverage
 
-## Shared Pattern & System Fit
+Before any later implementation agent edits website source, verify current repo truth instead of relying on this plan as a file-map guarantee:
 
-- **Cross-cutting feature marker**: yes, within public website content only
+1. Run `git status --short --branch`.
-- **Systems touched**: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` public pages, docs content, shared website copy/data files, navigation/footer helpers, metadata helpers, and smoke expectations as needed
+2. Locate the 404 spec folder with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`.
-- **Shared abstractions reused**: existing Spec 402/403 Astro website structure, Starlight docs, route metadata components, website data files, navigation utilities, and Playwright smoke helper patterns
+3. Read `specs/404-public-content-messaging/spec.md`, `plan.md`, and `tasks.md`.
-- **New abstraction introduced? why?**: none planned
+4. Inspect the website structure with `find apps/website -maxdepth 3 -type f | sort | sed -n '1,180p'`.
-- **Why the existing abstraction was sufficient or insufficient**: The existing website structure can express the required copy and route metadata. The insufficiency is content architecture, not framework capability.
+5. Read `apps/website/package.json` and use only scripts that actually exist.
-- **Bounded deviation / spread control**: no new content framework, design system, API contract, persisted state, or platform abstraction; any new helper must be website-local and justified by repeated existing website content usage
+6. Confirm `apps/platform` remains outside the change.
 
-## OperationRun UX Impact
+## Current Copy Inventory
 
-- **Touches OperationRun start/completion/link UX?**: no
+The later implementation must inventory current visible website copy before changing it:
-- **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
+- homepage hero and above-the-fold copy
+- homepage section titles and CTA labels
+- platform/product page copy
+- trust, pricing, contact, and docs entry copy if they repeat the same positioning
+- metadata titles and descriptions
+- navigation/footer labels only if they repeat stale positioning
+- smoke-test forbidden-pattern lists, if they exist
 
-- **Shared provider/platform boundary touched?**: no
+The inventory must identify old internal, defensive, academic, or architecture-heavy wording, including:
-- **Provider-owned seams**: N/A
-- **Platform-core seams**: N/A
-- **Neutral platform terms / contracts preserved**: Governance, evidence, findings, drift, restore planning, auditability, exceptions, reviews, evaluation, and rollout remain public positioning terms only
-- **Retained provider-specific semantics and why**: Microsoft tenant configuration remains in public product positioning because Tenantial's current public category is Microsoft tenant governance
-- **Bounded extraction or follow-up path**: none; Spec 405 may use the stabilized content for visual polish
 
-## Constitution Check
+- category-first positioning
+- "operating model" language as visible marketing copy
+- "source of truth" or "provider-extensible" as hero philosophy
+- internal governance-process wording
+- defensive boundary language that crowds out outcomes
+- vague trust language that sounds like certification without proof
 
-*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+## Copy Refactoring Workstreams
 
-- Inventory-first: PASS - no inventory, snapshot, or backup runtime behavior is changed.
+### 1. Hero And Above The Fold
-- Read/write separation: PASS - no product write/change behavior is introduced.
-- Graph contract path: PASS - no Microsoft Graph calls or contract registry changes.
-- Deterministic capabilities: PASS - no capability resolver or capability derivation changes.
-- RBAC-UX: PASS - no `/admin`, `/system`, tenant context, workspace context, capability, policy, or authorization behavior changes.
-- Workspace isolation: PASS - no workspace data or routes.
-- RBAC-UX destructive-like actions: PASS - no destructive actions.
-- RBAC-UX global search: PASS - no Filament resources or global search changes.
-- Tenant isolation: PASS - no tenant data, tenant routes, or cross-tenant views.
-- Run observability: PASS - no long-running, remote, queued, scheduled, or security-relevant DB action.
-- OperationRun start UX: PASS - no OperationRun behavior.
-- Ops-UX 3-surface feedback: PASS - no OperationRun notifications.
-- Ops-UX lifecycle: PASS - no OperationRun status/outcome transitions.
-- Ops-UX summary counts: PASS - no summary counts.
-- Ops-UX guards: PASS - no Ops-UX guard changes.
-- Ops-UX system runs: PASS - no system runs.
-- Automation: PASS - no queued/scheduled operations.
-- Data minimization: PASS - public copy and static/demo preview content only; no secrets or tokens.
-- Test governance (TEST-GOV-001): PASS - Browser/static website classification, explicit website smoke lane, no hidden Laravel/Filament/provider/database setup.
-- Proportionality (PROP-001): PASS - local website content architecture, no new product runtime structure.
-- No premature abstraction (ABSTR-001): PASS - no new factories, registries, resolvers, strategies, interfaces, or frameworks.
-- Persisted truth (PERSIST-001): PASS - no persisted product truth.
-- Behavioral state (STATE-001): PASS - no status/state/reason family.
-- UI semantics (UI-SEM-001): PASS - static public copy and preview labels remain local and do not become product taxonomy.
-- Shared pattern first (XCUT-001): PASS - cross-page website content reuses the existing website structure; no shared operator interaction family is touched.
-- Provider boundary (PROV-001): PASS - public Microsoft wording only; no shared provider/platform seam changes.
-- 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 new enum, DTO, presenter, persisted entity, interface, registry, resolver, taxonomy, or cross-domain framework.
-- Badge semantics (BADGE-001): PASS - no product badge semantics; preview labels must not become shared status truth.
-- 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 website copy is buyer-decision oriented; no operator surface.
-- Audience-aware disclosure: PASS - no raw/support product detail surface.
-- UI/UX inspect model: PASS - no list/detail operator surface.
-- UI/UX action hierarchy: PASS - no Filament actions.
-- UI/UX scope, truth, and naming: PASS - no admin scope labels; public copy must avoid implementation-first wording.
-- UI/UX placeholder ban: PASS - no Filament action groups.
-- UI naming: PASS - no operator-facing action labels, run titles, notifications, or audit prose.
-- Operator surfaces: PASS - no `/admin` surface.
-- Filament UI Action Surface Contract: PASS - no Filament Resource/RelationManager/Page.
-- Filament UI UX-001: PASS - no Filament screen.
-- Action-surface discipline: PASS - no operator action surface.
-- UI review workflow: PASS - plan carries N/A decisions forward and keeps `apps/platform` as hard stop.
 
-**Initial Gate Result**: PASS - no constitution violations or unresolved clarifications.
+Define the homepage first screen around this core message:
 
-## Test Governance Check
+- Microsoft 365 Policies unter Kontrolle bringen.
+- Policy-Drift früh erkennen.
+- Konfigurationen versioniert sichern.
+- auditfähige Evidence für Reviews, Changes und Recovery bereitstellen.
+- Intune as the first strong policy focus, not the product boundary.
 
-- **Test purpose / classification by changed surface**: Browser/static website
+Primary CTA: "Demo buchen"
-- **Affected validation lanes**: website build, public smoke, manual browser/content review, whitespace/scope checks
+Secondary CTA: "Plattform ansehen"
-- **Why this lane mix is the narrowest sufficient proof**: The feature changes public static pages, docs content, route metadata, CTAs, and browser-rendered copy. Laravel/Pest/Filament lanes would not prove the changed behavior and would add hidden platform cost.
-- **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 && 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**: Browser review remains explicit in website smoke/manual review; no heavy-governance lane
-- **Surface-class relief / special coverage rule**: N/A - public website
-- **Closing validation and reviewer handoff**: Reviewers should rely on website build, Playwright smoke, manual content review, no unsupported claims, intentional CTAs, no forbidden residue, and `apps/platform` untouched status.
-- **Budget / baseline / trend follow-up**: none expected
-- **Review-stop questions**: lane fit, browser breadth, hidden platform cost, CTA honesty, unsupported claim posture, route exposure
-- **Escalation path**: document-in-feature
-- **Active feature PR close-out entry**: Smoke Coverage
-- **Why no dedicated follow-up spec is needed**: The browser/static review cost is local to this content architecture pass unless repeated website release gates become a recurring process problem.
 
-## Project Structure
+### 2. Problem And Pain Section
 
-### Documentation (this feature)
+The first supporting section must make the buyer pain explicit:
 
-```text
+- Microsoft 365 policies drift.
-/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/
+- Admin centers show current settings but do not provide enough review context by themselves.
-├── plan.md
+- Operators need to know what changed, what is backed up, which evidence exists, and which findings need action before the next review.
-├── research.md
-├── data-model.md
-├── quickstart.md
-├── contracts/
-│   └── public-content-contract.md
-├── checklists/
-│   └── requirements.md
-└── tasks.md
-```
 
-### Source Code (repository root)
+Avoid product-philosophy explanations here.
 
-```text
+### 3. Capability Cards
-/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/
-├── astro.config.mjs
-├── package.json
-├── playwright.config.ts
-├── process-html.mjs
-├── public/
-├── src/
-│   ├── components/
-│   ├── content/
-│   ├── data_files/
-│   ├── images/
-│   ├── layouts/
-│   ├── pages/
-│   └── utils/
-└── tests/
-    └── smoke/
-```
 
-**Structure Decision**: Use the existing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` Astro app from Specs 402 and 403. Do not create new base source folders and do not touch `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`.
+Capability cards must be outcome-led and use the spec copy as the default source:
 
-## Complexity Tracking
+- Policy-Drift erkennen
+- Backups & Versionen behalten
+- Auditfähige Reviews vorbereiten
+- Recovery kontrolliert vorbereiten
+- Provider-Berechtigungen transparent machen
+- Entscheidungen nachvollziehbar machen
 
-| Violation | Why Needed | Simpler Alternative Rejected Because |
+Each card must describe what the buyer can see, compare, prepare, or document. Do not turn these into internal modules or architecture components.
-|-----------|------------|-------------------------------------|
-| None | N/A | N/A |
 
-## Proportionality Review
+### 4. Stakeholder And Persona Section
 
-- **Current operator problem**: Public buyers do not yet get a crisp product story, and claim-sensitive pages need stronger content discipline before layout work.
+Define a clear stakeholder section for:
-- **Existing structure is insufficient because**: Specs 402 and 403 established the website foundation and launch-readiness guardrails, but they did not finalize public messaging hierarchy, CTA language, or proof-safe page-level copy.
-- **Narrowest correct implementation**: Website-local copy, docs content, route metadata, CTA, trust/pricing/contact/FAQ/footer, and claim-safety updates inside `apps/website`.
-- **Ownership cost created**: Future public website changes must preserve the documented claim-safety, CTA consistency, and content hierarchy rules.
-- **Alternative intentionally rejected**: Starting with layout rhythm or introducing a broader content framework was rejected because the current need is stable copy and section intent, not new visual or runtime architecture.
-- **Release truth**: Current-release public website messaging truth.
 
-## Phase 0 Research
+- MSP Operatoren
+- Enterprise IT
+- Security & Audit
 
-Research output is captured in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md`.
+The section must show one reliable evidence basis for operators, security owners, and auditors. It should replace screenshot, Excel, and gut-feel decision language with review-ready evidence and traceable findings.
 
-**Resolved clarifications**:
+### 5. Differentiation Section
 
-- The feature uses the existing Astro 6 website and does not need a new framework or design-system decision.
+Differentiate Tenantial without attacking Microsoft tools:
-- The public contract is route content, metadata, CTA behavior, docs exposure, and claim posture; there are no API endpoints or data entities to contract.
-- The implementation must stabilize content before Spec 405 visual rhythm work.
-- Public Microsoft tenant wording is allowed as product positioning but must not imply website runtime provider access, Microsoft endorsement, or Microsoft Graph execution.
-- Validation stays in website build, public Playwright smoke, manual browser/content review, and `apps/platform` scope checks.
 
-## Phase 1 Design
+- Tenantial does not replace Microsoft Admin Center.
+- Tenantial adds versioning, evidence, drift visibility, review context, and auditability.
+- Tenantial is built for governance and controlled review, not blind automation.
 
-Design output is captured in:
+### 6. Trust Teaser
 
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md`
+Keep the trust teaser safe and specific:
-- `/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`
 
-No REST, GraphQL, database, Laravel, Filament, Livewire, Microsoft Graph, queue, job, policy, RBAC, or product runtime contracts are introduced.
+- allowed: audit trail, review packs, role-aware evidence, controlled recovery preparation, decision traceability
+- forbidden unless proven: DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, complete evidence coverage, no-customer-data claims
 
-## Post-Design Constitution Check
+Do not make trust the hero story in Spec 404. A separate trust-focused spec can deepen it.
 
-**Post-Design Gate Result**: PASS
+### 7. Bottom CTA
 
-- The Phase 1 design remains website-local.
+End with an evaluation-oriented CTA:
-- All clarification markers are resolved.
+
-- No product persistence, abstractions, state families, provider/platform seams, OperationRun behavior, RBAC behavior, Filament behavior, or Graph calls are introduced.
+- Headline: "Bereit, Microsoft 365 Governance messbar zu machen?"
-- Browser/static validation remains explicit and bounded to `apps/website`.
+- Body: "Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt."
-- `apps/platform` remains out of scope and must be verified by `git status --short -- apps/platform`.
+- Buttons: "Demo buchen" and "Plattform ansehen"
+
+### 8. SEO And Metadata Direction
+
+SEO metadata must compress the same B2B message:
+
+- Tenantial = Microsoft 365 policy governance
+- outcomes = drift detection, versioned backups, evidence, reviews, controlled recovery preparation, auditability
+- audiences = MSPs, Enterprise IT, Security, Audit
+- first domain = Intune
+- future posture = prepared for further policy domains, not live multi-cloud
+
+Do not use Intune-only, backup-only, autonomous remediation, or certification-heavy metadata.
+
+## Claim Guardrails And Static Search Terms
+
+Later implementation must include static scans for stale or unsafe copy. At minimum, scan website source and emitted public output when applicable for:
+
+- `Die richtige Produktkategorie zuerst`
+- `Für Teams, die Governance gemeinsam tragen`
+- `Klare Grenzen statt überzogener Versprechen`
+- `Den nächsten Schritt bewusst wählen`
+- `provider-extensible managed environment operating model`
+- `source-of-truth first operating model`
+- `Observe-to-Audit`
+- `governance-of-record`
+- `unter absoluter Kontrolle`
+- `Drift in Echtzeit`
+- `automatisch reparieren`
+- `autonomous remediation`
+- `Self-healing`
+- `automatic restore`
+- `lückenlose Evidenz`
+- `gerichtsfeste Nachweise`
+- `immutable backups`
+- `DSGVO-konform`
+- `ISO-zertifiziert`
+- `NIS2-konform`
+- `Google supported`
+- `AWS supported`
+- `multi-cloud supported`
+- `href="#"`
+- `lorem ipsum`
+
+Safe copy can still use "Microsoft 365 first", "Intune als erster starker Policy-Fokus", and "für weitere Policy-Domänen vorbereitet" when the surrounding text clearly separates current capability from roadmap or architecture direction.
+
+## Browser Smoke Requirements For Later Implementation
+
+Later implementation must verify:
+
+- desktop and mobile homepage first viewport reads cleanly
+- hero headline, subhead, supporting line, and CTAs are visible and not overlapping
+- section order matches the spec: hero, problem, capabilities, stakeholders, differentiation, trust teaser, bottom CTA
+- CTA targets are real routes or intentional in-page anchors
+- no placeholder links remain
+- no forbidden claims render in source or public output
+- metadata reinforces Microsoft 365 policy governance
+- Intune appears only as first domain or example focus
+- provider-extensible wording does not imply Google, AWS, or multi-cloud live support
+- `apps/platform` remains untouched
+
+Use the existing website scripts from `apps/website/package.json` and root workspace scripts only after verifying they exist.
+
+## Runtime And Scope Boundaries
+
+This plan is intentionally static-website-only for the current task:
+
+- no platform source edits
+- no build output edits
+- no dependency changes
+- no package-script changes
+- no backend runtime changes
+- no provider implementation changes
+- no `apps/platform` changes
+
+## Validation For This Spec Update
+
+For the current website-copy implementation, validation includes:
+
+- `corepack pnpm build:website`
+- targeted static claim scan for forbidden public copy in `apps/website/src` and `apps/website/public`
+- browser review on `http://127.0.0.1:4321/`
+- `git diff --check`
+- `git status --short -- apps/website apps/platform`
+- `git diff --name-only`
+
+Expected result: only approved 404 spec artifacts plus minimal `apps/website` source and website-smoke-test files are modified, with any pre-existing unrelated untracked files left untouched.
+
+## Follow-Up Specs
+
+- **405 Trust**: proof-backed trust, hosting, privacy, security, compliance, legal, and evidence claims
+- **406 Provider Taxonomy**: public current-versus-planned policy-domain and provider vocabulary
+- **407 Use Cases**: dedicated MSP, Enterprise IT, Security/Audit, Recovery, and Review landing pages

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

@@ -1,4 +1,4 @@
-# Quickstart: Spec 404 Public Content Architecture & Messaging
+# Quickstart: Spec 404 Public Website Positioning & Content Architecture
 
 ## Scope
 
@@ -15,6 +15,19 @@ ## Scope
 /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
@@ -38,51 +51,55 @@ ## Read-Only Content Audit
 Review public content sources before editing:
 
 ```bash
-cd /Users/ahmeddarrazi/Documents/projects/wt-website
+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
-rg -n "Tenantial|TenantAtlas|TenantPilot|TenantCTRL|ScrewFast|construction|hardware|manufacturing|trusted by|SOC 2|ISO|uptime|checkout|subscribe|sign up|login" apps/website/src
 ```
 
-Audit these content surfaces:
+Audit these content surfaces first:
 
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/pricing.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/trust.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/contact.astro`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files`
+- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/ContactPage.astro`
-- `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.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`
 - `/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 evidence-first governance for Microsoft tenant configuration
+- hero identifies Tenantial as policy governance and Microsoft 365 first
-- first two sections mention at least three of backup, restore, drift, findings, evidence, audit trail, exceptions, and reviews
+- provider-extensible language stays future-safe and does not claim live non-Microsoft support
-- headings read as a coherent story from product category to evaluation
+- operating-model section covers observe, evidence, detect, review, decide, and audit
-- each section adds new meaning
+- capability framing emphasizes policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability
-- CTAs match buyer stage and route intentionally
+- audience and boundary sections add meaning instead of repeating the hero
+- CTAs match real buyer-stage destinations
 
 For `/platform`:
 
-- explains backup, restore, drift, findings, evidence, auditability, exceptions, and reviews as one model
+- explains the governance model more deeply than the homepage
-- stays public and does not cite `apps/platform`
+- keeps Microsoft 365 first focus without collapsing back to Intune-only framing
 - frames previews as static/demo/illustrative where needed
-- does not imply live Microsoft tenant connection or Graph execution
+- does not cite or depend on `apps/platform`
+- does not imply live provider connection, Graph execution, or live tenant/customer data
 
 For pricing/evaluation:
 
-- contact-led and scoped
+- remains contact-led and scoped
-- no checkout, subscription activation, self-serve billing, account creation, or unsupported entitlement claims
+- 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 SOC 2, ISO, Microsoft endorsement, uptime, recovery, compliance, or customer-proof claims
+- no unsupported German hosting, DSGVO/GDPR, AVV/TOM, ISO/BSI/NIS2, endorsement, or customer-proof claims
-- no fake customer logos, testimonials, or "trusted by" claims
+- no fake logos, testimonials, or compliance badges
-- no public website live-tenant-data implication
+- no autonomous remediation or automatic restore claims
-- no newsletter, login, scheduling, or backend submission implication unless implemented
+- no public website live-data implication
 
 ## Build Validation
 
@@ -96,9 +113,10 @@ ## Smoke Validation
 cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke
 ```
 
-## Static Git Validation
+## 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
 ```
@@ -107,7 +125,7 @@ ## Static Git Validation
 
 ## Manual Browser Review
 
-Review these routes in desktop and mobile widths, light and dark modes:
+Review these routes in desktop and mobile widths:
 
 - `/`
 - `/platform`
@@ -126,28 +144,27 @@ ## Manual Browser Review
 
 Check:
 
-- product category is clear from the homepage hero and first sections
+- the homepage hero no longer frames the product as Intune-only
-- homepage headings form a coherent narrative
+- the public category is policy governance and Microsoft 365 first
-- `/platform` explains the product model more deeply than the homepage
+- provider-extensible wording does not imply live Google/AWS support
-- pricing remains conservative and contact-led
+- the operating model is visible and coherent
-- trust copy avoids unsupported proof
+- Intune appears only as one domain when named
-- CTAs are consistent and targets are intentional
+- trust copy does not overclaim compliance, hosting, certification, or automation
+- CTAs are concrete and intentional
 - no `href="#"` placeholders are visible or emitted
-- no forbidden public residue terms appear in visible copy or metadata
+- no forbidden residue terms appear in visible copy or metadata
-- static product previews are framed as illustrative/static/demo content where needed
 - keyboard users can reach navigation, CTAs, footer links, FAQ controls, and visible controls
 - visible focus states are present
 - no body-level horizontal overflow occurs
-- reduced-motion mode leaves content understandable
 
 ## Handoff
 
 Implementation summary must document:
 
-- changed public pages and docs surfaces
+- changed public routes and shared copy surfaces
-- CTA language decisions
+- provider-posture and claim-safety decisions
-- claim-safety decisions
+- CTA and navigation changes
 - metadata changes
-- validation results
+- validation commands and outcomes
-- remaining content follow-ups
+- deferred follow-up work for later public website specs
 - `apps/platform` untouched confirmation

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

@@ -1,100 +1,91 @@
-# Phase 0 Research: `apps/website` Public Content Architecture & Messaging
+# Phase 0 Research: Public Website Positioning & Content Architecture
 
-## Decision: Keep the Spec 402/403 Astro website foundation
+## Decision: Keep the existing Astro website foundation and shared copy architecture
 
-**Rationale**: The active website is a standalone Astro app at `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` with Starlight docs, sitemap generation, Tailwind v4, Preline, Lenis, and Playwright smoke tests already in place. Spec 404 is a content architecture and messaging pass, not another rebuild.
+**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 Spec 402.
+- Rebuild the public website foundation: rejected by scope and unnecessary after Specs 400-403.
-- Introduce a new design system or content framework: rejected because this feature should stabilize copy before Spec 405 visual polish.
+- 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 separate from the Laravel/Filament application and `apps/platform` is out of scope.
+- 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 content surfaces, CTAs, metadata, and claim posture as the contract
+## Decision: Treat public route behavior, messaging claims, CTAs, and metadata as the contract
 
-**Rationale**: This feature has no API endpoints or product runtime entities. The public behavior that matters is expressed through static pages, docs content, navigation/footer links, route metadata, CTA targets, FAQ/trust/pricing/contact copy, and generated public output.
+**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 readiness as product runtime state: rejected because it would create unnecessary taxonomy or persistence.
+- Model messaging states as persisted product data: rejected because it would create unnecessary taxonomy or persistence.
-- Leave the contract implicit in copy review comments: rejected because later layout work needs stable section intent and CTA rules.
+- Leave behavior implicit in review comments: rejected because the later implementation and smoke updates need stable, explicit rules.
 
-## Decision: Use a homepage narrative from category to evaluation
+## Decision: Use a homepage operating model instead of an Intune-first feature list
 
-**Rationale**: The homepage should tell a coherent story when headings are read in order. The content sequence should move from product category, to buyer problem, to evidence-first governance model, to capability groups, to evaluation and next action.
+**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 independent theme sections with similar claims: rejected because the spec identifies repetition and weak hierarchy as the core problem.
+- 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 feature grids: rejected because buyers first need category clarity and trust-safe product framing.
+- Lead with pricing or generic SaaS value claims: rejected because category clarity and trust-safe positioning must come first.
-- Optimize layout before copy: rejected because section spacing should follow stable content.
+- Defer narrative changes until visual polish: rejected because later layout decisions should follow stable section intent.
 
-## Decision: Make `/platform` the deeper public product-model page
+## Decision: Make `/platform` the deeper governance-model page and keep `/product` as the redirect alias
 
-**Rationale**: The public `/platform` route should explain how backup, restore, drift, findings, evidence, auditability, exceptions, and reviews fit together as one operating model. It must remain public positioning and must not use or imply internal `apps/platform` runtime behavior.
+**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**:
 
-- Mirror homepage copy on `/platform`: rejected because the page should carry deeper product-model explanation.
+- Maintain two competing product explanation pages: rejected because it would fragment the public story.
-- Reference admin implementation details: rejected because the public route must not be coupled to Laravel, Filament, Livewire, RBAC, tenant data, or Graph runtime code.
+- Mirror homepage copy on `/platform`: rejected because the route should go deeper than the homepage.
-- Present previews as live tenant output: rejected because previews are static/demo content only.
+- Reference internal admin implementation details: rejected because the public route must not imply Laravel/Filament/Livewire/runtime coupling.
 
-## Decision: Keep evaluation and pricing contact-led
+## Decision: Keep Microsoft 365 as the first focus and bound provider-extensible claims explicitly
 
-**Rationale**: No self-serve billing, checkout, account creation, instant subscription, fixed entitlement, or automated scheduling workflow has been supplied. Pricing and evaluation language should therefore describe scoped conversations, rollout planning, and contact-led evaluation.
+**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**:
 
-- Publish fixed SaaS plan entitlements: rejected because entitlement and billing truth is not available.
+- Present the product as Intune-only: rejected because it narrows the intended category too far.
-- Use consumer-style pricing tables with strong contrast: rejected because this spec focuses on calm enterprise trust and content clarity, not fake commercial certainty.
+- Present the product as broadly provider-agnostic today: rejected because current support truth does not justify it.
-- Hide pricing entirely: rejected because buyers still need evaluation expectations and a credible next step.
+- Avoid provider posture entirely: rejected because the spec requires safe provider-extensible framing.
 
-## Decision: Build trust through explicit restraint, not fake proof
+## Decision: Build trust through restrained claims and explicit boundaries
 
-**Rationale**: The spec assumes no verified customer logos, testimonials, certifications, Microsoft partnership proof, uptime guarantees, recovery guarantees, or compliance guarantees. Trust content should explain what Tenantial is intended to help make reviewable and auditable without claiming proof that has not been supplied.
+**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 enterprise proof language: rejected because it creates public trust risk.
+- Use aspirational trust claims to sound enterprise-ready: rejected because it creates legal and commercial risk.
-- Keep generic "trusted by" or certification placeholders: rejected unless removed or rewritten as neutral proof-safe language.
+- Remove trust language entirely: rejected because evaluators still need a clear, honest trust posture.
-- Avoid all trust language: rejected because security-conscious buyers need careful explanations of claim boundaries.
+- Hide boundaries and hope later trust pages fix them: rejected because public pages need safe wording now.
 
-## Decision: Normalize CTA intent before changing labels
+## Decision: Reuse the current smoke suite and augment it with claim scans rather than inventing new test families
 
-**Rationale**: CTA consistency should be based on buyer intent. Primary CTAs should lead to contact/demo/walkthrough intent, secondary CTAs should lead to product explanation, trust, pricing, or docs review, and no CTA should imply unavailable workflows.
+**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**:
-
-- Let each page invent local CTA language: rejected because CTA inconsistency is a stated problem.
-- Use "Sign up", "Start trial", "Subscribe", "Login", or "Buy now": rejected unless those workflows actually exist.
-- Route all CTAs to the same page: rejected because secondary educational CTAs should remain useful and contextual.
-
-## Decision: Keep docs exposure intentional
-
-**Rationale**: Exposed docs routes must contain intentional Tenantial-specific content or be hidden from navigation. Docs must not imply product behavior, support commitments, or integration claims that are not available.
-
-**Alternatives considered**:
-
-- Leave placeholder docs visible: rejected because public placeholder content weakens trust.
-- Remove all docs routes immediately: rejected unless review shows a route is not ready for intentional content.
-- Treat non-navigation docs as irrelevant: rejected because emitted public routes still affect public perception and indexing.
-
-## Decision: Validate with website build, public smoke, manual browser/content review, and scope checks
-
-**Rationale**: The current package scripts support `corepack pnpm build:website` and `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`. These lanes prove the public static website without pulling in Laravel runtime cost. Manual review remains necessary for narrative quality and claim safety.
 
 **Alternatives considered**:
 
 - Run Laravel/Pest/Filament tests: rejected because this feature does not touch `apps/platform`.
-- Rely only on copy review: rejected because public output still needs route, CTA, metadata, responsive, and smoke validation.
+- Add a new website-only test framework: rejected because the current smoke suite already covers the needed route and claim surfaces.
-- Add new browser test families now: rejected unless implementation changes require them; existing smoke can be updated proportionally during tasks.
+- 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 public pages are under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages`.
+- 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`.
-- Shared public copy and constants are likely to involve `/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/utils/navigation.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`.
+- 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`.
-- Starlight/docs content is under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`.
+- 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`.
-- Existing smoke tests live under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`.
+- Locale routing is mirrored under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` using shared component and copy sources.
-- Public route mirrors exist under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` and should be reviewed consistently with German default routes where currently exposed.
+- Starlight docs content lives under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` and is publicly rendered.
-- Placeholder content collections for blog, insights, and products exist in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content`; any public exposure must stay intentional and claim-safe.
+- 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

@@ -1,451 +1,409 @@
-# Feature Specification: `apps/website` Public Content Architecture & Messaging
+# Spec 404 - Public Website Sales Copy & Positioning Rewrite
 
 **Feature Branch**: `404-public-content-messaging`
 
-**Created**: 2026-05-22
+**Created**: 2026-05-25
 
 **Status**: Draft
 
-**Input**: User description: "Create Spec 404 for `apps/website` Public Content Architecture & Messaging before the later homepage layout rhythm and visual productization spec."
+**Input**: Rewrite the public Tenantial website positioning so a later website implementation can ship strong B2B SaaS, cybersecurity, and IT-operations sales copy instead of internal architecture, governance-process, or Spec Kit language.
 
-## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
+## Spec Candidate Check
 
-- **Problem**: The current public website has a safe foundation, but its copy still reads like a conservative theme adaptation rather than a clear Tenantial product narrative.
+- **Problem**: The current public website copy reads too much like an internal governance and architecture explanation. MSPs, IT leaders, security teams, and enterprise IT buyers need to understand the risks Tenantial reduces and the business outcomes it supports.
-- **Today's failure**: Visitors can miss the product category, see repeated claims across sections, or infer unsupported proof, billing, or live-tenant behavior from provisional public copy.
+- **Today's failure**: The site can sound defensive, philosophical, or category-first instead of clearly selling Microsoft 365 policy control, drift visibility, versioned configuration backups, review-ready evidence, controlled recovery preparation, and auditability.
-- **User-visible improvement**: Public visitors can understand Tenantial as evidence-first governance for Microsoft tenant configuration, follow the homepage story, and see consistent conservative CTAs and trust language.
+- **User-visible improvement**: A buyer can understand what Tenantial helps them do, why it matters, who it serves, and which Microsoft 365 governance risks it addresses without needing internal product or architecture context.
-- **Smallest enterprise-capable version**: Rewrite and normalize public website copy, headings, CTA labels, route metadata, FAQ/trust/pricing language, and claim-safety wording across the core public routes without changing the website foundation.
+- **Smallest enterprise-capable version**: Rewrite the governing Spec 404 artifacts so the next implementation agent has a concrete homepage copy contract, safe claim guardrails, section structure, CTA language, SEO direction, and acceptance criteria.
-- **Explicit non-goals**: No website rebuild, no broad visual redesign, no new design system, no backend workflows, no login/signup/billing/checkout/newsletter behavior, no Microsoft Graph behavior, and no changes to `apps/platform`.
+- **Explicit non-goals**: No `apps/platform` edits, no backend/runtime dependency changes, no database changes, no provider implementation, no trust/certification claims, and no unsupported production capability claims.
-- **Permanent complexity imported**: No persisted models, services, enums, runtime workflows, or product capability layers. The durable complexity is limited to sharper public messaging rules and route-level content ownership.
+- **Permanent complexity imported**: No models, services, enums, runtime flows, providers, persisted data, UI frameworks, or new website architecture. This spec imports only public copy rules and claim discipline.
-- **Why now**: Layout polish should follow stable content; otherwise spacing and visual hierarchy would be optimized around copy that may still change.
+- **Why now**: Public positioning is the input for later landing-page work. If the spec remains architecture-heavy, later implementation will optimize the wrong message.
-- **Why not local**: The issue crosses homepage, product, pricing, trust, contact, docs navigation, metadata, footer, and CTA language, so isolated copy fixes would keep the narrative fragmented.
+- **Why not local**: The correction must align `spec.md`, `plan.md`, and `tasks.md`; otherwise future implementation can still pull from old defensive, academic, or internal wording.
 - **Approval class**: Core Enterprise.
-- **Red flags triggered**: Public claim-safety risk; cross-route messaging consistency risk. No persistence, taxonomy, or runtime behavior red flags.
+- **Red flags triggered**: Public category ambiguity, trust-claim risk, provider overclaim risk, internal language leaking into buyer-facing copy.
-- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 2 | Produktnähe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12**
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12**
 - **Decision**: approve.
 
-## Spec Scope Fields *(mandatory)*
+### Red Flag Defense
 
-- **Scope**: Public website content surfaces in `apps/website`.
+This spec intentionally proceeds despite multiple red flags because the risks are public-facing trust and positioning risks, not a request for new platform machinery. The current correction prevents misleading public claims, Intune-only framing, unsupported provider language, and architecture-first marketing copy. The scope is deliberately narrow: only the 404 spec artifacts are rewritten now, and later implementation remains website-only. No runtime provider seam, persistence model, taxonomy, framework, or platform contract is introduced.
-- **Primary Routes**: `/`, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs routes, public navigation, FAQ surfaces, footer, and route metadata.
-- **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 explanation pages.
-
-For canonical-view specs, the spec MUST define:
-
-- **Default filter behavior when tenant-context is active**: N/A - no canonical tenant or workspace view is introduced.
-- **Explicit entitlement checks preventing cross-tenant leakage**: N/A - no tenant data, entitlement 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 only.
-- **Interaction class(es)**: public navigation, CTA labels, route metadata, FAQ copy, footer copy, and page-level product messaging.
-- **Systems touched**: `apps/website` public routes, shared website copy/components where already used, sitemap/robots-adjacent public route visibility if affected by navigation exposure.
-- **Existing pattern(s) to extend**: The current ScrewFast-derived public website structure and Spec 402/403 route model.
-- **Shared contract / presenter / builder / renderer to reuse**: Existing website content/component organization; no new shared runtime contract.
-- **Why the existing shared path is sufficient or insufficient**: The existing website substrate is sufficient for public content updates, but the current copy does not yet provide a stable Tenantial messaging architecture.
-- **Allowed deviation and why**: Bounded copy and metadata changes are allowed. Broad layout redesign and new design-system work are deferred to Spec 405.
-- **Consistency impact**: CTA wording, proof-safe trust language, product category language, and static/demo preview framing must stay aligned across all public pages.
-- **Review focus**: Reviewers must verify that copy changes do not create parallel brand claims, fake proof, unsupported workflows, 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, notification, queue, or link semantics are 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?**: no.
-- **Boundary classification**: N/A.
-- **Seams affected**: Public website wording about Microsoft tenant governance only.
-- **Neutral platform terms preserved or introduced**: Governance, evidence, findings, drift, restore planning, auditability, exceptions, reviews, evaluation, and rollout.
-- **Provider-specific semantics retained and why**: Microsoft tenant configuration remains part of the public product category, but public copy must not imply live provider access, Microsoft endorsement, or Microsoft Graph execution by the website.
-- **Why this does not deepen provider coupling accidentally**: The feature changes public positioning, not provider contracts, product runtime, tenant data handling, or platform-core taxonomies.
-- **Follow-up path**: Spec 405 may use the stabilized copy for visual rhythm and product preview polish.
-
-## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
-
-N/A - no operator-facing platform surface changes. 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 buyers do not yet get a crisp product story, and claim-sensitive pages still need stronger content discipline before layout work.
-- **Existing structure is insufficient because**: Specs 402 and 403 established the website foundation and launch-readiness guardrails, but they did not finalize public messaging hierarchy, CTA language, or proof-safe page-level copy.
-- **Narrowest correct implementation**: Update public website copy, route metadata, CTA labels, FAQ/trust/pricing wording, and exposed docs/navigation content only.
-- **Ownership cost**: Future public website changes must preserve the same claim-safety and CTA consistency rules.
-- **Alternative intentionally rejected**: Starting with homepage spacing and visual productization was rejected because content determines which sections, headings, CTAs, and product previews need visual priority.
-- **Release truth**: Current-release public website truth; not future-only preparation.
-
-### 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, route metadata, navigation/CTA wording, and claim safety; build and smoke checks prove the public output still renders and routes correctly.
-- **New or expanded test families**: none required by this specification.
-- **Fixture / helper cost impact**: none.
-- **Heavy-family visibility / justification**: none.
-- **Special surface test profile**: N/A.
-- **Standard-native relief or required special coverage**: Public website build, smoke, residue, CTA, and scope checks are sufficient.
-- **Reviewer handoff**: Reviewers must confirm content quality, conservative claims, intentional CTAs, route safety, and that `apps/platform` remains untouched.
-- **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`; `git diff --check`; `git status --short -- apps/platform`.
-
-## Depends On
-
-- Spec 402 - `apps/website` ScrewFast Website Rebuild
-- Spec 403 - `apps/website` Public Website Launch Readiness
 
 ## Scope
 
-This spec is strictly local to `apps/website`.
+This spec is a copy and positioning contract for the public Tenantial website.
 
-It focuses on public website content architecture, messaging hierarchy, CTA language, page-level copy, route metadata, and claim safety.
+- **Relevant application for later implementation**: `apps/website`
+- **Files changed by this implementation**: 404 spec artifacts plus the minimal `apps/website` source and website-smoke-test files needed to render and validate the approved homepage sales copy.
+- **Out of scope for this change**: platform source files, build output, runtime config, database, Laravel, Filament, Microsoft Graph integration, provider implementation, and unsupported trust/certification claims.
+- **Product focus**: Microsoft 365 is the first public market
+- **Start domain**: Intune may appear as the first strong policy focus and example domain
+- **Product boundary**: Intune must not be framed as the full product boundary
+- **Provider posture**: prepared for further policy domains may be used as an architecture or roadmap signal; Google, AWS, or multi-cloud support must not appear as live features unless separately proven by repo/product truth
 
-It does not redesign the website layout. It does not rebuild the ScrewFast-derived foundation. It does not recreate `apps/website`.
+## Spec Scope Fields
+
+- **Scope**: Public website copy and positioning contract.
+- **Primary Routes**: `apps/website`, primarily `/`, with supporting alignment possible for public website routes such as `/platform`, `/trust`, `/pricing`, `/contact`, and public metadata.
+- **Data Ownership**: No tenant-owned, workspace-owned, customer, provider, backup, evidence, or runtime product data is created, read, changed, or persisted.
+- **RBAC**: N/A. This spec concerns public website copy guidance and does not change authenticated platform access, tenant access, roles, permissions, or authorization behavior.
+
+For canonical-view specs:
+
+- **Default filter behavior when tenant-context is active**: N/A - no tenant-context view 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.
+
+## Positioning Goal
+
+Tenantial must be presented as a hard, credible B2B platform for Microsoft 365 governance and IT operations.
+
+Visible website copy must emphasize outcomes:
+
+- Microsoft 365 policies under control
+- early detection of policy drift
+- versioned configuration backups
+- evidence prepared for reviews, changes, recovery, and audits
+- controlled recovery and restore preparation
+- multi-customer and multi-tenant operating clarity for MSPs
+- shared evidence for IT, security, and audit teams
+- traceable decisions through findings, exceptions, accepted risks, follow-ups, and review packs
+
+The website must not lead with internal product philosophy, architecture, or taxonomy. It should sound like a product marketing manager for a B2B cybersecurity and IT-operations SaaS wrote it: active, direct, technically credible, outcome-oriented, and commercially useful.
+
+## Visible Copy Rules
+
+### Required Tone
+
+Visible public copy must be:
+
+- active and confident
+- technically credible without becoming a whitepaper
+- outcome-oriented
+- MSP- and enterprise-ready
+- specific about Microsoft 365 governance risks
+- clear about review, evidence, drift, backup, and recovery context
+- careful with compliance, automation, hosting, and provider claims
 
-## Important Scope Clarification
+Visible public copy must not be:
 
-In this feature, the word "platform" refers only to the public website route `/platform` inside `apps/website`.
+- defensive
+- academic
+- life-coach style
+- internal wiki prose
+- Spec Kit language
+- architecture-first
+- category-philosophy-first
+- vague neutral SaaS copy
 
-It does not refer to the Laravel/Filament application in `apps/platform`.
+### Do Not Use As Visible Marketing Headline Language
 
-`apps/platform` is completely out of scope:
+The following concepts and phrases must not be used as primary visible landing-page language:
 
-- do not modify it
+- "Die richtige Produktkategorie zuerst"
-- do not import from it
+- "Für Teams, die Governance gemeinsam tragen"
-- do not inspect it as a content source
+- "Klare Grenzen statt überzogener Versprechen"
-- do not run Laravel, Filament, Livewire, Blade, migrations, policies, providers, jobs, queues, database, tenant/workspace, RBAC, or Microsoft Graph code
+- "Den nächsten Schritt bewusst wählen"
-- only verify through `git status --short -- apps/platform` that it remains untouched
+- "provider-extensible managed environment operating model"
+- "source-of-truth first operating model"
+- "Policy Governance Kategorie"
+- "Observe-to-Audit operating model"
+- "governance-of-record platform"
+- "platform-core seam"
+- "provider-owned boundary"
+- "Spec Candidate Check"
+- "proportionality review"
 
-## Goal
+These ideas may inform internal planning, but they must not be the buyer-facing story.
 
-Establish a clear, conservative, enterprise-ready public messaging system for Tenantial before visual layout polish.
+### Preferred Public Language
 
-The website should communicate:
+Use direct, market-facing language such as:
 
-- what Tenantial is
+- "Microsoft 365 Policies unter Kontrolle bringen"
-- who it is for
+- "Policy-Drift früh erkennen"
-- which Microsoft tenant governance problems it addresses
+- "Konfigurationsstände versioniert sichern"
-- why evidence-first governance matters
+- "auditfähige Evidence vorbereiten"
-- how backup, restore, drift, findings, exceptions, auditability, and reviews fit together
+- "prüfbare Review Packs"
-- what a visitor should do next
+- "kontrollierte Recovery- und Restore-Vorbereitung"
+- "nachvollziehbarer Audit Trail"
+- "Microsoft 365 first"
+- "Intune als erster starker Policy-Fokus"
+- "für weitere Policy-Domänen vorbereitet"
 
-The content should be strong enough that a later layout-rhythm spec can optimize around stable section intent instead of placeholder copy.
+## Claim Guardrails
 
-## Non-Goals
+### Forbidden Or Strongly Restricted Claims
 
-This spec does not:
+Visible website copy must not claim:
 
-- change the ScrewFast-derived foundation
+- "unter absoluter Kontrolle"
-- rebuild or recreate `apps/website`
+- "Drift in Echtzeit", unless technically proven
-- perform broad visual redesign
+- "automatisch reparieren"
-- introduce a new design system
+- "autonomous remediation"
-- add backend forms, auth, billing, newsletter, login, checkout, account creation, or self-serve subscription behavior
+- "Self-healing"
-- add new product runtime capabilities
+- "automatic restore"
-- introduce Microsoft Graph calls
+- "lückenlose Evidenz", unless precisely scoped and proven
-- claim integrations or certifications that are not verified
+- "gerichtsfeste Nachweise"
-- add customer logos, testimonials, or "trusted by" claims
+- "immutable backups", unless real immutability is proven for the public claim context
-- touch `apps/platform`
+- "DSGVO-konform"
-- change Filament, Livewire, Laravel, Blade, providers, policies, migrations, jobs, queues, database, tenant isolation, workspace behavior, RBAC, or AuditLog behavior
+- "ISO-zertifiziert"
+- "NIS2-konform"
+- "Google supported"
+- "AWS supported"
+- "multi-cloud supported" as a live-feature claim
 
-## Problem
+### Safe Alternatives
 
-Spec 402 created the correct website foundation, and Spec 403 made the public website safer for launch. However, the current homepage and public pages still feel like a theme adaptation with conservative placeholder copy. The messaging is directionally correct but not yet sharp enough for an enterprise SaaS buyer.
+Use safer phrasing:
 
-Current issues:
+- "Policy-Drift früh erkennen"
+- "Konfigurationsstände versioniert sichern"
+- "auditfähige Evidence vorbereiten"
+- "Review Packs für Audits und Kundentermine vorbereiten"
+- "Recovery- und Restore-Fragen kontrolliert bewerten"
+- "Restore vorbereiten, bevor Änderungen ausgeführt werden"
+- "Nachvollziehbarkeit für Changes, Findings und Accepted Risks schaffen"
+- "Microsoft 365 first"
+- "Intune als erster starker Policy-Fokus"
+- "für weitere Policy-Domänen vorbereitet"
 
-- Hero messaging is long and visually heavy.
+### Trust And Compliance Posture
-- The homepage repeats similar concepts without a clear content hierarchy.
-- Product previews do not yet map to a crisp narrative.
-- Pricing/evaluation language feels provisional.
-- FAQ answers are safe but not yet strong.
-- Trust language is conservative but could better explain what is and is not claimed.
-- CTA labels need consistent buyer intent.
-- The website does not yet fully express the difference between Tenantial as governance-of-record and a helpdesk/device-action tool.
 
-## Content Positioning Principles
+Trust copy may speak about auditability, review preparation, role-aware evidence, and decision traceability. It must not imply legal certification, regulatory conformity, hosting guarantees, or customer-proof artifacts that are not currently proven.
 
-Public copy must follow these principles:
+## Homepage Copy Contract
 
-1. **Governance-of-record, not helpdesk**: Tenantial should be positioned as a governance, evidence, review, audit, backup/restore, and drift-control product for Microsoft tenant configuration.
+The later homepage implementation must follow this section structure unless a later approved spec narrows it.
-2. **Evidence-first**: The core message is not simply "backup Intune." It is "make tenant configuration changes reviewable, attributable, and recoverable through evidence."
-3. **Operator-safe**: Public copy must avoid implying blind automation, automatic restore success, or uncontrolled live tenant action.
-4. **Enterprise calm**: Copy should be precise, restrained, and credible. Avoid hype, inflated AI language, fake urgency, and unsupported security/compliance promises.
-5. **Public website only**: Marketing language may explain product intent, but must not imply that the public website itself connects to Microsoft tenants, runs Graph calls, or shows live tenant data.
-6. **No fake proof**: No customer logos, testimonials, certifications, Microsoft endorsements, uptime guarantees, compliance guarantees, or recovery guarantees unless verified proof is supplied.
 
-## User Scenarios & Testing *(mandatory)*
+### 1. Hero
 
-### User Story 1 - Understand The Product Category (Priority: P1)
+**Headline**
 
-A first-time visitor opens the homepage and understands that Tenantial is an evidence-first governance product for Microsoft tenant configuration.
+> Microsoft 365 Policies unter Kontrolle bringen.
 
-**Why this priority**: If visitors cannot quickly categorize the product, layout polish will not fix the website.
+**Subhead**
 
-**Independent Test**: Read the hero and first two homepage sections without relying on visuals.
+> Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.
 
-**Acceptance Scenarios**:
+**Supporting line**
 
-1. **Given** a visitor opens `/`, **When** they read the hero, **Then** they can identify Tenantial as a governance/evidence product for Microsoft tenant configuration.
+> Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen.
-2. **Given** they read the first two sections, **When** they summarize the product, **Then** they mention at least three of: backup, restore, drift, findings, evidence, audit trail, exceptions, reviews.
-3. **Given** they compare Tenantial to a helpdesk or device-action product, **When** reading the page, **Then** they understand Tenantial is not positioned as a helpdesk/device-action surface.
 
----
+**CTAs**
 
-### User Story 2 - Follow A Clear Website Narrative (Priority: P1)
+- Demo buchen
+- Plattform ansehen
 
-A buyer scrolls the homepage and sees a deliberate narrative from problem to model to capability to evaluation.
+### 2. Problem Section
 
-**Why this priority**: A strong homepage needs a content sequence, not just independent sections.
+**Headline**
 
-**Independent Test**: Read homepage section headings and subheadings in order.
+> Wenn Microsoft 365 Policies driften, reicht ein Admin Center nicht aus.
 
-**Acceptance Scenarios**:
+**Body**
 
-1. **Given** a visitor scans headings only, **When** they move from hero to footer, **Then** the section sequence tells a coherent story.
+> Tenantial zeigt, was sich geändert hat, welche Konfigurationen abgesichert sind, welche Evidence vorliegt und welche Findings vor dem nächsten Review geklärt werden müssen.
-2. **Given** a visitor reads body copy, **When** moving through sections, **Then** each section adds new meaning instead of repeating the same claims.
-3. **Given** a CTA appears, **When** read in context, **Then** it matches the visitor's likely decision stage.
 
----
+### 3. Capability Cards
 
-### User Story 3 - Explain The Public Product Model On `/platform` (Priority: P1)
+1. **Policy-Drift erkennen**
+   Abweichungen zwischen erwarteter und tatsächlicher Konfiguration sichtbar machen.
 
-A visitor opens `/platform` and understands Tenantial's product model in more detail.
+2. **Backups & Versionen behalten**
+   Policy-Zustände nachvollziehbar sichern und Änderungen historisch vergleichbar machen.
 
-**Why this priority**: The `/platform` route is the main product explanation page and should hold deeper messaging than the homepage.
+3. **Auditfähige Reviews vorbereiten**
+   Findings, Evidence, Accepted Risks und Review Packs für Kundentermine und interne Audits bündeln.
 
-**Independent Test**: Read `/platform` copy without using admin/platform code as a source.
+4. **Recovery kontrolliert vorbereiten**
+   Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden.
 
-**Acceptance Scenarios**:
+5. **Provider-Berechtigungen transparent machen**
+   Microsoft Graph und Provider-Zugriffe verständlich erklären, prüfen und capability-orientiert einordnen.
 
-1. **Given** a visitor opens `/platform`, **When** they read the page, **Then** backup, restore, drift, findings, evidence, auditability, exceptions, and reviews are explained as one operating model.
+6. **Entscheidungen nachvollziehbar machen**
-2. **Given** product-like previews are present, **When** copy references them, **Then** they are described as illustrative/static.
+   Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen.
-3. **Given** the page mentions Microsoft tenants, **When** reviewed, **Then** it remains public product positioning and does not imply website runtime provider access.
 
----
+### 4. Stakeholder Section
 
-### User Story 4 - Present Conservative Evaluation And Pricing Language (Priority: P2)
+**Headline**
 
-A buyer reads `/pricing` and homepage evaluation copy and understands that commercial packaging is scoped and contact-led.
+> Eine belastbare Wahrheit für MSPs, IT und Audit.
 
-**Why this priority**: Pricing language is a trust-sensitive surface.
+**Body**
 
-**Independent Test**: Read pricing/evaluation copy and verify it avoids unsupported billing and entitlement claims.
+> Tenantial verbindet technische Konfigurationsdaten mit Evidence, Findings und Reviews - damit Operatoren, Security-Verantwortliche und Auditoren nicht aus Screenshots, Excel-Listen oder Bauchgefühl entscheiden.
 
-**Acceptance Scenarios**:
+**Stakeholder cards**
 
-1. **Given** pricing is not finalized as self-serve billing, **When** `/pricing` renders, **Then** it does not claim checkout, subscription activation, instant onboarding, or fixed plan entitlements.
+- **MSP Operatoren**
-2. **Given** evaluation packages are shown, **When** reviewed, **Then** they are framed as scoped conversations or rollout options.
+  Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.
-3. **Given** CTAs appear in pricing sections, **When** clicked, **Then** they route to `/contact` or another intentional page.
 
----
+- **Enterprise IT**
+  Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren.
 
-### User Story 5 - Build Trust Without Fake Proof (Priority: P2)
+- **Security & Audit**
+  Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen.
 
-A security-conscious buyer reads trust/legal/FAQ copy and sees clear, conservative trust positioning.
+### 5. Differentiation Section
 
-**Why this priority**: Tenantial's buyer will care about governance and evidence. Trust copy must be honest and precise.
+**Headline**
 
-**Independent Test**: Read `/trust`, FAQ, legal-adjacent copy, and footer statements.
+> Gebaut für Governance. Nicht für blinde Automatisierung.
 
-**Acceptance Scenarios**:
+**Body**
 
-1. **Given** no verified certification proof exists, **When** trust copy is reviewed, **Then** it avoids SOC 2, ISO, Microsoft endorsement, compliance guarantee, uptime guarantee, and recovery guarantee claims.
+> Tenantial ersetzt nicht das Microsoft Admin Center. Es ergänzt es um die Schicht, die Enterprise-Teams im Alltag fehlt: Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen.
-2. **Given** no customer proof exists, **When** social-proof areas render, **Then** they avoid fake logos, testimonials, and "trusted by" claims.
-3. **Given** the public website mentions evidence, **When** reviewed, **Then** it does not imply that public pages expose live tenant data or real customer evidence.
 
----
+### 6. Trust Teaser
 
-### User Story 6 - Normalize CTA Language (Priority: P3)
+The trust teaser must stay specific but conservative. It may mention:
 
-A visitor sees consistent CTA language across homepage, platform, pricing, trust, docs, and footer.
+- nachvollziehbarer Audit Trail
+- Review Packs
+- Evidence for reviews and change discussions
+- role-aware governance context
+- controlled recovery preparation
+- security and audit stakeholders working from the same data basis
 
-**Why this priority**: CTA inconsistency makes the site feel unfinished.
+It must not claim DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, or complete evidence coverage.
 
-**Independent Test**: List all visible CTA labels and target URLs.
+### 7. Bottom CTA
 
-**Acceptance Scenarios**:
+**Headline**
 
-1. **Given** CTAs appear across pages, **When** labels are compared, **Then** the primary action language is consistent.
+> Bereit, Microsoft 365 Governance messbar zu machen?
-2. **Given** secondary CTAs appear, **When** clicked, **Then** they route to explanatory pages or anchors.
-3. **Given** a CTA implies a workflow, **When** reviewed, **Then** the workflow is actually available or the CTA is reworded.
 
-### Edge Cases
+**Body**
 
-- If a strong marketing phrase risks unsupported claims, prefer conservative wording.
+> Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt.
-- If a page is not ready for detailed content, use restrained intentional placeholder copy or hide it from navigation.
-- If docs content is exposed, it must not imply product behavior not yet supported.
-- If product screenshots/previews show values, they must be framed as illustrative/static.
-- If the public website mentions Microsoft, it must not imply Microsoft endorsement.
-- If public copy mentions restore, it must avoid guaranteed recovery language.
-- If copy mentions audit/compliance, it must avoid guaranteed compliance language.
-- If copy mentions security, it must avoid certification or assurance claims unless verified.
-- If CTA text references "walkthrough", "demo", or "contact", the target must be intentional and not imply automated scheduling unless implemented.
-- If old ScrewFast/source copy remains only in non-public attribution or internal files, it is not a content blocker unless it is emitted into public output.
 
-## Requirements *(mandatory)*
+**Buttons**
 
-### Assumptions
+- Demo buchen
+- Plattform ansehen
 
-- Spec 402 and Spec 403 are complete.
+## Metadata And SEO Direction
-- `apps/website` is ScrewFast-derived and currently builds.
-- The public website domain is `tenantial.com`.
-- No verified customer proof, certification proof, Microsoft partnership proof, or billing model has been supplied.
-- No backend form submission, scheduling, login, newsletter, or self-serve purchase workflow exists in website scope.
-- Tenantial's intended public positioning is evidence-first governance for Microsoft tenant configuration.
-- Tenantial is not positioned as a helpdesk, device-action, or live remediation product.
-- `apps/platform` is out of scope and must remain untouched.
 
-### Functional Requirements
+SEO metadata must sell the same story in compressed form:
 
-#### Scope
+- primary market: Microsoft 365 governance
+- primary outcomes: policy drift visibility, versioned configuration backup, evidence, reviews, controlled recovery preparation, auditability
+- target audiences: MSPs, Enterprise IT, security, audit
+- first domain: Intune
+- future posture: prepared for further policy domains, not live multi-cloud support
 
-- **FR-001**: The implementation MUST remain scoped to `apps/website`.
+Example title direction:
-- **FR-002**: The implementation MUST NOT touch `apps/platform`.
-- **FR-003**: The implementation MUST NOT recreate `apps/website`.
-- **FR-004**: The implementation MUST NOT replace the ScrewFast-derived foundation.
-- **FR-005**: The implementation MUST focus on public content, messaging, metadata, CTA labels, and claim safety.
-- **FR-006**: Layout and visual changes SHOULD be limited to what is necessary to support content clarity.
 
-#### Messaging Architecture
+> Tenantial - Microsoft 365 Policy Governance for MSPs and Enterprise IT
 
-- **FR-007**: The homepage MUST have a clear messaging hierarchy from hero to final CTA.
+Example description direction:
-- **FR-008**: Homepage section headings MUST tell a coherent story when read in order.
-- **FR-009**: Homepage sections MUST avoid unnecessary repetition.
-- **FR-010**: The product MUST be positioned as evidence-first governance for Microsoft tenant configuration.
-- **FR-011**: The product MUST NOT be positioned as a helpdesk, device-action, or blind automation tool.
 
-#### Product Capability Copy
+> Detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and controlled recovery.
 
-- **FR-012**: Public copy MUST explain backup, restore, drift detection, findings, evidence, auditability, exceptions, and reviews.
+## Requirements
-- **FR-013**: Restore copy MUST avoid guaranteed recovery or automatic success language.
-- **FR-014**: Drift/finding copy MUST emphasize reviewability and operator decision-making rather than automatic remediation.
-- **FR-015**: Evidence/audit copy MUST avoid claiming legal sufficiency, certification, or guaranteed compliance.
-- **FR-016**: Every public product-like preview or status-like preview value MUST be framed as static, demo, or illustrative content and MUST NOT imply live tenant data.
 
-#### Page-Level Content
+### Scope Requirements
 
-- **FR-017**: `/` MUST contain finalized homepage copy suitable for layout polish.
+- **FR-001**: The implementation MAY modify the 404 spec artifacts and `apps/website` source or website-smoke-test files required for the homepage sales-copy rewrite.
-- **FR-018**: `/platform` MUST contain deeper product-model copy than the homepage.
+- **FR-002**: Website implementation scope MUST remain `apps/website` only.
-- **FR-019**: `/pricing` MUST use conservative evaluation/scoped rollout language.
+- **FR-003**: This spec MUST explicitly forbid `apps/platform` changes.
-- **FR-020**: `/trust` MUST use proof-safe trust language.
+- **FR-004**: This implementation MUST not introduce backend runtime, database, platform, provider, dependency, or build-output changes.
-- **FR-021**: `/contact` MUST set realistic expectations about the contact/demo process.
-- **FR-022**: Docs routes exposed in navigation MUST contain intentional Tenantial-specific content or be hidden from navigation.
 
-#### CTA Language
+### Sales-Copy Requirements
 
-- **FR-023**: Primary CTA language SHOULD be consistent across the site.
+- **FR-005**: Visible public copy MUST sell business outcomes rather than internal architecture.
-- **FR-024**: Secondary CTA language SHOULD clearly indicate informational navigation.
+- **FR-006**: The homepage hero MUST lead with Microsoft 365 policy control, not product-category philosophy.
-- **FR-025**: CTAs MUST resolve to intentional routes or anchors.
+- **FR-007**: The hero and first supporting section MUST mention policy drift, versioned configuration backups, evidence, reviews, changes, and recovery context.
-- **FR-026**: CTAs MUST NOT imply unavailable workflow such as login, signup, checkout, account creation, instant provisioning, or automated scheduling.
+- **FR-008**: Microsoft 365 MUST be the first public market.
+- **FR-009**: Intune MAY appear as the first strong policy focus, but MUST NOT be treated as the full product boundary.
+- **FR-010**: Provider extensibility MUST be secondary and MUST NOT become hero philosophy.
+- **FR-011**: Google, AWS, and multi-cloud support MUST NOT appear as live capabilities unless separately proven.
+- **FR-012**: Public copy MUST address MSPs, Enterprise IT, Security, and Audit as first-class audiences.
+- **FR-013**: Public copy MUST present recovery and restore as controlled preparation and evaluation, not blind automation.
+- **FR-014**: Public copy MUST avoid the forbidden and strongly restricted claims listed in this spec.
+- **FR-015**: Public copy MUST avoid internal governance, architecture, and Spec Kit terms as visible buyer-facing language.
 
-#### Trust And Claim Safety
+### Homepage Structure Requirements
 
-- **FR-027**: Public copy MUST NOT include fake customer logos, fake testimonials, or unsupported "trusted by" claims.
+- **FR-016**: The later homepage implementation MUST include a hero, problem section, capability cards, stakeholder/persona section, differentiation section, trust teaser, and bottom CTA.
-- **FR-028**: Public copy MUST NOT claim SOC 2, ISO, Microsoft endorsement, guaranteed uptime, guaranteed recovery, or guaranteed compliance unless verified proof is supplied.
+- **FR-017**: Capability cards MUST be outcome-led and cover drift, backups/versioning, reviews/evidence, recovery preparation, permissions/provider access, and decision traceability.
-- **FR-029**: Public copy MUST NOT expose ScrewFast, construction, hardware, manufacturing, template, TenantAtlas, TenantPilot, or TenantCTRL as public brand residue.
+- **FR-018**: Stakeholder copy MUST explicitly cover MSP operators, Enterprise IT, and Security/Audit.
-- **FR-030**: Public copy MUST NOT imply the public website connects to a live Microsoft tenant.
+- **FR-019**: Differentiation copy MUST explain that Tenantial complements Microsoft Admin Center rather than replacing it.
-- **FR-031**: Public copy MUST NOT imply the public website displays real tenant data.
+- **FR-020**: Bottom CTA copy MUST invite a concrete demo or platform exploration without overclaiming maturity or automation.
 
-#### Metadata
+### Validation Requirements For Later Implementation
 
-- **FR-032**: Core public route titles and descriptions MUST reflect the revised messaging.
+- **FR-021**: Later implementation MUST include static scans for forbidden claims and old internal/defensive phrases.
-- **FR-033**: Metadata MUST remain Tenantial-specific and residue-free.
+- **FR-022**: Later implementation MUST include browser smoke review for desktop and mobile homepage readability, CTA visibility, and no visible copy overlap.
-- **FR-034**: Sitemap and robots behavior from Spec 403 MUST remain intact.
+- **FR-023**: Later implementation MUST confirm no `apps/platform` files changed.
+- **FR-024**: Later implementation MUST report whether old 404 copy was replaced or only supplemented.
 
-#### Validation
+## Testing / Lane / Runtime Impact
 
-- **FR-035**: Build validation MUST pass with `corepack pnpm build:website`.
+- **Current change classification**: Browser/static website copy implementation.
-- **FR-036**: Public smoke validation MUST pass with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`.
+- **Runtime impact**: Static website source and website smoke-test expectations only. No backend, database, provider, platform, dependency, or build-output change is introduced.
-- **FR-037**: Whitespace/conflict validation MUST pass with `git diff --check`.
+- **Affected validation lane for this implementation**: Website build, static forbidden-claim scan, desktop/mobile browser smoke, CTA/link checks, metadata review, and explicit confirmation that `apps/platform` remains untouched.
-- **FR-038**: Scope validation MUST confirm `git status --short -- apps/platform` is empty.
+- **Validation for this implementation**: `corepack pnpm build:website`, targeted static claim scan, browser review on `http://127.0.0.1:4321/`, `git diff --check`, `git diff --name-only`, and `git status --short -- apps/platform`.
-- **FR-039**: Implementation summary MUST list changed pages, CTA labels, claim-safety decisions, validation results, and any content follow-ups.
+- **Later implementation classification**: N/A for homepage sales copy; follow-up specs may extend supporting routes.
+- **Later implementation validation**: N/A.
+- **Pest/Laravel/Filament/Sail coverage**: N/A for this spec update. Later website-copy implementation should not add backend or platform test lanes unless it actually changes backend/platform behavior.
+- **Fixture/helper/runtime cost**: None for this spec update.
+- **Escalation**: If later implementation requires platform, provider, auth, database, or runtime changes, that work must be split into a separate spec.
 
-## Success Criteria *(mandatory)*
+## User Scenarios And Acceptance Criteria
 
-- **SC-001**: A reviewer can summarize Tenantial's product category from the homepage hero and first two sections in one sentence without using implementation notes.
+### User Story 1 - MSP Buyer Understands The Operational Risk
-- **SC-002**: Homepage headings read as a coherent narrative from problem to product model to evaluation when copied into a plain-text outline.
-- **SC-003**: `/platform` explains the product model more deeply than the homepage and covers backup, restore, drift, findings, evidence, auditability, exceptions, and reviews as one operating model.
-- **SC-004**: Public copy includes backup, restore, drift, findings, evidence, auditability, exceptions, and reviews without unsupported recovery, compliance, certification, or endorsement guarantees.
-- **SC-005**: Pricing/evaluation language is conservative and contact-led, with 0 claims of checkout, instant subscription activation, self-serve billing, or fixed unsupported entitlements.
-- **SC-006**: Trust copy contains 0 unsupported certifications, endorsements, customer-proof claims, uptime guarantees, recovery guarantees, or compliance guarantees.
-- **SC-007**: 100% of visible CTA labels use the normalized buyer-intent language defined by this feature, and 100% of CTA targets resolve to intentional routes or anchors.
-- **SC-008**: 0 public `href="#"` placeholders remain.
-- **SC-009**: 0 forbidden public residue terms appear in visible copy or metadata.
-- **SC-010**: `corepack pnpm build:website` passes.
-- **SC-011**: `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke` passes.
-- **SC-012**: `git diff --check` passes.
-- **SC-013**: `git status --short -- apps/platform` returns empty.
-
-## Implementation Notes For Planning
 
-Planning should preserve the following sequence:
+An MSP operator or owner reads the homepage and understands that Tenantial helps control Microsoft 365 policy drift, versioning, evidence, reviews, and recovery context across customer environments.
 
-- Start with a read-only content audit of visible headings, body copy, CTA labels, metadata titles, metadata descriptions, FAQ answers, and footer statements across core public routes.
+**Acceptance Criteria**
-- Define the homepage narrative before rewriting section copy.
-- Define `/platform` as the deeper public product-model explanation.
-- Normalize primary and secondary CTA language before changing individual labels.
-- Keep claim-safety wording conservative for restore, audit, compliance, trust, and pricing.
-- Review exposed docs routes and either update them with intentional Tenantial-specific content or hide them from public navigation.
-- Preserve sitemap, robots, redirect, and noindex behavior established by Spec 403 unless a website-scope correction is explicitly required.
-- Confirm `apps/platform` remains untouched during close-out.
 
-## Suggested Validation Commands
+1. Given the hero and problem section, when an MSP buyer summarizes the product, then they mention Microsoft 365 policy control and drift visibility rather than an internal governance model.
+2. Given the stakeholder cards, when an MSP buyer scans the page, then multi-customer or multi-tenant review preparation is visible without implying unsupported providers.
 
-```bash
+### User Story 2 - Enterprise IT Sees Recovery And Audit Context
-corepack pnpm build:website
-WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke
-git diff --check
-git status --short -- apps/platform
-```
 
-## Reviewer Notes
+An IT leader reads the page and understands that Tenantial documents changes, configuration history, drift, and recovery risk before action.
-
-Reviewers should evaluate content quality before requesting spacing or layout refinements.
 
-The review should answer:
+**Acceptance Criteria**
 
-1. Is the product category clear?
+1. Given the capability cards, when Enterprise IT evaluates the page, then versioned backups, historical comparison, and controlled recovery preparation are explicit.
-2. Is the homepage narrative coherent?
+2. Given the differentiation section, when Enterprise IT compares Tenantial to Microsoft Admin Center, then Tenantial is clearly positioned as an evidence, versioning, and review layer.
-3. Does `/platform` explain the product model better than the homepage?
-4. Are restore, audit, trust, pricing, and evidence claims conservative?
-5. Are CTA labels consistent and honest?
-6. Is the public website still free of unsupported claims and residue?
-7. Is `apps/platform` untouched?
 
-## Follow-Up
+### User Story 3 - Security And Audit See Review-Ready Evidence
 
-After this spec, the next likely spec is:
+Security and audit stakeholders see that Tenantial helps transform configuration data, findings, accepted risks, and follow-ups into review-ready material.
 
-- Spec 405 - `apps/website` Homepage Layout Rhythm & Visual Productization
+**Acceptance Criteria**
 
-Spec 405 should use the stabilized content from this spec as the basis for spacing, section rhythm, preview sizing, and visual polish.
+1. Given the stakeholder section, when Security or Audit scans the page, then evidence, findings, accepted risks, and review packs are visible.
+2. Given the trust teaser, when a compliance-sensitive evaluator reviews the copy, then it avoids unsupported legal, certification, hosting, or complete-evidence claims.
+
+### User Story 4 - Implementation Agent Has Concrete Copy Direction
+
+A later implementation agent can convert this spec into website copy without reintroducing internal architecture language.
+
+**Acceptance Criteria**
+
+1. Given this spec, when the agent drafts homepage copy, then each homepage section has concrete example text and claim guardrails.
+2. Given this spec, when the agent validates the implementation, then static scans can target forbidden phrases, overclaims, and old defensive copy.
+
+## Success Criteria
+
+- **SC-001**: Spec 404 is clearly titled as a Public Website Sales Copy & Positioning Rewrite.
+- **SC-002**: The spec sells business outcomes instead of internal architecture.
+- **SC-003**: Concrete visible homepage copy examples are present for hero, problem, capability cards, stakeholders, differentiation, and bottom CTA.
+- **SC-004**: Microsoft 365 is the first public market.
+- **SC-005**: Intune is allowed as a first strong policy focus, not as the product boundary.
+- **SC-006**: Provider extensibility is secondary and safely bounded.
+- **SC-007**: The spec bans unsupported compliance, automation, provider, hosting, and evidence-hardening claims.
+- **SC-008**: Acceptance criteria prove B2B sales-copy quality for MSP, Enterprise IT, Security, and Audit audiences.
+- **SC-009**: The spec states that later implementation is `apps/website` relevant only.
+- **SC-010**: The implementation changes only approved 404 spec artifacts and minimal `apps/website` source or website-smoke-test files; it changes no `apps/platform`, root workspace contracts, dependencies, build output, or backend runtime files.
+
+## Follow-Up Specs
+
+Potential follow-up specs should stay separate from this positioning rewrite:
+
+- **405 Trust**: detailed trust, security, hosting, legal, and evidence substantiation once proof exists
+- **406 Provider Taxonomy**: current-versus-planned provider and policy-domain vocabulary if public provider expansion becomes real
+- **407 Use Cases**: dedicated MSP, Enterprise IT, Security, Audit, and Recovery use-case pages

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

@@ -1,217 +1,84 @@
-# Tasks: `apps/website` Public Content Architecture & Messaging
+# Tasks: Public Website Sales Copy & Positioning Rewrite
 
-**Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/`
+**Input**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` and `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md`
-**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**: No new test family is required by Spec 404. Use existing website build and Playwright public smoke validation; update smoke expectations only where implementation changes make the existing checks incomplete. Do not add Pest, Laravel, Filament, Livewire, database, Sail, Microsoft Graph, queue, job, policy, RBAC, or `apps/platform` test coverage.
+**Scope**: This task list covers the Spec 404 correction plus the follow-up homepage implementation approved by the user. Do not edit `apps/platform`, root workspace contracts, build output, dependencies, or backend runtime files.
 
-## Phase 1: Setup
+**Validation lane**: Browser/static website validation plus spec/documentation review.
 
-**Purpose**: Establish the website-only scope and current public content baseline before editing.
+## Tasks
 
-- [X] T001 Confirm current git scope and verify `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform` is untouched by running `git status --short -- apps/platform` from `/Users/ahmeddarrazi/Documents/projects/wt-website`
+- [X] **T001: Repo-Zustand und Spec-404-Pfad verifizieren**
-- [X] T002 [P] Inventory homepage and product-route content sources in `/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`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+  Run `git status --short --branch` and locate 404 with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`. Confirm whether there is exactly one 404 folder. If multiple exist, choose the Public Website Sales Copy & Positioning Spec based on branch, title, and content, and document the decision in the plan or final report.
-- [X] T003 [P] Inventory pricing, trust, contact, and legal-adjacent content sources in `/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`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T004 [P] Inventory exposed docs and placeholder collections 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 CTA, navigation, footer, metadata, and smoke-validation surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.ts`, `/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`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`
 
----
+- [X] **T002: Bestehende 404-Artefakte lesen und Quark-/Architektur-Copy inventarisieren**
+  Read `spec.md`, `plan.md`, and `tasks.md` fully. Identify internal, defensive, academic, architecture-heavy, category-philosophy, "operating model", provider-boundary, and source-of-truth wording that should not drive visible website copy.
 
-## Phase 2: Foundational
+- [X] **T003: Sichtbare Copy-Prinzipien in `spec.md` ersetzen**
+  Rewrite the spec so visible public copy must sell business outcomes: Microsoft 365 policy control, early drift detection, versioned configuration backups, evidence, reviews, recovery context, auditability, and shared truth for MSPs, IT, Security, and Audit.
 
-**Purpose**: Normalize shared website copy rules before story-specific page edits.
+- [X] **T004: Hero-Copy-Beispiele auf B2B-Sales-Ton umstellen**
+  Add concrete hero examples: "Microsoft 365 Policies unter Kontrolle bringen.", the required subhead about MSPs and Enterprise IT, the supporting line with Microsoft 365 Governance and Intune as first strong policy focus, and CTAs "Demo buchen" and "Plattform ansehen".
 
-**Critical**: Complete this phase before user-story implementation.
+- [X] **T005: Alte defensive Section-Namen ersetzen**
+  Remove the old public-story direction around "Die richtige Produktkategorie zuerst", "Für Teams, die Governance gemeinsam tragen", "Klare Grenzen statt überzogener Versprechen", and "Den nächsten Schritt bewusst wählen". Replace them with problem, capability, stakeholder, differentiation, trust teaser, and bottom CTA sections.
 
-- [X] T006 Define the normalized primary and secondary CTA intent rules for German default and English mirror copy in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [X] **T006: Capability- und Outcome-Sprache definieren**
-- [X] T007 Normalize shared site tagline, short description, navigation labels, and footer conversation wording for evidence-first Microsoft tenant governance in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+  Define capability cards for policy drift, backups/versioning, audit-ready reviews, controlled recovery preparation, provider permissions, and traceable decisions. Each card must state an outcome rather than an internal product module.
-- [X] T008 Remove or rewrite public copy that implies unavailable login, signup, checkout, account creation, self-serve billing, subscription, automated scheduling, newsletter, or guaranteed backend submission workflows in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T009 Review and update forbidden residue or unsupported-claim smoke expectations for Spec 404 content terms 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 foundational edits still leave `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform` untouched by running `git status --short -- apps/platform` from `/Users/ahmeddarrazi/Documents/projects/wt-website`
 
-**Checkpoint**: Shared website messaging and CTA guardrails are ready for independently testable user-story work.
+- [X] **T007: MSP-/Enterprise-/Security-/Audit-Personas definieren**
+  Add stakeholder copy for MSP Operatoren, Enterprise IT, and Security & Audit. Make the shared data basis explicit: evidence, findings, reviews, accepted risks, and follow-ups instead of screenshots, Excel lists, or gut feel.
 
----
+- [X] **T008: Provider-/Intune-/Microsoft-365-Claim-Regeln schärfen**
+  Make Microsoft 365 the first public market. Allow Intune as the first strong policy focus and example domain. Treat provider extensibility as secondary. Forbid Google, AWS, and multi-cloud as live claims unless separately proven by repo/product truth.
 
-## Phase 3: User Story 1 - Understand The Product Category (Priority: P1) MVP
+- [X] **T009: Trust-/DSGVO-/Hosting-Claim-Regeln belassen, aber nicht als sichtbare Website-Story formulieren**
+  Keep strict trust guardrails for DSGVO, ISO, NIS2, hosting, legal-proof evidence, complete evidence, automatic remediation, and automatic restore. Allow only safe wording around auditability, review packs, role-aware evidence, controlled recovery preparation, and decision traceability.
 
-**Goal**: A first-time visitor opens `/` and understands that Tenantial is an evidence-first governance product for Microsoft tenant configuration.
+- [X] **T010: `plan.md` an neue Copy-Umsetzungslogik anpassen**
+  Rewrite the plan as a website-copy refactoring plan. It must include repo verification, current copy inventory, identification of internal/defensive copy, hero, problem/pain, capability cards, stakeholder/persona section, differentiation, trust teaser, bottom CTA, SEO/metadata direction, claim guardrails/static search terms, browser smoke requirements for later implementation, and no runtime changes in this spec update.
 
-**Independent Test**: Read the homepage hero and first two homepage sections without relying on visuals; the product category and at least three core concepts are clear.
+- [X] **T011: `tasks.md` konsistent zu `spec.md` und `plan.md` machen**
+  Ensure the tasks are numbered, checkable, and aligned with the approved scope transition from spec-only correction to website implementation. Keep platform, dependency, backend runtime, and build-output changes out of scope.
 
-- [X] T011 [US1] Rewrite homepage hero title, supporting copy, primary CTA, secondary CTA, and metadata for product-category clarity in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [X] **T012: Final prüfen, dass nur erlaubte Website- und keine `apps/platform`-Dateien geändert wurden**
-- [X] T012 [US1] Rewrite homepage first product section copy to mention backup, restore, drift, findings, evidence, auditability, exceptions, and reviews without unsupported guarantees in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+  Run `git status --short -- apps/website apps/platform` and `git diff --name-only`. Expected tracked changes are limited to `specs/404-public-content-messaging/` plus minimal `apps/website` source or smoke-test files.
-- [X] T013 [P] [US1] Review homepage hero and first-section rendering so the updated copy is used without layout redesign in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
-- [X] T014 [P] [US1] Align homepage feature labels and FAQ entry points with the evidence-first category message 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] T015 [US1] Validate User Story 1 by reviewing `/` against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md`
 
-**Checkpoint**: User Story 1 is independently shippable as the MVP.
+- [X] **T013: Final prüfen, dass 404 nicht mehr wie interne Architektur-/Philosophie-Copy klingt**
+  Review the final artifacts for visible-copy direction. They must read like a B2B cybersecurity and IT-operations sales-copy brief: direct, confident, technically credible, outcome-led, MSP-ready, enterprise-ready, and free from internal Spec Kit or architecture-first language as the public story.
 
----
+- [X] **T014: Abschlussbericht mit Replacement-Status erstellen**
+  Final report must list changed files, summarize the sales-copy correction, explicitly confirm which `apps/website` files changed and that no `apps/platform` files changed, state whether old 404 copy passages were replaced or only supplemented, and name relevant follow-up specs such as 405 Trust, 406 Provider Taxonomy, and 407 Use Cases.
 
-## Phase 4: User Story 2 - Follow A Clear Website Narrative (Priority: P1)
+- [X] **T015: Homepage-Copy in `apps/website` umsetzen**
+  Update the homepage source copy so the rendered first viewport uses the approved Microsoft 365 policy-control headline, subhead, supporting line, and CTAs.
 
-**Goal**: A buyer scrolls the homepage and sees a deliberate narrative from problem to model to capability to evaluation.
+- [X] **T016: Capability-Cards auf Outcome-Sprache umstellen**
+  Replace the old capability language with drift, backups/versioning, audit-ready reviews, controlled recovery, provider permissions, and traceable decisions.
 
-**Independent Test**: Copy homepage headings and subheadings into a plain-text outline; the sequence tells a coherent story without repeated claims.
+- [X] **T017: Stakeholder-, Differentiation- und Trust-Teaser-Sections umsetzen**
+  Render MSP, Enterprise IT, Security/Audit, differentiation, trust teaser, and bottom CTA sections from the approved sales-copy structure.
 
-- [X] T016 [US2] Reorder or rewrite homepage section intent copy from category to problem to operating model to capability proof to evaluation in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- [X] **T018: Metadata und Platform-Wording von interner Architektur-Copy befreien**
-- [X] T017 [US2] Adjust homepage component sequencing only as needed to support the revised narrative without broad layout redesign in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
+  Update public metadata and obvious supporting route copy to avoid governance-of-record, source-of-truth, and provider-extensible hero language.
-- [X] T018 [P] [US2] Rewrite homepage workflow tab headings and body copy so each tab adds distinct meaning in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T019 [P] [US2] Confirm homepage evaluation section copy remains calm and contact-led while supporting the narrative handoff 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/sections/pricing/PricingSection.astro`
-- [X] T020 [US2] Validate User Story 2 by reviewing homepage heading order and section repetition against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md`
 
-**Checkpoint**: User Story 2 is independently shippable once the homepage narrative reads coherently.
+- [X] **T019: Website build, static scan und Browser-Review ausführen**
+  Run the website build, forbidden-claim scan, browser review for the homepage, and existing website smoke suite with updated copy expectations.
 
----
+- [X] **T020: Final prüfen, dass keine `apps/platform`-, Dependency- oder Build-Output-Dateien geändert wurden**
+  Confirm changed files are limited to approved spec artifacts and minimal `apps/website` source or smoke-test files.
 
-## Phase 5: User Story 3 - Explain The Public Product Model On `/platform` (Priority: P1)
+## Definition Of Done
 
-**Goal**: A visitor opens `/platform` and understands Tenantial's public product model in more detail than the homepage.
+- `spec.md`, `plan.md`, and `tasks.md` are consistent.
-
+- Spec 404 is titled or clearly framed as "Public Website Sales Copy & Positioning Rewrite".
-**Independent Test**: Read `/platform` without using admin/platform code as a source; backup, restore, drift, findings, evidence, auditability, exceptions, and reviews are explained as one operating model.
+- The spec sells business outcomes rather than internal architecture.
-
+- Concrete visible copy examples are present.
-- [X] T021 [US3] Rewrite `/platform` page heading, subtitle, backup, drift, restore, and boundary copy for one public operating model in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- Microsoft 365 is clearly the first public market.
-- [X] T022 [US3] Ensure `/platform` renders the deeper product-model copy without importing from or referencing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform` in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro`
+- Intune is an example/start domain, not the product boundary.
-- [X] T023 [P] [US3] Tighten static/demo preview framing and alt text for platform product previews in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
+- Provider extensibility is secondary and not overclaimed.
-- [X] T024 [P] [US3] Review public docs product-model explanations for alignment with `/platform` in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`
+- Website implementation was performed only in approved `apps/website` source and website-smoke-test files.
-- [X] T025 [US3] Validate User Story 3 by reviewing `/platform` against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md`
+- No `apps/platform` changes were performed.
-
+- No root/workspace contracts were changed.
-**Checkpoint**: User Story 3 is independently shippable once `/platform` communicates the public product model safely.
+- Git diff contains only approved 404 spec artifacts plus minimal `apps/website` source and website-smoke-test files, aside from any pre-existing unrelated untracked files.
-
+- Final report states whether old 404 copy was replaced or only supplemented.
----
-
-## Phase 6: User Story 4 - Present Conservative Evaluation And Pricing Language (Priority: P2)
-
-**Goal**: A buyer reads `/pricing` and homepage evaluation copy and understands that commercial packaging is scoped and contact-led.
-
-**Independent Test**: Read pricing and evaluation copy; there are no checkout, subscription activation, instant onboarding, self-serve billing, or unsupported entitlement claims.
-
-- [X] T026 [US4] Rewrite pricing intro heading, subtitle, title, badges, and metadata as conservative evaluation language in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T027 [US4] Rewrite pricing package names, descriptions, feature lists, button labels, and target links to avoid fake fixed entitlements or purchase claims 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/data_files/pricing.json`
-- [X] T028 [P] [US4] Confirm pricing rendering does not add checkout, subscription, billing, account creation, or unsupported plan semantics in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/pricing/PricingSection.astro`
-- [X] T029 [P] [US4] Confirm homepage evaluation copy uses the same contact-led commercial posture in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`
-- [X] T030 [US4] Validate User Story 4 by reviewing `/pricing` and homepage evaluation copy against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md`
-
-**Checkpoint**: User Story 4 is independently shippable once commercial copy is conservative and contact-led.
-
----
-
-## Phase 7: User Story 5 - Build Trust Without Fake Proof (Priority: P2)
-
-**Goal**: A security-conscious buyer reads trust, FAQ, legal-adjacent, and footer copy and sees clear conservative trust positioning.
-
-**Independent Test**: Read `/trust`, FAQ, legal-adjacent copy, docs, and footer statements; unsupported certifications, endorsements, customer proof, uptime, recovery, and compliance guarantees do not appear.
-
-- [X] T031 [US5] Rewrite trust page heading, subtitle, CTA, stats, and metadata to explain claim boundaries without fake proof in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T032 [P] [US5] Rewrite FAQ answers for conservative restore, audit, compliance, Microsoft, preview, and evidence language in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json`
-- [X] T033 [P] [US5] Review legal, privacy, terms, and imprint copy for unsupported claims or placeholder residue in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/LegalPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TextPage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T034 [P] [US5] Rewrite exposed docs content that is not intentionally Tenantial-specific or hide unready docs from public navigation in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs`
-- [X] T035 [US5] Validate User Story 5 by scanning `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src` for forbidden proof and residue terms listed in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md`
-
-**Checkpoint**: User Story 5 is independently shippable once trust-sensitive public copy is proof-safe.
-
----
-
-## Phase 8: User Story 6 - Normalize CTA Language (Priority: P3)
-
-**Goal**: A visitor sees consistent CTA language across homepage, platform, pricing, trust, docs, contact, navigation, and footer.
-
-**Independent Test**: List all visible CTA labels and targets; every label maps to a supported buyer intent and every target resolves intentionally.
-
-- [X] T036 [US6] Normalize primary and secondary CTA labels across homepage, platform, pricing, trust, contact, docs, navigation, and footer copy in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`
-- [X] T037 [US6] Verify navigation and footer links use only intentional route targets and no placeholder social URLs in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`
-- [X] T038 [P] [US6] Reframe contact page form labels and instructions so they prepare a contact request without implying backend submission or automated scheduling 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/ContactPage.astro`
-- [X] T039 [P] [US6] Review docs navigation and in-page links for consistent CTA intent and intentional targets in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`
-- [X] T040 [US6] Validate User Story 6 by checking public CTA targets and `href="#"` placeholders in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src`
-
-**Checkpoint**: User Story 6 is independently shippable once CTA language and targets are consistent.
-
----
-
-## Final Phase: Polish And Cross-Cutting Concerns
-
-**Purpose**: Complete public content validation, smoke checks, and handoff.
-
-- [X] T041 [P] Update route titles, route descriptions, Open Graph summaries, and public metadata affected by the revised copy 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/Meta.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/ui/starlight/Head.astro`
-- [X] T042 [P] Review German default and English mirror copy for content parity and claim safety 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] T043 [P] Review sitemap, robots, redirect, and noindex behavior remains aligned with Spec 403 in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/robots.txt.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages`
-- [X] T044 [P] Update Playwright public smoke expectations only for changed public content, CTA, residue, metadata, or route behavior 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] T045 Run build validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `corepack pnpm build:website`
-- [X] T046 Run public smoke validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`
-- [X] T047 Run whitespace validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git diff --check`
-- [X] T048 Run scope validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git status --short -- apps/platform`
-- [X] T049 Prepare the final implementation handoff in the PR or final response with changed pages, docs surfaces, CTA language decisions, claim-safety decisions, metadata changes, validation results, remaining content follow-ups, and `apps/platform` untouched confirmation from `/Users/ahmeddarrazi/Documents/projects/wt-website`
-
----
-
-## Dependencies
-
-**Phase Dependencies**
-
-Setup must complete before Foundational. Foundational must complete before any user story. User Stories 1, 2, and 3 are all P1 and can proceed after Foundational, with US2 benefiting from the US1 homepage category vocabulary. User Stories 4 and 5 can proceed after Foundational and can run in parallel with each other once shared claim vocabulary is stable. User Story 6 should run after the main page copy decisions so CTA language can be normalized across all surfaces.
-
-**User Story Dependencies**
-
-- **US1**: Depends on Phase 2 only.
-- **US2**: Depends on Phase 2 and benefits from US1 wording.
-- **US3**: Depends on Phase 2 only.
-- **US4**: Depends on Phase 2 and pricing/evaluation vocabulary from foundational tasks.
-- **US5**: Depends on Phase 2 and claim-safety vocabulary from foundational tasks.
-- **US6**: Depends on US1-US5 copy decisions across public pages and docs.
-
-**MVP Scope**
-
-Complete Phase 1, Phase 2, and Phase 3 (US1) for the smallest independently reviewable increment.
-
----
-
-## Parallel Execution Examples
-
-**After Phase 2**
-
-```text
-US1 can update homepage category copy:
-- T011 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts
-- T013 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro
-
-US3 can update product-model copy:
-- T021 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts
-- T024 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx
-```
-
-**Pricing And Trust**
-
-```text
-US4 pricing work:
-- T027 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/data_files/pricing.json
-- T028 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/pricing/PricingSection.astro
-
-US5 trust work:
-- T032 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json
-- T034 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs
-```
-
-**Final Validation**
-
-```text
-Cross-cutting review can run in parallel before final commands:
-- T041 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/ui/starlight/Head.astro
-- T042 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
-- T043 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/robots.txt.ts
-```
-
----
-
-## Implementation Strategy
-
-1. Finish setup and foundational copy guardrails before page-level rewrites.
-2. Ship the MVP with US1 homepage product-category clarity.
-3. Complete US2 homepage narrative and US3 `/platform` product-model copy before final CTA normalization.
-4. Complete US4 pricing/evaluation and US5 trust/FAQ/legal/docs proof-safety in parallel where files do not overlap.
-5. Complete US6 CTA normalization after page copy settles.
-6. Finish with metadata, localized mirror review, smoke expectations, build, public smoke, whitespace, and `apps/platform` scope validation.
-
-## Test Governance Notes
-
-The declared test purpose is Browser/static website. The affected validation lanes are website build, Playwright public smoke, manual browser/content 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 content validation becomes a recurring release governance problem.