From 44d273955467fe0795a135dfcaf411dd1f69a20a Mon Sep 17 00:00:00 2001 From: Ahmed Darrazi Date: Mon, 25 May 2026 22:29:12 +0200 Subject: [PATCH] feat(website): tighten homepage messaging and trust flow --- .../src/components/pages/HomePage.astro | 48 +- .../sections/landing/HeroSection.astro | 9 + apps/website/src/data_files/constants.ts | 10 +- apps/website/src/data_files/site-copy.ts | 334 +++++------ apps/website/tests/smoke/interaction.spec.ts | 6 +- .../website/tests/smoke/public-routes.spec.ts | 22 +- apps/website/tests/smoke/smoke-helpers.ts | 6 +- specs/404-public-content-messaging/plan.md | 363 ++++++------ specs/404-public-content-messaging/spec.md | 518 +++++++++++------- specs/404-public-content-messaging/tasks.md | 216 ++------ 10 files changed, 735 insertions(+), 797 deletions(-) diff --git a/apps/website/src/components/pages/HomePage.astro b/apps/website/src/components/pages/HomePage.astro index 0b56d194..af995b35 100644 --- a/apps/website/src/components/pages/HomePage.astro +++ b/apps/website/src/components/pages/HomePage.astro @@ -2,20 +2,12 @@ import MainLayout from '@/layouts/MainLayout.astro'; import HeroSection from '@components/sections/landing/HeroSection.astro'; import FeaturesGeneral from '@components/sections/features/FeaturesGeneral.astro'; -import FeaturesNavs from '@components/sections/features/FeaturesNavs.astro'; -import PricingSection from '@components/sections/pricing/PricingSection.astro'; -import FAQ from '@components/sections/misc/FAQ.astro'; import PrimaryCTA from '@components/ui/buttons/PrimaryCTA.astro'; import SecondaryCTA from '@components/ui/buttons/SecondaryCTA.astro'; import heroImage from '@images/tenantial-dashboard.avif'; import featureImage from '@images/tenantial-review-board.avif'; -import reviewImage from '@images/tenantial-evidence-intake.avif'; -import evidenceImage from '@images/tenantial-decision-review.avif'; -import governanceImage from '@images/tenantial-restore-plan.avif'; import { - faqsByLocale, featuresByLocale, - pricingByLocale, siteCopy, } from '@data/site-copy'; import { localizeHref, type Locale } from '@/i18n'; @@ -27,18 +19,6 @@ 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: workflowImages[index], -})); --- ({ secondaryBtn={copy.secondaryCta} secondaryBtnURL={localizeHref('/platform', locale)} withReview={false} + supportingLine={copy.supportingLine} src={heroImage} alt={copy.heroAlt} /> @@ -67,8 +48,6 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({ features={featuresByLocale[locale]} /> - -

@@ -123,9 +102,28 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({

- +
+
+
+

+ {copy.trustTeaserTitle} +

+

+ {copy.trustTeaserSubtitle} +

+
- +
    + { + copy.trustPoints.map((point: string) => ( +
  • + {point} +
    • + )) + } +
+
+
@@ -145,7 +143,7 @@ const tabs = copy.tabs.map((tab: any, index: number) => ({ />
diff --git a/apps/website/src/components/sections/landing/HeroSection.astro b/apps/website/src/components/sections/landing/HeroSection.astro index 27359661..d9579285 100644 --- a/apps/website/src/components/sections/landing/HeroSection.astro +++ b/apps/website/src/components/sections/landing/HeroSection.astro @@ -9,6 +9,7 @@ import ReviewComponent from '@components/ui/blocks/ReviewComponent.astro'; const { title, subTitle, + supportingLine, primaryBtn, primaryBtnURL, secondaryBtn, @@ -25,6 +26,7 @@ const { interface Props { title: string; subTitle?: string; + supportingLine?: string; primaryBtn?: string; primaryBtnURL?: string; secondaryBtn?: string; @@ -62,6 +64,13 @@ interface Props {

) } + { + supportingLine && ( +

+ {supportingLine} +

+ ) + } { /* Action Button Section: This section includes two CTAs with their own styles and URL */ } diff --git a/apps/website/src/data_files/constants.ts b/apps/website/src/data_files/constants.ts index fc520cc3..cf4a0eca 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: 'Policy Governance für Microsoft 365', + tagline: 'Microsoft 365 Policies unter Kontrolle bringen', description: - '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.', + 'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.', description_short: - 'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.', + 'Microsoft 365 Governance mit Policy-Drift, versionierten Backups, Evidence, Reviews und kontrollierter Recovery-Vorbereitung.', url: 'https://tenantial.com', author: 'Tenantial', }; @@ -35,9 +35,9 @@ export const OG = { locale: 'de_DE', type: 'website', url: SITE.url, - title: `${SITE.title}: Policy Governance für Microsoft 365`, + title: `${SITE.title}: Microsoft 365 Policies unter Kontrolle bringen`, description: - 'Ordne beobachteten Zustand, Evidence, Drift, Reviews, Audit Trail und kontrollierte Recovery-Planung für Microsoft 365 mit konservativen, auditfreundlichen Workflows ein.', + 'Policy-Drift früh erkennen, Konfigurationsstände versioniert sichern und auditfähige Evidence für Reviews, Changes und kontrollierte Recovery vorbereiten.', image: ogImageSrc, }; diff --git a/apps/website/src/data_files/site-copy.ts b/apps/website/src/data_files/site-copy.ts index 63b6d80e..aa92921d 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: 'Policy Governance für Microsoft 365', + tagline: 'Microsoft 365 Policies unter Kontrolle bringen', description: - '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.', + 'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.', descriptionShort: - 'Policy-Governance-Workflows für Microsoft 365 mit Evidence, Drift Detection, Review, Audit Trail und kontrollierter Recovery-Planung.', + 'Microsoft 365 Governance mit Policy-Drift, versionierten Backups, Evidence, Reviews und kontrollierter Recovery-Vorbereitung.', }, nav: [ { name: 'Start', url: '/' }, @@ -80,113 +80,76 @@ export const siteCopy: Record = { walkthrough: 'Walkthrough anfragen', }, home: { - pageTitle: 'Tenantial | Policy Governance für Microsoft 365', + pageTitle: 'Tenantial | Microsoft 365 Policies unter Kontrolle bringen', metaDescription: - '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.', + 'Policy-Drift früh erkennen, Konfigurationsstände versioniert sichern und auditfähige Evidence für Reviews, Changes und kontrollierte Recovery vorbereiten.', heroTitle: - 'Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen', + 'Microsoft 365 Policies unter Kontrolle bringen.', heroSubtitle: - '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: 'Governance-Modell ansehen', + 'Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.', + supportingLine: + 'Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen.', + primaryCta: 'Demo buchen', + secondaryCta: 'Plattform ansehen', heroAlt: 'Statische Tenantial Governance-Dashboard-Vorschau', - featureTitle: 'Die richtige Produktkategorie zuerst', + featureTitle: + 'Wenn Microsoft 365 Policies driften, reicht ein Admin Center nicht aus.', featureSubtitle: - '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.', + 'Tenantial zeigt, was sich geändert hat, welche Konfigurationen abgesichert sind, welche Evidence vorliegt und welche Findings vor dem nächsten Review geklärt werden müssen.', featureAlt: 'Statische Tenantial Review-Board-Vorschau', - workflowTitle: - 'Vom beobachteten Zustand zu Evidence, Review und Audit Trail.', - tabs: [ - { - heading: 'Beobachten', - content: - 'Starte mit dem beobachteten Microsoft-365-Status und einer lesbaren Sicht auf relevante Richtlinien, Konfigurationen und Verantwortlichkeiten.', - svg: 'frame', - alt: 'Statische Tenantial Observed-State-Vorschau', - first: true, - }, - { - heading: 'Evidence sammeln', - content: - '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: 'Drift erkennen', - content: - 'Mache Unterschiede, Findings und Veränderungen sichtbar, bevor Teams überspringen, was überhaupt geprüft werden muss.', - svg: 'verified', - 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', + audienceTitle: 'Eine belastbare Wahrheit für MSPs, IT und Audit.', audienceSubtitle: - 'Tenantial adressiert Buyer und Operatoren, die Richtlinienkontext, Review-Arbeit und Recovery-Readiness gemeinsam einordnen müssen.', + 'Tenantial verbindet technische Konfigurationsdaten mit Evidence, Findings und Reviews - damit Operatoren, Security-Verantwortliche und Auditoren nicht aus Screenshots, Excel-Listen oder Bauchgefühl entscheiden.', audiences: [ { - title: 'MSPs und Service-Teams', + title: 'MSP Operatoren', content: - 'Schaffe eine prüfbare Evidence-Basis für Tenant-Reviews, Change-Freigaben und kontrollierte Recovery-Gespräche über mehrere Kundenumgebungen hinweg.', + 'Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.', }, { - title: 'Interne IT- und Security-Teams', + title: 'Enterprise IT', content: - 'Mache Microsoft-365-Richtlinien, Drift und Review-Entscheidungen lesbar, bevor kritische Änderungen in Produktion oder Ausnahmeprozesse gehen.', + 'Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren.', }, { - title: 'Governance- und Audit-Verantwortliche', + title: 'Security & Audit', content: - 'Halte Findings, akzeptierte Risiken, Exceptions und Audit Trail so sichtbar, dass Entscheidungen später nachvollzogen statt rekonstruiert werden müssen.', + 'Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen.', }, ], - boundaryTitle: 'Klare Grenzen statt überzogener Versprechen', + boundaryTitle: 'Gebaut für Governance. Nicht für blinde Automatisierung.', boundarySubtitle: - 'Tenantial positioniert Policy Governance, nicht eine zweite Admin-Oberfläche oder approval-freie Automatisierung.', + 'Tenantial ersetzt nicht das Microsoft Admin Center. Es ergänzt es um die Schicht, die Enterprise-Teams im Alltag fehlt: Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen.', boundaries: [ { - title: 'Kein Admin-Center-Klon', + title: 'Versionierung statt Momentaufnahme', content: - 'Die öffentliche Website beschreibt Governance-Flows, Evidence und Reviews. Sie ersetzt keine produktive Microsoft-Adminoberfläche.', + 'Policy-Zustände bleiben historisch vergleichbar, damit Changes und Review-Fragen nicht aus Screenshots rekonstruiert werden müssen.', }, { - title: 'Keine blinde Automation', + title: 'Evidence statt Bauchgefühl', content: - 'Drift, Findings, Recovery und Freigaben bleiben review- und bestätigungspflichtig statt autonomer Remediation.', + 'Findings, Accepted Risks und Review Packs bringen Security, IT und Audit auf dieselbe belastbare Datenbasis.', }, { - title: 'Kein Helpdesk- oder PSA-Ersatz', + title: 'Recovery vor Ausführung bewerten', content: - 'Tenantial fokussiert Policy Governance, Entscheidungsgrundlagen und Auditierbarkeit, nicht Ticketabwicklung oder Support-SLAs.', + 'Restore- und Recovery-Fragen werden mit Scope, Risiko und Evidence bewertet, bevor Änderungen ausgeführt werden.', }, ], - finalCtaTitle: 'Den nächsten Schritt bewusst wählen', + trustTeaserTitle: 'Evidence, Findings und Review Packs für nachvollziehbare Entscheidungen.', + trustTeaserSubtitle: + 'Tenantial bündelt Policy-Zustände, Findings, Accepted Risks und Follow-ups zu Review Packs, die Kundentermine, interne Audits und Recovery-Entscheidungen mit belastbarem Kontext vorbereiten.', + trustPoints: [ + 'Nachvollziehbarer Audit Trail für Changes und Accepted Risks', + 'Review Packs für Kundentermine und interne Audits', + 'Rollenbewusster Governance-Kontext für Operatoren, Security und Audit', + ], + finalCtaTitle: 'Bereit, Microsoft 365 Governance messbar zu machen?', finalCtaSubtitle: - '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', + 'Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt.', + finalPrimaryCta: 'Demo buchen', + finalSecondaryCta: 'Plattform ansehen', faqTitle: 'Häufige
Fragen', }, platform: { @@ -195,10 +158,10 @@ export const siteCopy: Record = { '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 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.', + 'Tenantial ergänzt Microsoft Admin Center um Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen. Microsoft 365 ist der erste Markt; weitere Policy-Domänen bleiben klar als vorbereitete Richtung eingeordnet.', focusTitle: 'Heutiger Fokus und künftige Richtung', focusSubtitle: - 'Die öffentliche Produktstory trennt bewusst zwischen aktuellem Microsoft-365-Fokus und provider-extensibler Zukunftsrichtung.', + 'Die öffentliche Produktstory trennt bewusst zwischen aktuellem Microsoft-365-Fokus und vorbereiteten weiteren Policy-Domänen.', focusCards: [ { title: 'Aktueller Fokus: Microsoft 365', @@ -206,9 +169,9 @@ export const siteCopy: Record = { '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', + title: 'Künftige Richtung: weitere Policy-Domänen', content: - 'Andere Provider können als Architektur- oder Roadmap-Richtung genannt werden, aber nicht als live unterstützte Integrationen oder verifizierte Workflows.', + 'Weitere Policy-Domänen können als Architektur- oder Roadmap-Richtung genannt werden, aber nicht als live unterstützte Integrationen oder verifizierte Workflows.', }, ], backupTitle: 'Beobachteter Zustand und Policy-Evidence', @@ -231,7 +194,7 @@ export const siteCopy: Record = { '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: 'Microsoft 365', description: 'heutiger Fokus' }, - { stat: 'Provider-extensible', description: 'klar als Richtung markiert' }, + { stat: 'Weitere Domänen', description: 'klar als Richtung markiert' }, { stat: 'Keine Live-Daten', description: 'auf der öffentlichen Website' }, ], mainStatTitle: 'Heute', @@ -280,16 +243,16 @@ export const siteCopy: Record = { trust: { pageTitle: 'Vertrauen | Tenantial', metaDescription: - 'Tenantial öffentliche Trust-Haltung mit konservativen Claims, klaren Grenzen und Policy-Governance-Wortwahl ohne false assurance.', + 'Tenantial Trust-Haltung für Microsoft-365-Policy-Governance mit auditfähiger Evidence, klaren Grenzen, nachvollziehbaren Reviews und kontrollierter Recovery-Vorbereitung.', heading: 'Vertrauen beginnt mit nachprüfbaren Grenzen', subtitle: - 'Tenantial 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.', + 'Tenantial macht sichtbar, welche Evidence vorliegt, welche Findings geklärt sind, welche Risiken akzeptiert wurden und welche Recovery-Fragen vor einer Änderung bewertet werden müssen.', cta: 'Tenantial kontaktieren', - statsTitle: 'Konservative Trust-Haltung', + statsTitle: 'Trust für prüfbare Reviews', statsSubtitle: - '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.', + 'Review Packs, Audit Trail und klare Zuständigkeiten helfen MSPs, Enterprise IT und Security-Teams, Entscheidungen auf belastbarem Kontext statt auf Momentaufnahmen zu treffen.', mainStatTitle: 'Review-first', - mainStatSubTitle: 'öffentliche Claims bleiben konservativ', + mainStatSubTitle: 'Evidence, Findings und Entscheidungen bleiben nachvollziehbar', stats: [ { stat: 'Keine', description: 'Compliance-Zusagen ohne Nachweis' }, { stat: 'Keine', description: 'Kundenlogo- oder Endorsement-Claims' }, @@ -332,11 +295,11 @@ export const siteCopy: Record = { }, en: { site: { - tagline: 'Policy governance for Microsoft 365', + tagline: 'Bring Microsoft 365 policies under control', description: - '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.', + 'Tenantial helps MSPs and enterprise IT teams detect policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.', descriptionShort: - 'Policy-governance workflows for Microsoft 365 with evidence, drift detection, review, audit trail, and controlled recovery planning.', + 'Microsoft 365 governance with policy drift, versioned backups, evidence, reviews, and controlled recovery preparation.', }, nav: [ { name: 'Home', url: '/' }, @@ -377,113 +340,76 @@ export const siteCopy: Record = { walkthrough: 'Request walkthrough', }, home: { - pageTitle: 'Tenantial | Policy governance for Microsoft 365', + pageTitle: 'Tenantial | Bring Microsoft 365 policies under control', metaDescription: - '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.', + 'Detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and controlled recovery.', heroTitle: - 'Policy governance for Microsoft 365 and modern cloud environments', + 'Bring Microsoft 365 policies under control.', heroSubtitle: - '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 governance model', + 'Tenantial helps MSPs and enterprise IT teams detect policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.', + supportingLine: + 'Built for Microsoft 365 governance - with Intune as the first strong policy focus and a model prepared for further policy domains.', + primaryCta: 'Book a demo', + secondaryCta: 'View platform', heroAlt: 'Static Tenantial governance dashboard preview', - featureTitle: 'Start with the right product category', + featureTitle: + 'When Microsoft 365 policies drift, an admin center is not enough.', featureSubtitle: - '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.', + 'Tenantial shows what changed, which configurations are protected, which evidence exists, and which findings need to be resolved before the next review.', featureAlt: 'Static Tenantial review board preview', - workflowTitle: - 'From observed state to evidence, review, and audit trail.', - tabs: [ - { - heading: 'Observe', - content: - 'Start from readable Microsoft 365 policy state, ownership context, and the configuration boundaries that need review.', - svg: 'frame', - alt: 'Static Tenantial observed-state preview', - first: true, - }, - { - heading: 'Collect evidence', - content: - '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: 'Detect drift', - content: - 'Make differences, findings, and change signals visible before teams skip the question of what really needs review.', - svg: 'verified', - 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', + audienceTitle: 'One reliable truth for MSPs, IT, and audit.', audienceSubtitle: - 'Tenantial speaks to buyers and operators who need to align policy context, review work, and recovery readiness before change moves forward.', + 'Tenantial connects technical configuration data with evidence, findings, and reviews so operators, security owners, and auditors do not decide from screenshots, spreadsheets, or gut feel.', audiences: [ { - title: 'MSPs and service teams', + title: 'MSP operators', content: - 'Create a reviewable evidence base for tenant reviews, change approvals, and controlled recovery conversations across multiple customer environments.', + 'Monitor, compare, and prepare multiple customer environments for controlled reviews.', }, { - title: 'Internal IT and security teams', + title: 'Enterprise IT', content: - 'Make Microsoft 365 policy posture, drift, and review decisions readable before high-impact changes move into production or exception handling.', + 'Document changes, drift, and recovery risks in a traceable way.', }, { - title: 'Governance and audit stakeholders', + title: 'Security & Audit', content: - 'Keep findings, accepted risk, exceptions, and audit trail visible so decisions can be inspected later instead of reconstructed under pressure.', + 'Turn evidence, findings, and accepted risks into reviewable material.', }, ], - boundaryTitle: 'Clear boundaries instead of inflated promises', + boundaryTitle: 'Built for governance. Not blind automation.', boundarySubtitle: - 'Tenantial positions policy governance, not a second admin surface or approval-free automation.', + 'Tenantial does not replace Microsoft Admin Center. It adds the layer enterprise teams miss in daily work: versioning, evidence, drift visibility, review context, and auditable decisions.', boundaries: [ { - title: 'Not an admin-center clone', + title: 'Versioning beyond snapshots', content: - 'The public website explains governance flows, evidence, and review work. It does not replace a production Microsoft administration surface.', + 'Policy states remain historically comparable so changes and review questions do not need to be rebuilt from screenshots.', }, { - title: 'No blind automation', + title: 'Evidence beyond gut feel', content: - 'Drift, findings, recovery, and approvals remain review-driven and explicitly confirmed instead of framed as self-running remediation.', + 'Findings, accepted risks, and review packs bring security, IT, and audit onto the same reliable data basis.', }, { - title: 'Not a helpdesk or PSA replacement', + title: 'Recovery evaluated before execution', content: - 'Tenantial focuses on policy governance, decision support, and auditability rather than ticket handling, service routing, or support SLAs.', + 'Restore and recovery questions are assessed with scope, risk, and evidence before changes are executed.', }, ], - finalCtaTitle: 'Choose the next step intentionally', + trustTeaserTitle: 'Evidence, findings, and review packs for traceable decisions.', + trustTeaserSubtitle: + 'Tenantial brings policy state, findings, accepted risks, and follow-ups into review packs that prepare customer meetings, internal audits, and recovery decisions with reliable context.', + trustPoints: [ + 'Traceable audit trail for changes and accepted risks', + 'Review packs for customer meetings and internal audits', + 'Role-aware governance context for operators, security, and audit', + ], + finalCtaTitle: 'Ready to make Microsoft 365 governance measurable?', finalCtaSubtitle: - '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', + 'See in a focused demo how Tenantial brings policy drift, backups, evidence, and reviews into a controlled governance process.', + finalPrimaryCta: 'Book a demo', + finalSecondaryCta: 'View platform', faqTitle: 'Frequently
asked questions', }, platform: { @@ -492,10 +418,10 @@ export const siteCopy: Record = { '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 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.', + 'Tenantial complements Microsoft Admin Center with versioning, evidence, drift visibility, review context, and auditable decisions. Microsoft 365 is the first market; further policy domains stay clearly framed as prepared direction.', focusTitle: 'Current focus and future direction', focusSubtitle: - 'The public story intentionally separates current Microsoft 365 scope from provider-extensible future direction.', + 'The public story intentionally separates current Microsoft 365 scope from prepared future policy domains.', focusCards: [ { title: 'Current focus: Microsoft 365', @@ -503,9 +429,9 @@ export const siteCopy: Record = { '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', + title: 'Future direction: further policy domains', content: - 'Other providers may be referenced as architecture or roadmap direction, but not as live integrations or verified operating workflows.', + 'Further policy domains may be referenced as architecture or roadmap direction, but not as live integrations or verified operating workflows.', }, ], backupTitle: 'Observed state and policy evidence', @@ -528,7 +454,7 @@ export const siteCopy: Record = { '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: 'Microsoft 365', description: 'current focus' }, - { stat: 'Provider-extensible', description: 'clearly marked as direction' }, + { stat: 'Further domains', description: 'clearly marked as direction' }, { stat: 'No live data', description: 'on the public website' }, ], mainStatTitle: 'Today', @@ -576,16 +502,16 @@ export const siteCopy: Record = { trust: { pageTitle: 'Trust | Tenantial', metaDescription: - 'Tenantial public trust posture with conservative claims, clear boundaries, and policy-governance wording without false assurance.', + 'Tenantial trust posture for Microsoft 365 policy governance with audit-ready evidence, clear boundaries, traceable reviews, and controlled recovery preparation.', heading: 'Trust starts with reviewable boundaries', subtitle: - 'Tenantial 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.', + 'Tenantial shows which evidence exists, which findings are resolved, which risks have been accepted, and which recovery questions need assessment before a change.', cta: 'Contact Tenantial', - statsTitle: 'Conservative trust posture', + statsTitle: 'Trust for review-ready governance', statsSubtitle: - '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.', + 'Review packs, audit trail, and clear ownership help MSPs, enterprise IT, and security teams make decisions from reliable context instead of point-in-time screenshots.', mainStatTitle: 'Review-first', - mainStatSubTitle: 'public claims stay conservative', + mainStatSubTitle: 'evidence, findings, and decisions stay traceable', stats: [ { stat: 'No', description: 'unsupported compliance claims' }, { stat: 'No', description: 'customer-proof or endorsement claims' }, @@ -629,77 +555,77 @@ export const siteCopy: Record = { export const featuresByLocale: Record = { de: [ { - heading: 'Policy-Evidence', + heading: 'Policy-Drift erkennen', content: - 'Führe beobachtete Richtlinien, Snapshots und Kontext in einer lesbaren Evidence-Basis zusammen, bevor Governance-Entscheidungen beginnen.', + 'Abweichungen zwischen erwarteter und tatsächlicher Konfiguration sichtbar machen.', svg: 'frame', }, { - heading: 'Drift und Veränderungssignale', + heading: 'Backups & Versionen behalten', content: - 'Mache Drift, Findings und Unterschiede sichtbar, bevor Teams über Freigaben, Ausnahmen oder kontrollierte Recovery-Arbeit sprechen.', + 'Policy-Zustände nachvollziehbar sichern und Änderungen historisch vergleichbar machen.', svg: 'dashboard', }, { - heading: 'Governance-Reviews', + heading: 'Auditfähige Reviews vorbereiten', content: - 'Ordne MSPs, interne IT-Teams und Governance-Verantwortliche um dieselbe Review-Grundlage statt um isolierte Tool-Sichten herum.', + 'Findings, Evidence, Accepted Risks und Review Packs für Kundentermine und interne Audits bündeln.', svg: 'verified', }, { - heading: 'Kontrollierte Recovery', + heading: 'Recovery kontrolliert vorbereiten', content: - 'Plane Restore und Recovery defensiv mit Preview, Validierung, selektivem Scope und expliziter Bestätigung statt mit Vollautomationsversprechen.', + 'Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden.', svg: 'tools', }, { - heading: 'Provider-Readiness', + heading: 'Provider-Berechtigungen transparent machen', content: - 'Halte Microsoft 365 als heutigen Fokus klar und beschreibe weitere Provider nur als Architektur- oder Roadmap-Richtung.', + 'Microsoft Graph und Provider-Zugriffe verständlich erklären, prüfen und capability-orientiert einordnen.', svg: 'frame', }, { - heading: 'Decision Traceability', + heading: 'Entscheidungen nachvollziehbar machen', content: - 'Verknüpfe Findings, Exceptions, akzeptierte Risiken und Audit Trail so, dass Entscheidungen später prüfbar bleiben.', + 'Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen.', svg: 'dashboard', }, ], en: [ { - heading: 'Policy evidence', + heading: 'Detect policy drift', content: - 'Bring observed policy state, snapshots, and supporting context into one readable evidence base before governance decisions begin.', + 'Make deviations between expected and actual configuration visible.', svg: 'frame', }, { - heading: 'Drift and change signals', + heading: 'Keep backups & versions', content: - 'Make drift, findings, and differences visible before teams talk about approval, exceptions, or controlled recovery work.', + 'Preserve policy states in a traceable way and compare changes historically.', svg: 'dashboard', }, { - heading: 'Governance reviews', + heading: 'Prepare audit-ready reviews', content: - 'Align MSPs, internal IT teams, and governance stakeholders around the same review lane instead of isolated tool views.', + 'Bundle findings, evidence, accepted risks, and review packs for customer meetings and internal audits.', svg: 'verified', }, { - heading: 'Controlled recovery', + heading: 'Prepare controlled recovery', content: - 'Plan restore and recovery defensively with preview, validation, selective scope, and explicit confirmation instead of automation promises.', + 'Assess restore and recovery questions with scope, risk, and evidence before changes are executed.', svg: 'tools', }, { - heading: 'Provider readiness', + heading: 'Make provider permissions transparent', content: - 'Keep Microsoft 365 explicit as the current focus while describing other providers only as architecture or roadmap direction.', + 'Explain, verify, and classify Microsoft Graph and provider access by capability.', svg: 'frame', }, { - heading: 'Decision traceability', + heading: 'Make decisions traceable', content: - 'Connect findings, exceptions, accepted risk, and audit trail so later decisions remain inspectable.', + 'Put findings, exceptions, accepted risks, and follow-ups into a reviewable governance context.', svg: 'dashboard', }, ], @@ -789,7 +715,7 @@ export const faqsByLocale: Record = { { question: 'Was hilft Tenantial Teams zu verstehen?', answer: - '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.', + 'Tenantial hilft Teams, Microsoft 365 Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.', }, { question: 'Ist Microsoft 365 der einzige relevante Kontext?', @@ -815,7 +741,7 @@ export const faqsByLocale: Record = { { question: 'What does Tenantial help teams understand?', answer: - 'Tenantial explains policy governance for Microsoft 365: observed state, evidence, drift, review, decisions, audit trail, and controlled recovery planning in one operating model.', + 'Tenantial helps teams detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and recovery.', }, { question: 'Is Microsoft 365 the only relevant context?', diff --git a/apps/website/tests/smoke/interaction.spec.ts b/apps/website/tests/smoke/interaction.spec.ts index 3c8a2bf6..fd74fc98 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: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/, + name: /Microsoft 365 Policies unter Kontrolle bringen/, }) ).toBeVisible(); await page.locator('button[aria-label="Light Theme Toggle"]:visible').click(); await expect( page.getByRole('heading', { - name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/, + name: /Microsoft 365 Policies unter Kontrolle bringen/, }) ).toBeVisible(); }); @@ -54,7 +54,7 @@ test('homepage mobile first viewport remains readable', async ({ await page.goto('/'); const heading = page.getByRole('heading', { - name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i, + name: /Microsoft 365 Policies unter Kontrolle bringen/i, }); await expect(heading).toBeVisible(); diff --git a/apps/website/tests/smoke/public-routes.spec.ts b/apps/website/tests/smoke/public-routes.spec.ts index e99e145f..7915044e 100644 --- a/apps/website/tests/smoke/public-routes.spec.ts +++ b/apps/website/tests/smoke/public-routes.spec.ts @@ -20,8 +20,8 @@ import { globby } from 'globby'; const routeMetadata = { '/': { - title: /Tenantial.*Policy Governance für Microsoft 365/i, - description: /Policy Governance für Microsoft 365/i, + title: /Tenantial.*Microsoft 365 Policies unter Kontrolle bringen/i, + description: /Policy-Drift früh erkennen|Konfigurationsstände versioniert sichern/i, }, '/platform': { title: /Plattform \| Tenantial/i, @@ -76,8 +76,8 @@ const routeMetadata = { description: /Policy-Governance-Modell|Evidence-Review-Workflows/i, }, '/en/': { - title: /Tenantial.*Policy governance for Microsoft 365/i, - description: /policy governance for Microsoft 365/i, + title: /Tenantial.*Bring Microsoft 365 policies under control/i, + description: /Detect Microsoft 365 policy drift early|versioned configuration backups/i, }, '/en/platform': { title: /Platform \| Tenantial/i, @@ -93,7 +93,7 @@ const routeMetadata = { }, '/en/trust': { title: /Trust \| Tenantial/i, - description: /conservative claims|false assurance|policy-governance/i, + description: /trust posture|policy governance|review/i, }, '/en/legal': { title: /Legal \| Tenantial/i, @@ -149,21 +149,21 @@ test('homepage first viewport explains core Tenantial capabilities', async ({ await page.goto('/'); const heading = page.getByRole('heading', { - name: /Policy Governance für Microsoft 365 und moderne Cloud-Umgebungen/i, + name: /Microsoft 365 Policies unter Kontrolle bringen/i, }); await expect(heading).toBeVisible(); const box = await heading.boundingBox(); expect(box?.y ?? Number.POSITIVE_INFINITY).toBeLessThan(420); await expect( - page.getByRole('link', { name: /Walkthrough anfragen/i }).first() + page.getByRole('link', { name: /Demo buchen/i }).first() ).toHaveAttribute('href', '/contact'); await expect( - page.getByRole('link', { name: /Governance-Modell ansehen/i }).first() + page.getByRole('link', { name: /Plattform ansehen/i }).first() ).toHaveAttribute('href', '/platform'); await expect( - page.getByRole('link', { name: /Trust-Grenzen ansehen/i }).last() - ).toHaveAttribute('href', '/trust'); + page.getByRole('link', { name: /Plattform ansehen/i }).last() + ).toHaveAttribute('href', '/platform'); await expectCoreCapabilitiesVisible(page); }); @@ -177,7 +177,7 @@ test('/platform explains the public product model without internal runtime terms ).toBeVisible(); await expectCoreCapabilitiesVisible(page); 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(/weitere Policy-Domänen|Weitere Domänen/i); await expect(page.locator('body')).toContainText( /authentifiziert keine Besucher, liest keinen Microsoft Tenant, führt keine Operationen aus und speichert keine Tenant-Exporte/i ); diff --git a/apps/website/tests/smoke/smoke-helpers.ts b/apps/website/tests/smoke/smoke-helpers.ts index a7d6ff0c..473b906f 100644 --- a/apps/website/tests/smoke/smoke-helpers.ts +++ b/apps/website/tests/smoke/smoke-helpers.ts @@ -179,14 +179,14 @@ export async function expectCoreCapabilitiesVisible(page: Page): Promise { const text = (await page.locator('body').innerText()).toLowerCase(); for (const terms of [ - ['policy governance', 'policy-governance'], + ['policy governance', 'policy-governance', 'governance'], ['microsoft 365'], ['evidence'], - ['drift detection', 'drift'], + ['drift detection', 'policy-drift', 'drift'], ['reviews', 'review'], ['audit trail', 'auditability'], ['controlled recovery', 'recovery', 'restore'], - ['provider', 'future direction', 'roadmap direction'], + ['provider', 'policy-domänen', 'policy domains', 'further policy domains'], ]) { expect( terms.some(term => text.includes(term)), diff --git a/specs/404-public-content-messaging/plan.md b/specs/404-public-content-messaging/plan.md index 0f1aa249..dfbb925b 100644 --- a/specs/404-public-content-messaging/plan.md +++ b/specs/404-public-content-messaging/plan.md @@ -1,229 +1,216 @@ -# Implementation Plan: Public Website Positioning & Content Architecture +# Implementation Plan: Public Website Sales Copy & Positioning Rewrite -**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` +**Branch**: `404-public-content-messaging` +**Date**: 2026-05-25 +**Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` ## Summary -Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 as the first focus and provider-extensible language kept explicitly future-safe. The implementation will stay inside `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` and reuse the existing Astro route/content architecture: locale-keyed copy in `src/data_files/site-copy.ts`, thin route wrappers in `src/pages`, shared page components in `src/components/pages`, metadata through `MainLayout` and `Meta`, and the current Playwright smoke suite for route, link, claim, and metadata validation. +This plan turns Spec 404 into a website-copy refactoring plan, not an architecture plan. The goal is to guide a later implementation that rewrites public Tenantial website copy toward B2B SaaS, cybersecurity, and IT-operations outcomes for MSPs, Enterprise IT, Security, and Audit. -## Technical Context +This implementation renders the approved homepage sales copy in `apps/website` while keeping platform/backend/runtime scope untouched. -**Language/Version**: TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0 -**Primary Dependencies**: Astro, `@astrojs/starlight`, `@astrojs/sitemap`, `@astrojs/mdx`, Tailwind CSS v4, `@tailwindcss/vite`, Preline 4, Lenis, GSAP, Sharp, Playwright -**Storage**: N/A - static website content 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 +## Scope Decision -## UI / Surface Guardrail Plan +- **404 path found**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging` +- **Decision**: This is the Public Website Sales Copy & Positioning Spec because the branch, folder name, prior title, and existing content all target public website messaging, homepage hierarchy, provider/trust wording, metadata, and `apps/website`. +- **Spec artifact scope**: `spec.md`, `plan.md`, and `tasks.md` +- **Website implementation scope**: `apps/website` source files and website smoke-test expectations needed for the homepage copy rewrite +- **Explicitly out of scope now**: `apps/platform`, root package/workspace contracts, build output, runtime config, generated assets, dependencies, backend code, provider integrations, and unsupported trust/certification claims -- **Guardrail scope**: no 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 +## Repo Verification -## Shared Pattern & System Fit +Before any later implementation agent edits website source, verify current repo truth instead of relying on this plan as a file-map guarantee: -- **Cross-cutting feature marker**: yes -- **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 +1. Run `git status --short --branch`. +2. Locate the 404 spec folder with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`. +3. Read `specs/404-public-content-messaging/spec.md`, `plan.md`, and `tasks.md`. +4. Inspect the website structure with `find apps/website -maxdepth 3 -type f | sort | sed -n '1,180p'`. +5. Read `apps/website/package.json` and use only scripts that actually exist. +6. Confirm `apps/platform` remains outside the change. -## OperationRun UX Impact +## Current Copy Inventory -- **Touches OperationRun start/completion/link UX?**: no -- **Central contract reused**: N/A -- **Delegated UX behaviors**: N/A -- **Surface-owned behavior kept local**: N/A -- **Queued DB-notification policy**: N/A -- **Terminal notification path**: N/A -- **Exception path**: none +The later implementation must inventory current visible website copy before changing it: -## Provider Boundary & Portability Fit +- homepage hero and above-the-fold copy +- homepage section titles and CTA labels +- platform/product page copy +- trust, pricing, contact, and docs entry copy if they repeat the same positioning +- metadata titles and descriptions +- navigation/footer labels only if they repeat stale positioning +- smoke-test forbidden-pattern lists, if they exist -- **Shared provider/platform boundary touched?**: 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 +The inventory must identify old internal, defensive, academic, or architecture-heavy wording, including: -## Constitution Check +- category-first positioning +- "operating model" language as visible marketing copy +- "source of truth" or "provider-extensible" as hero philosophy +- internal governance-process wording +- defensive boundary language that crowds out outcomes +- vague trust language that sounds like certification without proof -*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.* +## Copy Refactoring Workstreams -- Inventory-first: PASS - no inventory, 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 +### 1. Hero And Above The Fold -**Initial Gate Result**: PASS - no constitution violations or unresolved clarifications. +Define the homepage first screen around this core message: -## Test Governance Check +- Microsoft 365 Policies unter Kontrolle bringen. +- Policy-Drift früh erkennen. +- Konfigurationen versioniert sichern. +- auditfähige Evidence für Reviews, Changes und Recovery bereitstellen. +- Intune as the first strong policy focus, not the product boundary. -- **Test purpose / classification by changed surface**: Browser/static website -- **Affected validation lanes**: website build, public smoke, manual browser review, static claim scan, whitespace/scope checks -- **Why this lane mix is the narrowest sufficient proof**: The feature changes public copy, route metadata, CTA intent, navigation exposure, and claim discipline. Laravel/Pest/Filament lanes would not prove the changed behavior. -- **Narrowest proving command(s)**: `cd /Users/ahmeddarrazi/Documents/projects/wt-website && corepack pnpm build:website`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git diff --check`; `cd /Users/ahmeddarrazi/Documents/projects/wt-website && git status --short -- apps/platform` -- **Fixture / helper / factory / seed / context cost risks**: none - no database, provider, workspace, membership, session, queue, Sail, Laravel, Filament, or Livewire setup -- **Expensive defaults or shared helper growth introduced?**: no -- **Heavy-family additions, promotions, or visibility changes**: none - existing Playwright smoke remains explicit and website-local -- **Surface-class relief / special coverage rule**: N/A - public website -- **Closing validation and reviewer handoff**: Reviewers should rely on website build, Playwright smoke, static claim scan, desktop/mobile manual review, and `apps/platform` untouched confirmation. If copy changes add new public docs or navigation surfaces, smoke route allowlists and metadata expectations must be updated in the same feature. -- **Budget / baseline / trend follow-up**: none expected -- **Review-stop questions**: lane fit, claim drift, placeholder-link drift, route-exposure drift, hidden platform coupling -- **Escalation path**: document-in-feature -- **Active feature PR close-out entry**: Smoke Coverage -- **Why no dedicated follow-up spec is needed**: The validation cost remains local to this public website positioning pass unless future website work creates a recurring release-governance problem. +Primary CTA: "Demo buchen" +Secondary CTA: "Plattform ansehen" -## Project Structure +### 2. Problem And Pain Section -### Documentation (this feature) +The first supporting section must make the buyer pain explicit: -```text -/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/ -├── plan.md -├── research.md -├── data-model.md -├── quickstart.md -├── contracts/ -│ └── public-content-contract.md -└── tasks.md -``` +- Microsoft 365 policies drift. +- Admin centers show current settings but do not provide enough review context by themselves. +- Operators need to know what changed, what is backed up, which evidence exists, and which findings need action before the next review. -### Source Code (repository root) +Avoid product-philosophy explanations here. -```text -/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/ -├── astro.config.mjs -├── package.json -├── playwright.config.ts -├── process-html.mjs -├── public/ -├── src/ -│ ├── components/ -│ │ ├── pages/ -│ │ └── sections/ -│ ├── content/ -│ │ ├── docs/ -│ │ ├── blog/ -│ │ ├── insights/ -│ │ └── products/ -│ ├── data_files/ -│ ├── layouts/ -│ ├── pages/ -│ │ └── en/ -│ └── utils/ -└── tests/ - └── smoke/ -``` +### 3. Capability Cards -**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`. +Capability cards must be outcome-led and use the spec copy as the default source: -## Complexity Tracking +- Policy-Drift erkennen +- Backups & Versionen behalten +- Auditfähige Reviews vorbereiten +- Recovery kontrolliert vorbereiten +- Provider-Berechtigungen transparent machen +- Entscheidungen nachvollziehbar machen -| Violation | Why Needed | Simpler Alternative Rejected Because | -|-----------|------------|-------------------------------------| -| None | N/A | N/A | +Each card must describe what the buyer can see, compare, prepare, or document. Do not turn these into internal modules or architecture components. -## Proportionality Review +### 4. Stakeholder And Persona Section -- **Current operator problem**: Public 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. +Define a clear stakeholder section for: -## Phase 0 Research +- MSP Operatoren +- Enterprise IT +- Security & Audit -Research output is captured in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md`. +The section must show one reliable evidence basis for operators, security owners, and auditors. It should replace screenshot, Excel, and gut-feel decision language with review-ready evidence and traceable findings. -**Resolved clarifications**: +### 5. Differentiation Section -- The 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. +Differentiate Tenantial without attacking Microsoft tools: -## Phase 1 Design +- Tenantial does not replace Microsoft Admin Center. +- Tenantial adds versioning, evidence, drift visibility, review context, and auditability. +- Tenantial is built for governance and controlled review, not blind automation. -Design output is captured in: +### 6. Trust Teaser -- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md` -- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` -- `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` +Keep the trust teaser safe and specific: -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. +- allowed: audit trail, review packs, role-aware evidence, controlled recovery preparation, decision traceability +- forbidden unless proven: DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, complete evidence coverage, no-customer-data claims -## Post-Design Constitution Check +Do not make trust the hero story in Spec 404. A separate trust-focused spec can deepen it. -**Post-Design Gate Result**: PASS +### 7. Bottom CTA -- Phase 1 remains website-local and scoped to `apps/website`. -- All clarification markers are resolved. -- No product persistence, abstraction, status family, provider runtime seam, OperationRun behavior, RBAC behavior, or Filament behavior is introduced. -- Shared-pattern reuse stays within the existing website copy/layout/metadata/smoke system. -- Provider vocabulary remains bounded to public positioning only. -- Validation remains explicit and limited to website build, smoke, claim scans, and scope checks. -- Agent context must be updated with the current plan outputs before implementation continues. +End with an evaluation-oriented CTA: + +- Headline: "Bereit, Microsoft 365 Governance messbar zu machen?" +- Body: "Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt." +- Buttons: "Demo buchen" and "Plattform ansehen" + +### 8. SEO And Metadata Direction + +SEO metadata must compress the same B2B message: + +- Tenantial = Microsoft 365 policy governance +- outcomes = drift detection, versioned backups, evidence, reviews, controlled recovery preparation, auditability +- audiences = MSPs, Enterprise IT, Security, Audit +- first domain = Intune +- future posture = prepared for further policy domains, not live multi-cloud + +Do not use Intune-only, backup-only, autonomous remediation, or certification-heavy metadata. + +## Claim Guardrails And Static Search Terms + +Later implementation must include static scans for stale or unsafe copy. At minimum, scan website source and emitted public output when applicable for: + +- `Die richtige Produktkategorie zuerst` +- `Für Teams, die Governance gemeinsam tragen` +- `Klare Grenzen statt überzogener Versprechen` +- `Den nächsten Schritt bewusst wählen` +- `provider-extensible managed environment operating model` +- `source-of-truth first operating model` +- `Observe-to-Audit` +- `governance-of-record` +- `unter absoluter Kontrolle` +- `Drift in Echtzeit` +- `automatisch reparieren` +- `autonomous remediation` +- `Self-healing` +- `automatic restore` +- `lückenlose Evidenz` +- `gerichtsfeste Nachweise` +- `immutable backups` +- `DSGVO-konform` +- `ISO-zertifiziert` +- `NIS2-konform` +- `Google supported` +- `AWS supported` +- `multi-cloud supported` +- `href="#"` +- `lorem ipsum` + +Safe copy can still use "Microsoft 365 first", "Intune als erster starker Policy-Fokus", and "für weitere Policy-Domänen vorbereitet" when the surrounding text clearly separates current capability from roadmap or architecture direction. + +## Browser Smoke Requirements For Later Implementation + +Later implementation must verify: + +- desktop and mobile homepage first viewport reads cleanly +- hero headline, subhead, supporting line, and CTAs are visible and not overlapping +- section order matches the spec: hero, problem, capabilities, stakeholders, differentiation, trust teaser, bottom CTA +- CTA targets are real routes or intentional in-page anchors +- no placeholder links remain +- no forbidden claims render in source or public output +- metadata reinforces Microsoft 365 policy governance +- Intune appears only as first domain or example focus +- provider-extensible wording does not imply Google, AWS, or multi-cloud live support +- `apps/platform` remains untouched + +Use the existing website scripts from `apps/website/package.json` and root workspace scripts only after verifying they exist. + +## Runtime And Scope Boundaries + +This plan is intentionally static-website-only for the current task: + +- no platform source edits +- no build output edits +- no dependency changes +- no package-script changes +- no backend runtime changes +- no provider implementation changes +- no `apps/platform` changes + +## Validation For This Spec Update + +For the current website-copy implementation, validation includes: + +- `corepack pnpm build:website` +- targeted static claim scan for forbidden public copy in `apps/website/src` and `apps/website/public` +- browser review on `http://127.0.0.1:4321/` +- `git diff --check` +- `git status --short -- apps/website apps/platform` +- `git diff --name-only` + +Expected result: only approved 404 spec artifacts plus minimal `apps/website` source and website-smoke-test files are modified, with any pre-existing unrelated untracked files left untouched. + +## Follow-Up Specs + +- **405 Trust**: proof-backed trust, hosting, privacy, security, compliance, legal, and evidence claims +- **406 Provider Taxonomy**: public current-versus-planned policy-domain and provider vocabulary +- **407 Use Cases**: dedicated MSP, Enterprise IT, Security/Audit, Recovery, and Review landing pages diff --git a/specs/404-public-content-messaging/spec.md b/specs/404-public-content-messaging/spec.md index ae49e7c8..3613bbd9 100644 --- a/specs/404-public-content-messaging/spec.md +++ b/specs/404-public-content-messaging/spec.md @@ -1,4 +1,4 @@ -# Feature Specification: Public Website Positioning & Content Architecture +# Spec 404 - Public Website Sales Copy & Positioning Rewrite **Feature Branch**: `404-public-content-messaging` @@ -6,286 +6,404 @@ # Feature Specification: Public Website Positioning & Content Architecture **Status**: Draft -**Input**: User description: "Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 first positioning, provider-extensible direction, an Observe-to-Audit operating model, and strict public claim discipline." +**Input**: Rewrite the public Tenantial website positioning so a later website implementation can ship strong B2B SaaS, cybersecurity, and IT-operations sales copy instead of internal architecture, governance-process, or Spec Kit language. -## Spec Candidate Check *(mandatory - SPEC-GATE-001)* +## Spec Candidate Check -- **Problem**: The 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. +- **Problem**: The current public website copy reads too much like an internal governance and architecture explanation. MSPs, IT leaders, security teams, and enterprise IT buyers need to understand the risks Tenantial reduces and the business outcomes it supports. +- **Today's failure**: The site can sound defensive, philosophical, or category-first instead of clearly selling Microsoft 365 policy control, drift visibility, versioned configuration backups, review-ready evidence, controlled recovery preparation, and auditability. +- **User-visible improvement**: A buyer can understand what Tenantial helps them do, why it matters, who it serves, and which Microsoft 365 governance risks it addresses without needing internal product or architecture context. +- **Smallest enterprise-capable version**: Rewrite the governing Spec 404 artifacts so the next implementation agent has a concrete homepage copy contract, safe claim guardrails, section structure, CTA language, SEO direction, and acceptance criteria. +- **Explicit non-goals**: No `apps/platform` edits, no backend/runtime dependency changes, no database changes, no provider implementation, no trust/certification claims, and no unsupported production capability claims. +- **Permanent complexity imported**: No models, services, enums, runtime flows, providers, persisted data, UI frameworks, or new website architecture. This spec imports only public copy rules and claim discipline. +- **Why now**: Public positioning is the input for later landing-page work. If the spec remains architecture-heavy, later implementation will optimize the wrong message. +- **Why not local**: The correction must align `spec.md`, `plan.md`, and `tasks.md`; otherwise future implementation can still pull from old defensive, academic, or internal wording. - **Approval class**: Core Enterprise. -- **Red flags triggered**: Public category ambiguity; provider-claim risk; compliance/trust overclaim risk; narrow Intune-only framing risk. +- **Red flags triggered**: Public category ambiguity, trust-claim risk, provider overclaim risk, internal language leaking into buyer-facing copy. - **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | **Gesamt: 11/12** - **Decision**: approve. -## Spec Scope Fields *(mandatory)* +### Red Flag Defense -- **Scope**: workspace. -- **Primary Routes**: `/`, `/platform`, `/pricing`, `/trust`, `/contact`, exposed docs navigation, public metadata, public CTA surfaces, and any shared marketing copy/configuration that drives those routes. -- **Data Ownership**: No tenant-owned or workspace-owned records are created, changed, or read. This is public website content only. -- **RBAC**: Not applicable. The affected surfaces are public marketing and product-positioning pages. +This spec intentionally proceeds despite multiple red flags because the risks are public-facing trust and positioning risks, not a request for new platform machinery. The current correction prevents misleading public claims, Intune-only framing, unsupported provider language, and architecture-first marketing copy. The scope is deliberately narrow: only the 404 spec artifacts are rewritten now, and later implementation remains website-only. No runtime provider seam, persistence model, taxonomy, framework, or platform contract is introduced. -For canonical-view specs, the spec MUST define: +## Scope -- **Default filter behavior when tenant-context is active**: N/A - no tenant-context or canonical platform view is introduced. +This spec is a copy and positioning contract for the public Tenantial website. + +- **Relevant application for later implementation**: `apps/website` +- **Files changed by this implementation**: 404 spec artifacts plus the minimal `apps/website` source and website-smoke-test files needed to render and validate the approved homepage sales copy. +- **Out of scope for this change**: platform source files, build output, runtime config, database, Laravel, Filament, Microsoft Graph integration, provider implementation, and unsupported trust/certification claims. +- **Product focus**: Microsoft 365 is the first public market +- **Start domain**: Intune may appear as the first strong policy focus and example domain +- **Product boundary**: Intune must not be framed as the full product boundary +- **Provider posture**: prepared for further policy domains may be used as an architecture or roadmap signal; Google, AWS, or multi-cloud support must not appear as live features unless separately proven by repo/product truth + +## Spec Scope Fields + +- **Scope**: Public website copy and positioning contract. +- **Primary Routes**: `apps/website`, primarily `/`, with supporting alignment possible for public website routes such as `/platform`, `/trust`, `/pricing`, `/contact`, and public metadata. +- **Data Ownership**: No tenant-owned, workspace-owned, customer, provider, backup, evidence, or runtime product data is created, read, changed, or persisted. +- **RBAC**: N/A. This spec concerns public website copy guidance and does not change authenticated platform access, tenant access, roles, permissions, or authorization behavior. + +For canonical-view specs: + +- **Default filter behavior when tenant-context is active**: N/A - no tenant-context view or canonical platform view is introduced. - **Explicit entitlement checks preventing cross-tenant leakage**: N/A - no tenant data, workspace data, or authenticated platform state is involved. -## 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`)* +## Positioning Goal + +Tenantial must be presented as a hard, credible B2B platform for Microsoft 365 governance and IT operations. + +Visible website copy must emphasize outcomes: + +- Microsoft 365 policies under control +- early detection of policy drift +- versioned configuration backups +- evidence prepared for reviews, changes, recovery, and audits +- controlled recovery and restore preparation +- multi-customer and multi-tenant operating clarity for MSPs +- shared evidence for IT, security, and audit teams +- traceable decisions through findings, exceptions, accepted risks, follow-ups, and review packs + +The website must not lead with internal product philosophy, architecture, or taxonomy. It should sound like a product marketing manager for a B2B cybersecurity and IT-operations SaaS wrote it: active, direct, technically credible, outcome-oriented, and commercially useful. + +## Visible Copy Rules + +### Required Tone + +Visible public copy must be: + +- active and confident +- technically credible without becoming a whitepaper +- outcome-oriented +- MSP- and enterprise-ready +- specific about Microsoft 365 governance risks +- clear about review, evidence, drift, backup, and recovery context +- careful with compliance, automation, hosting, and provider claims -- **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. +Visible public copy must not be: -## 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`)* +- defensive +- academic +- life-coach style +- internal wiki prose +- Spec Kit language +- architecture-first +- category-philosophy-first +- vague neutral SaaS copy -N/A - no OperationRun start, completion, queue, notification, or deep-link behavior is touched. +### Do Not Use As Visible Marketing Headline Language -## 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`)* +The following concepts and phrases must not be used as primary visible landing-page language: -- **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. +- "Die richtige Produktkategorie zuerst" +- "Für Teams, die Governance gemeinsam tragen" +- "Klare Grenzen statt überzogener Versprechen" +- "Den nächsten Schritt bewusst wählen" +- "provider-extensible managed environment operating model" +- "source-of-truth first operating model" +- "Policy Governance Kategorie" +- "Observe-to-Audit operating model" +- "governance-of-record platform" +- "platform-core seam" +- "provider-owned boundary" +- "Spec Candidate Check" +- "proportionality review" -## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)* +These ideas may inform internal planning, but they must not be the buyer-facing story. -N/A - no operator-facing platform surface is changed. This feature changes public website content surfaces only. +### Preferred Public Language -## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)* +Use direct, market-facing language such as: -N/A - no operator-facing decision surface is added or materially changed. +- "Microsoft 365 Policies unter Kontrolle bringen" +- "Policy-Drift früh erkennen" +- "Konfigurationsstände versioniert sichern" +- "auditfähige Evidence vorbereiten" +- "prüfbare Review Packs" +- "kontrollierte Recovery- und Restore-Vorbereitung" +- "nachvollziehbarer Audit Trail" +- "Microsoft 365 first" +- "Intune als erster starker Policy-Fokus" +- "für weitere Policy-Domänen vorbereitet" -## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)* +## Claim Guardrails -N/A - no operator-facing detail or status surface is added or materially changed. +### Forbidden Or Strongly Restricted Claims -## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)* +Visible website copy must not claim: -N/A - no operator-facing list, detail, queue, audit, config, or report surface is added or materially changed. +- "unter absoluter Kontrolle" +- "Drift in Echtzeit", unless technically proven +- "automatisch reparieren" +- "autonomous remediation" +- "Self-healing" +- "automatic restore" +- "lückenlose Evidenz", unless precisely scoped and proven +- "gerichtsfeste Nachweise" +- "immutable backups", unless real immutability is proven for the public claim context +- "DSGVO-konform" +- "ISO-zertifiziert" +- "NIS2-konform" +- "Google supported" +- "AWS supported" +- "multi-cloud supported" as a live-feature claim -## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)* +### Safe Alternatives -N/A - no operator-facing page or workflow is added or materially refactored. +Use safer phrasing: -## Proportionality Review *(mandatory when structural complexity is introduced)* +- "Policy-Drift früh erkennen" +- "Konfigurationsstände versioniert sichern" +- "auditfähige Evidence vorbereiten" +- "Review Packs für Audits und Kundentermine vorbereiten" +- "Recovery- und Restore-Fragen kontrolliert bewerten" +- "Restore vorbereiten, bevor Änderungen ausgeführt werden" +- "Nachvollziehbarkeit für Changes, Findings und Accepted Risks schaffen" +- "Microsoft 365 first" +- "Intune als erster starker Policy-Fokus" +- "für weitere Policy-Domänen vorbereitet" -- **New source of truth?**: no. -- **New persisted entity/table/artifact?**: no. -- **New abstraction?**: no. -- **New enum/state/reason family?**: no. -- **New cross-domain UI framework/taxonomy?**: no. -- **Current operator problem**: Public evaluators, MSPs, and internal IT teams do not yet get a stable product category or governance operating model from the website. -- **Existing structure is insufficient because**: Specs 400-403 established website foundation and launch safety, but they did not finalize a public positioning architecture for policy governance, provider posture, or safe trust language. -- **Narrowest correct implementation**: Rework public copy, hierarchy, navigation, metadata, terminology, and claim guardrails in `apps/website` only. -- **Ownership cost**: Future public pages and website edits must preserve the same positioning contract, provider posture, and trust-safe wording. -- **Alternative intentionally rejected**: Broad visual redesign and detailed trust/legal expansion were rejected because they would deepen scope before the public narrative is stable. -- **Release truth**: Current-release public positioning truth, with later follow-up work for detailed trust, provider taxonomy, and use-case expansion. +### Trust And Compliance Posture -### Compatibility posture +Trust copy may speak about auditability, review preparation, role-aware evidence, and decision traceability. It must not imply legal certification, regulatory conformity, hosting guarantees, or customer-proof artifacts that are not currently proven. -This feature assumes a pre-production public website content environment. +## Homepage Copy Contract -Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec. +The later homepage implementation must follow this section structure unless a later approved spec narrows it. -Canonical replacement is preferred over preservation. +### 1. Hero -## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)* +**Headline** -- **Test purpose / classification**: Browser/static public website validation. -- **Validation lane(s)**: fast-feedback and public smoke. -- **Why this classification and these lanes are sufficient**: The feature changes public content, metadata, navigation, CTA wording, and claim discipline; website build, smoke, and targeted static claim scans are the narrowest proof that the public output remains correct. -- **New or expanded test families**: none required beyond existing website validation and targeted static content scans. -- **Fixture / helper cost impact**: none. -- **Heavy-family visibility / justification**: none. -- **Special surface test profile**: N/A. -- **Standard-native relief or required special coverage**: Homepage desktop/mobile review, public route smoke, placeholder-link scan, claim scan, and `apps/platform` untouched confirmation are sufficient. -- **Reviewer handoff**: Reviewers must confirm product category clarity, operating-model visibility, provider-safe wording, trust-safe wording, honest navigation/CTAs, and zero `apps/platform` drift. -- **Budget / baseline / trend impact**: none expected. -- **Escalation needed**: none. -- **Active feature PR close-out entry**: Smoke Coverage. -- **Planned validation commands**: `corepack pnpm build:website`; `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`; `grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true`; `git diff --check`; `git status --short -- apps/platform`. +> Microsoft 365 Policies unter Kontrolle bringen. -## User Scenarios & Testing *(mandatory)* +**Subhead** -### User Story 1 - Recognize The Right Product Category (Priority: P1) +> Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen. -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. +**Supporting line** -**Why this priority**: If the product category is wrong, every later page and CTA inherits the wrong expectation. +> Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen. -**Independent Test**: Read the hero and the next section on the homepage without relying on internal product knowledge. +**CTAs** -**Acceptance Scenarios**: +- Demo buchen +- Plattform ansehen -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. +### 2. Problem Section ---- +**Headline** -### User Story 2 - Follow The Governance Operating Model (Priority: P1) +> Wenn Microsoft 365 Policies driften, reicht ein Admin Center nicht aus. -A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail. +**Body** -**Why this priority**: The operating model is the clearest way to explain the product without reducing it to a feature list. +> Tenantial zeigt, was sich geändert hat, welche Konfigurationen abgesichert sind, welche Evidence vorliegt und welche Findings vor dem nächsten Review geklärt werden müssen. -**Independent Test**: Read homepage section titles and core section summaries in order from top to bottom. +### 3. Capability Cards -**Acceptance Scenarios**: +1. **Policy-Drift erkennen** + Abweichungen zwischen erwarteter und tatsächlicher Konfiguration sichtbar machen. -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. +2. **Backups & Versionen behalten** + Policy-Zustände nachvollziehbar sichern und Änderungen historisch vergleichbar machen. ---- +3. **Auditfähige Reviews vorbereiten** + Findings, Evidence, Accepted Risks und Review Packs für Kundentermine und interne Audits bündeln. -### User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2) +4. **Recovery kontrolliert vorbereiten** + Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden. -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. +5. **Provider-Berechtigungen transparent machen** + Microsoft Graph und Provider-Zugriffe verständlich erklären, prüfen und capability-orientiert einordnen. -**Why this priority**: Provider posture and boundary language strongly influence trust, scope expectations, and commercial qualification. +6. **Entscheidungen nachvollziehbar machen** + Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen. -**Independent Test**: Read the homepage and the primary supporting product page without referencing implementation notes. +### 4. Stakeholder Section -**Acceptance Scenarios**: +**Headline** -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. +> Eine belastbare Wahrheit für MSPs, IT und Audit. ---- +**Body** -### User Story 4 - Trust The Site Without False Assurance (Priority: P2) +> Tenantial verbindet technische Konfigurationsdaten mit Evidence, Findings und Reviews - damit Operatoren, Security-Verantwortliche und Auditoren nicht aus Screenshots, Excel-Listen oder Bauchgefühl entscheiden. -A DACH or enterprise evaluator reads the trust teaser, metadata, and CTA surfaces and sees conservative, honest claims. +**Stakeholder cards** -**Why this priority**: The website must invite evaluation without overpromising compliance, hosting, or automation. +- **MSP Operatoren** + Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten. -**Independent Test**: Review hero copy, trust teaser, supporting sections, metadata, navigation links, and CTAs on primary public routes. +- **Enterprise IT** + Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren. -**Acceptance Scenarios**: +- **Security & Audit** + Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen. -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. +### 5. Differentiation Section -### Edge Cases +**Headline** -- 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. +> Gebaut für Governance. Nicht für blinde Automatisierung. -## Requirements *(mandatory)* +**Body** -### Assumptions +> Tenantial ersetzt nicht das Microsoft Admin Center. Es ergänzt es um die Schicht, die Enterprise-Teams im Alltag fehlt: Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen. -- 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. +### 6. Trust Teaser -### Functional Requirements +The trust teaser must stay specific but conservative. It may mention: -#### Scope And Workspace Contracts +- nachvollziehbarer Audit Trail +- Review Packs +- Evidence for reviews and change discussions +- role-aware governance context +- controlled recovery preparation +- security and audit stakeholders working from the same data basis -- **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. +It must not claim DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, or complete evidence coverage. -#### Positioning Contract +### 7. Bottom CTA -- **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. +**Headline** -#### Provider Posture Rules +> Bereit, Microsoft 365 Governance messbar zu machen? -- 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. +**Body** -#### Homepage Content Architecture +> Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt. -- **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. +**Buttons** -#### Supporting Route And Navigation Requirements +- Demo buchen +- Plattform ansehen -- **FR-022**: Supporting public routes such as `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs navigation MUST reinforce the same positioning contract as the homepage. -- **FR-023**: If public navigation labels are adjusted, they MUST use honest labels such as `Platform`, `Use Cases`, `Trust`, `Docs`, `Pricing`, and `Contact`, or equivalent labels that match available route truth. -- **FR-024**: Navigation and CTA surfaces MUST NOT contain `href="#"` placeholders or production-looking links to content that does not exist. -- **FR-025**: If a route does not exist or lacks real content, it MUST be omitted from navigation or represented with an intentionally limited page consistent with current website conventions. -- **FR-026**: `/platform` or the primary supporting product route MUST explain the governance model more deeply than the homepage while remaining clearly public and non-runtime-coupled. +## Metadata And SEO Direction -#### Metadata And Terminology +SEO metadata must sell the same story in compressed form: -- **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. +- primary market: Microsoft 365 governance +- primary outcomes: policy drift visibility, versioned configuration backup, evidence, reviews, controlled recovery preparation, auditability +- target audiences: MSPs, Enterprise IT, security, audit +- first domain: Intune +- future posture: prepared for further policy domains, not live multi-cloud support -#### Claim Guardrails +Example title direction: -- **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. +> Tenantial - Microsoft 365 Policy Governance for MSPs and Enterprise IT -#### Validation And Reporting +Example description direction: -- **FR-037**: The implementation MUST use only scripts that actually exist in the workspace root or `apps/website/package.json`. -- **FR-038**: Validation MUST include a website build check using the existing workspace scripts. -- **FR-039**: Validation MUST include a website smoke or browser check if local preview/test support exists. -- **FR-040**: Validation MUST include a static scan for placeholder links and forbidden public claims in website source and committed public output when applicable. -- **FR-041**: Completion reporting MUST document changed public surfaces, commands run, pass/fail results, deferred follow-up work, and confirmation that `apps/platform` remained untouched. - -## Success Criteria *(mandatory)* - -- **SC-001**: A reviewer can describe Tenantial from the homepage hero and next section as a policy governance platform for Microsoft 365 without calling it an Intune-only or backup-only tool. -- **SC-002**: Homepage copy presents a clear six-step governance narrative from observed state to audit trail that a reviewer can list in order from the rendered page. -- **SC-003**: Intune appears only as one example domain in homepage/supporting copy and does not appear as the primary product category in visible headings or metadata. -- **SC-004**: Provider-extensible language appears without any unverified live-support claim for Google, AWS, or other non-Microsoft providers. -- **SC-005**: Trust-related public copy contains zero unverified claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, certifications, or autonomous remediation/recovery. -- **SC-006**: Navigation and CTA surfaces contain zero placeholder destinations, and every visible CTA leads to a concrete next step or real route. -- **SC-007**: MSP/internal IT/governance-evaluator messaging is visible on the public site without reducing the target audience to endpoint administrators alone. -- **SC-008**: Homepage metadata and primary supporting routes consistently reinforce policy-governance positioning, Microsoft 365 first focus, and evidence/review language. -- **SC-009**: No `apps/platform` files are modified as part of the feature. -- **SC-010**: Public website validation completes successfully, or any failure is explicitly documented as pre-existing. +> Detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and controlled recovery. + +## Requirements + +### Scope Requirements + +- **FR-001**: The implementation MAY modify the 404 spec artifacts and `apps/website` source or website-smoke-test files required for the homepage sales-copy rewrite. +- **FR-002**: Website implementation scope MUST remain `apps/website` only. +- **FR-003**: This spec MUST explicitly forbid `apps/platform` changes. +- **FR-004**: This implementation MUST not introduce backend runtime, database, platform, provider, dependency, or build-output changes. + +### Sales-Copy Requirements + +- **FR-005**: Visible public copy MUST sell business outcomes rather than internal architecture. +- **FR-006**: The homepage hero MUST lead with Microsoft 365 policy control, not product-category philosophy. +- **FR-007**: The hero and first supporting section MUST mention policy drift, versioned configuration backups, evidence, reviews, changes, and recovery context. +- **FR-008**: Microsoft 365 MUST be the first public market. +- **FR-009**: Intune MAY appear as the first strong policy focus, but MUST NOT be treated as the full product boundary. +- **FR-010**: Provider extensibility MUST be secondary and MUST NOT become hero philosophy. +- **FR-011**: Google, AWS, and multi-cloud support MUST NOT appear as live capabilities unless separately proven. +- **FR-012**: Public copy MUST address MSPs, Enterprise IT, Security, and Audit as first-class audiences. +- **FR-013**: Public copy MUST present recovery and restore as controlled preparation and evaluation, not blind automation. +- **FR-014**: Public copy MUST avoid the forbidden and strongly restricted claims listed in this spec. +- **FR-015**: Public copy MUST avoid internal governance, architecture, and Spec Kit terms as visible buyer-facing language. + +### Homepage Structure Requirements + +- **FR-016**: The later homepage implementation MUST include a hero, problem section, capability cards, stakeholder/persona section, differentiation section, trust teaser, and bottom CTA. +- **FR-017**: Capability cards MUST be outcome-led and cover drift, backups/versioning, reviews/evidence, recovery preparation, permissions/provider access, and decision traceability. +- **FR-018**: Stakeholder copy MUST explicitly cover MSP operators, Enterprise IT, and Security/Audit. +- **FR-019**: Differentiation copy MUST explain that Tenantial complements Microsoft Admin Center rather than replacing it. +- **FR-020**: Bottom CTA copy MUST invite a concrete demo or platform exploration without overclaiming maturity or automation. + +### Validation Requirements For Later Implementation + +- **FR-021**: Later implementation MUST include static scans for forbidden claims and old internal/defensive phrases. +- **FR-022**: Later implementation MUST include browser smoke review for desktop and mobile homepage readability, CTA visibility, and no visible copy overlap. +- **FR-023**: Later implementation MUST confirm no `apps/platform` files changed. +- **FR-024**: Later implementation MUST report whether old 404 copy was replaced or only supplemented. + +## Testing / Lane / Runtime Impact + +- **Current change classification**: Browser/static website copy implementation. +- **Runtime impact**: Static website source and website smoke-test expectations only. No backend, database, provider, platform, dependency, or build-output change is introduced. +- **Affected validation lane for this implementation**: Website build, static forbidden-claim scan, desktop/mobile browser smoke, CTA/link checks, metadata review, and explicit confirmation that `apps/platform` remains untouched. +- **Validation for this implementation**: `corepack pnpm build:website`, targeted static claim scan, browser review on `http://127.0.0.1:4321/`, `git diff --check`, `git diff --name-only`, and `git status --short -- apps/platform`. +- **Later implementation classification**: N/A for homepage sales copy; follow-up specs may extend supporting routes. +- **Later implementation validation**: N/A. +- **Pest/Laravel/Filament/Sail coverage**: N/A for this spec update. Later website-copy implementation should not add backend or platform test lanes unless it actually changes backend/platform behavior. +- **Fixture/helper/runtime cost**: None for this spec update. +- **Escalation**: If later implementation requires platform, provider, auth, database, or runtime changes, that work must be split into a separate spec. + +## User Scenarios And Acceptance Criteria + +### User Story 1 - MSP Buyer Understands The Operational Risk + +An MSP operator or owner reads the homepage and understands that Tenantial helps control Microsoft 365 policy drift, versioning, evidence, reviews, and recovery context across customer environments. + +**Acceptance Criteria** + +1. Given the hero and problem section, when an MSP buyer summarizes the product, then they mention Microsoft 365 policy control and drift visibility rather than an internal governance model. +2. Given the stakeholder cards, when an MSP buyer scans the page, then multi-customer or multi-tenant review preparation is visible without implying unsupported providers. + +### User Story 2 - Enterprise IT Sees Recovery And Audit Context + +An IT leader reads the page and understands that Tenantial documents changes, configuration history, drift, and recovery risk before action. + +**Acceptance Criteria** + +1. Given the capability cards, when Enterprise IT evaluates the page, then versioned backups, historical comparison, and controlled recovery preparation are explicit. +2. Given the differentiation section, when Enterprise IT compares Tenantial to Microsoft Admin Center, then Tenantial is clearly positioned as an evidence, versioning, and review layer. + +### User Story 3 - Security And Audit See Review-Ready Evidence + +Security and audit stakeholders see that Tenantial helps transform configuration data, findings, accepted risks, and follow-ups into review-ready material. + +**Acceptance Criteria** + +1. Given the stakeholder section, when Security or Audit scans the page, then evidence, findings, accepted risks, and review packs are visible. +2. Given the trust teaser, when a compliance-sensitive evaluator reviews the copy, then it avoids unsupported legal, certification, hosting, or complete-evidence claims. + +### User Story 4 - Implementation Agent Has Concrete Copy Direction + +A later implementation agent can convert this spec into website copy without reintroducing internal architecture language. + +**Acceptance Criteria** + +1. Given this spec, when the agent drafts homepage copy, then each homepage section has concrete example text and claim guardrails. +2. Given this spec, when the agent validates the implementation, then static scans can target forbidden phrases, overclaims, and old defensive copy. + +## Success Criteria + +- **SC-001**: Spec 404 is clearly titled as a Public Website Sales Copy & Positioning Rewrite. +- **SC-002**: The spec sells business outcomes instead of internal architecture. +- **SC-003**: Concrete visible homepage copy examples are present for hero, problem, capability cards, stakeholders, differentiation, and bottom CTA. +- **SC-004**: Microsoft 365 is the first public market. +- **SC-005**: Intune is allowed as a first strong policy focus, not as the product boundary. +- **SC-006**: Provider extensibility is secondary and safely bounded. +- **SC-007**: The spec bans unsupported compliance, automation, provider, hosting, and evidence-hardening claims. +- **SC-008**: Acceptance criteria prove B2B sales-copy quality for MSP, Enterprise IT, Security, and Audit audiences. +- **SC-009**: The spec states that later implementation is `apps/website` relevant only. +- **SC-010**: The implementation changes only approved 404 spec artifacts and minimal `apps/website` source or website-smoke-test files; it changes no `apps/platform`, root workspace contracts, dependencies, build output, or backend runtime files. + +## Follow-Up Specs + +Potential follow-up specs should stay separate from this positioning rewrite: + +- **405 Trust**: detailed trust, security, hosting, legal, and evidence substantiation once proof exists +- **406 Provider Taxonomy**: current-versus-planned provider and policy-domain vocabulary if public provider expansion becomes real +- **407 Use Cases**: dedicated MSP, Enterprise IT, Security, Audit, and Recovery use-case pages diff --git a/specs/404-public-content-messaging/tasks.md b/specs/404-public-content-messaging/tasks.md index b277b8d7..cb27f627 100644 --- a/specs/404-public-content-messaging/tasks.md +++ b/specs/404-public-content-messaging/tasks.md @@ -1,184 +1,84 @@ -# Tasks: Public Website Positioning & Content Architecture +# Tasks: Public Website Sales Copy & Positioning Rewrite -**Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/` -**Prerequisites**: [plan.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md), [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md), [research.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/research.md), [data-model.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/data-model.md), [public-content-contract.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md), [quickstart.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md) +**Input**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md` and `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md` -**Tests**: 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. +**Scope**: This task list covers the Spec 404 correction plus the follow-up homepage implementation approved by the user. Do not edit `apps/platform`, root workspace contracts, build output, dependencies, or backend runtime files. -## Phase 1: Setup +**Validation lane**: Browser/static website validation plus spec/documentation review. -**Purpose**: Establish the exact website-only scope and current public-content baseline before editing. +## Tasks -- [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` +- [X] **T001: Repo-Zustand und Spec-404-Pfad verifizieren** + Run `git status --short --branch` and locate 404 with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`. Confirm whether there is exactly one 404 folder. If multiple exist, choose the Public Website Sales Copy & Positioning Spec based on branch, title, and content, and document the decision in the plan or final report. ---- +- [X] **T002: Bestehende 404-Artefakte lesen und Quark-/Architektur-Copy inventarisieren** + Read `spec.md`, `plan.md`, and `tasks.md` fully. Identify internal, defensive, academic, architecture-heavy, category-philosophy, "operating model", provider-boundary, and source-of-truth wording that should not drive visible website copy. -## Phase 2: Foundational +- [X] **T003: Sichtbare Copy-Prinzipien in `spec.md` ersetzen** + Rewrite the spec so visible public copy must sell business outcomes: Microsoft 365 policy control, early drift detection, versioned configuration backups, evidence, reviews, recovery context, auditability, and shared truth for MSPs, IT, Security, and Audit. -**Purpose**: Normalize shared positioning, metadata, and validation rules before user-story work. +- [X] **T004: Hero-Copy-Beispiele auf B2B-Sales-Ton umstellen** + Add concrete hero examples: "Microsoft 365 Policies unter Kontrolle bringen.", the required subhead about MSPs and Enterprise IT, the supporting line with Microsoft 365 Governance and Intune as first strong policy focus, and CTAs "Demo buchen" and "Plattform ansehen". -**Critical**: Complete this phase before user-story implementation. +- [X] **T005: Alte defensive Section-Namen ersetzen** + Remove the old public-story direction around "Die richtige Produktkategorie zuerst", "Für Teams, die Governance gemeinsam tragen", "Klare Grenzen statt überzogener Versprechen", and "Den nächsten Schritt bewusst wählen". Replace them with problem, capability, stakeholder, differentiation, trust teaser, and bottom CTA sections. -- [x] T006 Define the 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` +- [X] **T006: Capability- und Outcome-Sprache definieren** + Define capability cards for policy drift, backups/versioning, audit-ready reviews, controlled recovery preparation, provider permissions, and traceable decisions. Each card must state an outcome rather than an internal product module. -**Checkpoint**: Shared positioning rules, metadata defaults, and smoke guardrails are ready for independently testable story work. +- [X] **T007: MSP-/Enterprise-/Security-/Audit-Personas definieren** + Add stakeholder copy for MSP Operatoren, Enterprise IT, and Security & Audit. Make the shared data basis explicit: evidence, findings, reviews, accepted risks, and follow-ups instead of screenshots, Excel lists, or gut feel. ---- +- [X] **T008: Provider-/Intune-/Microsoft-365-Claim-Regeln schärfen** + Make Microsoft 365 the first public market. Allow Intune as the first strong policy focus and example domain. Treat provider extensibility as secondary. Forbid Google, AWS, and multi-cloud as live claims unless separately proven by repo/product truth. -## Phase 3: User Story 1 - Recognize The Right Product Category (Priority: P1) MVP +- [X] **T009: Trust-/DSGVO-/Hosting-Claim-Regeln belassen, aber nicht als sichtbare Website-Story formulieren** + Keep strict trust guardrails for DSGVO, ISO, NIS2, hosting, legal-proof evidence, complete evidence, automatic remediation, and automatic restore. Allow only safe wording around auditability, review packs, role-aware evidence, controlled recovery preparation, and decision traceability. -**Goal**: A first-time visitor opens `/` and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility. +- [X] **T010: `plan.md` an neue Copy-Umsetzungslogik anpassen** + Rewrite the plan as a website-copy refactoring plan. It must include repo verification, current copy inventory, identification of internal/defensive copy, hero, problem/pain, capability cards, stakeholder/persona section, differentiation, trust teaser, bottom CTA, SEO/metadata direction, claim guardrails/static search terms, browser smoke requirements for later implementation, and no runtime changes in this spec update. -**Independent Test**: Read the 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: `tasks.md` konsistent zu `spec.md` und `plan.md` machen** + Ensure the tasks are numbered, checkable, and aligned with the approved scope transition from spec-only correction to website implementation. Keep platform, dependency, backend runtime, and build-output changes out of scope. -- [x] T011 [US1] Rewrite homepage hero 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 +- [X] **T012: Final prüfen, dass nur erlaubte Website- und keine `apps/platform`-Dateien geändert wurden** + Run `git status --short -- apps/website apps/platform` and `git diff --name-only`. Expected tracked changes are limited to `specs/404-public-content-messaging/` plus minimal `apps/website` source or smoke-test files. -**Checkpoint**: User Story 1 is independently shippable as the MVP. +- [X] **T013: Final prüfen, dass 404 nicht mehr wie interne Architektur-/Philosophie-Copy klingt** + Review the final artifacts for visible-copy direction. They must read like a B2B cybersecurity and IT-operations sales-copy brief: direct, confident, technically credible, outcome-led, MSP-ready, enterprise-ready, and free from internal Spec Kit or architecture-first language as the public story. ---- +- [X] **T014: Abschlussbericht mit Replacement-Status erstellen** + Final report must list changed files, summarize the sales-copy correction, explicitly confirm which `apps/website` files changed and that no `apps/platform` files changed, state whether old 404 copy passages were replaced or only supplemented, and name relevant follow-up specs such as 405 Trust, 406 Provider Taxonomy, and 407 Use Cases. -## Phase 4: User Story 2 - Follow The Governance Operating Model (Priority: P1) +- [X] **T015: Homepage-Copy in `apps/website` umsetzen** + Update the homepage source copy so the rendered first viewport uses the approved Microsoft 365 policy-control headline, subhead, supporting line, and CTAs. -**Goal**: A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail. +- [X] **T016: Capability-Cards auf Outcome-Sprache umstellen** + Replace the old capability language with drift, backups/versioning, audit-ready reviews, controlled recovery, provider permissions, and traceable decisions. -**Independent Test**: 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] **T017: Stakeholder-, Differentiation- und Trust-Teaser-Sections umsetzen** + Render MSP, Enterprise IT, Security/Audit, differentiation, trust teaser, and bottom CTA sections from the approved sales-copy structure. -- [x] 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` +- [X] **T018: Metadata und Platform-Wording von interner Architektur-Copy befreien** + Update public metadata and obvious supporting route copy to avoid governance-of-record, source-of-truth, and provider-extensible hero language. -**Checkpoint**: User Story 2 is independently shippable once the homepage operating model reads coherently. +- [X] **T019: Website build, static scan und Browser-Review ausführen** + Run the website build, forbidden-claim scan, browser review for the homepage, and existing website smoke suite with updated copy expectations. ---- +- [X] **T020: Final prüfen, dass keine `apps/platform`-, Dependency- oder Build-Output-Dateien geändert wurden** + Confirm changed files are limited to approved spec artifacts and minimal `apps/website` source or smoke-test files. -## Phase 5: User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2) +## Definition Of Done -**Goal**: A security-conscious evaluator can see Microsoft 365 as the current focus, provider-extensible direction as future-safe, and clear boundaries about what the product is not. - -**Independent Test**: Read the homepage and `/platform`; current Microsoft focus, future provider direction, and non-admin-center/non-helpdesk boundaries are all explicit without live-support claims for other providers. - -- [x] T023 [US3] Rewrite the Microsoft 365 first section and provider/domain labeling rules in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` -- [x] T024 [US3] Update `/platform` copy to separate current Microsoft focus from future provider direction and to reinforce product boundaries in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PlatformPage.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` -- [x] T025 [P] [US3] Align public docs provider-boundary explanations with the same current-versus-future posture in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/platform/evidence-review.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/intro.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/intro.mdx` -- [x] T026 [P] [US3] Review navigation and footer labels so route exposure stays honest for platform, docs, trust, pricing, and contact surfaces in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro` -- [x] T027 [US3] Validate User Story 3 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/index.astro` - -**Checkpoint**: User Story 3 is independently shippable once provider posture and boundaries are clear and safe. - ---- - -## Phase 6: User Story 4 - Trust The Site Without False Assurance (Priority: P2) - -**Goal**: A DACH or enterprise evaluator reads the trust teaser, metadata, navigation, and CTA surfaces and sees conservative, honest claims. - -**Independent Test**: Review `/trust`, `/pricing`, `/contact`, homepage trust surfaces, and metadata; there are no false assurance, placeholder-link, or autonomous-remediation claims. - -- [x] T028 [US4] Rewrite the trust teaser, trust page copy, and trust-adjacent CTA language for conservative claims in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` -- [x] T029 [US4] Update homepage, platform, pricing, and trust metadata to remove false assurance and preserve policy-governance wording in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/constants.ts` -- [x] T030 [P] [US4] Review conservative trust, contact-led evaluation, and legal-adjacent rendering in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/PricingPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/ContactPage.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/LegalPage.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TextPage.astro` -- [x] T031 [P] [US4] Update docs and checklist content to avoid false provider/compliance/automation assurance in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/first-project-checklist.mdx`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/getting-started.mdx`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/en/guides/first-project-checklist.mdx` -- [x] T032 [US4] Update smoke and interaction expectations for trust-safe links, metadata, and placeholder-free CTAs in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts` -- [x] T033 [US4] Validate User Story 4 against `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` and `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/contracts/public-content-contract.md` by reviewing `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/trust.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/pricing.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/contact.astro` - -**Checkpoint**: User Story 4 is independently shippable once trust-sensitive surfaces remain honest and placeholder-free. - ---- - -## Final Phase: Polish And Cross-Cutting Concerns - -**Purpose**: Complete localization parity, route exposure review, browser/static validation, and implementation handoff. - -- [x] T034 [P] Review German default and English mirror parity for all changed marketing routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en` -- [x] T035 [P] Reconcile exposed docs/navigation and redirect behavior with the updated positioning contract in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/product.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/products/index.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/product.astro` -- [x] T036 [P] Review dominant next-step CTA intent across the homepage, platform, pricing, trust, contact, footer, and exposed docs routes in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro`, and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs` -- [x] T037 [P] Run the targeted static claim scan from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` against `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public` -- [x] T038 Run website build validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `corepack pnpm build:website` -- [x] T039 Run public smoke validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke` -- [x] T040 Run whitespace validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git diff --check` -- [x] T041 Run scope validation from `/Users/ahmeddarrazi/Documents/projects/wt-website` with `git status --short -- apps/platform` -- [x] T042 Perform the manual desktop/mobile browser review described in `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md` for `/`, `/platform`, `/pricing`, `/trust`, `/contact`, and exposed docs routes -- [x] T043 Prepare the final implementation handoff with changed surfaces, provider/trust guardrail decisions, validation results, follow-up specs, and `apps/platform` untouched confirmation from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/plan.md` - ---- - -## Dependencies - -**Phase Dependencies** - -Setup must complete before Foundational. Foundational must complete before any user story. User Stories 1 and 2 are the P1 path and should land before provider/trust refinement. User Story 3 depends on the shared category and operating-model vocabulary from earlier phases. User Story 4 depends on the shared provider, CTA, metadata, and navigation decisions so trust-safe wording does not drift from the rest of the site. - -**User Story Dependencies** - -- **US1**: Depends on Phase 2 only. -- **US2**: Depends on Phase 2 and benefits from US1 category vocabulary. -- **US3**: Depends on Phase 2 and benefits from US1-US2 shared narrative. -- **US4**: Depends on Phase 2 and benefits from US1-US3 provider, metadata, and navigation decisions. - -**MVP Scope** - -Complete Phase 1, Phase 2, and Phase 3 (US1) for the smallest independently reviewable increment. Phase 4 (US2) is the immediate next increment once the product category is fixed. - ---- - -## Parallel Execution Examples - -**After Phase 2** - -```text -US1 supporting-surface work can run in parallel after the main homepage copy settles: -- T015 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/HomePage.astro -- T016 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/faqs.json - -US2 operating-model support work can run in parallel once the sequence is defined: -- T020 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/features.json -- T021 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/welcome-to-docs.mdx and related intro mirrors -``` - -**Provider And Trust** - -```text -US3 and US4 can progress on different files once shared vocabulary is stable: -- T025 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/platform/evidence-review.mdx and related mirrors -- T030 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro, PricingPage.astro, ContactPage.astro, LegalPage.astro, and TextPage.astro -- T031 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs/guides/getting-started.mdx and related checklist mirrors -``` - -**Final Validation** - -```text -Cross-cutting closeout can run in parallel before the final command sequence: -- T034 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en -- T035 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/astro.config.mjs and redirect route files -- T036 in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/Navbar.astro, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/sections/navbar&footer/FooterSection.astro, and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs -- T037 from /Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/quickstart.md against /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public -``` - ---- - -## Implementation Strategy - -1. Finish setup and foundational vocabulary/metadata/smoke guardrails before page-level rewrites. -2. Ship the MVP by fixing homepage category framing in US1. -3. Layer the operating-model narrative in US2 before broadening provider posture in US3. -4. Complete trust-safe metadata, docs, and CTA coverage in US4 after the shared category and provider story settle. -5. Finish with localization parity, route-exposure review, static claim scans, build, smoke, manual browser review, and scope validation. - -## Test Governance Notes - -The declared test purpose is Browser/static website. The affected validation lanes are website build, Playwright public smoke, targeted static claim scans, manual browser review, whitespace validation, and `apps/platform` scope validation. No Pest, Laravel, Filament, Livewire, database, provider, workspace, membership, session, queue, Sail, or heavy-governance setup is introduced. No dedicated follow-up spec is needed unless repeated public-website release validation becomes a recurring governance problem. +- `spec.md`, `plan.md`, and `tasks.md` are consistent. +- Spec 404 is titled or clearly framed as "Public Website Sales Copy & Positioning Rewrite". +- The spec sells business outcomes rather than internal architecture. +- Concrete visible copy examples are present. +- Microsoft 365 is clearly the first public market. +- Intune is an example/start domain, not the product boundary. +- Provider extensibility is secondary and not overclaimed. +- Website implementation was performed only in approved `apps/website` source and website-smoke-test files. +- No `apps/platform` changes were performed. +- No root/workspace contracts were changed. +- Git diff contains only approved 404 spec artifacts plus minimal `apps/website` source and website-smoke-test files, aside from any pre-existing unrelated untracked files. +- Final report states whether old 404 copy was replaced or only supplemented.