ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

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

Merged
ahmido merged 4 commits from 404-public-content-messaging into website-dev 2026-05-25 20:35:33 +00:00
Conversation 0 Commits 4 Files Changed 35 +1341 -1222
35 changed files with 1341 additions and 1222 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/agents/copilot-instructions.md vendored
View File

@ -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

116
apps/website/src/components/pages/HomePage.astro
View File

@ -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 PricingSection from '@components/sections/pricing/PricingSection.astro';
import FAQ from '@components/sections/misc/FAQ.astro';
import PrimaryCTA from '@components/ui/buttons/PrimaryCTA.astro';
import SecondaryCTA from '@components/ui/buttons/SecondaryCTA.astro';
import heroImage from '@images/tenantial-dashboard.avif';
import featureImage from '@images/tenantial-review-board.avif';
import reviewImage from '@images/tenantial-evidence-intake.avif';
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>

26
apps/website/src/components/pages/PlatformPage.astro
View File

@ -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}

9
apps/website/src/components/sections/landing/HeroSection.astro
View File

@ -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 */
}

4
apps/website/src/components/ui/blocks/IconBlock.astro
View File

@ -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}>

2
apps/website/src/components/ui/blocks/LeftSection.astro
View File

@ -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>

2
apps/website/src/components/ui/blocks/RightSection.astro
View File

@ -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>

8
apps/website/src/components/ui/blocks/StatsBig.astro
View File

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

10
apps/website/src/components/ui/blocks/StatsSmall.astro
View File

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

12
apps/website/src/components/ui/blocks/TabNav.astro
View File

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

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

@ -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.

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

@ -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.

14
apps/website/src/content/docs/en/guides/intro.mdx
View File

@ -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 snapshots support comparison and restore planning.
- How drift, findings, and exceptions make decisions attributable.
- How restore is treated as preview-first work with validation, selective scope, and explicit confirmation.
- How observed state and policy evidence are collected and normalized for review.
- How drift, findings, and review work lead into a traceable decision.
- How Microsoft 365 as the current focus is separated from provider-extensible future direction.
- How controlled recovery stays preview-first work with validation, selective scope, and explicit confirmation.

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

@ -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.
- Snapshots are explicit records for comparison and planning.
- Drift and findings become review work.
- Exceptions and audit notes keep decisions attributable.
- Restore is planned through preview, validation, selective scope, and explicit confirmation without promising recovery success.
- Observed state is the starting point for review work.
- Policy evidence and snapshots become explicit records for comparison and planning.
- Drift and findings turn into visible review work instead of background diagnostics.
- Decisions, exceptions, and accepted risk stay attributable through audit trail.
- Recovery is planned through preview, validation, selective scope, and explicit confirmation without promising recovery success.

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

@ -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">
Understand the public product model before planning a rollout conversation.
<Card title="Operating model" icon="document">
Understand the sequence from observe to evidence, detect, review, decide, and audit before planning a rollout conversation.
</Card>
<Card title="Platform Notes" icon="seti:terraform">
Review how Tenantial frames inventory evidence, snapshots, drift, findings, exceptions, reviews, and restore planning.
<Card title="Provider and trust boundaries" icon="seti:terraform">
Review how Tenantial keeps Microsoft 365 as the current focus, treats other providers as future direction, and keeps trust claims conservative.
</Card>
</CardGrid>

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

@ -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.

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

@ -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.

14
apps/website/src/content/docs/guides/intro.mdx
View File

@ -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 Snapshots Vergleich und Restore-Planung unterstützen.
- Wie Drift, Findings und Exceptions Entscheidungen zuordenbar machen.
- Wie Restore als preview-first Arbeit mit Validierung, selektivem Scope und expliziter Bestätigung behandelt wird.
- Wie beobachteter Zustand und Policy-Evidence für Reviews gesammelt und normalisiert werden.
- Wie Drift, Findings und Review-Arbeit zu einer nachvollziehbaren Entscheidung führen.
- Wie Microsoft 365 als aktueller Fokus von provider-extensibler Zukunftsrichtung getrennt wird.
- Wie kontrollierte Recovery als preview-first Arbeit mit Validierung, selektivem Scope und expliziter Bestätigung behandelt wird.

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

@ -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.
- Snapshots sind explizite Records für Vergleich und Planung.
- Drift und Findings werden zu Review-Arbeit.
- Exceptions und Audit-Notizen halten Entscheidungen zuordenbar.
- Restore wird über Preview, Validierung, selektiven Scope und explizite Bestätigung geplant, ohne Recovery-Erfolg zu versprechen.
- Beobachteter Zustand ist der Ausgangspunkt für Review-Arbeit.
- Policy-Evidence und Snapshots werden als explizite Records für Vergleich und Planung festgehalten.
- Drift und Findings werden zu sichtbarer Review-Arbeit statt zu stiller Hintergrunddiagnose.
- Entscheidungen, Ausnahmen und akzeptierte Risiken bleiben über Audit Trail nachvollziehbar.
- Recovery wird über Preview, Validierung, selektiven Scope und explizite Bestätigung geplant, ohne Recovery-Erfolg zu versprechen.

12
apps/website/src/content/docs/welcome-to-docs.mdx
View File

@ -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">
Verstehe das öffentliche Produktmodell, bevor ein Rollout-Gespräch geplant wird.
<Card title="Operating Model" icon="document">
Verstehe die Abfolge aus beobachten, Evidence sammeln, Drift erkennen, Review, Entscheidung und Audit Trail, bevor ein Rollout-Gespräch geplant wird.
</Card>
<Card title="Plattform-Notizen" icon="seti:terraform">
Prüfe, wie Tenantial Inventory Evidence, Snapshots, Drift, Findings, Exceptions, Reviews und Restore-Planung rahmt.
<Card title="Provider- und Trust-Grenzen" icon="seti:terraform">
Prüfe, wie Tenantial Microsoft 365 heute fokussiert, weitere Provider nur als Richtung rahmt und Trust-Claims bewusst konservativ hält.
</Card>
</CardGrid>

10
apps/website/src/data_files/constants.ts
View File

@ -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,
};

14
apps/website/src/data_files/faqs.json
View File

@ -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?",
"answer": "No. Tenantial describes restore as a cautious workflow with preview, validation, selective scope, explicit confirmation, and review context, without promising recovery success."
},
{
"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."
"question": "Is Tenantial meant for MSPs and internal IT teams?",
"answer": "Yes. The public positioning speaks to MSPs, internal IT, security, and governance teams that need to align policy context, review work, and recovery readiness."
}
]
}

28
apps/website/src/data_files/features.json
View File

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

400
apps/website/src/data_files/site-copy.ts
View File

@ -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.',
primaryCta: 'Walkthrough anfragen',
secondaryCta: 'Produktmodell ansehen',
'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.',
supportingLine:
'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:
'Vom <span class="text-yellow-500 dark:text-yellow-400">Snapshot</span> zur Review-Entscheidung.',
tabs: [
audienceTitle: 'Eine belastbare Wahrheit für MSPs, IT und Audit.',
audienceSubtitle:
'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.',
svg: 'frame',
alt: 'Statische Tenantial Evidence-Intake-Vorschau',
first: true,
'Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.',
},
{
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.',
svg: 'dashboard',
alt: 'Statische Tenantial Decision-Review-Vorschau',
second: true,
'Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren.',
},
{
heading: 'Restore-Planung',
title: 'Security & Audit',
content:
'Behandle Restore als preview-first Arbeit mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung.',
svg: 'verified',
alt: 'Statische Tenantial Restore-Planungs-Vorschau',
'Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen.',
},
],
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.',
heading: 'Öffentliches Produktmodell',
'Tenantial erklärt Policy Governance für Microsoft 365 mit beobachtetem Zustand, Evidence, Drift Detection, Governance Reviews, Audit Trail und kontrollierter Recovery-Planung.',
heading: 'Policy-Governance-Modell für Microsoft 365',
subtitle:
'Tenantial 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.',
backupTitle: 'Backup- und Snapshot-Evidence',
'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.',
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: 'Preview', description: 'vor Restore-Ausführung' },
{ stat: 'Review', description: 'vor kritischen Änderungen' },
{ stat: 'Microsoft 365', description: 'heutiger Fokus' },
{ stat: 'Weitere Domänen', description: 'klar als Richtung markiert' },
{ stat: 'Keine Live-Daten', description: 'auf der öffentlichen Website' },
],
mainStatTitle: '0',
mainStatTitle: 'Heute',
mainStatSubTitle:
'Live-Tenant-Datensätze werden von dieser öffentlichen Website genutzt',
'Microsoft 365 ist der erste öffentliche Fokus der Produktstory',
},
pricingIntro: {
pageTitle: 'Preise | Tenantial',
metaDescription:
'Tenantial Preise nutzen konservative Evaluierungs- und Rollout-Gespräche statt sofortiger Zahlung oder Access-Claims.',
'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.',
heading: 'Vertrauen beginnt mit klaren Grenzen',
'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 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.',
mainStatTitle: 'Statisch',
mainStatSubTitle: 'nur Produkt-Previews',
'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: 'Review-first',
mainStatSubTitle: 'Evidence, Findings und Entscheidungen bleiben nachvollziehbar',
stats: [
{ stat: 'Keine', description: 'Kundenlogo-Belege' },
{ stat: 'Keine', description: 'externen Endorsements' },
{ stat: 'Keine', description: 'Compliance-Zusagen ohne Nachweis' },
{ 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.',
primaryCta: 'Request walkthrough',
secondaryCta: 'View product model',
'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.',
supportingLine:
'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:
'From <span class="text-yellow-500 dark:text-yellow-400">snapshot</span> to review decision.',
tabs: [
audienceTitle: 'One reliable truth for MSPs, IT, and audit.',
audienceSubtitle:
'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.',
svg: 'frame',
alt: 'Static Tenantial evidence intake preview',
first: true,
'Monitor, compare, and prepare multiple customer environments for controlled reviews.',
},
{
heading: 'Decision review',
title: 'Enterprise IT',
content:
'Surface drift detection, findings, exceptions, auditability, and review notes before administrators choose the next action.',
svg: 'dashboard',
alt: 'Static Tenantial decision review preview',
second: true,
'Document changes, drift, and recovery risks in a traceable way.',
},
{
heading: 'Restore planning',
title: 'Security & Audit',
content:
'Treat restore as preview-first work with validation, conflict awareness, selective scope, and explicit confirmation.',
svg: 'verified',
alt: 'Static Tenantial restore planning preview',
'Turn evidence, findings, and accepted risks into reviewable material.',
},
],
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.',
heading: 'Public product model',
'Tenantial explains policy governance for Microsoft 365 with observed state, evidence, drift detection, governance reviews, audit trail, and controlled recovery planning.',
heading: 'Policy governance model for Microsoft 365',
subtitle:
'Tenantial 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.',
backupTitle: 'Backup and snapshot evidence',
'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.',
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: 'Preview', description: 'before restore execution' },
{ stat: 'Review', description: 'before high-impact changes' },
{ stat: 'Microsoft 365', description: 'current focus' },
{ stat: 'Further domains', description: 'clearly marked as direction' },
{ stat: 'No live data', description: 'on the public website' },
],
mainStatTitle: '0',
mainStatSubTitle: 'live tenant records used by this public website',
mainStatTitle: 'Today',
mainStatSubTitle: 'Microsoft 365 is the first public product focus',
},
pricingIntro: {
pageTitle: 'Pricing | Tenantial',
metaDescription:
'Tenantial pricing uses conservative evaluation and rollout conversation paths, not instant public payment or access claims.',
'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.',
heading: 'Trust starts with clear 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 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.',
mainStatTitle: 'Static',
mainStatSubTitle: 'product previews only',
'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: 'Review-first',
mainStatSubTitle: 'evidence, findings, and decisions stay traceable',
stats: [
{ stat: 'No', description: 'customer-logo proof' },
{ stat: 'No', description: 'external endorsement claim' },
{ stat: 'No', description: 'unsupported compliance claims' },
{ stat: 'No', description: 'customer-proof or endorsement claims' },
{ stat: 'No', description: 'live tenant connection' },
],
},
@ -467,54 +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.',
svg: 'checkCircle',
'Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden.',
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.',
svg: 'checkCircle',
'Assess restore and recovery questions with scope, risk, and evidence before changes are executed.',
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.',
},
{
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.',
'Ja. Die öffentliche Positionierung spricht MSPs, interne IT-, Security- und Governance-Teams an, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.',
},
],
},
@ -629,7 +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.',
},
{
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.',
'Yes. The public positioning speaks to MSPs, internal IT, security, and governance teams that need to align policy context, review work, and recovery readiness.',
},
],
},

10
apps/website/tests/smoke/interaction.spec.ts
View File

@ -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();
});

61
apps/website/tests/smoke/public-routes.spec.ts
View File

@ -20,24 +20,24 @@ import { globby } from 'globby';
const routeMetadata = {
'/': {
title: /Tenantial.*Evidenzbasierte Microsoft-Tenant-Governance/i,
description: /evidenzbasierte Governance/i,
title: /Tenantial.*Microsoft 365 Policies unter Kontrolle bringen/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,
description:
/evidence-first governance for Microsoft tenant configuration/i,
title: /Tenantial.*Bring Microsoft 365 policies under control/i,
description: /Detect Microsoft 365 policy drift early|versioned configuration backups/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();
});

23
apps/website/tests/smoke/smoke-helpers.ts
View File

@ -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'],
['restore'],
['drift detection', 'drift'],
['findings'],
['policy governance', 'policy-governance', 'governance'],
['microsoft 365'],
['evidence'],
['auditability'],
['exceptions'],
['drift detection', 'policy-drift', 'drift'],
['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)),

11
specs/404-public-content-messaging/checklists/requirements.md
View File

@ -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.
- No `[NEEDS CLARIFICATION]` markers were needed; the spec uses the user's explicit scope and conservative defaults.
- Repository validation commands are listed as delivery checks; product requirements remain focused on public content, buyer understanding, CTA consistency, and claim safety.
- Validation pass 1 completed on 2026-05-25.
- No `[NEEDS CLARIFICATION]` markers remain; the supplied positioning, provider posture, and trust boundaries were specific enough to avoid open questions.
- Repository/workspace contract references and validation commands are intentional delivery guards, not framework-selection leakage.
- Existing downstream planning artifacts under `specs/404-public-content-messaging/` predate this refreshed spec and should be reconciled before implementation continues.

114
specs/404-public-content-messaging/contracts/public-content-contract.md
View File

@ -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
- first two homepage sections allow a reviewer to name at least three of backup, restore, drift, findings, evidence, audit trail, exceptions, and reviews
- section headings read as a coherent sequence from product category to buyer problem to operating model to capability proof to evaluation
- each major section adds distinct meaning rather than repeating the same product claim
- CTAs match the visitor's likely decision stage
- homepage copy stays suitable for later Spec 405 spacing and visual polish
- the hero clearly identifies Tenantial as policy governance for Microsoft 365 and modern cloud environments, or an equivalent policy-governance phrasing
- Microsoft 365 is presented as the first focus without collapsing the category to Intune-only messaging
- provider-extensible wording is allowed only as design or future direction, not live-support proof
- a trust teaser introduces auditability, evidence history, role-based access, review trails, or DACH evaluation readiness without false assurance
- an operating-model section makes the flow from observed state to evidence, detection, review, decision, and audit trail explicit
- a capability section explains policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability rather than a narrow feature list
- audience messaging reaches MSPs, internal IT teams, and governance-minded evaluators, not only endpoint administrators
- a boundaries section makes clear that Tenantial is not an admin-center clone, not blind automation, and not a helpdesk or PSA replacement
- the final CTA offers a concrete next step with an intentional destination
## `/platform` 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 Tenantial as governance-of-record, not helpdesk, device-action, or blind automation
- frames product-like previews as static/demo/illustrative where needed
- explains the governance model more deeply than the homepage
- connects evidence, findings, drift, review, accepted risks or exceptions, controlled recovery, and audit trail into one public product story
- keeps Microsoft 365 first focus without promising unsupported providers as live integrations
- frames previews, screenshots, or product-like examples as static/demo/illustrative where needed
- does not import, inspect, or cite `apps/platform` as an implementation source
- does not imply that the public website connects to a 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
- no checkout, instant subscription activation, self-serve billing, account creation, or fixed unsupported entitlement claims
- managed rollout language reads as a scoped commercial conversation rather than a fake fixed plan
- pricing/evaluation CTAs route to `/contact` or another intentional route/anchor
- visual language requirements are limited to content clarity; broad layout polish remains Spec 405
- Microsoft 365 is the current public focus
- Intune is one Microsoft 365 policy domain, not the umbrella product category
- Entra or other Microsoft domains may be described only when consistent with current route truth
- Google, AWS, and other non-Microsoft providers may appear only as architecture direction, future direction, or provider-extensible wording unless current support is verified
- roadmap or architecture-direction references must be clearly labeled as such
## Trust, 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
- Microsoft endorsement or partnership claims
- compliance guarantees
- recovery guarantees
- uptime guarantees
- fake customer logos
- fake testimonials
- fake "trusted by" claims
- real customer evidence implications
- public website live-tenant-data implications
- German hosting
- DSGVO or GDPR compliance
- AVV or TOM availability
- ISO, BSI, NIS2, or similar certification
- Microsoft endorsement or partnership
- no customer data stored
- automatic restore, autonomous remediation, self-healing, or approval-free automation
- fake customer logos, fake testimonials, fake case studies, or fake compliance badges
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
- secondary educational paths route to product, pricing, trust, docs, or legal explanations
- localized public links remain in the current locale where a localized route exists
- labels avoid login, signup, account creation, checkout, subscription, instant provisioning, automated scheduling, or guaranteed backend submission implications unless those workflows exist
- CTA language is normalized by intent family before individual labels are rewritten
- no navigation labels that imply production-ready pages which do not exist
- primary CTAs lead to contact, walkthrough, demo discussion, or another real next step
- secondary CTAs lead to product explanation, trust review, pricing review, or docs review
- localized routes remain in the current locale where a localized mirror exists
- labels avoid login, signup, account creation, checkout, subscription, instant provisioning, self-serve billing, or automated scheduling implications unless those workflows exist
## Metadata Contract
Each rendered canonical route must provide:
- Tenantial-specific page title
- Tenantial-specific page description
- Tenantial-specific page title and description
- policy-governance positioning rather than Intune-only framing
- route-appropriate canonical, Open Graph, and Twitter summary values
- no ScrewFast, construction, hardware, manufacturing, template, TenantAtlas, TenantPilot, or TenantCTRL residue in public metadata
- no unsupported proof 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
- no unsupported provider, trust, proof, or automation claims in title, description, Open Graph, Twitter, schema, or docs metadata
- sitemap and robots behavior preserved from the launch-readiness baseline unless a website-scope correction is documented
## Docs Exposure Contract
Exposed docs routes must:
- contain intentional Tenantial-specific content or be hidden from public navigation
- avoid placeholder theme content
- avoid unsupported product behavior claims
- avoid support, legal, integration, compliance, or recovery commitments not supplied by the product/business
- keep public docs separate from `apps/platform` implementation documentation unless a future spec explicitly changes scope
- reinforce the same policy-governance and claim-safe posture as the marketing routes
- avoid placeholder theme content and unsupported product behavior claims
- avoid support, legal, provider, compliance, or recovery commitments not supplied by current product/business truth
- remain clearly separate from `apps/platform` implementation documentation unless a future spec changes scope
## Product Preview Contract
Static product previews must:
- be framed as illustrative, static, or demo content where needed
- avoid implying live tenant data
- avoid implying live tenant/customer/provider data
- avoid internal Laravel/Filament implementation details
- avoid turning visual labels into product runtime taxonomy
- communicate meaning through text or labels, not color alone
- avoid turning visual labels into runtime product taxonomy
- communicate meaning through wording and labeling, not color alone
## Browser And Accessibility Contract

160
specs/404-public-content-messaging/data-model.md
View File

@ -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`
- `path`: public URL path when the surface maps to a route
- `locale`: German default, English mirror, shared, or locale-neutral
- `sourceArea`: page, shared data file, component, docs content, metadata, navigation, footer, or smoke expectation
- `audienceIntent`: first-time visitor, buyer evaluator, security-conscious reviewer, or site owner/reviewer
- `sectionRole`: category definition, problem framing, operating model, capability explanation, evaluation, trust, FAQ, legal-adjacent, or closing CTA
- `readiness`: needs audit, needs rewrite, accepted, or hidden from navigation
- `surfaceId`: stable identifier such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, `footer`, or `site-meta`
- `path`: public route path when the surface maps to a URL
- `locale`: default German, English mirror, shared, or locale-neutral
- `sourceArea`: shared copy file, route wrapper, page component, docs content, metadata component, navigation/footer component, or smoke expectation
- `audienceIntent`: first-time visitor, MSP evaluator, internal IT evaluator, governance reviewer, or site maintainer
- `surfaceRole`: hero, operating model, capability section, provider posture, trust teaser, boundary section, CTA surface, docs surface, or route metadata
- `status`: needs audit, needs rewrite, accepted, hidden from navigation, or removed
**Validation Rules**
- Every exposed core public page must have intentional Tenantial-specific content.
- Homepage surfaces must support a coherent narrative from product category to evaluation.
- `/platform` surfaces must explain the public product model more deeply than the homepage.
- Surfaces must not import, reference, or depend on `apps/platform`.
- Every exposed core public route must have intentional Tenantial-specific content.
- Homepage surfaces must support policy-governance category clarity and an operating-model narrative.
- `/platform` must explain the governance model more deeply than the homepage.
- No positioning surface may import, reference, or depend on `apps/platform`.
## Messaging Claim
Represents visible copy or metadata that could create a product, 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
- `proofStatus`: verified, conservative positioning, illustrative/static, unsupported, or remove
- `claimCategory`: product category, provider posture, trust, pricing, restore, automation, compliance, endorsement, social proof, preview framing, or workflow expectation
- `proofStatus`: verified, conservative positioning, architecture direction, illustrative/static, unsupported, or remove
- `riskLevel`: low, medium, high
- `requiredAction`: keep, rewrite, remove, hide, or verify proof
**Validation Rules**
- Unsupported SOC 2, ISO, Microsoft endorsement, compliance guarantee, recovery guarantee, uptime guarantee, and customer-proof claims must be removed or rewritten.
- Restore language must avoid guaranteed recovery or automatic success.
- Audit/evidence language must avoid legal sufficiency, certification, and guaranteed compliance.
- Public copy must not imply that the website connects to or displays live Microsoft tenant data.
- Unsupported provider, certification, compliance, hosting, endorsement, and customer-proof claims must be removed or rewritten.
- Restore and automation language must avoid autonomous remediation or guaranteed recovery.
- Trust language must stop at evaluation readiness, auditability, evidence history, review trails, and role-based access unless proof exists.
- Public copy must not imply that the website connects to or displays live provider/customer data.
## 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
- `sourceSurface`: page, component, footer, docs nav, or metadata-adjacent content area where the CTA appears
- `target`: route, anchor, static asset, mailto link, or legitimate external URL
- `intentFamily`: primary contact/demo, secondary product explanation, pricing evaluation, trust/legal review, docs review, or navigation
- `workflowImplied`: contact request, product education, pricing discussion, trust review, docs review, login, signup, checkout, subscription, account creation, automated scheduling, or backend submission
- `providerOrDomain`: Microsoft 365, Intune, Entra, Conditional Access, SharePoint, OneDrive sharing, Enterprise Apps, Service Principals, Google Workspace, AWS, or other domain wording
- `publicStatus`: current focus, example domain, roadmap domain, architecture direction, or disallowed claim
- `allowedLabel`: Microsoft 365 first, one policy domain, planned, roadmap domain, architecture direction, or omit
- `guardrail`: exact wording or implication that must be avoided
- `relatedSurfaces`: homepage, platform, docs, metadata, trust, or pricing surfaces where the reference appears
**Validation Rules**
- Microsoft 365 is the current public focus.
- Intune may appear only as one Microsoft 365 policy domain.
- Non-Microsoft providers may appear only as architecture direction or future direction when not verified.
- Public wording must not imply current live support where none exists.
## Operating Model Step
Represents one step in the public governance operating model.
**Fields**
- `stepId`: observe, evidence, detect, review, decide, audit
- `displayLabel`: localized section label for the step
- `goal`: what the step explains to a visitor
- `supportingConcepts`: evidence, findings, drift, exceptions, accepted risks, next actions, or audit trail elements
- `relatedSurfaces`: homepage, platform, docs, or metadata summaries where the step appears
**Validation Rules**
- The homepage operating model must contain a complete sequence from observed state to audit trail.
- Step labels must remain understandable to public evaluators and not degrade into implementation vocabulary.
- Each step must add meaning rather than repeat the prior step.
## CTA Intent
Represents a visible CTA, navigation item, footer link, or docs/action link.
**Fields**
- `label`: visible link or CTA text
- `sourceSurface`: route, shared component, footer, docs nav, or metadata-adjacent surface where the CTA appears
- `target`: route, anchor, static asset, `mailto:` link, or legitimate external URL
- `intentFamily`: primary contact/demo, secondary product explanation, trust review, docs review, pricing/evaluation, or navigation
- `workflowImplied`: walkthrough request, contact request, product education, trust review, pricing discussion, docs review, login, signup, checkout, account creation, self-serve billing, or automated scheduling
- `supported`: yes or no
**Validation Rules**
- Public CTAs must resolve to intentional routes or anchors.
- Public CTAs must not use `href="#"`.
- CTAs must not imply unavailable login, signup, checkout, account creation, instant provisioning, self-serve billing, automated scheduling, or guaranteed backend submission workflows.
- 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.
- Public CTAs must resolve to intentional targets and must not use `href="#"`.
- CTA labels must not imply unavailable login, signup, checkout, account creation, self-serve billing, or automated scheduling workflows.
- Primary CTA language should remain consistent across core public routes.
## Route Metadata
Represents public route title, description, canonical, 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.
- Sitemap and robots behavior from Spec 403 must remain intact unless explicitly corrected within website scope.
- Metadata must avoid unsupported provider, compliance, trust, or automation claims.
- Sitemap and robots behavior from the launch-readiness baseline must remain intact unless a website-scope correction is required.
## Relationships
- A `Public Content Surface` may contain many `Messaging Claim`, `CTA Intent`, `Product Capability Narrative`, `Static Preview Reference`, 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 `Product Capability Narrative` may appear on multiple public content surfaces, with the homepage carrying concise positioning and `/platform` carrying deeper explanation.
- `Route Metadata` belongs to one public route and must be reviewed with the visible copy for the same route.
- A `Public Positioning Surface` may contain many `Messaging Claim`, `Provider Posture Entry`, `Operating Model Step`, `CTA Intent`, and `Route Metadata` review points.
- A `Provider Posture Entry` may appear on multiple public positioning surfaces, but each appearance must preserve the same current-versus-future public status.
- An `Operating Model Step` may appear on the homepage, `/platform`, and docs surfaces, with the homepage carrying concise explanation and `/platform` carrying deeper detail.
- A `CTA Intent` belongs to one source surface and targets one intentional route, anchor, asset, or legitimate external URL.
- `Route Metadata` belongs to one public route and must be reviewed alongside the visible copy for that same route.
## State Transitions

354
specs/404-public-content-messaging/plan.md
View File

@ -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`
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`
**Branch**: `404-public-content-messaging`
**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
**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
## Scope Decision
## 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
- **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
## Repo Verification
## 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
- **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
- **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
- **New abstraction introduced? why?**: none planned
- **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.
- **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
1. Run `git status --short --branch`.
2. Locate the 404 spec folder with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`.
3. Read `specs/404-public-content-messaging/spec.md`, `plan.md`, and `tasks.md`.
4. Inspect the website structure with `find apps/website -maxdepth 3 -type f | sort | sed -n '1,180p'`.
5. Read `apps/website/package.json` and use only scripts that actually exist.
6. Confirm `apps/platform` remains outside the change.
## OperationRun UX Impact
## Current Copy Inventory
- **Touches OperationRun start/completion/link UX?**: no
- **Central contract reused**: N/A
- **Delegated UX behaviors**: N/A
- **Surface-owned behavior kept local**: N/A
- **Queued DB-notification policy**: N/A
- **Terminal notification path**: N/A
- **Exception path**: none
The later implementation must inventory current visible website copy before changing it:
## 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
- **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
The inventory must identify old internal, defensive, academic, or architecture-heavy wording, including:
## 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.
- 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.
### 1. Hero And Above The Fold
**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
- **Affected validation lanes**: website build, public smoke, manual browser/content review, whitespace/scope checks
- **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.
Primary CTA: "Demo buchen"
Secondary CTA: "Plattform ansehen"
## Project Structure
### 2. Problem And Pain Section
### Documentation (this feature)
The first supporting section must make the buyer pain explicit:
```text
/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/
├── plan.md
├── research.md
├── data-model.md
├── quickstart.md
├── contracts/
│ └── public-content-contract.md
├── checklists/
│ └── requirements.md
└── tasks.md
```
- Microsoft 365 policies drift.
- Admin centers show current settings but do not provide enough review context by themselves.
- Operators need to know what changed, what is backed up, which evidence exists, and which findings need action before the next review.
### Source Code (repository root)
Avoid product-philosophy explanations here.
```text
/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/
```
### 3. Capability Cards
**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 |
|-----------|------------|-------------------------------------|
| None | N/A | N/A |
Each card must describe what the buyer can see, compare, prepare, or document. Do not turn these into internal modules or architecture components.
## 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.
- **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.
Define a clear stakeholder section for:
## 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.
- 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.
Differentiate Tenantial without attacking Microsoft tools:
## 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`
- `/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`
Keep the trust teaser safe and specific:
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.
- 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.
- Browser/static validation remains explicit and bounded to `apps/website`.
- `apps/platform` remains out of scope and must be verified by `git status --short -- apps/platform`.
End with an evaluation-oriented CTA:
- Headline: "Bereit, Microsoft 365 Governance messbar zu machen?"
- Body: "Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt."
- 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

101
specs/404-public-content-messaging/quickstart.md
View File

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

111
specs/404-public-content-messaging/research.md
View File

@ -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.
- Introduce a new design system or content framework: rejected because this feature should stabilize copy before Spec 405 visual polish.
- 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.
- Rebuild the public website foundation: rejected by scope and unnecessary after Specs 400-403.
- Introduce a new content framework or CMS: rejected because this feature needs narrative clarity, not another authoring layer.
- Use `apps/platform` as a content source: rejected because the public `/platform` route is static website positioning and `apps/platform` is explicitly out of scope.
## Decision: Treat 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.
- Leave the contract implicit in copy review comments: rejected because later layout work needs stable section intent and CTA rules.
- Model messaging states as persisted product data: rejected because it would create unnecessary taxonomy or persistence.
- Leave behavior implicit in review comments: rejected because the later implementation and smoke updates need stable, explicit rules.
## Decision: Use a homepage 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.
- Lead with pricing or feature grids: rejected because buyers first need category clarity and trust-safe product framing.
- Optimize layout before copy: rejected because section spacing should follow stable content.
- Keep the existing feature-list emphasis: rejected because it allows the product to collapse back to an Intune-only or backup-only impression.
- Lead with pricing or generic SaaS value claims: rejected because category clarity and trust-safe positioning must come first.
- Defer narrative changes until visual polish: rejected because later layout decisions should follow stable section intent.
## Decision: Make `/platform` the deeper 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.
- Reference admin implementation details: rejected because the public route must not be coupled to Laravel, Filament, Livewire, RBAC, tenant data, or Graph runtime code.
- Present previews as live tenant output: rejected because previews are static/demo content only.
- Maintain two competing product explanation pages: rejected because it would fragment the public story.
- Mirror homepage copy on `/platform`: rejected because the route should go deeper than the homepage.
- Reference internal admin implementation details: rejected because the public route must not imply Laravel/Filament/Livewire/runtime coupling.
## Decision: Keep 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.
- Use consumer-style pricing tables with strong contrast: rejected because this spec focuses on calm enterprise trust and content clarity, not fake commercial certainty.
- Hide pricing entirely: rejected because buyers still need evaluation expectations and a credible next step.
- Present the product as Intune-only: rejected because it narrows the intended category too far.
- Present the product as broadly provider-agnostic today: rejected because current support truth does not justify it.
- Avoid provider posture entirely: rejected because the spec requires safe provider-extensible framing.
## Decision: Build trust through 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.
- Keep generic "trusted by" or certification placeholders: rejected unless removed or rewritten as neutral proof-safe language.
- Avoid all trust language: rejected because security-conscious buyers need careful explanations of claim boundaries.
- Use aspirational trust claims to sound enterprise-ready: rejected because it creates legal and commercial risk.
- Remove trust language entirely: rejected because evaluators still need a clear, honest trust posture.
- Hide boundaries and hope later trust pages fix them: rejected because public pages need safe wording now.
## Decision: 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.
**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.
**Rationale**: The existing Playwright smoke helpers already validate rendered routes, placeholder-link bans, forbidden public residue, metadata, redirects, mobile navigation, keyboard reachability, and overflow. Those checks, plus a targeted static grep scan for newly forbidden terms, are the narrowest sufficient validation.
**Alternatives considered**:
- Run Laravel/Pest/Filament tests: rejected because this feature does not touch `apps/platform`.
- Rely only on copy review: rejected because public output still needs route, CTA, metadata, responsive, and smoke validation.
- Add new browser test families now: rejected unless implementation changes require them; existing smoke can be updated proportionally during tasks.
- Add a new website-only test framework: rejected because the current smoke suite already covers the needed route and claim surfaces.
- Rely only on manual copy review: rejected because emitted output, links, and metadata also need executable proof.
## Decision: Keep docs and locale mirrors intentional and in sync with the positioning contract
**Rationale**: The public website exposes docs routes under both the default locale and `/en/...` mirrors, and both route families are driven by shared content/copy organization. Public docs and locale mirrors therefore need the same claim discipline and route-intent review as the core marketing pages.
**Alternatives considered**:
- Treat docs exposure as separate from positioning: rejected because public docs influence buyer understanding and indexing.
- Update only German default routes: rejected because `/en/...` pages share the same positioning responsibility.
- Hide all docs routes temporarily: rejected unless specific routes are found to be unready during implementation.
## Current Source Observations
- Core public pages are under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/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`.
- Starlight/docs content is under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`.
- Existing smoke tests live under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`.
- 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.
- 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.
- Core marketing routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages` are thin wrappers around shared components in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages`.
- Navigation labels, CTA labels, page titles, and page descriptions are centralized in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`.
- Metadata flows through `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`.
- Locale routing is mirrored under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` using shared component and copy sources.
- Starlight docs content lives under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` and is publicly rendered.
- Existing smoke coverage lives under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke` and already includes forbidden public pattern detection, placeholder-link detection, metadata checks, and mobile/keyboard/overflow checks.
- Placeholder collections still exist under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/blog`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/insights`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/products`; public exposure must remain intentional and route-safe.

632
specs/404-public-content-messaging/spec.md
View File

@ -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.
- **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.
- **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.
- **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.
- **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`.
- **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.
- **Why now**: Layout polish should follow stable content; otherwise spacing and visual hierarchy would be optimized around copy that may still change.
- **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.
- **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**: 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**: 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 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 `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 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**: 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 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.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 2 | Produktnähe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12**
- **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 | 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`.
- **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
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.
## 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
- do not import from it
- do not inspect it as a content source
- do not run Laravel, Filament, Livewire, Blade, migrations, policies, providers, jobs, queues, database, tenant/workspace, RBAC, or Microsoft Graph code
- only verify through `git status --short -- apps/platform` that it remains untouched
- "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"
- "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
- who it is for
- which Microsoft tenant governance problems it addresses
- why evidence-first governance matters
- how backup, restore, drift, findings, exceptions, auditability, and reviews fit together
- what a visitor should do next
- "Microsoft 365 Policies unter Kontrolle bringen"
- "Policy-Drift früh erkennen"
- "Konfigurationsstände versioniert sichern"
- "auditfähige Evidence vorbereiten"
- "prüfbare Review Packs"
- "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
- rebuild or recreate `apps/website`
- perform broad visual redesign
- introduce a new design system
- add backend forms, auth, billing, newsletter, login, checkout, account creation, or self-serve subscription behavior
- add new product runtime capabilities
- introduce Microsoft Graph calls
- claim integrations or certifications that are not verified
- add customer logos, testimonials, or "trusted by" claims
- touch `apps/platform`
- change Filament, Livewire, Laravel, Blade, providers, policies, migrations, jobs, queues, database, tenant isolation, workspace behavior, RBAC, or AuditLog behavior
- "unter absoluter Kontrolle"
- "Drift in Echtzeit", unless technically proven
- "automatisch reparieren"
- "autonomous remediation"
- "Self-healing"
- "automatic restore"
- "lückenlose Evidenz", unless precisely scoped and proven
- "gerichtsfeste Nachweise"
- "immutable backups", unless real immutability is proven for the public claim context
- "DSGVO-konform"
- "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.
- 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.
### Trust And Compliance Posture
## 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.
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.
The later homepage implementation must follow this section structure unless a later approved spec narrows it.
## 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.
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.
> Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen.
---
**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.
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.
> 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.
---
### 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.
2. **Given** product-like previews are present, **When** copy references them, **Then** they are described as illustrative/static.
3. **Given** the page mentions Microsoft tenants, **When** reviewed, **Then** it remains public product positioning and does not imply website runtime provider access.
6. **Entscheidungen nachvollziehbar machen**
Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen.
---
### 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.
2. **Given** evaluation packages are shown, **When** reviewed, **Then** they are framed as scoped conversations or rollout options.
3. **Given** CTAs appear in pricing sections, **When** clicked, **Then** they route to `/contact` or another intentional page.
- **MSP Operatoren**
Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.
---
- **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.
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.
> 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.
---
### 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.
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.
> Bereit, Microsoft 365 Governance messbar zu machen?
### Edge Cases
**Body**
- If a strong marketing phrase risks unsupported claims, prefer conservative wording.
- 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.
> Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt.
## Requirements *(mandatory)*
**Buttons**
### Assumptions
- Demo buchen
- Plattform ansehen
- Spec 402 and Spec 403 are complete.
- `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.
## Metadata And SEO Direction
### 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`.
- **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.
Example title direction:
#### 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.
- **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.
Example description direction:
#### 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.
- **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.
## Requirements
#### Page-Level Content
### Scope Requirements
- **FR-017**: `/` MUST contain finalized homepage copy suitable for layout polish.
- **FR-018**: `/platform` MUST contain deeper product-model copy than the homepage.
- **FR-019**: `/pricing` MUST use conservative evaluation/scoped rollout language.
- **FR-020**: `/trust` MUST use proof-safe trust language.
- **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.
- **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-002**: Website implementation scope MUST remain `apps/website` only.
- **FR-003**: This spec MUST explicitly forbid `apps/platform` changes.
- **FR-004**: This implementation MUST not introduce backend runtime, database, platform, provider, dependency, or build-output changes.
#### CTA Language
### Sales-Copy Requirements
- **FR-023**: Primary CTA language SHOULD be consistent across the site.
- **FR-024**: Secondary CTA language SHOULD clearly indicate informational navigation.
- **FR-025**: CTAs MUST resolve to intentional routes or anchors.
- **FR-026**: CTAs MUST NOT imply unavailable workflow such as login, signup, checkout, account creation, instant provisioning, or automated scheduling.
- **FR-005**: Visible public copy MUST sell business outcomes rather than internal architecture.
- **FR-006**: The homepage hero MUST lead with Microsoft 365 policy control, not product-category philosophy.
- **FR-007**: The hero and first supporting section MUST mention policy drift, versioned configuration backups, evidence, reviews, changes, and recovery context.
- **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-028**: Public copy MUST NOT claim SOC 2, ISO, Microsoft endorsement, guaranteed uptime, guaranteed recovery, or guaranteed compliance unless verified proof is supplied.
- **FR-029**: Public copy MUST NOT expose ScrewFast, construction, hardware, manufacturing, template, TenantAtlas, TenantPilot, or TenantCTRL as public brand residue.
- **FR-030**: Public copy MUST NOT imply the public website connects to a live Microsoft tenant.
- **FR-031**: Public copy MUST NOT imply the public website displays real tenant data.
- **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-017**: Capability cards MUST be outcome-led and cover drift, backups/versioning, reviews/evidence, recovery preparation, permissions/provider access, and decision traceability.
- **FR-018**: Stakeholder copy MUST explicitly cover MSP operators, Enterprise IT, and Security/Audit.
- **FR-019**: Differentiation copy MUST explain that Tenantial complements Microsoft Admin Center rather than replacing it.
- **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-033**: Metadata MUST remain Tenantial-specific and residue-free.
- **FR-034**: Sitemap and robots behavior from Spec 403 MUST remain intact.
- **FR-021**: Later implementation MUST include static scans for forbidden claims and old internal/defensive phrases.
- **FR-022**: Later implementation MUST include browser smoke review for desktop and mobile homepage readability, CTA visibility, and no visible copy overlap.
- **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`.
- **FR-036**: Public smoke validation MUST pass with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`.
- **FR-037**: Whitespace/conflict validation MUST pass with `git diff --check`.
- **FR-038**: Scope validation MUST confirm `git status --short -- apps/platform` is empty.
- **FR-039**: Implementation summary MUST list changed pages, CTA labels, claim-safety decisions, validation results, and any content follow-ups.
- **Current change classification**: Browser/static website copy implementation.
- **Runtime impact**: Static website source and website smoke-test expectations only. No backend, database, provider, platform, dependency, or build-output change is introduced.
- **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.
- **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`.
- **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.
- **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
### User Story 1 - MSP Buyer Understands The Operational Risk
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.
- 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.
**Acceptance Criteria**
## 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
corepack pnpm build:website
WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke
git diff --check
git status --short -- apps/platform
```
### User Story 2 - Enterprise IT Sees Recovery And Audit Context
## Reviewer Notes
Reviewers should evaluate content quality before requesting spacing or layout refinements.
An IT leader reads the page and understands that Tenantial documents changes, configuration history, drift, and recovery risk before action.
The review should answer:
**Acceptance Criteria**
1. Is the product category clear?
2. Is the homepage narrative coherent?
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?
1. Given the capability cards, when Enterprise IT evaluates the page, then versioned backups, historical comparison, and controlled recovery preparation are explicit.
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.
## 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

249
specs/404-public-content-messaging/tasks.md
View File

@ -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/`
**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)
**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`
**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] 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`
- [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] **T001: Repo-Zustand und Spec-404-Pfad verifizieren**
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] **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] 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`
- [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`
- [X] **T006: Capability- und Outcome-Sprache definieren**
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.
**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 [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`
- [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`
- [X] **T012: Final prüfen, dass nur erlaubte Website- und keine `apps/platform`-Dateien geändert wurden**
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.
**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] 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`
- [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`
- [X] **T018: Metadata und Platform-Wording von interner Architektur-Copy befreien**
Update public metadata and obvious supporting route copy to avoid governance-of-record, source-of-truth, and provider-extensible hero language.
**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.
**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.
- [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`
- [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`
- [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`
- [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`
- [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`
**Checkpoint**: User Story 3 is independently shippable once `/platform` communicates the public product model safely.
---
## 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.
- `spec.md`, `plan.md`, and `tasks.md` are consistent.
- Spec 404 is titled or clearly framed as "Public Website Sales Copy & Positioning Rewrite".
- The spec sells business outcomes rather than internal architecture.
- Concrete visible copy examples are present.
- Microsoft 365 is clearly the first public market.
- Intune is an example/start domain, not the product boundary.
- Provider extensibility is secondary and not overclaimed.
- Website implementation was performed only in approved `apps/website` source and website-smoke-test files.
- No `apps/platform` changes were performed.
- No root/workspace contracts were changed.
- 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.