diff --git a/.github/agents/copilot-instructions.md b/.github/agents/copilot-instructions.md index 910f11be..13f860f2 100644 --- a/.github/agents/copilot-instructions.md +++ b/.github/agents/copilot-instructions.md @@ -266,6 +266,8 @@ ## Active Technologies - PostgreSQL via existing `workspace_settings` rows plus existing audit log records; no new table or billing/account model (251-commercial-entitlements-billing-state) - PHP 8.4 (Laravel 12) + Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `UiEnforcement`, `OperationUxPresenter`, `OperationRunService`, `OperationCatalog`, `SystemOperationRunLinks`, `OperationRunLinks`, `AuditRecorder`, `WorkspaceAuditLogger`, and `PlatformCapabilities` (253-remove-findings-backfill-runtime-surfaces) - PostgreSQL existing `findings`, `operation_runs`, `audit_logs`, and related runtime tables only; no new persistence, migration, or data backfill is planned (253-remove-findings-backfill-runtime-surfaces) +- TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 + Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwrigh (404-public-content-messaging) +- N/A - static website content and generated build output only; no database or product persistence (404-public-content-messaging) - PHP 8.4.15 (feat/005-bulk-operations) @@ -300,9 +302,9 @@ ## Code Style PHP 8.4.15: Follow standard conventions ## Recent Changes +- 404-public-content-messaging: Added TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 + Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwrigh - 253-remove-findings-backfill-runtime-surfaces: Added PHP 8.4 (Laravel 12) + Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `UiEnforcement`, `OperationUxPresenter`, `OperationRunService`, `OperationCatalog`, `SystemOperationRunLinks`, `OperationRunLinks`, `AuditRecorder`, `WorkspaceAuditLogger`, and `PlatformCapabilities` - 251-commercial-entitlements-billing-state: Added PHP 8.4 (Laravel 12) + Filament v5 + Livewire v4, existing workspace settings stack (`SettingsRegistry`, `SettingsResolver`, `SettingsWriter`), `WorkspaceEntitlementResolver`, `ReviewPackService`, system directory detail page -- 249-customer-review-workspace: Added PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Pest v4, existing review/evidence/review-pack/audit/RBAC support services ### Pre-production compatibility check diff --git a/apps/website/src/components/pages/HomePage.astro b/apps/website/src/components/pages/HomePage.astro index 98677c06..0b56d194 100644 --- a/apps/website/src/components/pages/HomePage.astro +++ b/apps/website/src/components/pages/HomePage.astro @@ -5,6 +5,8 @@ import FeaturesGeneral from '@components/sections/features/FeaturesGeneral.astro import FeaturesNavs from '@components/sections/features/FeaturesNavs.astro'; import PricingSection from '@components/sections/pricing/PricingSection.astro'; import FAQ from '@components/sections/misc/FAQ.astro'; +import PrimaryCTA from '@components/ui/buttons/PrimaryCTA.astro'; +import SecondaryCTA from '@components/ui/buttons/SecondaryCTA.astro'; import heroImage from '@images/tenantial-dashboard.avif'; import featureImage from '@images/tenantial-review-board.avif'; import reviewImage from '@images/tenantial-evidence-intake.avif'; @@ -25,9 +27,17 @@ interface Props { } const copy = siteCopy[locale].home; +const workflowImages = [ + heroImage, + featureImage, + reviewImage, + evidenceImage, + governanceImage, + featureImage, +]; const tabs = copy.tabs.map((tab: any, index: number) => ({ ...tab, - src: [reviewImage, evidenceImage, governanceImage][index], + src: workflowImages[index], })); --- @@ -59,7 +69,85 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({ +
+
+

+ {copy.audienceTitle} +

+

+ {copy.audienceSubtitle} +

+
+ +
+ { + copy.audiences.map((audience: any) => ( +
+

+ {audience.title} +

+

+ {audience.content} +

+
+ )) + } +
+
+ +
+
+
+

+ {copy.boundaryTitle} +

+

+ {copy.boundarySubtitle} +

+
+ +
+ { + copy.boundaries.map((boundary: any) => ( +
+

+ {boundary.title} +

+

+ {boundary.content} +

+
+ )) + } +
+
+
+ + +
+
+
+

+ {copy.finalCtaTitle} +

+

+ {copy.finalCtaSubtitle} +

+
+ +
+ + +
+
+
diff --git a/apps/website/src/components/pages/PlatformPage.astro b/apps/website/src/components/pages/PlatformPage.astro index 609fd9cb..7dbfd305 100644 --- a/apps/website/src/components/pages/PlatformPage.astro +++ b/apps/website/src/components/pages/PlatformPage.astro @@ -57,6 +57,32 @@ const canonicalPath = localizedPath('/platform', locale); btnURL={localizeHref('/contact', locale)} /> +
+
+

+ {copy.focusTitle} +

+

+ {copy.focusSubtitle} +

+
+ +
+ { + copy.focusCards.map((card: any) => ( +
+

+ {card.title} +

+

+ {card.content} +

+
+ )) + } +
+
+ {/* Slot to allow for extensibility of the component */} - +
+ +
{/* Heading of the section */}

diff --git a/apps/website/src/components/ui/blocks/LeftSection.astro b/apps/website/src/components/ui/blocks/LeftSection.astro index 14bf12bf..58b9ccfc 100644 --- a/apps/website/src/components/ui/blocks/LeftSection.astro +++ b/apps/website/src/components/ui/blocks/LeftSection.astro @@ -33,7 +33,7 @@ interface Props {
{/* The title of the section */}

{title}

diff --git a/apps/website/src/components/ui/blocks/RightSection.astro b/apps/website/src/components/ui/blocks/RightSection.astro index 2834626d..fee2841a 100644 --- a/apps/website/src/components/ui/blocks/RightSection.astro +++ b/apps/website/src/components/ui/blocks/RightSection.astro @@ -37,7 +37,7 @@ interface Props {
{/* Title of the section */}

{title}

diff --git a/apps/website/src/components/ui/blocks/StatsBig.astro b/apps/website/src/components/ui/blocks/StatsBig.astro index 580d6200..525f5720 100644 --- a/apps/website/src/components/ui/blocks/StatsBig.astro +++ b/apps/website/src/components/ui/blocks/StatsBig.astro @@ -9,9 +9,11 @@ interface Props { --- {/* Container for the title and subtitle */} -
-

+

+

{title}

-

{subTitle}

+

+ {subTitle} +

diff --git a/apps/website/src/components/ui/blocks/StatsSmall.astro b/apps/website/src/components/ui/blocks/StatsSmall.astro index ba500ed0..c5127a75 100644 --- a/apps/website/src/components/ui/blocks/StatsSmall.astro +++ b/apps/website/src/components/ui/blocks/StatsSmall.astro @@ -9,7 +9,11 @@ interface Props { --- {/* Container for title and subtitle */} -
-

{title}

-

{subTitle}

+
+

+ {title} +

+

+ {subTitle} +

diff --git a/apps/website/src/components/ui/blocks/TabNav.astro b/apps/website/src/components/ui/blocks/TabNav.astro index b4396c13..6c3048ff 100644 --- a/apps/website/src/components/ui/blocks/TabNav.astro +++ b/apps/website/src/components/ui/blocks/TabNav.astro @@ -14,6 +14,8 @@ interface Props { // Define button classes const BUTTON_CLASS = 'dark:hover:bg-neutral-700 rounded-xl p-4 text-start outline-hidden ring-zinc-500 transition duration-300 hover:bg-neutral-200 focus-visible:ring-3 hs-tab-active:bg-neutral-50 hs-tab-active:shadow-md hs-tab-active:hover:border-transparent dark:ring-zinc-200 dark:focus:outline-hidden dark:hs-tab-active:bg-neutral-700/60 md:p-5'; +const ICON_CLASS = + 'mt-0.5 flex size-10 shrink-0 items-center justify-center text-neutral-500 transition-colors hs-tab-active:text-orange-500 dark:text-neutral-400 dark:hs-tab-active:text-orange-300 [&_svg]:m-0 [&_svg]:h-7 [&_svg]:w-7 [&_svg]:fill-current'; /* first: This property should be set to true for the initial TabNav component in your list @@ -40,13 +42,15 @@ Example: role="tab" > {/* Slot for additional content */} - - + + + + {/* Container for the heading and content of the tab */} - + {/* Heading of the tab, changes color when active */} {heading} {/* Content of the tab, changes color when active */} diff --git a/apps/website/src/content/docs/en/guides/first-project-checklist.mdx b/apps/website/src/content/docs/en/guides/first-project-checklist.mdx index 76850568..1e4e582a 100644 --- a/apps/website/src/content/docs/en/guides/first-project-checklist.mdx +++ b/apps/website/src/content/docs/en/guides/first-project-checklist.mdx @@ -9,8 +9,10 @@ sidebar: Use this checklist before a product walkthrough: - Confirm which Microsoft tenant workflows are in scope. +- Confirm that Microsoft 365 is the current focus and any other providers are treated only as future direction. - Separate read-only review needs from any future write or restore needs. - Identify audit and approval expectations. - Map backup, restore, drift, findings, evidence, auditability, exceptions, and reviews to the buyer questions that matter most. +- Keep trust, compliance, and recovery assumptions listed as items to verify rather than promises already made. - Plan staging validation before production rollout. - Keep private tenant data out of public website communication. diff --git a/apps/website/src/content/docs/en/guides/getting-started.mdx b/apps/website/src/content/docs/en/guides/getting-started.mdx index 2ffede17..7ef2c20f 100644 --- a/apps/website/src/content/docs/en/guides/getting-started.mdx +++ b/apps/website/src/content/docs/en/guides/getting-started.mdx @@ -11,9 +11,11 @@ Start with a scoped conversation about the tenant governance problem you want to Useful preparation: - Identify the Microsoft tenant administration workflows that need review. +- Note which questions are clearly in current Microsoft 365 scope and which provider questions stay future direction. - List which policy families, backup flows, or restore planning scenarios matter first. - Decide who needs to participate in evidence review and approval. - Note which findings, exceptions, or auditability expectations would carry the most decision value. +- Separate trust, compliance, and recovery questions into verified facts versus open review points. - Avoid sending private tenant exports or credentials through public website contact paths. Tenantial walkthroughs should stay focused on review clarity, least-privilege rollout planning, and staging validation before production use. diff --git a/apps/website/src/content/docs/en/guides/intro.mdx b/apps/website/src/content/docs/en/guides/intro.mdx index 27c1ace4..99a5b680 100644 --- a/apps/website/src/content/docs/en/guides/intro.mdx +++ b/apps/website/src/content/docs/en/guides/intro.mdx @@ -1,18 +1,20 @@ --- title: Introduction to Tenantial -description: Public introduction to Tenantial's evidence-first Microsoft tenant governance model. +description: Public introduction to Tenantial's policy-governance model for Microsoft 365. sidebar: label: Introduction order: 1 --- -Tenantial is positioned around evidence-first Microsoft tenant governance. Public materials explain how observed inventory, immutable policy snapshots, drift review, findings, exceptions, auditability, and defensive restore planning fit together as one reviewable product model. +Tenantial is positioned around policy governance for Microsoft 365. Public materials explain how observed state, policy evidence, drift, review, decisions, and audit trail fit together as one reviewable operating model. + +Microsoft 365 is the current public focus. Other providers may appear only as architecture or roadmap direction, not as live supported integrations. The website documentation is intentionally public and static. It does not expose live tenant data, operational evidence, private support material, credentials, or connected Microsoft accounts. ## What to review first -- How policy evidence is collected and normalized for review. -- How 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. diff --git a/apps/website/src/content/docs/en/platform/evidence-review.mdx b/apps/website/src/content/docs/en/platform/evidence-review.mdx index 668e6ffb..7a6c0a30 100644 --- a/apps/website/src/content/docs/en/platform/evidence-review.mdx +++ b/apps/website/src/content/docs/en/platform/evidence-review.mdx @@ -1,17 +1,19 @@ --- title: Evidence Review -description: Public platform note for Tenantial evidence review workflows. +description: Public platform note for Tenantial evidence-review workflows inside the Microsoft 365 policy-governance model. sidebar: label: Evidence Review order: 1 --- -Evidence review is the public framing for Tenantial's product direction. This note describes static product concepts and no live tenant connection. +Evidence review is the public framing for Tenantial's policy-governance model for Microsoft 365. This note describes static product concepts and no live tenant connection. + +Microsoft 365 is the current focus of this public story. Other providers may appear only as architecture or roadmap direction. The model is intentionally cautious: -- Inventory is treated as observed state. -- 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. diff --git a/apps/website/src/content/docs/en/welcome-to-docs.mdx b/apps/website/src/content/docs/en/welcome-to-docs.mdx index 8727ff9a..71601374 100644 --- a/apps/website/src/content/docs/en/welcome-to-docs.mdx +++ b/apps/website/src/content/docs/en/welcome-to-docs.mdx @@ -3,13 +3,13 @@ title: Tenantial Docs head: - tag: title content: Tenantial Docs -description: Public notes for understanding Tenantial's evidence-first Microsoft tenant governance model. +description: Public notes for understanding Tenantial's policy-governance model for Microsoft 365. editUrl: false lastUpdated: false next: false hero: title: Tenantial documentation - tagline: Public notes for evidence review, snapshot discipline, drift, findings, auditability, and cautious restore planning. + tagline: Public notes for observed state, evidence, drift, review, decisions, and audit trail with controlled recovery planning. actions: - text: Get started icon: right-arrow @@ -21,11 +21,11 @@ import '@styles/starlight_main.css'; import { Card, CardGrid } from '@astrojs/starlight/components'; - - Understand the public product model before planning a rollout conversation. + + Understand the sequence from observe to evidence, detect, review, decide, and audit before planning a rollout conversation. - - Review how Tenantial frames inventory evidence, snapshots, drift, findings, exceptions, reviews, and restore planning. + + Review how Tenantial keeps Microsoft 365 as the current focus, treats other providers as future direction, and keeps trust claims conservative. diff --git a/apps/website/src/content/docs/guides/first-project-checklist.mdx b/apps/website/src/content/docs/guides/first-project-checklist.mdx index 5c88c6be..7a78ef99 100644 --- a/apps/website/src/content/docs/guides/first-project-checklist.mdx +++ b/apps/website/src/content/docs/guides/first-project-checklist.mdx @@ -9,8 +9,10 @@ sidebar: Nutze diese Checkliste vor einem Produkt-Walkthrough: - Bestätige, welche Microsoft-Tenant-Workflows im Scope sind. +- Bestätige, dass Microsoft 365 der aktuelle Fokus ist und weitere Provider nur als Zukunftsrichtung behandelt werden. - Trenne Read-only-Review-Bedarf von künftigem Write- oder Restore-Bedarf. - Identifiziere Audit- und Approval-Erwartungen. - Ordne Backup, Restore, Drift, Findings, Evidence, Auditability, Exceptions und Reviews den wichtigsten Buyer-Fragen zu. +- Halte Trust-, Compliance- und Recovery-Annahmen als zu prüfende Themen fest statt als gegebene Zusagen. - Plane Staging-Validierung vor einem Produktionsrollout. - Halte private Tenant-Daten aus öffentlicher Website-Kommunikation heraus. diff --git a/apps/website/src/content/docs/guides/getting-started.mdx b/apps/website/src/content/docs/guides/getting-started.mdx index bf0b1437..eae3d79e 100644 --- a/apps/website/src/content/docs/guides/getting-started.mdx +++ b/apps/website/src/content/docs/guides/getting-started.mdx @@ -11,9 +11,11 @@ Starte mit einem scoped Gespräch über das Tenant-Governance-Problem, das gelö Sinnvolle Vorbereitung: - Identifiziere die Microsoft-Tenant-Administrationsworkflows, die Review brauchen. +- Halte fest, welche Themen heute klar in Microsoft 365 liegen und welche Provider-Fragen nur Zukunftsrichtung bleiben. - Liste die Policy-Familien, Backup-Flows oder Restore-Planungsszenarien, die zuerst relevant sind. - Entscheide, wer an Evidence Review und Approval teilnehmen muss. - Notiere, welche Findings, Exceptions oder Auditability-Erwartungen den größten Entscheidungswert hätten. +- Trenne Trust-, Compliance- und Recovery-Fragen in bestätigte Fakten versus offene Prüfpunkte. - Sende keine privaten Tenant-Exporte oder Credentials über öffentliche Website-Kontaktpfade. Tenantial Walkthroughs sollten auf Review-Klarheit, Least-Privilege-Rollout-Planung und Staging-Validierung vor Produktionseinsatz fokussiert bleiben. diff --git a/apps/website/src/content/docs/guides/intro.mdx b/apps/website/src/content/docs/guides/intro.mdx index 728f5306..c0a41281 100644 --- a/apps/website/src/content/docs/guides/intro.mdx +++ b/apps/website/src/content/docs/guides/intro.mdx @@ -1,18 +1,20 @@ --- title: Einführung in Tenantial -description: Öffentliche Einführung in Tenantials evidenzbasiertes Microsoft-Tenant-Governance-Modell. +description: Öffentliche Einführung in Tenantials Policy-Governance-Modell für Microsoft 365. sidebar: label: Einführung order: 1 --- -Tenantial ist auf evidence-first Microsoft-Tenant-Governance ausgerichtet. Öffentliche Materialien erklären, wie beobachtetes Inventory, unveränderliche Policy-Snapshots, Drift Review, Findings, Exceptions, Auditability und defensive Restore-Planung als ein prüfbares Produktmodell zusammenhängen. +Tenantial ist auf Policy Governance für Microsoft 365 ausgerichtet. Öffentliche Materialien erklären, wie beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail als ein prüfbares Operating Model zusammenhängen. + +Microsoft 365 ist der aktuelle öffentliche Fokus. Weitere Provider dürfen nur als Architektur- oder Roadmap-Richtung erscheinen, nicht als live unterstützte Integrationen. Die Website-Dokumentation ist bewusst öffentlich und statisch. Sie legt keine Live-Tenant-Daten, operative Evidence, private Support-Materialien, Credentials oder verbundenen Microsoft-Konten offen. ## Was zuerst geprüft werden sollte -- Wie Policy Evidence für Reviews gesammelt und normalisiert wird. -- Wie 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. diff --git a/apps/website/src/content/docs/platform/evidence-review.mdx b/apps/website/src/content/docs/platform/evidence-review.mdx index eec600ca..4f616044 100644 --- a/apps/website/src/content/docs/platform/evidence-review.mdx +++ b/apps/website/src/content/docs/platform/evidence-review.mdx @@ -1,17 +1,19 @@ --- title: Evidence Review -description: Öffentliche Plattform-Notiz für Tenantial Evidence-Review-Workflows. +description: Öffentliche Plattform-Notiz für Tenantials Evidence-Review-Workflows im Policy-Governance-Modell für Microsoft 365. sidebar: label: Evidence Review order: 1 --- -Evidence Review ist die öffentliche Rahmung für Tenantials Produktrichtung. Die Notiz beschreibt statische Produktkonzepte und keine Live-Tenant-Verbindung. +Evidence Review ist die öffentliche Rahmung für Tenantials Policy-Governance-Modell für Microsoft 365. Die Notiz beschreibt statische Produktkonzepte und keine Live-Tenant-Verbindung. + +Microsoft 365 ist der aktuelle Fokus dieser öffentlichen Story. Weitere Provider dürfen nur als Architektur- oder Roadmap-Richtung erscheinen. Das Modell ist bewusst vorsichtig: -- Inventory wird als beobachteter Zustand behandelt. -- 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. diff --git a/apps/website/src/content/docs/welcome-to-docs.mdx b/apps/website/src/content/docs/welcome-to-docs.mdx index 77d20201..18877e58 100644 --- a/apps/website/src/content/docs/welcome-to-docs.mdx +++ b/apps/website/src/content/docs/welcome-to-docs.mdx @@ -3,13 +3,13 @@ title: Tenantial Docs head: - tag: title content: Tenantial Docs -description: Öffentliche Notizen zum evidenzbasierten Microsoft-Tenant-Governance-Modell von Tenantial. +description: Öffentliche Notizen zum Policy-Governance-Modell für Microsoft 365 von Tenantial. editUrl: false lastUpdated: false next: false hero: title: Tenantial Dokumentation - tagline: Öffentliche Notizen zu Evidence Review, Snapshot-Disziplin, Drift, Findings, Auditability und vorsichtiger Restore-Planung. + tagline: Öffentliche Notizen zu beobachtetem Zustand, Evidence, Drift, Review, Entscheidung und Audit Trail mit kontrollierter Recovery-Planung. actions: - text: Starten icon: right-arrow @@ -21,11 +21,11 @@ import '@styles/starlight_main.css'; import { Card, CardGrid } from '@astrojs/starlight/components'; - - Verstehe das öffentliche Produktmodell, bevor ein Rollout-Gespräch geplant wird. + + Verstehe die Abfolge aus beobachten, Evidence sammeln, Drift erkennen, Review, Entscheidung und Audit Trail, bevor ein Rollout-Gespräch geplant wird. - - Prüfe, wie Tenantial Inventory Evidence, Snapshots, Drift, Findings, Exceptions, Reviews und Restore-Planung rahmt. + + Prüfe, wie Tenantial Microsoft 365 heute fokussiert, weitere Provider nur als Richtung rahmt und Trust-Claims bewusst konservativ hält. diff --git a/apps/website/src/data_files/constants.ts b/apps/website/src/data_files/constants.ts index 93fb7f93..fc520cc3 100644 --- a/apps/website/src/data_files/constants.ts +++ b/apps/website/src/data_files/constants.ts @@ -2,11 +2,11 @@ import ogImageSrc from '@images/social.png'; export const SITE = { title: 'Tenantial', - tagline: 'Evidenzbasierte Microsoft-Tenant-Governance', + tagline: 'Policy Governance für Microsoft 365', description: - 'Tenantial hilft Microsoft-Tenant-Teams, Policy-Evidence, Snapshots, Drift, Findings, Exceptions, Auditability und Restore-Pläne in prüfbare Entscheidungen zu übersetzen.', + 'Tenantial hilft MSPs, internen IT-Teams und Governance-Verantwortlichen, beobachteten Zustand, Policy-Evidence, Drift, Findings, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 in prüfbare Entscheidungen zu übersetzen.', description_short: - 'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Review, Backup, Drift, Findings und Restore-Planung.', + 'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.', url: 'https://tenantial.com', author: 'Tenantial', }; @@ -35,9 +35,9 @@ export const OG = { locale: 'de_DE', type: 'website', url: SITE.url, - title: `${SITE.title}: Evidenzbasierte Microsoft-Tenant-Governance`, + title: `${SITE.title}: Policy Governance für Microsoft 365`, description: - 'Prüfe Tenant Inventory, Snapshots, Drift, Findings, Evidence, Exceptions und Restore-Pläne mit konservativen, auditfreundlichen Workflows.', + 'Ordne beobachteten Zustand, Evidence, Drift, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 mit konservativen, auditfreundlichen Workflows ein.', image: ogImageSrc, }; diff --git a/apps/website/src/data_files/faqs.json b/apps/website/src/data_files/faqs.json index f83dacb2..fd2e8b28 100644 --- a/apps/website/src/data_files/faqs.json +++ b/apps/website/src/data_files/faqs.json @@ -3,19 +3,19 @@ "faqs": [ { "question": "What does Tenantial help teams understand?", - "answer": "Tenantial explains backup evidence, restore planning, drift detection, findings, evidence, auditability, exceptions, and reviews as one governance model for Microsoft tenant configuration." + "answer": "Tenantial explains policy governance for Microsoft 365: observed state, evidence, drift, review, decisions, audit trail, and controlled recovery planning in one operating model." + }, + { + "question": "Is Microsoft 365 the only relevant context?", + "answer": "Microsoft 365 is the current public focus. Other providers may be referenced as architecture or roadmap direction, but not as live supported integrations." }, { "question": "Does this public website connect to a live tenant?", "answer": "No. Product previews and examples are static demonstrations and do not authenticate visitors or read tenant data." }, { - "question": "Is restore positioned as an automatic outcome?", - "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." } ] } diff --git a/apps/website/src/data_files/features.json b/apps/website/src/data_files/features.json index ca6a8236..82bb0817 100644 --- a/apps/website/src/data_files/features.json +++ b/apps/website/src/data_files/features.json @@ -1,22 +1,32 @@ [ { - "heading": "Backup evidence", - "content": "Review observed policy metadata and backup snapshots from one readable source before 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" } ] diff --git a/apps/website/src/data_files/site-copy.ts b/apps/website/src/data_files/site-copy.ts index f1c96fc6..63b6d80e 100644 --- a/apps/website/src/data_files/site-copy.ts +++ b/apps/website/src/data_files/site-copy.ts @@ -35,11 +35,11 @@ type FaqGroup = { export const siteCopy: Record = { de: { site: { - tagline: 'Evidenzbasierte Microsoft-Tenant-Governance', + tagline: 'Policy Governance für Microsoft 365', 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, internen IT-Teams und Governance-Verantwortlichen, beobachteten Zustand, Policy-Evidence, Drift, Findings, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 in prüfbare Entscheidungen zu übersetzen.', descriptionShort: - 'Evidenzbasierte Governance-Workflows für Microsoft-Tenant-Reviews, Backup, Drift, Findings und Restore-Planung.', + 'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.', }, nav: [ { name: 'Start', url: '/' }, @@ -80,98 +80,179 @@ export const siteCopy: Record = { walkthrough: 'Walkthrough anfragen', }, home: { - pageTitle: 'Tenantial | Evidenzbasierte Microsoft-Tenant-Governance', + pageTitle: 'Tenantial | Policy Governance für Microsoft 365', metaDescription: - 'Tenantial ist evidenzbasierte Governance für Microsoft-Tenant-Konfiguration mit Backup, Restore, Drift Detection, Findings, Evidence, Auditability, Exceptions und Reviews.', + 'Tenantial ist Policy Governance für Microsoft 365: beobachteter Zustand, Policy-Evidence, Drift Detection, Reviews, Entscheidungen, Audit Trail und kontrollierte Recovery-Planung in einem prüfbaren Operating Model.', heroTitle: - 'Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration', + 'Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen', heroSubtitle: - 'Tenantial macht Backup, Restore, Drift Detection, Findings, Evidence, Exceptions, Auditability und Reviews zu einem prüfbaren Governance-Modell, bevor kritische Änderungen entschieden werden.', + 'Tenantial zeigt, wie beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail zu einem evidenzbasierten Governance-Modell werden. Microsoft 365 ist heute der erste Fokus; weitere Provider bleiben bewusst Zukunftsrichtung.', primaryCta: 'Walkthrough anfragen', - secondaryCta: 'Produktmodell ansehen', + secondaryCta: 'Governance-Modell ansehen', heroAlt: 'Statische Tenantial Governance-Dashboard-Vorschau', - featureTitle: 'Vom beobachteten Zustand zur Review-Entscheidung', + featureTitle: 'Die richtige Produktkategorie zuerst', 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 ist weder ein Intune-only Hilfstool noch ein Admin-Center-Klon. Die Plattform rahmt Microsoft 365 als ersten Einsatzbereich für Policy Governance, damit MSPs, interne IT-Teams und Governance-Verantwortliche dieselbe Evidence-Basis lesen.', featureAlt: 'Statische Tenantial Review-Board-Vorschau', workflowTitle: - 'Vom Snapshot zur Review-Entscheidung.', + 'Vom beobachteten Zustand zu Evidence, Review und Audit Trail.', tabs: [ { - heading: 'Evidence erfassen', + heading: 'Beobachten', content: - 'Normalisiere Inventory-, Backup- und Snapshot-Kontext, damit Reviews mit einer lesbaren Sicht auf den beobachteten Policy-Zustand starten.', + 'Starte mit dem beobachteten Microsoft-365-Status und einer lesbaren Sicht auf relevante Richtlinien, Konfigurationen und Verantwortlichkeiten.', svg: 'frame', - alt: 'Statische Tenantial Evidence-Intake-Vorschau', + alt: 'Statische Tenantial Observed-State-Vorschau', first: true, }, { - heading: 'Findings prüfen', + heading: 'Evidence sammeln', content: - 'Mache Drift Detection, Findings, Exceptions, Auditability und Review-Notizen sichtbar, bevor Administratoren die nächste Aktion wählen.', - svg: 'dashboard', - alt: 'Statische Tenantial Decision-Review-Vorschau', + 'Halte Snapshots, Nachweise und Kontext so fest, dass spätere Reviews auf einer stabilen Evidence-Basis und nicht auf Erinnerung beruhen.', + svg: 'books', + alt: 'Statische Tenantial Evidence-Intake-Vorschau', second: true, }, { - heading: 'Restore-Planung', + heading: 'Drift erkennen', content: - 'Behandle Restore als preview-first Arbeit mit Validierung, Konfliktbewusstsein, selektivem Scope und expliziter Bestätigung.', + 'Mache Unterschiede, Findings und Veränderungen sichtbar, bevor Teams überspringen, was überhaupt geprüft werden muss.', svg: 'verified', - alt: 'Statische Tenantial Restore-Planungs-Vorschau', + alt: 'Statische Tenantial Drift-Detection-Vorschau', + }, + { + heading: 'Review durchführen', + content: + 'Bringe MSPs, interne IT-Teams und Governance-Verantwortliche in denselben Review-Kontext aus Findings, Risiken, Exceptions und nächsten Schritten.', + svg: 'groups', + alt: 'Statische Tenantial Review-Board-Vorschau', + }, + { + heading: 'Entscheidung vorbereiten', + content: + 'Leite nachvollziehbare Entscheidungen für Freigaben, Ausnahmen oder kontrollierte Recovery-Arbeit aus Review, Evidence und Scope ab.', + svg: 'frame', + alt: 'Statische Tenantial Decision-Preparation-Vorschau', + }, + { + heading: 'Audit Trail sichern', + content: + 'Halte Begründung, akzeptierte Risiken und ausgewählte Aktionen so fest, dass spätere Audits nicht raten müssen, warum ein Schritt freigegeben wurde.', + svg: 'dashboard', + alt: 'Statische Tenantial Audit-Trail-Vorschau', }, ], + audienceTitle: 'Für Teams, die Governance gemeinsam tragen', + audienceSubtitle: + 'Tenantial adressiert Buyer und Operatoren, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.', + audiences: [ + { + title: 'MSPs und Service-Teams', + content: + 'Schaffe eine prüfbare Evidence-Basis für Tenant-Reviews, Change-Freigaben und kontrollierte Recovery-Gespräche über mehrere Kundenumgebungen hinweg.', + }, + { + title: 'Interne IT- und Security-Teams', + content: + 'Mache Microsoft-365-Richtlinien, Drift und Review-Entscheidungen lesbar, bevor kritische Änderungen in Produktion oder Ausnahmeprozesse gehen.', + }, + { + title: 'Governance- und Audit-Verantwortliche', + content: + 'Halte Findings, akzeptierte Risiken, Exceptions und Audit Trail so sichtbar, dass Entscheidungen später nachvollzogen statt rekonstruiert werden müssen.', + }, + ], + boundaryTitle: 'Klare Grenzen statt überzogener Versprechen', + boundarySubtitle: + 'Tenantial positioniert Policy Governance, nicht eine zweite Admin-Oberfläche oder approval-freie Automatisierung.', + boundaries: [ + { + title: 'Kein Admin-Center-Klon', + content: + 'Die öffentliche Website beschreibt Governance-Flows, Evidence und Reviews. Sie ersetzt keine produktive Microsoft-Adminoberfläche.', + }, + { + title: 'Keine blinde Automation', + content: + 'Drift, Findings, Recovery und Freigaben bleiben review- und bestätigungspflichtig statt autonomer Remediation.', + }, + { + title: 'Kein Helpdesk- oder PSA-Ersatz', + content: + 'Tenantial fokussiert Policy Governance, Entscheidungsgrundlagen und Auditierbarkeit, nicht Ticketabwicklung oder Support-SLAs.', + }, + ], + finalCtaTitle: 'Den nächsten Schritt bewusst wählen', + finalCtaSubtitle: + 'Starte mit einem Walkthrough, wenn du Microsoft-365-Governance, Provider-Grenzen oder Recovery-Readiness für deinen Kontext einordnen willst.', + finalPrimaryCta: 'Walkthrough anfragen', + finalSecondaryCta: 'Trust-Grenzen ansehen', faqTitle: 'Häufige
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 beschreibt ein Governance-of-record-Modell für Microsoft 365. Beobachteter Zustand, Policy-Evidence, Drift, Review, Entscheidung und Audit Trail bleiben heute auf Microsoft 365 fokussiert; die Architektur bleibt provider-extensibel, ohne aktuelle Live-Unterstützung für andere Provider zu behaupten.', + focusTitle: 'Heutiger Fokus und künftige Richtung', + focusSubtitle: + 'Die öffentliche Produktstory trennt bewusst zwischen aktuellem Microsoft-365-Fokus und provider-extensibler Zukunftsrichtung.', + focusCards: [ + { + title: 'Aktueller Fokus: Microsoft 365', + content: + 'Intune, Entra und weitere Microsoft-365-Policy-Domains werden als heutiger Governance-Kontext beschrieben, nicht als vollständige Liste künftiger Provider.', + }, + { + title: 'Künftige Richtung: provider-extensibel', + content: + 'Andere Provider können als Architektur- oder Roadmap-Richtung genannt werden, aber nicht als live unterstützte Integrationen oder verifizierte Workflows.', + }, + ], + backupTitle: 'Beobachteter Zustand und Policy-Evidence', backupSubtitle: - 'Administratoren brauchen einen reproduzierbaren Nachweis dessen, was beobachtet wurde, bevor entschieden wird, ob eine Änderung sicher ist. Tenantial rahmt Backup-Snapshots als Review-Evidence 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: 'Provider-extensible', description: 'klar als Richtung markiert' }, + { stat: 'Keine Live-Daten', description: 'auf der öffentlichen Website' }, ], - mainStatTitle: '0', + mainStatTitle: 'Heute', mainStatSubTitle: - 'Live-Tenant-Datensätze werden von dieser öffentlichen Website genutzt', + 'Microsoft 365 ist der erste öffentliche Fokus der Produktstory', }, pricingIntro: { pageTitle: 'Preise | Tenantial', metaDescription: - 'Tenantial Preise nutzen konservative Evaluierungs- und Rollout-Gespräche statt sofortiger Zahlung oder Access-Claims.', + '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 +280,19 @@ export const siteCopy: Record = { 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 öffentliche Trust-Haltung mit konservativen Claims, klaren Grenzen und Policy-Governance-Wortwahl ohne false assurance.', + 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 spricht über Audit Trail, Review-Arbeit und kontrollierte Recovery-Planung, ohne Kundenlogo-Belege, externe Endorsements, Compliance-Zusagen oder Recovery-Versprechen zu behaupten, die nicht geliefert und geprüft wurden.', cta: 'Tenantial kontaktieren', - statsTitle: 'Öffentliche Website-Grenzen', + statsTitle: 'Konservative Trust-Haltung', statsSubtitle: - 'Die Website beschreibt eine vorsichtige Produktrichtung. Sie legt keine privaten Tenant-Daten offen, führt keine Tenant-Operationen aus und ist kein Support-Evidence-Portal.', - mainStatTitle: 'Statisch', - mainStatSubTitle: 'nur Produkt-Previews', + 'Die Website beschreibt eine vorsichtige Produktrichtung für DACH- und Enterprise-Evaluierungen. Sie legt keine privaten Tenant-Daten offen, führt keine Tenant-Operationen aus und ist kein Support-Evidence-Portal.', + mainStatTitle: 'Review-first', + mainStatSubTitle: 'öffentliche Claims bleiben konservativ', stats: [ - { stat: '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 +332,11 @@ export const siteCopy: Record = { }, en: { site: { - tagline: 'Evidence-first Microsoft tenant governance', + tagline: 'Policy governance for Microsoft 365', description: - 'Tenantial helps Microsoft tenant teams turn policy evidence, snapshots, drift, findings, exceptions, auditability, and restore plans into reviewable decisions.', + 'Tenantial helps MSPs, internal IT teams, and governance reviewers turn observed state, policy evidence, drift, findings, reviews, audit trail, and controlled recovery planning into reviewable decisions for Microsoft 365.', descriptionShort: - 'Evidence-first governance workflows for Microsoft tenant review, backup, drift, findings, and restore planning.', + 'Policy-governance workflows for Microsoft 365 with evidence, drift detection, review, audit trail, and controlled recovery planning.', }, nav: [ { name: 'Home', url: '/' }, @@ -296,97 +377,178 @@ export const siteCopy: Record = { walkthrough: 'Request walkthrough', }, home: { - pageTitle: 'Tenantial | Evidence-first Microsoft tenant governance', + pageTitle: 'Tenantial | Policy governance for Microsoft 365', metaDescription: - 'Tenantial is evidence-first governance for Microsoft tenant configuration, with backup, restore, drift detection, findings, evidence, auditability, exceptions, and reviews.', + 'Tenantial is policy governance for Microsoft 365: observed state, policy evidence, drift detection, reviews, decisions, audit trail, and controlled recovery planning in one reviewable operating model.', heroTitle: - 'Evidence-first governance for Microsoft tenant configuration', + 'Policy governance for Microsoft 365 and modern cloud environments', heroSubtitle: - 'Tenantial turns backup, restore, drift detection, findings, evidence, exceptions, auditability, and reviews into a governance model before high-impact changes move forward.', + 'Tenantial shows how observed state, policy evidence, drift, review, decision, and audit trail become one evidence-first governance model. Microsoft 365 is the current focus; other providers remain clearly future direction.', primaryCta: 'Request walkthrough', - secondaryCta: 'View product model', + secondaryCta: 'View governance model', heroAlt: 'Static Tenantial governance dashboard preview', - featureTitle: 'From observed state to reviewable decisions', + featureTitle: 'Start with the right product category', 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 is not an Intune-only utility and not an admin-center clone. The platform frames Microsoft 365 as the first operating domain for policy governance so MSPs, internal IT teams, and governance reviewers can read the same evidence base.', featureAlt: 'Static Tenantial review board preview', workflowTitle: - 'From snapshot to review decision.', + 'From observed state to evidence, review, and audit trail.', tabs: [ { - heading: 'Evidence intake', + heading: 'Observe', content: - 'Normalize inventory, backup, and snapshot context so reviews start from one readable view of observed policy state.', + 'Start from readable Microsoft 365 policy state, ownership context, and the configuration boundaries that need review.', svg: 'frame', - alt: 'Static Tenantial evidence intake preview', + alt: 'Static Tenantial observed-state preview', first: true, }, { - heading: 'Decision review', + heading: 'Collect evidence', content: - 'Surface drift detection, findings, exceptions, auditability, and review notes before administrators choose the next action.', - svg: 'dashboard', - alt: 'Static Tenantial decision review preview', + 'Keep snapshots, supporting notes, and policy evidence stable enough that later review does not depend on memory or screenshots alone.', + svg: 'books', + alt: 'Static Tenantial evidence intake preview', second: true, }, { - heading: 'Restore planning', + heading: 'Detect drift', content: - 'Treat restore as preview-first work with validation, conflict awareness, selective scope, and explicit confirmation.', + 'Make differences, findings, and change signals visible before teams skip the question of what really needs review.', svg: 'verified', - alt: 'Static Tenantial restore planning preview', + alt: 'Static Tenantial drift detection preview', + }, + { + heading: 'Run review', + content: + 'Bring MSPs, internal IT teams, and governance stakeholders into the same review lane across findings, risk, exceptions, and next actions.', + svg: 'groups', + alt: 'Static Tenantial review board preview', + }, + { + heading: 'Prepare decisions', + content: + 'Turn review context into traceable approval, exception, or controlled recovery decisions instead of informal handoffs.', + svg: 'frame', + alt: 'Static Tenantial decision preparation preview', + }, + { + heading: 'Preserve audit trail', + content: + 'Keep the rationale, accepted risk, and selected action visible so later audit and governance work can follow the decision path.', + svg: 'dashboard', + alt: 'Static Tenantial audit trail preview', }, ], + audienceTitle: 'For teams that share governance responsibility', + audienceSubtitle: + 'Tenantial speaks to buyers and operators who need to align policy context, review work, and recovery readiness before change moves forward.', + audiences: [ + { + title: 'MSPs and service teams', + content: + 'Create a reviewable evidence base for tenant reviews, change approvals, and controlled recovery conversations across multiple customer environments.', + }, + { + title: 'Internal IT and security teams', + content: + 'Make Microsoft 365 policy posture, drift, and review decisions readable before high-impact changes move into production or exception handling.', + }, + { + title: 'Governance and audit stakeholders', + content: + 'Keep findings, accepted risk, exceptions, and audit trail visible so decisions can be inspected later instead of reconstructed under pressure.', + }, + ], + boundaryTitle: 'Clear boundaries instead of inflated promises', + boundarySubtitle: + 'Tenantial positions policy governance, not a second admin surface or approval-free automation.', + boundaries: [ + { + title: 'Not an admin-center clone', + content: + 'The public website explains governance flows, evidence, and review work. It does not replace a production Microsoft administration surface.', + }, + { + title: 'No blind automation', + content: + 'Drift, findings, recovery, and approvals remain review-driven and explicitly confirmed instead of framed as self-running remediation.', + }, + { + title: 'Not a helpdesk or PSA replacement', + content: + 'Tenantial focuses on policy governance, decision support, and auditability rather than ticket handling, service routing, or support SLAs.', + }, + ], + finalCtaTitle: 'Choose the next step intentionally', + finalCtaSubtitle: + 'Start with a walkthrough if you need to place Microsoft 365 governance, provider boundaries, or recovery readiness in your own operating context.', + finalPrimaryCta: 'Request walkthrough', + finalSecondaryCta: 'Review trust boundaries', faqTitle: 'Frequently
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 describes a governance-of-record model for Microsoft 365. Observed state, policy evidence, drift, review, decision, and audit trail stay focused on Microsoft 365 today while the architecture remains provider-extensible without claiming live support elsewhere.', + focusTitle: 'Current focus and future direction', + focusSubtitle: + 'The public story intentionally separates current Microsoft 365 scope from provider-extensible future direction.', + focusCards: [ + { + title: 'Current focus: Microsoft 365', + content: + 'Intune, Entra, and other Microsoft 365 policy domains are described as the current governance context, not as a promise of every future provider.', + }, + { + title: 'Future direction: provider-extensible', + content: + 'Other providers may be referenced as architecture or roadmap direction, but not as live integrations or verified operating workflows.', + }, + ], + backupTitle: 'Observed state and policy evidence', backupSubtitle: - 'Administrators need a reproducible record of what was observed before deciding whether a change is safe. Tenantial frames backup snapshots as review evidence 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: 'Provider-extensible', description: 'clearly marked as direction' }, + { stat: 'No live data', description: 'on the public website' }, ], - mainStatTitle: '0', - mainStatSubTitle: 'live tenant records used by this public website', + mainStatTitle: 'Today', + mainStatSubTitle: 'Microsoft 365 is the first public product focus', }, pricingIntro: { pageTitle: 'Pricing | Tenantial', metaDescription: - 'Tenantial pricing uses conservative evaluation and rollout conversation paths, not instant public payment or access claims.', + '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 +576,19 @@ export const siteCopy: Record = { trust: { pageTitle: 'Trust | Tenantial', metaDescription: - 'Tenantial public trust posture with conservative claims and clear static preview boundaries.', - heading: 'Trust starts with clear boundaries', + 'Tenantial public trust posture with conservative claims, clear boundaries, and policy-governance wording without false assurance.', + heading: 'Trust starts with reviewable boundaries', subtitle: - 'Tenantial public copy avoids customer-logo proof, third-party endorsement language, external assurance statements, service-level commitments, and recovery promises unless supplied and reviewed.', + 'Tenantial talks about audit trail, review work, and controlled recovery planning without making customer-proof, endorsement, compliance, or recovery claims that have not been supplied and reviewed.', cta: 'Contact Tenantial', - statsTitle: 'Public website posture', + statsTitle: 'Conservative trust posture', statsSubtitle: - 'The website describes a cautious product direction. It does not expose private tenant data, run tenant operations, or act as a support evidence portal.', - mainStatTitle: 'Static', - mainStatSubTitle: 'product previews only', + 'The website describes a cautious product direction for DACH and enterprise evaluators. It does not expose private tenant data, run tenant operations, or act as a support evidence portal.', + mainStatTitle: 'Review-first', + mainStatSubTitle: 'public claims stay conservative', stats: [ - { stat: 'No', description: 'customer-logo proof' }, - { stat: 'No', description: 'external endorsement claim' }, + { stat: 'No', description: 'unsupported compliance claims' }, + { stat: 'No', description: 'customer-proof or endorsement claims' }, { stat: 'No', description: 'live tenant connection' }, ], }, @@ -467,54 +629,78 @@ export const siteCopy: Record = { export const featuresByLocale: Record = { de: [ { - heading: 'Backup-Evidence', + heading: 'Policy-Evidence', content: - 'Prüfe beobachtete Policy-Metadaten und Backup-Snapshots aus einer lesbaren Quelle, bevor Governance-Entscheidungen beginnen.', + 'Führe beobachtete Richtlinien, Snapshots und Kontext in einer lesbaren Evidence-Basis zusammen, bevor Governance-Entscheidungen beginnen.', svg: 'frame', }, { - heading: 'Restore-Planung', + heading: 'Drift und Veränderungssignale', content: - 'Vergleiche unveränderliche Snapshots und plane Restore-Arbeit mit Validierung, selektivem Scope und explizitem Review statt Recovery-Versprechen.', + 'Mache Drift, Findings und Unterschiede sichtbar, bevor Teams über Freigaben, Ausnahmen oder kontrollierte Recovery-Arbeit sprechen.', svg: 'dashboard', }, { - heading: 'Drift Detection', + heading: 'Governance-Reviews', content: - 'Verwandle Unterschiede, Findings und Evidence in lesbare Review-Arbeit, bevor Administratoren entscheiden, ob etwas geändert werden sollte.', + 'Ordne MSPs, interne IT-Teams und Governance-Verantwortliche um dieselbe Review-Grundlage statt um isolierte Tool-Sichten herum.', svg: 'verified', }, { - heading: 'Auditability und Exceptions', + heading: 'Kontrollierte Recovery', content: - 'Halte Exceptions, Review-Notizen und Auditability sichtbar, damit Entscheidungen zuordenbar und konservativ bleiben.', - svg: 'checkCircle', + 'Plane Restore und Recovery defensiv mit Preview, Validierung, selektivem Scope und expliziter Bestätigung statt mit Vollautomationsversprechen.', + svg: 'tools', + }, + { + heading: 'Provider-Readiness', + content: + 'Halte Microsoft 365 als heutigen Fokus klar und beschreibe weitere Provider nur als Architektur- oder Roadmap-Richtung.', + svg: 'frame', + }, + { + heading: 'Decision Traceability', + content: + 'Verknüpfe Findings, Exceptions, akzeptierte Risiken und Audit Trail so, dass Entscheidungen später prüfbar bleiben.', + svg: 'dashboard', }, ], en: [ { - heading: 'Backup evidence', + heading: 'Policy evidence', content: - 'Review observed policy metadata and backup snapshots from one readable source before governance decisions start.', + 'Bring observed policy state, snapshots, and supporting context into one readable evidence base before governance decisions begin.', svg: 'frame', }, { - heading: 'Restore planning', + heading: 'Drift and change signals', content: - 'Compare immutable snapshots and plan restore work with validation, selective scope, and explicit review rather than automatic recovery promises.', + 'Make drift, findings, and differences visible before teams talk about approval, exceptions, or controlled recovery work.', svg: 'dashboard', }, { - heading: 'Drift detection', + heading: 'Governance reviews', content: - 'Turn differences, findings, and evidence into readable review work before administrators decide whether anything should change.', + 'Align MSPs, internal IT teams, and governance stakeholders around the same review lane instead of isolated tool views.', svg: 'verified', }, { - heading: 'Auditability and exceptions', + heading: 'Controlled recovery', content: - 'Keep exceptions, review notes, and auditability visible so decisions stay attributable and conservative.', - svg: 'checkCircle', + 'Plan restore and recovery defensively with preview, validation, selective scope, and explicit confirmation instead of automation promises.', + svg: 'tools', + }, + { + heading: 'Provider readiness', + content: + 'Keep Microsoft 365 explicit as the current focus while describing other providers only as architecture or roadmap direction.', + svg: 'frame', + }, + { + heading: 'Decision traceability', + content: + 'Connect findings, exceptions, accepted risk, and audit trail so later decisions remain inspectable.', + svg: 'dashboard', }, ], }; @@ -603,7 +789,12 @@ export const faqsByLocale: Record = { { question: 'Was hilft Tenantial Teams zu verstehen?', answer: - 'Tenantial ist auf Backup-Evidence, Restore-Planung, Drift Detection, Findings, Auditability, Exceptions und Reviews für Microsoft-Tenant-Konfiguration ausgerichtet.', + 'Tenantial erklärt Policy Governance für Microsoft 365: beobachteter Zustand, Evidence, Drift, Review, Entscheidung, Audit Trail und kontrollierte Recovery-Planung in einem gemeinsamen Operating Model.', + }, + { + question: 'Ist Microsoft 365 der einzige relevante Kontext?', + answer: + 'Microsoft 365 ist heute der erste öffentliche Fokus. Weitere Provider können als Architektur- oder Roadmap-Richtung erwähnt werden, aber nicht als live unterstützte Integrationen.', }, { question: @@ -612,14 +803,9 @@ export const faqsByLocale: Record = { '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 +815,12 @@ export const faqsByLocale: Record = { { question: 'What does Tenantial help teams understand?', answer: - 'Tenantial is positioned around backup evidence, restore planning, drift detection, findings, auditability, exceptions, and reviews for Microsoft tenant configuration.', + 'Tenantial explains policy governance for Microsoft 365: observed state, evidence, drift, review, decisions, audit trail, and controlled recovery planning in one operating model.', + }, + { + question: 'Is Microsoft 365 the only relevant context?', + answer: + 'Microsoft 365 is the current public focus. Other providers may be referenced as architecture or roadmap direction, but not as live supported integrations.', }, { question: 'Does this public website connect to a live tenant?', @@ -637,14 +828,9 @@ export const faqsByLocale: Record = { '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.', }, ], }, diff --git a/apps/website/tests/smoke/interaction.spec.ts b/apps/website/tests/smoke/interaction.spec.ts index 8a05b079..3c8a2bf6 100644 --- a/apps/website/tests/smoke/interaction.spec.ts +++ b/apps/website/tests/smoke/interaction.spec.ts @@ -33,14 +33,14 @@ test('theme toggle keeps page content visible', async ({ page }) => { await page.locator('button[aria-label="Dark Theme Toggle"]:visible').click(); await expect( page.getByRole('heading', { - name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/, + name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/, }) ).toBeVisible(); await page.locator('button[aria-label="Light Theme Toggle"]:visible').click(); await expect( page.getByRole('heading', { - name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/, + name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/, }) ).toBeVisible(); }); @@ -54,7 +54,7 @@ test('homepage mobile first viewport remains readable', async ({ await page.goto('/'); const heading = page.getByRole('heading', { - name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/i, + name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i, }); await expect(heading).toBeVisible(); @@ -154,7 +154,7 @@ test('language picker switches between German default and English routes', async await expect(page).toHaveURL(/\/en\/platform\/?$/); await expect( - page.getByRole('heading', { name: /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(); }); diff --git a/apps/website/tests/smoke/public-routes.spec.ts b/apps/website/tests/smoke/public-routes.spec.ts index 38e65eed..e99e145f 100644 --- a/apps/website/tests/smoke/public-routes.spec.ts +++ b/apps/website/tests/smoke/public-routes.spec.ts @@ -20,24 +20,24 @@ import { globby } from 'globby'; const routeMetadata = { '/': { - title: /Tenantial.*Evidenzbasierte Microsoft-Tenant-Governance/i, - description: /evidenzbasierte Governance/i, + title: /Tenantial.*Policy Governance für Microsoft 365/i, + description: /Policy Governance für Microsoft 365/i, }, '/platform': { title: /Plattform \| Tenantial/i, - description: /öffentliches Produktmodell/i, + description: /Policy Governance|Microsoft 365/i, }, '/pricing': { title: /Preise \| Tenantial/i, - description: /Evaluierungs.*Rollout/i, + description: /Policy-Governance-Evaluierung|Rollout-Planung/i, }, '/contact': { title: /Kontakt \| Tenantial/i, - description: /Walkthrough.*Rollout/i, + description: /Walkthrough|Provider-Grenzen|Policy-Governance/i, }, '/trust': { title: /Vertrauen \| Tenantial/i, - description: /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.*Policy governance for Microsoft 365/i, + description: /policy governance for Microsoft 365/i, }, '/en/platform': { title: /Platform \| Tenantial/i, - description: /public product model for Microsoft tenant/i, + description: /policy governance|Microsoft 365/i, }, '/en/pricing': { title: /Pricing \| Tenantial/i, - description: /evaluation and rollout conversation paths/i, + description: /policy-governance evaluation|rollout planning/i, }, '/en/contact': { title: /Contact \| Tenantial/i, - description: /walkthrough.*scoped rollout conversation/i, + description: /walkthrough|provider boundaries|policy governance/i, }, '/en/trust': { title: /Trust \| Tenantial/i, - description: /conservative claims.*static preview boundaries/i, + description: /conservative claims|false assurance|policy-governance/i, }, '/en/legal': { title: /Legal \| Tenantial/i, @@ -114,23 +113,23 @@ const routeMetadata = { }, '/en/welcome-to-docs/': { title: /Tenantial Docs/i, - description: /evidence-first Microsoft tenant governance model/i, + description: /policy-governance model for Microsoft 365/i, }, '/en/guides/intro/': { title: /Introduction to Tenantial/i, - description: /evidence-first Microsoft tenant governance model/i, + description: /policy-governance model for Microsoft 365/i, }, '/en/guides/getting-started/': { title: /Getting Started/i, - description: /Tenantial walkthrough/i, + description: /Tenantial walkthrough|governance problem/i, }, '/en/guides/first-project-checklist/': { title: /Evaluation Checklist/i, - description: /conservative checklist for early Tenantial evaluation/i, + description: /conservative checklist|early Tenantial evaluation/i, }, '/en/platform/evidence-review/': { title: /Evidence Review/i, - description: /Tenantial evidence review workflows/i, + description: /policy-governance model|evidence-review workflows/i, }, } as const; @@ -150,7 +149,7 @@ test('homepage first viewport explains core Tenantial capabilities', async ({ await page.goto('/'); const heading = page.getByRole('heading', { - name: /Evidenzbasierte Governance für Microsoft-Tenant-Konfiguration/i, + name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i, }); await expect(heading).toBeVisible(); @@ -160,8 +159,11 @@ test('homepage first viewport explains core Tenantial capabilities', async ({ page.getByRole('link', { name: /Walkthrough anfragen/i }).first() ).toHaveAttribute('href', '/contact'); await expect( - page.getByRole('link', { name: /Produktmodell ansehen/i }).first() + page.getByRole('link', { name: /Governance-Modell ansehen/i }).first() ).toHaveAttribute('href', '/platform'); + await expect( + page.getByRole('link', { name: /Trust-Grenzen ansehen/i }).last() + ).toHaveAttribute('href', '/trust'); await expectCoreCapabilitiesVisible(page); }); @@ -171,10 +173,11 @@ test('/platform explains the public product model without internal runtime terms await page.goto('/platform'); await expect( - page.getByRole('heading', { name: /Ö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(/provider-extensible|provider-extensibler/i); await expect(page.locator('body')).toContainText( /authentifiziert keine Besucher, liest keinen Microsoft Tenant, führt keine Operationen aus und speichert keine Tenant-Exporte/i ); @@ -262,7 +265,7 @@ for (const route of redirectRoutes) { await expect(page).toHaveURL(new RegExp(`${expected.target}/?$`)); await expect( page.getByRole('heading', { - name: /Öffentliches Produktmodell|Public product model/, + name: /Policy-Governance-Modell für Microsoft 365|Policy governance model for Microsoft 365/, }) ).toBeVisible(); }); diff --git a/apps/website/tests/smoke/smoke-helpers.ts b/apps/website/tests/smoke/smoke-helpers.ts index b6b01f2e..a7d6ff0c 100644 --- a/apps/website/tests/smoke/smoke-helpers.ts +++ b/apps/website/tests/smoke/smoke-helpers.ts @@ -87,6 +87,17 @@ const forbiddenPublicPatterns = [ { label: 'Microsoft certification claim', pattern: /Microsoft certified/i }, { label: 'recovery guarantee', pattern: /guaranteed recovery/i }, { label: 'compliance guarantee', pattern: /guaranteed compliance/i }, + { label: 'Intune-only tool claim', pattern: /Intune Management Tool/i }, + { label: 'backup-tool claim', pattern: /Intune backup tool/i }, + { label: 'DSGVO compliance claim', pattern: /DSGVO compliant/i }, + { label: 'GDPR compliance claim', pattern: /GDPR compliant/i }, + { label: 'ISO certified claim', pattern: /ISO certified/i }, + { label: 'Google supported claim', pattern: /Google supported/i }, + { label: 'AWS supported claim', pattern: /AWS supported/i }, + { label: 'automatic restore claim', pattern: /automatic restore/i }, + { label: 'autonomous remediation claim', pattern: /autonomous remediation/i }, + { label: 'neutral SaaS residue', pattern: /neutral SaaS visual/i }, + { label: 'lorem ipsum residue', pattern: /lorem ipsum/i }, { label: 'fake checkout CTA', pattern: /\b(buy now|checkout)\b/i }, { label: 'fake newsletter CTA', pattern: /\b(subscribe|newsletter)\b/i }, { @@ -168,14 +179,14 @@ export async function expectCoreCapabilitiesVisible(page: Page): Promise { const text = (await page.locator('body').innerText()).toLowerCase(); for (const terms of [ - ['backup'], - ['restore'], - ['drift detection', 'drift'], - ['findings'], + ['policy governance', 'policy-governance'], + ['microsoft 365'], ['evidence'], - ['auditability'], - ['exceptions'], + ['drift detection', 'drift'], ['reviews', 'review'], + ['audit trail', 'auditability'], + ['controlled recovery', 'recovery', 'restore'], + ['provider', 'future direction', 'roadmap direction'], ]) { expect( terms.some(term => text.includes(term)), diff --git a/specs/404-public-content-messaging/checklists/requirements.md b/specs/404-public-content-messaging/checklists/requirements.md index 74f497b9..67c65375 100644 --- a/specs/404-public-content-messaging/checklists/requirements.md +++ b/specs/404-public-content-messaging/checklists/requirements.md @@ -1,8 +1,8 @@ -# Specification Quality Checklist: `apps/website` Public Content Architecture & Messaging +# Specification Quality Checklist: Public Website Positioning & Content Architecture **Purpose**: Validate specification completeness and quality before proceeding to planning -**Created**: 2026-05-22 +**Created**: 2026-05-25 **Feature**: [spec.md](../spec.md) @@ -33,6 +33,7 @@ ## Feature Readiness ## Notes -- Validation pass 1 completed on 2026-05-22. -- 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. diff --git a/specs/404-public-content-messaging/contracts/public-content-contract.md b/specs/404-public-content-messaging/contracts/public-content-contract.md index 6cb42cb1..1935b522 100644 --- a/specs/404-public-content-messaging/contracts/public-content-contract.md +++ b/specs/404-public-content-messaging/contracts/public-content-contract.md @@ -1,12 +1,12 @@ -# Public Content Contract: Spec 404 Content Architecture & Messaging +# Public Website Positioning Contract: Spec 404 This feature has no REST, GraphQL, Laravel, Filament, Livewire, Microsoft Graph, database, queue, job, policy, RBAC, or product runtime API contract. -The contract is the public static website content behavior that reviewers and smoke tests must verify. +The contract is the public static website behavior that reviewers and smoke checks must verify. ## Core Public Routes -The following German default routes must render intentionally and expose Tenantial-specific content, metadata, and CTAs: +The following default routes must render intentionally and expose Tenantial-specific content, metadata, and CTAs: - `/` - `/platform` @@ -23,7 +23,7 @@ ## Core Public Routes - `/guides/first-project-checklist/` - `/platform/evidence-review/` -The following English route mirrors must remain consistent where they are intentionally exposed: +The following English mirrors must remain consistent where they are intentionally exposed: - `/en/` - `/en/platform` @@ -40,96 +40,100 @@ ## Core Public Routes - `/en/guides/first-project-checklist/` - `/en/platform/evidence-review/` -## Homepage Messaging Contract +Redirect-only aliases such as `/product` must continue to resolve intentionally and must not become a second competing product story. + +## Homepage Positioning Contract The homepage must satisfy: -- hero copy identifies Tenantial as evidence-first governance for Microsoft tenant configuration -- 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 diff --git a/specs/404-public-content-messaging/data-model.md b/specs/404-public-content-messaging/data-model.md index db9282c3..51f63134 100644 --- a/specs/404-public-content-messaging/data-model.md +++ b/specs/404-public-content-messaging/data-model.md @@ -1,112 +1,109 @@ -# Data Model: `apps/website` Public Content Architecture & Messaging +# Data Model: Public Website Positioning & Content Architecture This feature introduces no database tables, product runtime models, persisted entities, enums, status families, provider contracts, or shared product taxonomy. The records below are planning and validation concepts for static website artifacts only. -## Public Content Surface +## Public Positioning Surface -Represents an intentional public page, docs page, navigation area, footer area, FAQ area, or metadata surface affected by this content architecture pass. +Represents one intentional public route, docs route, navigation/footer surface, or shared metadata surface affected by the positioning pass. **Fields** -- `surfaceId`: stable human-readable identifier, such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, or `footer` -- `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 diff --git a/specs/404-public-content-messaging/plan.md b/specs/404-public-content-messaging/plan.md index 3012fab3..0f1aa249 100644 --- a/specs/404-public-content-messaging/plan.md +++ b/specs/404-public-content-messaging/plan.md @@ -1,50 +1,50 @@ -# Implementation Plan: `apps/website` Public Content Architecture & Messaging +# Implementation Plan: Public Website Positioning & Content Architecture -**Branch**: `404-public-content-messaging` | **Date**: 2026-05-22 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` +**Branch**: `404-public-content-messaging` | **Date**: 2026-05-25 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` **Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` ## Summary -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. +Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 as the first focus and provider-extensible language kept explicitly future-safe. The implementation will stay inside `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` and reuse the existing Astro route/content architecture: locale-keyed copy in `src/data_files/site-copy.ts`, thin route wrappers in `src/pages`, shared page components in `src/components/pages`, metadata through `MainLayout` and `Meta`, and the current Playwright smoke suite for route, link, claim, and metadata validation. ## Technical Context **Language/Version**: TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 **Primary Dependencies**: Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwright -**Storage**: N/A - static website content, 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 +**Storage**: N/A - static website content and generated build output only; no database or product persistence +**Testing**: Astro build via `corepack pnpm build:website`, existing Playwright smoke tests under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke`, targeted static claim scans +**Validation Lanes**: website build, public smoke, manual browser review, static claim scan, whitespace check, `apps/platform` scope check +**Target Platform**: Static Astro public website deployed from `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`, with German default routes and `/en/...` mirrors +**Project Type**: Web - standalone Astro public website inside a monorepo +**Performance Goals**: No body-level horizontal overflow on validated desktop/mobile routes; primary navigation and CTAs stay readable and reachable; metadata and canonical routes stay intentional +**Constraints**: Runtime/source changes are scoped to `apps/website`; preserve root package script names, website package name `@tenantatlas/website`, `WEBSITE_PORT`, and `apps/*` workspace conventions; no `apps/platform` changes; no fake trust/provider claims; no placeholder links; no auth/API/database/runtime coupling +**Scale/Scope**: Core public pages `/`, `/platform`, `/pricing`, `/trust`, `/contact`, legal pages, exposed docs routes, locale mirrors, navigation/footer surfaces, route metadata, and smoke expectations ## UI / Surface Guardrail Plan -- **Guardrail scope**: no 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 +- **Guardrail scope**: no operator-facing surface change; public website positioning workflow only +- **Native vs custom classification summary**: custom Astro public website; no Filament/Blade/admin surface +- **Shared-family relevance**: public navigation, CTA language, metadata, docs exposure, and smoke helper patterns +- **State layers in scope**: localized static page content, navigation/footer data, route metadata, docs content, smoke expectations +- **Audience modes in scope**: public visitor, MSP evaluator, internal IT evaluator, DACH trust reviewer +- **Decision/diagnostic/raw hierarchy plan**: public copy stays decision-first for visitors; diagnostics and proof boundaries are explained plainly rather than exposed as raw runtime detail +- **Raw/support gating plan**: N/A - no operator support/raw evidence surface +- **One-primary-action / duplicate-truth control**: each primary route keeps one clear next step, typically contact or deeper product explanation, while repeated or competing CTA language is normalized +- **Handling modes by drift class or surface**: public claim, placeholder-link, and navigation drift are review-mandatory inside this feature; `apps/platform` drift is a hard stop +- **Repository-signal treatment**: website-source and website-smoke changes are expected; any platform/runtime drift is exception-required and out of scope +- **Special surface test profiles**: N/A - public website only +- **Required tests or manual smoke**: public smoke, static claim scan, and manual desktop/mobile browser review - **Exception path and spread control**: none - **Active feature PR close-out entry**: Smoke Coverage ## Shared Pattern & System Fit -- **Cross-cutting feature marker**: yes, 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 +- **Cross-cutting feature marker**: yes +- **Systems touched**: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke` +- **Shared abstractions reused**: locale-keyed `siteCopy`, thin route wrappers in `src/pages`, `MainLayout.astro`, `Meta.astro`, `localizeHref()` and locale helpers, shared Navbar/Footer components, Playwright smoke helper patterns for forbidden claims and placeholder links +- **New abstraction introduced? why?**: none +- **Why the existing abstraction was sufficient or insufficient**: The current website already centralizes copy, navigation, metadata, and smoke assertions. Spec 404 needs a better narrative and stricter claim posture, not a new framework. +- **Bounded deviation / spread control**: no new abstraction; bounded cleanup of stale helpers such as German-only `navigation.ts` usage is allowed if needed to keep copy and route logic aligned ## OperationRun UX Impact @@ -58,79 +58,79 @@ ## OperationRun UX Impact ## Provider Boundary & Portability Fit -- **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 +- **Shared provider/platform boundary touched?**: yes +- **Provider-owned seams**: public Microsoft 365 wording, Intune as one example domain, any roadmap/provider-direction examples in public copy +- **Platform-core seams**: none; no runtime platform contracts, provider contracts, or shared persistence truth change +- **Neutral platform terms / contracts preserved**: policy governance, cloud policy governance, managed environment, provider connection, policy evidence, drift detection, findings, exceptions, accepted risks, decision summary, audit trail, controlled recovery, provider readiness +- **Retained provider-specific semantics and why**: Microsoft 365 remains the first public focus because that is current product truth; Intune is retained only as one Microsoft 365 policy domain and not the umbrella category +- **Bounded extraction or follow-up path**: follow-up-spec for a broader public provider/domain taxonomy if future route or copy work needs a richer current-versus-planned matrix ## Constitution Check *GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.* -- Inventory-first: PASS - no inventory, 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. +- Inventory-first: PASS - no inventory, snapshots, backups, or source-of-truth runtime behavior changes +- Read/write separation: PASS - no write/change behavior is introduced +- Graph contract path: PASS - no Microsoft Graph calls or contract-registry changes +- Deterministic capabilities: PASS - no capability derivation or resolver changes +- RBAC-UX: PASS - no `/admin`, `/system`, tenant context, workspace context, authorization, or capability behavior changes +- Workspace isolation: PASS - no workspace data or workspace-scoped route behavior changes +- RBAC-UX destructive-like actions: PASS - no destructive actions +- RBAC-UX global search: PASS - no Filament or global-search changes +- Tenant isolation: PASS - no tenant data, tenant reads, or tenant routes +- Run observability: PASS - no long-running, remote, queued, or scheduled product work +- OperationRun start UX: PASS - no OperationRun behavior +- Ops-UX 3-surface feedback: PASS - no OperationRun notifications or lifecycle output +- Ops-UX lifecycle: PASS - no `OperationRun.status` or `OperationRun.outcome` changes +- Ops-UX summary counts: PASS - no summary-count semantics +- Ops-UX guards: PASS - no Ops-UX guard changes +- Ops-UX system runs: PASS - no system-run behavior +- Automation: PASS - no queue, retry, lock, idempotency, or backoff behavior +- Data minimization: PASS - public static copy and metadata only; no secrets, tokens, or tenant data +- Test governance (TEST-GOV-001): PASS - browser/static classification is explicit, uses existing website lanes, and introduces no hidden Laravel/Filament/provider/database setup cost +- Proportionality (PROP-001): PASS - website-local narrative and metadata updates only; no new product structure or semantic machinery +- No premature abstraction (ABSTR-001): PASS - no new factories, registries, resolvers, strategies, interfaces, or pipelines +- Persisted truth (PERSIST-001): PASS - no new persisted product truth or artifacts beyond existing static build output +- Behavioral state (STATE-001): PASS - no new product states, statuses, or reason families +- UI semantics (UI-SEM-001): PASS - public copy and labels remain local presentation, not a shared semantic framework +- Shared pattern first (XCUT-001): PASS - existing shared website copy, layout, metadata, navigation, and smoke helpers are reused +- Provider boundary (PROV-001): PASS - public provider vocabulary is explicitly bounded to positioning only; no platform-core coupling is added +- V1 explicitness / few layers (V1-EXP-001, LAYER-001): PASS - direct website-local edits only +- Spec discipline / bloat check (SPEC-DISC-001, BLOAT-001): PASS - no enum, DTO, presenter, persisted entity, interface, registry, resolver, or taxonomy is introduced +- Badge semantics (BADGE-001): PASS - no shared badge/status taxonomy changes +- Filament-native UI (UI-FIL-001): PASS - no Filament UI +- UI/UX surface taxonomy: PASS - no operator-facing surface +- Decision-first operating model: PASS - public visitor decision flow is improved, but no operator decision surface is added +- Audience-aware disclosure: PASS - trust/proof boundaries are stated conservatively without exposing operator/raw evidence surfaces +- UI/UX inspect model: PASS - no operator list/detail surface +- UI/UX action hierarchy: PASS - no Filament actions or admin action surfaces +- UI/UX scope, truth, and naming: PASS - public category language, provider posture, and CTA vocabulary stay honest and non-implementation-first +- UI/UX placeholder ban: PASS - placeholder links and fake pages are explicitly banned by this feature +- UI naming: PASS - public CTA labels map to real next steps and avoid unsupported workflow verbs +- Operator surfaces: PASS - no `/admin` surface changes +- Filament UI Action Surface Contract: PASS - no Filament Resource/RelationManager/Page changes +- Filament UI UX-001: PASS - no Filament screen changes +- Action-surface discipline: PASS - no operator action surface changes +- UI review workflow: PASS - website-specific shared patterns and public validation responsibilities stay explicit without widening into platform scope **Initial Gate Result**: PASS - no constitution violations or unresolved clarifications. ## Test Governance Check - **Test purpose / classification by changed surface**: Browser/static website -- **Affected validation lanes**: website build, public smoke, manual browser/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` +- **Affected validation lanes**: website build, public smoke, manual browser review, static claim scan, whitespace/scope checks +- **Why this lane mix is the narrowest sufficient proof**: The feature changes public copy, route metadata, CTA intent, navigation exposure, and claim discipline. Laravel/Pest/Filament lanes would not prove the changed behavior. +- **Narrowest proving command(s)**: `cd /Users/ahmeddarrazi/Documents/projects/wt-website && corepack pnpm build:website`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git diff --check`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short -- apps/platform` - **Fixture / helper / factory / seed / context cost risks**: none - no database, provider, workspace, membership, session, queue, Sail, Laravel, Filament, or Livewire setup - **Expensive defaults or shared helper growth introduced?**: no -- **Heavy-family additions, promotions, or visibility changes**: Browser review remains explicit in website smoke/manual review; no heavy-governance lane +- **Heavy-family additions, promotions, or visibility changes**: none - existing Playwright smoke remains explicit and website-local - **Surface-class relief / special coverage rule**: N/A - public website -- **Closing validation and reviewer handoff**: Reviewers should rely on website build, Playwright smoke, manual content review, no unsupported claims, intentional CTAs, no forbidden residue, and `apps/platform` untouched status. +- **Closing validation and reviewer handoff**: Reviewers should rely on website build, Playwright smoke, static claim scan, desktop/mobile manual review, and `apps/platform` untouched confirmation. If copy changes add new public docs or navigation surfaces, smoke route allowlists and metadata expectations must be updated in the same feature. - **Budget / baseline / trend follow-up**: none expected -- **Review-stop questions**: lane fit, browser breadth, hidden platform cost, CTA honesty, unsupported claim posture, route exposure +- **Review-stop questions**: lane fit, claim drift, placeholder-link drift, route-exposure drift, hidden platform coupling - **Escalation path**: document-in-feature - **Active feature PR close-out entry**: Smoke Coverage -- **Why no dedicated follow-up spec is needed**: The browser/static review cost is local to this content architecture pass unless repeated website release gates become a recurring process problem. +- **Why no dedicated follow-up spec is needed**: The validation cost remains local to this public website positioning pass unless future website work creates a recurring release-governance problem. ## Project Structure @@ -144,8 +144,6 @@ ### Documentation (this feature) ├── quickstart.md ├── contracts/ │ └── public-content-contract.md -├── checklists/ -│ └── requirements.md └── tasks.md ``` @@ -160,17 +158,23 @@ ### Source Code (repository root) ├── public/ ├── src/ │ ├── components/ +│ │ ├── pages/ +│ │ └── sections/ │ ├── content/ +│ │ ├── docs/ +│ │ ├── blog/ +│ │ ├── insights/ +│ │ └── products/ │ ├── data_files/ -│ ├── images/ │ ├── layouts/ │ ├── pages/ +│ │ └── en/ │ └── utils/ └── tests/ └── smoke/ ``` -**Structure Decision**: Use the existing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` Astro app from Specs 402 and 403. Do not create new base source folders and do not touch `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`. +**Structure Decision**: Use the existing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` Astro application and its current localized route/component/content organization. Do not create new base folders and do not touch `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`. ## Complexity Tracking @@ -180,12 +184,12 @@ ## Complexity Tracking ## Proportionality Review -- **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. +- **Current operator problem**: Public evaluators and reviewers still receive the wrong product category and an incomplete governance narrative from the current website. +- **Existing structure is insufficient because**: The website foundation is already stable, but its public copy, metadata, navigation, and trust/provider boundaries do not yet express the intended policy-governance positioning. +- **Narrowest correct implementation**: Update the existing website-local copy system, page hierarchy, docs exposure, metadata, and smoke expectations inside `apps/website` only. +- **Ownership cost created**: Ongoing maintenance of public positioning copy, provider/trust claim guardrails, and smoke expectations for emitted public routes. +- **Alternative intentionally rejected**: A broad website redesign, a new content system, and any `apps/platform`-linked implementation or provider runtime work. +- **Release truth**: Current-release public website positioning truth. ## Phase 0 Research @@ -193,11 +197,14 @@ ## Phase 0 Research **Resolved clarifications**: -- 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. +- The active website remains the existing Astro 6 app in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`; no framework decision is needed. +- Core public routes are thin wrappers that delegate to shared page components in `src/components/pages`. +- The primary copy, navigation, CTA labels, and per-route metadata are centralized in `src/data_files/site-copy.ts`. +- German default routes and `/en/...` mirrors share the same content source through locale-keyed records rather than separate content systems. +- `/product` is a redirect alias to `/platform`, so the governance model should stay anchored to `/platform` and not a second product page. +- Existing Playwright smoke helpers already cover rendered routes, redirect aliases, placeholder-link bans, forbidden public residue, metadata, and mobile/keyboard/overflow checks. +- Public docs routes are intentionally emitted and must stay aligned with the same positioning/claim contract as the core marketing pages. +- No REST, GraphQL, database, queue, Laravel, Filament, Livewire, or provider-runtime contract is required for this feature. ## Phase 1 Design @@ -207,14 +214,16 @@ ## Phase 1 Design - `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` - `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` -No REST, GraphQL, database, Laravel, Filament, Livewire, Microsoft Graph, queue, job, policy, RBAC, or product runtime contracts are introduced. +The design treats public route behavior, messaging claims, provider posture, CTAs, operating-model sections, and route metadata as the contract. No REST, GraphQL, database, Laravel, Filament, Livewire, Microsoft Graph, queue, job, RBAC, or runtime platform contract is introduced. ## Post-Design Constitution Check **Post-Design Gate Result**: PASS -- The Phase 1 design remains website-local. +- Phase 1 remains website-local and scoped to `apps/website`. - 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`. +- No product persistence, abstraction, status family, provider runtime seam, OperationRun behavior, RBAC behavior, or Filament behavior is introduced. +- Shared-pattern reuse stays within the existing website copy/layout/metadata/smoke system. +- Provider vocabulary remains bounded to public positioning only. +- Validation remains explicit and limited to website build, smoke, claim scans, and scope checks. +- Agent context must be updated with the current plan outputs before implementation continues. diff --git a/specs/404-public-content-messaging/quickstart.md b/specs/404-public-content-messaging/quickstart.md index 78aed688..07310de4 100644 --- a/specs/404-public-content-messaging/quickstart.md +++ b/specs/404-public-content-messaging/quickstart.md @@ -1,4 +1,4 @@ -# Quickstart: Spec 404 Public Content Architecture & Messaging +# Quickstart: Spec 404 Public Website Positioning & Content Architecture ## Scope @@ -15,6 +15,19 @@ ## Scope /Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform ``` +## Verify Current Repo Truth First + +Run the required repo checks before editing: + +```bash +cd /Users/ahmeddarrazi/Documents/projects/wt-website && pwd +cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short --branch +cd /Users/ahmeddarrazi/Documents/projects/wt-website && find apps/website -maxdepth 3 -type f | sort | sed -n '1,160p' +cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat package.json +cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat pnpm-workspace.yaml +cd /Users/ahmeddarrazi/Documents/projects/wt-website && cat apps/website/package.json +``` + ## Install Dependencies If Needed ```bash @@ -38,51 +51,55 @@ ## Read-Only Content Audit Review public content sources before editing: ```bash -cd /Users/ahmeddarrazi/Documents/projects/wt-website -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 diff --git a/specs/404-public-content-messaging/research.md b/specs/404-public-content-messaging/research.md index b8b4bad7..e71adfc8 100644 --- a/specs/404-public-content-messaging/research.md +++ b/specs/404-public-content-messaging/research.md @@ -1,100 +1,91 @@ -# Phase 0 Research: `apps/website` Public Content Architecture & Messaging +# Phase 0 Research: Public Website Positioning & Content Architecture -## Decision: Keep the Spec 402/403 Astro website foundation +## Decision: Keep the existing Astro website foundation and shared copy architecture -**Rationale**: The active website is a standalone Astro app at `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` with Starlight docs, sitemap generation, Tailwind v4, Preline, Lenis, and Playwright smoke tests already in place. Spec 404 is a content architecture and messaging pass, not another rebuild. +**Rationale**: The active website is already a standalone Astro app at `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` with Starlight docs, locale-aware route mirrors, shared page components, centralized route copy in `src/data_files/site-copy.ts`, and Playwright smoke coverage. Spec 404 is a positioning and content-architecture pass, not a rebuild. **Alternatives considered**: -- Rebuild the public website foundation: rejected by scope and unnecessary after Spec 402. -- 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. diff --git a/specs/404-public-content-messaging/spec.md b/specs/404-public-content-messaging/spec.md index d5ceddf8..ae49e7c8 100644 --- a/specs/404-public-content-messaging/spec.md +++ b/specs/404-public-content-messaging/spec.md @@ -1,69 +1,69 @@ -# Feature Specification: `apps/website` Public Content Architecture & Messaging +# Feature Specification: Public Website Positioning & Content Architecture **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**: User description: "Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 first positioning, provider-extensible direction, an Observe-to-Audit operating model, and strict public claim discipline." -## Spec Candidate Check *(mandatory — SPEC-GATE-001)* +## Spec Candidate Check *(mandatory - SPEC-GATE-001)* -- **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 public website still risks framing Tenantial as an Intune backup utility, a narrow Microsoft admin tool, or generic SaaS copy instead of the intended governance-of-record platform. +- **Today's failure**: Visitors can leave with the wrong category, miss the governance operating model, or infer unsupported provider, compliance, trust, or automation claims from incomplete positioning. +- **User-visible improvement**: Public visitors can understand Tenantial as a policy governance platform, see Microsoft 365 as the first focus without collapsing the story to Intune, and follow a clear evidence-review-decision narrative. +- **Smallest enterprise-capable version**: Refresh public website copy hierarchy, terminology, metadata, navigation labels, CTA language, and claim guardrails inside `apps/website` only, without changing platform runtime behavior. +- **Explicit non-goals**: No `apps/platform` changes, no shared auth or API coupling, no CMS, no provider implementation work, no detailed legal or trust proofs, no fake social proof, no fake certifications, and no website-wide visual-system rewrite beyond what content hierarchy requires. +- **Permanent complexity imported**: No persisted models, services, enums, or runtime workflows. The durable complexity is limited to public positioning rules, provider-claim guardrails, trust-claim guardrails, and route-level content architecture. +- **Why now**: Launch-readiness and later visual productization depend on a stable public narrative; polishing layout first would optimize around the wrong product story. +- **Why not local**: The mispositioning spans hero copy, operating-model sections, capability framing, navigation, metadata, trust language, CTA labels, and supporting route hierarchy. - **Approval class**: Core Enterprise. -- **Red flags triggered**: Public 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; provider-claim risk; compliance/trust overclaim risk; narrow Intune-only framing risk. +- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12** - **Decision**: approve. ## Spec Scope Fields *(mandatory)* -- **Scope**: Public website content surfaces in `apps/website`. -- **Primary Routes**: `/`, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs routes, public navigation, FAQ surfaces, footer, and route metadata. +- **Scope**: workspace. +- **Primary Routes**: `/`, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs navigation, public metadata, public CTA surfaces, and any shared marketing copy/configuration that drives those routes. - **Data Ownership**: No tenant-owned or workspace-owned records are created, changed, or read. This is public website content only. -- **RBAC**: Not applicable. The affected surfaces are public marketing and product explanation pages. +- **RBAC**: Not applicable. The affected surfaces are public marketing and product-positioning pages. For canonical-view specs, the spec MUST define: -- **Default filter behavior when tenant-context is active**: N/A - no 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. +- **Default filter behavior when tenant-context is active**: N/A - no tenant-context or canonical platform view is introduced. +- **Explicit entitlement checks preventing cross-tenant leakage**: N/A - no tenant data, workspace data, or authenticated platform state is involved. ## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)* -- **Cross-cutting feature?**: yes, within public website content 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. +- **Cross-cutting feature?**: yes, within public website content surfaces. +- **Interaction class(es)**: public navigation, homepage section hierarchy, CTA labels, capability cards, trust teaser language, route metadata, and public route discovery. +- **Systems touched**: `apps/website` pages, shared marketing content/configuration, route metadata, public navigation/footer surfaces, and any public docs route exposure. +- **Existing pattern(s) to extend**: The public website foundation from Specs 400-403 and the current shared content/layout organization inside `apps/website`. +- **Shared contract / presenter / builder / renderer to reuse**: Existing website route and content composition; no new runtime contract is required. +- **Why the existing shared path is sufficient or insufficient**: The current website substrate is sufficient to carry the revised narrative, but its public copy hierarchy is not yet aligned to the intended product category or claim discipline. +- **Allowed deviation and why**: Bounded copy, metadata, navigation, and content-hierarchy updates are allowed. Broad redesign, trust-surface expansion, and provider-taxonomy expansion are deferred follow-up work. +- **Consistency impact**: Product category language, Microsoft-first wording, provider-extensible wording, operating-model labels, trust-safe wording, and CTA intent must remain aligned across public routes. +- **Review focus**: Reviewers must verify that no page reintroduces Intune-only framing, unsupported provider claims, unsupported compliance claims, fake proof, placeholder links, or `apps/platform` coupling. ## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)* -N/A - no OperationRun start, completion, notification, queue, or link semantics are touched. +N/A - no OperationRun start, completion, queue, notification, or deep-link behavior is touched. ## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)* -- **Shared provider/platform boundary touched?**: 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. +- **Shared provider/platform boundary touched?**: yes, at public positioning and vocabulary level only. +- **Boundary classification**: mixed public-positioning vocabulary; no runtime provider seam changes. +- **Seams affected**: Public category language, Microsoft-first wording, provider-extensible wording, current-versus-future provider/domain labels, and homepage capability framing. +- **Neutral platform terms preserved or introduced**: Policy governance, cloud policy governance, managed environment, provider connection, policy evidence, drift detection, findings, exceptions, accepted risks, review packs, decision summary, audit trail, controlled recovery, and provider readiness. +- **Provider-specific semantics retained and why**: Microsoft 365 remains the first public focus because that is the current product truth. Intune may be described only as one Microsoft 365 policy domain. Google, AWS, and other providers remain future direction only. +- **Why this does not deepen provider coupling accidentally**: The feature changes public positioning only. It does not change provider contracts, platform-core taxonomies, provider runtime logic, or supported-integration truth. +- **Follow-up path**: A later public provider/domain taxonomy feature can expand current-versus-planned labeling without changing this positioning baseline. ## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)* -N/A - no operator-facing platform surface changes. This feature changes public website content surfaces only. +N/A - no operator-facing platform surface is changed. This feature changes public website content surfaces only. ## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)* @@ -88,12 +88,12 @@ ## Proportionality Review *(mandatory when structural complexity is introduced)* - **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. +- **Current operator problem**: Public evaluators, MSPs, and internal IT teams do not yet get a stable product category or governance operating model from the website. +- **Existing structure is insufficient because**: Specs 400-403 established website foundation and launch safety, but they did not finalize a public positioning architecture for policy governance, provider posture, or safe trust language. +- **Narrowest correct implementation**: Rework public copy, hierarchy, navigation, metadata, terminology, and claim guardrails in `apps/website` only. +- **Ownership cost**: Future public pages and website edits must preserve the same positioning contract, provider posture, and trust-safe wording. +- **Alternative intentionally rejected**: Broad visual redesign and detailed trust/legal expansion were rejected because they would deepen scope before the public narrative is stable. +- **Release truth**: Current-release public positioning truth, with later follow-up work for detailed trust, provider taxonomy, and use-case expansion. ### Compatibility posture @@ -107,345 +107,185 @@ ## 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. +- **Why this classification and these lanes are sufficient**: The feature changes public content, metadata, navigation, CTA wording, and claim discipline; website build, smoke, and targeted static claim scans are the narrowest proof that the public output remains correct. +- **New or expanded test families**: none required beyond existing website validation and targeted static content scans. - **Fixture / helper cost impact**: none. - **Heavy-family visibility / justification**: none. - **Special surface test profile**: N/A. -- **Standard-native relief or required special coverage**: 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. +- **Standard-native relief or required special coverage**: Homepage desktop/mobile review, public route smoke, placeholder-link scan, claim scan, and `apps/platform` untouched confirmation are sufficient. +- **Reviewer handoff**: Reviewers must confirm product category clarity, operating-model visibility, provider-safe wording, trust-safe wording, honest navigation/CTAs, and zero `apps/platform` drift. - **Budget / baseline / trend impact**: none expected. - **Escalation needed**: none. - **Active feature PR close-out entry**: Smoke Coverage. -- **Planned validation commands**: `corepack pnpm build:website`; `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `git diff --check`; `git status --short -- apps/platform`. - -## Depends On - -- Spec 402 - `apps/website` ScrewFast Website Rebuild -- Spec 403 - `apps/website` Public Website Launch Readiness - -## Scope - -This spec is strictly local to `apps/website`. - -It focuses on public website content architecture, messaging hierarchy, CTA language, page-level copy, route metadata, and claim safety. - -It does not redesign the website layout. It does not rebuild the ScrewFast-derived foundation. It does not recreate `apps/website`. - -## Important Scope Clarification - -In this feature, the word "platform" refers only to the public website route `/platform` inside `apps/website`. - -It does not refer to the Laravel/Filament application in `apps/platform`. - -`apps/platform` is completely out of scope: - -- 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 - -## Goal - -Establish a clear, conservative, enterprise-ready public messaging system for Tenantial before visual layout polish. - -The website should communicate: - -- 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 - -The content should be strong enough that a later layout-rhythm spec can optimize around stable section intent instead of placeholder copy. - -## Non-Goals - -This spec does not: - -- 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 - -## Problem - -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. - -Current issues: - -- 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. - -## Content Positioning Principles - -Public copy must follow these principles: - -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. +- **Planned validation commands**: `corepack pnpm build:website`; `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `git diff --check`; `git status --short -- apps/platform`. ## User Scenarios & Testing *(mandatory)* -### User Story 1 - Understand The Product Category (Priority: P1) +### User Story 1 - Recognize The Right Product Category (Priority: P1) -A first-time visitor opens the homepage and understands that Tenantial is an evidence-first governance product for Microsoft tenant configuration. +A first-time visitor opens the homepage and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility. -**Why this priority**: If visitors cannot quickly categorize the product, layout polish will not fix the website. +**Why this priority**: If the product category is wrong, every later page and CTA inherits the wrong expectation. -**Independent Test**: Read the hero and first two homepage sections without relying on visuals. +**Independent Test**: Read the hero and the next section on the homepage without relying on internal product knowledge. **Acceptance Scenarios**: -1. **Given** a visitor opens `/`, **When** they read the hero, **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. +1. **Given** a visitor opens `/`, **When** they read the hero and supporting line, **Then** they can describe Tenantial as policy governance rather than an Intune backup or helpdesk tool. +2. **Given** a visitor reads the first screen and adjacent positioning copy, **When** they summarize the product, **Then** they mention Microsoft 365 first focus and evidence-based governance. +3. **Given** Intune appears in the copy, **When** the visitor reads the surrounding text, **Then** Intune is understood as one policy domain rather than the full product category. --- -### User Story 2 - Follow A Clear Website Narrative (Priority: P1) +### User Story 2 - Follow The Governance Operating Model (Priority: P1) -A buyer scrolls the homepage and sees a deliberate narrative from problem to model to capability to evaluation. +A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail. -**Why this priority**: A strong homepage needs a content sequence, not just independent sections. +**Why this priority**: The operating model is the clearest way to explain the product without reducing it to a feature list. -**Independent Test**: Read homepage section headings and subheadings in order. +**Independent Test**: Read homepage section titles and core section summaries in order from top to bottom. **Acceptance Scenarios**: -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. +1. **Given** a visitor scans the homepage, **When** they reach the operating-model section, **Then** they can identify the flow from observed state to audit trail. +2. **Given** the capability section is visible, **When** the visitor reads the cards, **Then** the story focuses on evidence, drift, reviews, controlled recovery, provider readiness, and decision traceability rather than raw feature enumeration. +3. **Given** the visitor compares the operating-model section with the hero, **When** they continue down the page, **Then** each section adds new meaning instead of repeating the same claim. --- -### User Story 3 - Explain The Public Product Model On `/platform` (Priority: P1) +### User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2) -A visitor opens `/platform` and understands Tenantial's product model in more detail. +A security-conscious evaluator can see Microsoft 365 as the current focus, provider extensibility as future-safe direction, and clear boundaries about what the product is not. -**Why this priority**: The `/platform` route is the main product explanation page and should hold deeper messaging than the homepage. +**Why this priority**: Provider posture and boundary language strongly influence trust, scope expectations, and commercial qualification. -**Independent Test**: Read `/platform` copy without using admin/platform code as a source. +**Independent Test**: Read the homepage and the primary supporting product page without referencing implementation notes. **Acceptance Scenarios**: -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. +1. **Given** a visitor reads the Microsoft-first section, **When** they review provider/domain examples, **Then** current focus and future direction are clearly separated. +2. **Given** the visitor reads boundary language, **When** they compare Tenantial to an admin center, helpdesk, PSA, or blind automation tool, **Then** those categories are clearly rejected. +3. **Given** a visitor looks for Google, AWS, or other non-Microsoft provider claims, **When** they review the page, **Then** they find only architecture-direction or provider-extensible wording, not live-support claims. --- -### User Story 4 - Present Conservative Evaluation And Pricing Language (Priority: P2) +### User Story 4 - Trust The Site Without False Assurance (Priority: P2) -A buyer reads `/pricing` and homepage evaluation copy and understands that commercial packaging is scoped and contact-led. +A DACH or enterprise evaluator reads the trust teaser, metadata, and CTA surfaces and sees conservative, honest claims. -**Why this priority**: Pricing language is a trust-sensitive surface. +**Why this priority**: The website must invite evaluation without overpromising compliance, hosting, or automation. -**Independent Test**: Read pricing/evaluation copy and verify it avoids unsupported billing and entitlement claims. +**Independent Test**: Review hero copy, trust teaser, supporting sections, metadata, navigation links, and CTAs on primary public routes. **Acceptance Scenarios**: -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. - ---- - -### User Story 5 - Build Trust Without Fake Proof (Priority: P2) - -A security-conscious buyer reads trust/legal/FAQ copy and sees clear, conservative trust positioning. - -**Why this priority**: Tenantial's buyer will care about governance and evidence. Trust copy must be honest and precise. - -**Independent Test**: Read `/trust`, FAQ, legal-adjacent copy, and footer statements. - -**Acceptance Scenarios**: - -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. - ---- - -### User Story 6 - Normalize CTA Language (Priority: P3) - -A visitor sees consistent CTA language across homepage, platform, pricing, trust, docs, and footer. - -**Why this priority**: CTA inconsistency makes the site feel unfinished. - -**Independent Test**: List all visible CTA labels and target URLs. - -**Acceptance Scenarios**: - -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. +1. **Given** no verified legal or certification proof is provided, **When** trust-related copy is reviewed, **Then** it avoids claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or zero customer data storage. +2. **Given** public CTAs and navigation are present, **When** a visitor interacts with them, **Then** every visible link resolves to a real route or intentional page state and no `href="#"` placeholders remain. +3. **Given** restore, remediation, and automation language appears, **When** the copy is reviewed, **Then** it speaks about controlled recovery and approval-ready follow-up rather than autonomous remediation or automatic restore. ### Edge Cases -- If 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. +- If provider-extensible wording appears near provider examples, it must not imply that Google, AWS, or other providers are live today. +- If Intune is named in the hero, capability copy, or domain examples, it must remain one policy domain and not become the umbrella category. +- If trust or DACH language is added, it must stop at auditability, evidence, review trail, role-based access, or evaluation readiness unless verified legal claims exist. +- If a navigation label suggests a page that does not exist or is not ready, the route must be omitted or replaced with an intentional limited page that matches current website conventions. +- If the site mixes German and English copy, the mix must be intentional and not look like mockup residue. +- If supporting routes mention roadmap domains, the copy must clearly label them as planned or architecture direction. +- If metadata compresses the message, it must still preserve policy-governance positioning and avoid Intune-only framing. +- If previews, screenshots, or status-like content appear, they must not imply live customer/provider data unless explicitly verified. ## Requirements *(mandatory)* ### Assumptions -- 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. +- Specs 400-403 provide the current public website foundation and launch-readiness baseline. +- `apps/website` is the only application scope for this feature. +- The workspace contracts that matter to the website remain the root script names, website package name `@tenantatlas/website`, `WEBSITE_PORT`, and `apps/*` pnpm workspace convention. +- No verified Google, AWS, or other non-Microsoft provider support has been supplied as current product truth. +- No verified claim exists yet for German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or "no customer data stored" messaging. +- Detailed DACH trust, Datenschutz, hosting, legal, and security evidence belongs to a later trust-focused feature rather than this positioning feature. - `apps/platform` is out of scope and must remain untouched. ### Functional Requirements -#### Scope +#### Scope And Workspace Contracts -- **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. +- **FR-001**: The implementation MUST remain scoped to `apps/website` and directly related website workspace-contract files only. +- **FR-002**: The implementation MUST NOT modify `apps/platform` runtime, routes, auth, database, Filament, Livewire, or provider code. +- **FR-003**: The implementation MUST NOT add platform API calls, shared auth/session coupling, database dependencies, or route dependencies from the public website to `apps/platform`. +- **FR-004**: The implementation MUST preserve the root package script names, website package name `@tenantatlas/website`, `WEBSITE_PORT` convention, and `apps/*` pnpm workspace contract. +- **FR-005**: Before execution, the implementation MUST verify current repo truth for root scripts, website scripts, and website source structure instead of assuming a fixed file layout. +- **FR-006**: The feature MUST NOT introduce a CMS, fake placeholder pages, fake customer proof, fake certifications, or fake trust artifacts. -#### Messaging Architecture +#### Positioning Contract -- **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. +- **FR-007**: The public website MUST position Tenantial primarily as a Policy Governance Platform or an equivalent cloud policy governance phrasing. +- **FR-008**: The public website MUST NOT primarily position Tenantial as an Intune backup tool, Intune management tool, Microsoft admin center replacement, helpdesk, PSA platform, compliance certification platform, or autonomous remediation platform. +- **FR-009**: Homepage and metadata copy MUST communicate Microsoft 365 as the first product focus. +- **FR-010**: Intune MAY appear in public copy only as one Microsoft 365 policy domain, not as the product category. +- **FR-011**: Public copy MAY describe the product as provider-extensible by design or future-ready beyond a single admin center. +- **FR-012**: Public copy MUST NOT present Google, AWS, or other non-Microsoft providers as live supported integrations unless verified current product truth exists. -#### Product Capability Copy +#### Provider Posture Rules -- **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. +- Microsoft 365 is the current public product focus. +- Intune is one Microsoft 365 policy domain. +- Entra or Conditional Access may be described as Microsoft 365 governance domains only when consistent with current website truth. +- SharePoint, OneDrive sharing, enterprise apps, service principals, Google, AWS, and other providers may appear only as roadmap or architecture-direction language when they are not current product truth. -#### Page-Level Content +#### Homepage Content Architecture -- **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-013**: The homepage MUST explain what Tenantial governs and why evidence-based governance matters. +- **FR-014**: The homepage hero MUST communicate policy governance, Microsoft 365 first focus, and provider-extensible direction in one screen. +- **FR-015**: The homepage MUST include a trust teaser or equivalent light trust surface that speaks about auditability, evidence history, role-based access, review trail, or DACH evaluation readiness without overclaiming legal or certification status. +- **FR-016**: The homepage MUST include an operating-model section that covers observed state, evidence, detection, review, decision, and audit trail. +- **FR-017**: The homepage MUST shift capability framing away from narrow Intune feature language and toward policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability. +- **FR-018**: The homepage MUST include a Microsoft 365 first section or equivalent explanation that is concrete without collapsing the product into Intune-only positioning. +- **FR-019**: The homepage MUST include concise audience messaging for MSPs and internal IT teams or an equivalent audience split that matches public commercial intent. +- **FR-020**: The homepage MUST include clear boundary language that Tenantial is a governance and evidence layer, not an admin-center clone, not blind automation, and not a helpdesk or PSA replacement. +- **FR-021**: The homepage MUST end with concrete CTA language tied to real destinations or deliberate in-page navigation. -#### CTA Language +#### Supporting Route And Navigation 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-022**: Supporting public routes such as `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs navigation MUST reinforce the same positioning contract as the homepage. +- **FR-023**: If public navigation labels are adjusted, they MUST use honest labels such as `Platform`, `Use Cases`, `Trust`, `Docs`, `Pricing`, and `Contact`, or equivalent labels that match available route truth. +- **FR-024**: Navigation and CTA surfaces MUST NOT contain `href="#"` placeholders or production-looking links to content that does not exist. +- **FR-025**: If a route does not exist or lacks real content, it MUST be omitted from navigation or represented with an intentionally limited page consistent with current website conventions. +- **FR-026**: `/platform` or the primary supporting product route MUST explain the governance model more deeply than the homepage while remaining clearly public and non-runtime-coupled. -#### Trust And Claim Safety +#### Metadata And Terminology -- **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-027**: Homepage metadata MUST position Tenantial as policy governance for Microsoft 365 and avoid Intune-only framing. +- **FR-028**: Public metadata and visible copy MUST stay aligned on policy governance, evidence, review, decision, and auditability rather than raw feature lists. +- **FR-029**: Preferred public terminology MUST emphasize policy governance, managed environments, provider connections, policy evidence, drift detection, findings, exceptions, accepted risks, decision summaries, audit trail, controlled recovery, and provider readiness or equivalent governance language. +- **FR-030**: Restore terminology MUST prefer controlled recovery, restore readiness, or recovery planning over blind rollback or guaranteed restore language. +- **FR-031**: Public copy MUST remain consistent in route language and avoid accidental English/German mockup residue. -#### Metadata +#### Claim Guardrails -- **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-032**: Public copy MUST NOT claim Google support, AWS support, multi-cloud support today, provider-agnostic execution today, or provider-agnostic restore unless verified. +- **FR-033**: Public copy MUST NOT claim DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, German hosting, Microsoft endorsement, or "no customer data stored" unless verified. +- **FR-034**: Public copy MUST NOT claim autonomous remediation, automatic restore, self-healing, or approval-free automation. +- **FR-035**: Public copy MUST NOT include fake customer logos, fake testimonials, fake compliance badges, lorem ipsum, neutral-SaaS residue, or other placeholder artifacts in emitted public output. +- **FR-036**: If roadmap or architecture-direction language is used, it MUST be clearly separated from currently available product focus. -#### Validation +#### Validation And Reporting -- **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. +- **FR-037**: The implementation MUST use only scripts that actually exist in the workspace root or `apps/website/package.json`. +- **FR-038**: Validation MUST include a website build check using the existing workspace scripts. +- **FR-039**: Validation MUST include a website smoke or browser check if local preview/test support exists. +- **FR-040**: Validation MUST include a static scan for placeholder links and forbidden public claims in website source and committed public output when applicable. +- **FR-041**: Completion reporting MUST document changed public surfaces, commands run, pass/fail results, deferred follow-up work, and confirmation that `apps/platform` remained untouched. ## Success Criteria *(mandatory)* -- **SC-001**: A reviewer can 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 - -Planning should preserve the following sequence: - -- 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. - -## Suggested Validation Commands - -```bash -corepack pnpm build:website -WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke -git diff --check -git status --short -- apps/platform -``` - -## Reviewer Notes - -Reviewers should evaluate content quality before requesting spacing or layout refinements. - -The review should answer: - -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? - -## Follow-Up - -After this spec, the next likely spec is: - -- Spec 405 - `apps/website` Homepage Layout Rhythm & Visual Productization - -Spec 405 should use the stabilized content from this spec as the basis for spacing, section rhythm, preview sizing, and visual polish. +- **SC-001**: A reviewer can describe Tenantial from the homepage hero and next section as a policy governance platform for Microsoft 365 without calling it an Intune-only or backup-only tool. +- **SC-002**: Homepage copy presents a clear six-step governance narrative from observed state to audit trail that a reviewer can list in order from the rendered page. +- **SC-003**: Intune appears only as one example domain in homepage/supporting copy and does not appear as the primary product category in visible headings or metadata. +- **SC-004**: Provider-extensible language appears without any unverified live-support claim for Google, AWS, or other non-Microsoft providers. +- **SC-005**: Trust-related public copy contains zero unverified claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, certifications, or autonomous remediation/recovery. +- **SC-006**: Navigation and CTA surfaces contain zero placeholder destinations, and every visible CTA leads to a concrete next step or real route. +- **SC-007**: MSP/internal IT/governance-evaluator messaging is visible on the public site without reducing the target audience to endpoint administrators alone. +- **SC-008**: Homepage metadata and primary supporting routes consistently reinforce policy-governance positioning, Microsoft 365 first focus, and evidence/review language. +- **SC-009**: No `apps/platform` files are modified as part of the feature. +- **SC-010**: Public website validation completes successfully, or any failure is explicitly documented as pre-existing. diff --git a/specs/404-public-content-messaging/tasks.md b/specs/404-public-content-messaging/tasks.md index ea7e220f..b277b8d7 100644 --- a/specs/404-public-content-messaging/tasks.md +++ b/specs/404-public-content-messaging/tasks.md @@ -1,147 +1,119 @@ -# Tasks: `apps/website` Public Content Architecture & Messaging +# Tasks: Public Website Positioning & Content Architecture **Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/` **Prerequisites**: [plan.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md), [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md), [research.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md), [data-model.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md), [public-content-contract.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md), [quickstart.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md) -**Tests**: 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. +**Tests**: This feature remains in the browser/static website lane. Reuse the existing Astro build, Playwright public smoke suite, targeted static claim scans, and manual browser review under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`. Do not add Pest, Laravel, Filament, Livewire, database, Sail, Microsoft Graph, queue, job, policy, RBAC, or `apps/platform` coverage. ## Phase 1: Setup -**Purpose**: Establish the website-only scope and current public content baseline before editing. +**Purpose**: Establish the exact website-only scope and current public-content baseline before editing. -- [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 Confirm repo-truth inputs by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/package.json`, `/Users/ahmeddarrazi/Documents/projects/wt-website/pnpm-workspace.yaml`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/package.json` +- [x] T002 [P] Inventory homepage and platform content sources in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro` +- [x] T003 [P] Inventory navigation, footer, metadata, and localization surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` +- [x] T004 [P] Inventory docs, placeholder collections, and supporting route content in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/blog`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/insights`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/products` +- [x] T005 [P] Inventory current smoke coverage and forbidden-pattern guards in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts` --- ## Phase 2: Foundational -**Purpose**: Normalize shared website copy rules before story-specific page edits. +**Purpose**: Normalize shared positioning, metadata, and validation rules before user-story work. **Critical**: Complete this phase before user-story implementation. -- [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 Define the shared policy-governance vocabulary, Microsoft 365 first phrasing, provider-extensible guardrails, and CTA intent rules in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T007 Normalize shared site title, base description, and route-level metadata defaults in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro` +- [x] T008 Review and correct stale localized navigation helpers or route-link utilities in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/i18n.ts` +- [x] T009 Refresh forbidden-pattern coverage and public-route expectations for policy-governance, provider, and trust guardrails in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts` +- [x] T010 Confirm the foundational scope still excludes `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform` by checking from `/Users/ahmeddarrazi/Documents/projects/wt-website` -**Checkpoint**: Shared website messaging and CTA guardrails are ready for independently testable user-story work. +**Checkpoint**: Shared positioning rules, metadata defaults, and smoke guardrails are ready for independently testable story work. --- -## Phase 3: User Story 1 - Understand The Product Category (Priority: P1) MVP +## Phase 3: User Story 1 - Recognize The Right Product Category (Priority: P1) MVP -**Goal**: A first-time visitor opens `/` and understands that Tenantial is an evidence-first governance product for Microsoft tenant configuration. +**Goal**: A first-time visitor opens `/` and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility. -**Independent Test**: Read the homepage hero and first two homepage sections without relying on visuals; the product category and at least three core concepts are clear. +**Independent Test**: Read the hero and the next homepage section without relying on internal product knowledge; the product is clearly described as policy governance with Microsoft 365 as the first focus. -- [X] T011 [US1] Rewrite homepage hero 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] T011 [US1] Rewrite homepage hero headline, body, supporting line, and primary/secondary CTA copy in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T012 [US1] Update homepage category-proof and first supporting-section copy so Microsoft 365 first and evidence-based governance are explicit in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T013 [US1] Add explicit audience messaging for MSPs and internal IT teams in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro` +- [x] T014 [US1] Add a concrete end-of-homepage CTA with a real route or deliberate in-page target in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro` +- [x] T015 [US1] Adapt homepage rendering to the new category, audience, and CTA copy without widening layout scope in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro` +- [x] T016 [P] [US1] Align supporting highlights and FAQ prompts with the new product category in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json` +- [x] T017 [US1] Validate User Story 1 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` using the rendered homepage routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/index.astro` to confirm category framing, audience messaging, and terminal CTA intent **Checkpoint**: User Story 1 is independently shippable as the MVP. --- -## Phase 4: User Story 2 - Follow A Clear Website Narrative (Priority: P1) +## Phase 4: User Story 2 - Follow The Governance Operating Model (Priority: P1) -**Goal**: A buyer scrolls the homepage and sees a deliberate narrative from problem to model to capability to evaluation. +**Goal**: A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail. -**Independent Test**: Copy homepage headings and subheadings into a plain-text outline; the sequence tells a coherent story without repeated claims. +**Independent Test**: Read homepage section titles and core summaries in order from top to bottom; the operating-model flow is clear and each section adds new meaning. -- [X] 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 [US2] Rewrite the homepage operating-model sequence and section summaries around observe, evidence, detect, review, decide, and audit in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T019 [US2] Update homepage section ordering and block composition for the new operating-model narrative in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro` +- [x] T020 [P] [US2] Refresh homepage capability cards for policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json` +- [x] T021 [P] [US2] Update the docs landing and intro narrative to reflect the same governance model in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/welcome-to-docs.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/welcome-to-docs.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/intro.mdx` +- [x] T022 [US2] Validate User Story 2 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing the operating-model and capability sections in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro` -**Checkpoint**: User Story 2 is independently shippable once the homepage narrative reads coherently. +**Checkpoint**: User Story 2 is independently shippable once the homepage operating model reads coherently. --- -## Phase 5: User Story 3 - Explain The Public Product Model On `/platform` (Priority: P1) +## Phase 5: User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2) -**Goal**: A visitor opens `/platform` and understands Tenantial's public product model in more detail than the homepage. +**Goal**: A security-conscious evaluator can see Microsoft 365 as the current focus, provider-extensible direction as future-safe, and clear boundaries about what the product is not. -**Independent Test**: Read `/platform` without using admin/platform code as a source; backup, restore, drift, findings, evidence, auditability, exceptions, and reviews are explained as one operating model. +**Independent Test**: Read the homepage and `/platform`; current Microsoft focus, future provider direction, and non-admin-center/non-helpdesk boundaries are all explicit without live-support claims for other providers. -- [X] 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` +- [x] T023 [US3] Rewrite the Microsoft 365 first section and provider/domain labeling rules in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T024 [US3] Update `/platform` copy to separate current Microsoft focus from future provider direction and to reinforce product boundaries in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T025 [P] [US3] Align public docs provider-boundary explanations with the same current-versus-future posture in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/intro.mdx` +- [x] T026 [P] [US3] Review navigation and footer labels so route exposure stays honest for platform, docs, trust, pricing, and contact surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro` +- [x] T027 [US3] Validate User Story 3 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro` -**Checkpoint**: User Story 3 is independently shippable once `/platform` communicates the public product model safely. +**Checkpoint**: User Story 3 is independently shippable once provider posture and boundaries are clear and safe. --- -## Phase 6: User Story 4 - Present Conservative Evaluation And Pricing Language (Priority: P2) +## Phase 6: User Story 4 - Trust The Site Without False Assurance (Priority: P2) -**Goal**: A buyer reads `/pricing` and homepage evaluation copy and understands that commercial packaging is scoped and contact-led. +**Goal**: A DACH or enterprise evaluator reads the trust teaser, metadata, navigation, and CTA surfaces and sees conservative, honest claims. -**Independent Test**: Read pricing and evaluation copy; there are no checkout, subscription activation, instant onboarding, self-serve billing, or unsupported entitlement claims. +**Independent Test**: Review `/trust`, `/pricing`, `/contact`, homepage trust surfaces, and metadata; there are no false assurance, placeholder-link, or autonomous-remediation 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` +- [x] T028 [US4] Rewrite the trust teaser, trust page copy, and trust-adjacent CTA language for conservative claims in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` +- [x] T029 [US4] Update homepage, platform, pricing, and trust metadata to remove false assurance and preserve policy-governance wording in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts` +- [x] T030 [P] [US4] Review conservative trust, contact-led evaluation, and legal-adjacent rendering in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/ContactPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/LegalPage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TextPage.astro` +- [x] T031 [P] [US4] Update docs and checklist content to avoid false provider/compliance/automation assurance in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/first-project-checklist.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/getting-started.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/first-project-checklist.mdx` +- [x] T032 [US4] Update smoke and interaction expectations for trust-safe links, metadata, and placeholder-free CTAs in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts` +- [x] T033 [US4] Validate User Story 4 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` and `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/trust.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/pricing.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/contact.astro` -**Checkpoint**: User Story 4 is independently shippable once 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. +**Checkpoint**: User Story 4 is independently shippable once trust-sensitive surfaces remain honest and placeholder-free. --- ## Final Phase: Polish And Cross-Cutting Concerns -**Purpose**: Complete public content validation, smoke checks, and handoff. +**Purpose**: Complete localization parity, route exposure review, browser/static validation, and implementation 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` +- [x] T034 [P] Review German default and English mirror parity for all changed marketing routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` +- [x] T035 [P] Reconcile exposed docs/navigation and redirect behavior with the updated positioning contract in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/product.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/products/index.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/product.astro` +- [x] T036 [P] Review dominant next-step CTA intent across the homepage, platform, pricing, trust, contact, footer, and exposed docs routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` +- [x] T037 [P] Run the targeted static claim scan from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` against `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public` +- [x] T038 Run website build validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `corepack pnpm build:website` +- [x] T039 Run public smoke validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke` +- [x] T040 Run whitespace validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git diff --check` +- [x] T041 Run scope validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git status --short -- apps/platform` +- [x] T042 Perform the manual desktop/mobile browser review described in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` for `/`, `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs routes +- [x] T043 Prepare the final implementation handoff with changed surfaces, provider/trust guardrail decisions, validation results, follow-up specs, and `apps/platform` untouched confirmation from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md` --- @@ -149,20 +121,18 @@ ## 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. +Setup must complete before Foundational. Foundational must complete before any user story. User Stories 1 and 2 are the P1 path and should land before provider/trust refinement. User Story 3 depends on the shared category and operating-model vocabulary from earlier phases. User Story 4 depends on the shared provider, CTA, metadata, and navigation decisions so trust-safe wording does not drift from the rest of the site. **User Story Dependencies** - **US1**: Depends on Phase 2 only. -- **US2**: Depends on Phase 2 and benefits from US1 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. +- **US2**: Depends on Phase 2 and benefits from US1 category vocabulary. +- **US3**: Depends on Phase 2 and benefits from US1-US2 shared narrative. +- **US4**: Depends on Phase 2 and benefits from US1-US3 provider, metadata, and navigation decisions. **MVP Scope** -Complete Phase 1, Phase 2, and Phase 3 (US1) for the smallest independently reviewable increment. +Complete Phase 1, Phase 2, and Phase 3 (US1) for the smallest independently reviewable increment. Phase 4 (US2) is the immediate next increment once the product category is fixed. --- @@ -171,47 +141,44 @@ ## 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 +US1 supporting-surface work can run in parallel after the main homepage copy settles: +- T015 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro +- T016 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json -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 +US2 operating-model support work can run in parallel once the sequence is defined: +- T020 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json +- T021 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/welcome-to-docs.mdx and related intro mirrors ``` -**Pricing And Trust** +**Provider 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 +US3 and US4 can progress on different files once shared vocabulary is stable: +- T025 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx and related mirrors +- T030 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro, PricingPage.astro, ContactPage.astro, LegalPage.astro, and TextPage.astro +- T031 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx and related checklist mirrors ``` **Final Validation** ```text -Cross-cutting 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 +Cross-cutting closeout can run in parallel before the final command sequence: +- T034 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en +- T035 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs and redirect route files +- T036 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro, and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs +- T037 from /Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md against /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public ``` --- ## Implementation Strategy -1. Finish setup and foundational 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. +1. Finish setup and foundational vocabulary/metadata/smoke guardrails before page-level rewrites. +2. Ship the MVP by fixing homepage category framing in US1. +3. Layer the operating-model narrative in US2 before broadening provider posture in US3. +4. Complete trust-safe metadata, docs, and CTA coverage in US4 after the shared category and provider story settle. +5. Finish with localization parity, route-exposure review, static claim scans, build, smoke, manual browser review, and scope validation. ## Test Governance Notes -The declared test purpose is Browser/static website. The affected validation lanes are website build, Playwright public smoke, 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. +The declared test purpose is Browser/static website. The affected validation lanes are website build, Playwright public smoke, targeted static claim scans, manual browser review, whitespace validation, and `apps/platform` scope validation. No Pest, Laravel, Filament, Livewire, database, provider, workspace, membership, session, queue, Sail, or heavy-governance setup is introduced. No dedicated follow-up spec is needed unless repeated public-website release validation becomes a recurring governance problem.