spec: add provider policy domain public taxonomy

2026-05-26 14:11:15 +02:00 · 2026-05-26 14:11:15 +02:00 · eceb5ccc18
commit eceb5ccc18
parent 714b910734
8 changed files with 1141 additions and 0 deletions
--- a/Agents.md
+++ b/Agents.md
@ -948,6 +948,8 @@ ## Active Technologies
 - No new technology; reuses TypeScript 6.0.3, Astro 6.3.3, Node.js >=20.0.0, pnpm 10.33.0, Starlight, Tailwind CSS v4, Preline, Lenis, GSAP, Sharp, and Playwright for static website content, docs content, route metadata, and generated build output only; no database or product persistence. (404-public-content-messaging)
 - TypeScript 6, Astro 6, Node.js `>=20.0.0` + Astro, Tailwind CSS v4, Starlight, Playwrigh (405-dach-trust-datenschutz-security-website-surface)
 - N/A - static Astro pages and centralized locale copy in TypeScrip (405-dach-trust-datenschutz-security-website-surface)
+- TypeScript 6.0.3, Astro 6.3.3, Tailwind CSS 4.3.0 + Astro, `@astrojs/check`, `@astrojs/sitemap`, Tailwind CSS v4, Playwright smoke tests (406-provider-policy-domain-public-taxonomy)
+- N/A - static public website content only; no runtime persistence (406-provider-policy-domain-public-taxonomy)

 ## Recent Changes
 - 066-rbac-ui-enforcement-helper-v2-session-1769732329: Planned UiEnforcement v2 (spec + plan + design artifacts)
--- a/specs/406-provider-policy-domain-public-taxonomy/checklists/requirements.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/checklists/requirements.md
@ -0,0 +1,36 @@
+# Specification Quality Checklist: Provider & Policy Domain Public Taxonomy
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-05-26
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Validation iteration 1 passed.
+- No clarification markers remain.
+- The spec keeps runtime and implementation mechanics out of scope while retaining user-facing route and public-website scope constraints needed for planning.
--- a/specs/406-provider-policy-domain-public-taxonomy/contracts/public-taxonomy-routes.openapi.yaml
+++ b/specs/406-provider-policy-domain-public-taxonomy/contracts/public-taxonomy-routes.openapi.yaml
@ -0,0 +1,167 @@
+openapi: 3.1.0
+info:
+  title: Tenantial Public Provider and Policy Domain Taxonomy Routes
+  version: 0.1.0
+  description: >
+    Static public website route contract for Spec 406. These routes return
+    HTML pages only and do not expose platform runtime APIs, tenant data, or
+    provider integration capabilities.
+servers:
+  - url: http://127.0.0.1:4321
+    description: Local website preview using WEBSITE_PORT default
+paths:
+  /platform/domains:
+    get:
+      summary: German public provider and policy domain taxonomy page
+      operationId: getGermanProviderPolicyDomainTaxonomy
+      tags:
+        - Public Website
+      responses:
+        "200":
+          description: Static HTML taxonomy page
+          content:
+            text/html:
+              schema:
+                type: string
+              examples:
+                page:
+                  summary: Required visible content
+                  value: "Microsoft 365 zuerst. Gebaut fuer Policy-Domaenen ueber Intune hinaus."
+        "404":
+          description: Route not configured
+      x-content-requirements:
+        locale: de
+        mustInclude:
+          - Microsoft 365 first-market positioning in German site language
+          - Intune as first strong policy focus, not full product category
+          - Status legend with five public status meanings
+          - Microsoft 365 domain matrix
+          - Future provider direction section
+          - Buyer-facing MSP and enterprise IT section
+        mustNotInclude:
+          - href="#"
+          - Google supported
+          - AWS supported
+          - Okta supported
+          - multi-cloud supported
+          - all cloud providers
+          - every SaaS platform
+          - provider-agnostic restore
+          - universal policy governance
+          - automatic remediation
+          - automatic restore
+          - self-healing
+          - real-time drift
+          - immutable backups
+          - gerichtsfeste Nachweise
+          - lueckenlose Evidenz
+  /en/platform/domains:
+    get:
+      summary: English public provider and policy domain taxonomy page
+      operationId: getEnglishProviderPolicyDomainTaxonomy
+      tags:
+        - Public Website
+      responses:
+        "200":
+          description: Static HTML taxonomy page
+          content:
+            text/html:
+              schema:
+                type: string
+              examples:
+                page:
+                  summary: Required visible content
+                  value: "Microsoft 365 first. Built for policy domains beyond Intune."
+        "404":
+          description: Route not configured
+      x-content-requirements:
+        locale: en
+        mustInclude:
+          - Microsoft 365 first-market positioning
+          - Intune as first strong policy focus, not full product category
+          - Status legend with five public status meanings
+          - Microsoft 365 domain matrix
+          - Future provider direction section
+          - Buyer-facing MSP and enterprise IT section
+        mustNotInclude:
+          - href="#"
+          - Google supported
+          - AWS supported
+          - Okta supported
+          - multi-cloud supported
+          - all cloud providers
+          - every SaaS platform
+          - provider-agnostic restore
+          - universal policy governance
+          - automatic remediation
+          - automatic restore
+          - self-healing
+          - real-time drift
+          - immutable backups
+components:
+  schemas:
+    PublicStatusLabel:
+      type: object
+      required:
+        - key
+        - label
+        - description
+      properties:
+        key:
+          type: string
+          enum:
+            - current-focus
+            - planned-domain
+            - architecture-direction
+            - not-currently-available
+            - not-claimed
+        label:
+          type: string
+        description:
+          type: string
+    PolicyDomainRow:
+      type: object
+      required:
+        - domain
+        - provider
+        - statusKey
+        - governanceValue
+        - tenantialHelpsWith
+        - claimBoundary
+      properties:
+        domain:
+          type: string
+        provider:
+          type: string
+        statusKey:
+          $ref: "#/components/schemas/PublicStatusKey"
+        governanceValue:
+          type: string
+        tenantialHelpsWith:
+          type: string
+        claimBoundary:
+          type: string
+    FutureProviderRow:
+      type: object
+      required:
+        - provider
+        - statusKey
+        - safeWording
+        - claimBoundary
+      properties:
+        provider:
+          type: string
+        statusKey:
+          $ref: "#/components/schemas/PublicStatusKey"
+        safeWording:
+          type: string
+        claimBoundary:
+          type: string
+    PublicStatusKey:
+      type: string
+      enum:
+        - current-focus
+        - planned-domain
+        - architecture-direction
+        - not-currently-available
+        - not-claimed
--- a/specs/406-provider-policy-domain-public-taxonomy/data-model.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/data-model.md
@ -0,0 +1,162 @@
+# Data Model: Provider & Policy Domain Public Taxonomy
+
+This feature has no persisted data model. The entities below are website content structures used to render a public taxonomy route. They must remain static/page-local content unless a later spec explicitly introduces runtime provider capability truth.
+
+## Taxonomy Page
+
+**Represents**: The localized public page or substantial platform-page section explaining providers, policy domains, status labels, future-provider direction, buyer meaning, and CTA destinations.
+
+**Fields**:
+
+- `locale`: `de` or `en`
+- `pageTitle`: localized metadata title
+- `metaDescription`: localized metadata description
+- `heroEyebrow`: short positioning label
+- `heroTitle`: main H1
+- `heroSubtitle`: body copy stating Microsoft 365 first, Intune as first strong domain, and future extensibility without live-support overclaiming
+- `primaryCta`: optional CTA with real destination
+- `secondaryCta`: optional CTA with real destination
+- `statusLegend`: list of Public Status Labels
+- `domainMatrix`: list of Policy Domain Rows
+- `futureProviders`: list of Future Provider Rows
+- `buyerCards`: list of Buyer Meaning Cards
+
+**Validation rules**:
+
+- `pageTitle` and `metaDescription` must not claim Google/AWS/Okta live support.
+- CTA destinations must be real routes, real anchors, or real contact destinations.
+- The page must contain status legend, Microsoft 365 domain matrix, future-provider section, and buyer-facing section.
+- The page must not contain `href="#"`.
+
+## Public Status Label
+
+**Represents**: A website-only status label used to distinguish current focus, planned direction, architecture direction, unavailable areas, and non-claims.
+
+**Fields**:
+
+- `key`: stable content key such as `current-focus`, `planned-domain`, `architecture-direction`, `not-currently-available`, or `not-claimed`
+- `label`: localized visible label
+- `description`: localized explanation of what the label means
+
+**Validation rules**:
+
+- Must include exactly the five public meanings required by the spec, with localized labels.
+- Must be visible on the taxonomy surface.
+- Must not be reused as runtime product state, provider capability state, or persisted status.
+
+**State transitions**: None. These are static public labels. Any future change from planned to current requires repo/product truth verification during implementation or a later spec.
+
+## Policy Domain Row
+
+**Represents**: One Microsoft 365 policy/governance domain presented to buyers.
+
+**Fields**:
+
+- `domain`: visible domain name
+- `provider`: visible provider or provider family
+- `statusKey`: reference to Public Status Label
+- `governanceValue`: buyer-facing reason this domain matters
+- `tenantialHelpsWith`: short description of Tenantial's role
+- `claimBoundary`: explicit limit on what is and is not claimed
+
+**Required rows**:
+
+- Intune / Endpoint Policies
+- Entra / Identity & Access
+- Conditional Access & Sign-in Controls
+- SharePoint / OneDrive Sharing
+- Enterprise Apps & Service Principals
+- Security Posture Evidence
+- Provider Permissions & Readiness
+- Review Packs & Governance Evidence
+
+**Validation rules**:
+
+- Every row must include all fields.
+- Intune / Endpoint Policies may be `current-focus` only if repo/product truth supports it.
+- Unverified Microsoft-adjacent domains default to `planned-domain`.
+- Security Posture Evidence must be framed as evidence/signal coverage, not remediation ownership.
+- Provider Permissions & Readiness must be framed as provider-specific requirements, not universal platform truth.
+- Claim boundaries must avoid unsupported automation, restore, or provider-support claims.
+
+**State transitions**: None in this feature. Status wording can change only when implementation verifies current product truth or a later spec updates public claim status.
+
+## Future Provider Row
+
+**Represents**: One non-Microsoft provider or provider family discussed as future architecture direction.
+
+**Fields**:
+
+- `provider`: visible provider or provider family name
+- `statusKey`: normally `architecture-direction`
+- `safeWording`: cautious statement that avoids live availability claims
+- `claimBoundary`: explicit statement that no current support is claimed unless verified
+
+**Required rows**:
+
+- Google Workspace / Google Cloud
+- AWS
+- Okta / Identity Providers
+- Other SaaS Policy Systems
+
+**Validation rules**:
+
+- Default status is `architecture-direction`.
+- Must not use official logos, fake badges, or partner-like visuals.
+- Must not use `supported`, `available today`, `works with`, or equivalent live-support language unless verified.
+
+**State transitions**: None in this feature.
+
+## Buyer Meaning Card
+
+**Represents**: A buyer-oriented explanation of what the taxonomy means for MSPs and enterprise IT.
+
+**Fields**:
+
+- `title`: short buyer-facing label
+- `content`: localized explanation
+
+**Required cards**:
+
+- Start concrete
+- Scale governance
+- Avoid tool sprawl
+- Stay honest
+
+**Validation rules**:
+
+- Must describe buyer value, not internal architecture.
+- Must not duplicate the full taxonomy matrix.
+- Must not introduce unsupported provider or compliance claims.
+
+## Navigation Link
+
+**Represents**: A public website link to the taxonomy route from homepage, platform page, nav, or footer.
+
+**Fields**:
+
+- `label`: localized visible link label
+- `href`: localized route or anchor
+- `placement`: homepage, platform page, navigation, footer, or CTA
+
+**Validation rules**:
+
+- `href` must resolve to a real page, real section, or real contact destination.
+- No placeholder links.
+- Navigation/footer placement must follow existing website IA conventions and avoid top-level clutter.
+
+## Metadata Contract
+
+**Represents**: The taxonomy page title and description.
+
+**Fields**:
+
+- `title`
+- `description`
+- `canonicalPath`
+
+**Validation rules**:
+
+- Must mention policy domains/provider direction safely.
+- May mention Microsoft 365, Intune, Entra, Conditional Access, SharePoint, Enterprise Apps, and future provider direction.
+- Must not claim Google Workspace support, AWS support, Okta support, multi-cloud support, or universal policy governance.
--- a/specs/406-provider-policy-domain-public-taxonomy/plan.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/plan.md
@ -0,0 +1,184 @@
+# Implementation Plan: Provider & Policy Domain Public Taxonomy
+
+**Branch**: `406-provider-policy-domain-public-taxonomy` | **Date**: 2026-05-26 | **Spec**: [/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/spec.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/spec.md)  
+**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/spec.md`
+
+## Summary
+
+Create a website-only public taxonomy surface that explains Tenantial's provider and policy-domain posture: Microsoft 365 first, Intune as the first strong policy focus, adjacent Microsoft 365 domains safely labeled by status, and Google/AWS/Okta framed only as future architecture direction unless verified. The implementation approach is to add a localized Astro public route at `/platform/domains` and `/en/platform/domains`, reuse the existing public website shell, content data, CTA, navigation, footer, metadata, and Playwright smoke-test patterns, and keep all platform runtime files untouched.
+
+## Technical Context
+
+**Language/Version**: TypeScript 6.0.3, Astro 6.3.3, Tailwind CSS 4.3.0  
+**Primary Dependencies**: Astro, `@astrojs/check`, `@astrojs/sitemap`, Tailwind CSS v4, Playwright smoke tests  
+**Storage**: N/A - static public website content only; no runtime persistence  
+**Testing**: `corepack pnpm --filter @tenantatlas/website build` and `corepack pnpm --filter @tenantatlas/website test`; optional `format:check` if formatting scope is touched  
+**Validation Lanes**: confidence, browser  
+**Target Platform**: static public website built from `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`, local preview on `WEBSITE_PORT` with default `4321`  
+**Project Type**: web application, website package only  
+**Performance Goals**: taxonomy page should be statically generated; first-time evaluators can identify Microsoft 365 first and Intune as one domain within 60 seconds; desktop and mobile layouts must avoid horizontal overflow  
+**Constraints**: `apps/website` only; no `apps/platform`; no root script contract changes; preserve package name `@tenantatlas/website`; preserve `WEBSITE_PORT`; no fake logos, badges, placeholder links, or unsupported provider claims  
+**Scale/Scope**: one localized taxonomy route pair, light homepage/platform/nav/footer integration, public metadata updates, static claim scans, and website smoke coverage
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no authenticated operator-facing surface change; public website claim-guardrail surface only
+- **Native vs custom classification summary**: existing Astro public website primitives and Tailwind conventions; no Filament/admin UI
+- **Shared-family relevance**: public navigation, footer links, CTA links, public metadata, public status labels
+- **State layers in scope**: page content, route, metadata, navigation/footer copy; no runtime state
+- **Audience modes in scope**: public buyer/evaluator only; no operator-MSP/support-platform modes
+- **Decision/diagnostic/raw hierarchy plan**: buyer-facing explanation only; no diagnostics or raw evidence
+- **Raw/support gating plan**: N/A - no raw/support evidence exposed
+- **One-primary-action / duplicate-truth control**: route should expose one main CTA back to real contact or platform context; homepage/platform teasers stay short and link to the taxonomy rather than restating it
+- **Handling modes by drift class or surface**: report-only website claim guardrail; unsupported provider claims are implementation blockers for this feature
+- **Repository-signal treatment**: review-mandatory for risky public claims and placeholder links found by static scans
+- **Special surface test profiles**: N/A - public website surface
+- **Required tests or manual smoke**: website build, Playwright public-route smoke, desktop/mobile browser smoke if preview is available, static risky-claim scan
+- **Exception path and spread control**: none; any runtime provider support or public roadmap governance must move to a follow-up spec
+- **Active feature PR close-out entry**: Smoke Coverage
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes
+- **Systems touched**: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`, `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/utils/navigation.ts`, public route smoke tests
+- **Shared abstractions reused**: `MainLayout`, existing page-component pattern, `siteCopy`, `localizeHref`, `localizedPath`, current navbar/footer content conventions, existing Playwright smoke helpers
+- **New abstraction introduced? why?**: none; use page-local content objects and existing component conventions
+- **Why the existing abstraction was sufficient or insufficient**: the website already renders localized public pages from shared copy and layout primitives; the taxonomy needs content and route extension, not a new content framework
+- **Bounded deviation / spread control**: dedicated `/platform/domains` route is a bounded IA addition; it must not become a runtime provider roadmap framework
+
+## OperationRun UX Impact
+
+- **Touches OperationRun start/completion/link UX?**: no
+- **Central contract reused**: N/A
+- **Delegated UX behaviors**: N/A
+- **Surface-owned behavior kept local**: none
+- **Queued DB-notification policy**: N/A
+- **Terminal notification path**: N/A
+- **Exception path**: none
+
+## Provider Boundary & Portability Fit
+
+- **Shared provider/platform boundary touched?**: yes, public vocabulary only
+- **Provider-owned seams**: Microsoft 365, Intune, Entra, Conditional Access, SharePoint/OneDrive, Enterprise Apps, Service Principals as public examples and Microsoft-specific domains
+- **Platform-core seams**: public neutral terms such as provider, managed environment, provider connection, policy domain, policy evidence, governance review, audit trail, controlled recovery, review pack, claim boundary
+- **Neutral platform terms / contracts preserved**: provider, provider connection, managed environment, policy domain, policy evidence, review pack, audit trail
+- **Retained provider-specific semantics and why**: Microsoft 365 and Intune stay explicit because they are current public market positioning; non-Microsoft providers stay future architecture direction unless verified
+- **Bounded extraction or follow-up path**: document-in-feature for route/IA decision; follow-up-spec for runtime provider support, detailed provider capability documentation, or public roadmap governance
+
+## Constitution Check
+
+### Pre-Design Gate
+
+- **Inventory-first / snapshots-second**: Pass. No inventory, snapshots, backups, or external tenant state changes.
+- **Read/write separation**: Pass. Public website content only; no tenant or provider writes.
+- **Graph contract path**: Pass. No Microsoft Graph calls or contract registry changes.
+- **Deterministic capabilities**: Pass. No runtime capability derivation changes.
+- **RBAC / workspace / tenant isolation**: Pass. Public read-only website; no authenticated routes, memberships, or capability enforcement changes.
+- **Run observability / OperationRun**: Pass. No queued, remote, scheduled, long-running, or OperationRun-linked work.
+- **Automation and data minimization**: Pass. No automation, logs, secrets, or provider data.
+- **Test governance**: Pass with website Browser/confidence lane; no platform fixtures or heavy governance suite expansion.
+- **Proportionality / bloat**: Pass with bounded website-only taxonomy/status vocabulary; no persisted state, runtime enum, provider registry, or abstraction.
+- **Provider boundary**: Pass. Public vocabulary separates Microsoft current focus from future-provider architecture direction and avoids live claims.
+- **Shared pattern first**: Pass. Reuse existing website layout/copy/navigation/test patterns.
+- **Filament/admin UI checks**: N/A. No Laravel, Filament, Livewire, or admin/operator surface changes.
+
+**Gate Result**: PASS. No unjustified constitution violations.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: Browser for public website route/content; confidence for static build and type/content checks
+- **Affected validation lanes**: confidence, browser
+- **Why this lane mix is the narrowest sufficient proof**: the feature is a public static website surface; build/check proves static generation and Playwright smoke proves route reachability, metadata, links, mobile/desktop readability, and claim visibility
+- **Narrowest proving command(s)**: `corepack pnpm --filter @tenantatlas/website build`; `corepack pnpm --filter @tenantatlas/website test`; static `grep`/`rg` claim scan across `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/public`
+- **Fixture / helper / factory / seed / context cost risks**: none
+- **Expensive defaults or shared helper growth introduced?**: no
+- **Heavy-family additions, promotions, or visibility changes**: none
+- **Surface-class relief / special coverage rule**: N/A - public website surface
+- **Closing validation and reviewer handoff**: reviewers should confirm `apps/platform` is untouched, all exposed links are real, status labels are visible, non-Microsoft providers are not live claims, and smoke tests cover German and English taxonomy routes
+- **Budget / baseline / trend follow-up**: none expected
+- **Review-stop questions**: stop if route links are placeholders, copy claims unsupported provider availability, generated output contains risky claims, or implementation touches platform runtime
+- **Escalation path**: follow-up-spec only for runtime provider support or public roadmap governance
+- **Active feature PR close-out entry**: Smoke Coverage
+- **Why no dedicated follow-up spec is needed**: the planned change is one bounded public website taxonomy; routine test and content upkeep stays inside this feature
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/
+|-- plan.md
+|-- research.md
+|-- data-model.md
+|-- quickstart.md
+|-- contracts/
+|   `-- public-taxonomy-routes.openapi.yaml
+`-- tasks.md
+```
+
+### Source Code (repository root)
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/
+|-- package.json
+|-- src/
+|   |-- components/
+|   |   `-- pages/
+|   |       |-- DomainTaxonomyPage.astro
+|   |       |-- HomePage.astro
+|   |       `-- PlatformPage.astro
+|   |-- data_files/
+|   |   `-- site-copy.ts
+|   |-- pages/
+|   |   |-- platform/
+|   |   |   `-- domains.astro
+|   |   `-- en/
+|   |       `-- platform/
+|   |           `-- domains.astro
+|   `-- utils/
+|       `-- navigation.ts
+`-- tests/
+    `-- smoke/
+        |-- public-routes.spec.ts
+        |-- interaction.spec.ts
+        `-- smoke-helpers.ts
+```
+
+**Structure Decision**: Use the existing Astro website structure under `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website`. Add a localized page component and nested static routes for `/platform/domains` and `/en/platform/domains`; update existing copy/navigation/tests rather than introducing a new content system.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| None | N/A | N/A |
+
+## Proportionality Review
+
+- **Current operator problem**: public evaluators cannot tell which domains are current focus, planned, future direction, unavailable, or not claimed
+- **Existing structure is insufficient because**: homepage/platform prose alone cannot distinguish Microsoft 365 first, Intune as one domain, adjacent Microsoft domains, and future non-Microsoft providers without either narrowing or overclaiming
+- **Narrowest correct implementation**: one website-only taxonomy route pair with page-local status labels and claim boundaries, plus light discoverability
+- **Ownership cost created**: future website copy and tests must keep statuses, metadata, and provider claims aligned with product truth
+- **Alternative intentionally rejected**: runtime provider capability registry, CMS, or public roadmap framework; those would add machinery beyond the current public-claim problem
+- **Release truth**: current public website truth with bounded future-provider direction language
+
+## Phase 0: Research
+
+Research tasks were derived from route, localization, validation, and provider-claim unknowns. Findings are consolidated in [/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/research.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/research.md). No `NEEDS CLARIFICATION` items remain.
+
+## Phase 1: Design And Contracts
+
+Design artifacts are:
+
+- [/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/data-model.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/data-model.md)
+- [/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/contracts/public-taxonomy-routes.openapi.yaml](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/contracts/public-taxonomy-routes.openapi.yaml)
+- [/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/quickstart.md](/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/quickstart.md)
+
+### Post-Design Constitution Check
+
+- **Gate Result**: PASS.
+- **Reason**: Phase 1 keeps the taxonomy website-only, static, and page-local. It introduces no persistence, runtime provider support, platform capability registry, Graph calls, RBAC changes, OperationRun behavior, Filament surfaces, or root workspace script changes.
+- **Remaining review focus**: ensure implementation does not turn status labels into runtime state, does not publish unsupported provider availability, does not add fake provider logos/badges, and does not touch `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform`.
+
+## Phase 2: Planning Boundary
+
+This `/speckit.plan` output stops before task generation. `/speckit.tasks` should create implementation tasks from this plan, the spec, and the generated design artifacts.
--- a/specs/406-provider-policy-domain-public-taxonomy/quickstart.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/quickstart.md
@ -0,0 +1,196 @@
+# Quickstart: Provider & Policy Domain Public Taxonomy
+
+## 1. Confirm Scope
+
+Work from repository root:
+
+```bash
+cd /Users/ahmeddarrazi/Documents/projects/wt-website
+git status --short --branch
+cat package.json
+cat pnpm-workspace.yaml 2>/dev/null || true
+cat apps/website/package.json
+find apps/website -maxdepth 3 -type f | sort | sed -n '1,220p'
+```
+
+Scope boundaries:
+
+- Allowed: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/**`
+- Allowed: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/406-provider-policy-domain-public-taxonomy/**`
+- Forbidden: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/platform/**`
+- Forbidden: root workspace script contract changes
+
+## 2. Implement The Route
+
+Preferred route:
+
+- `/platform/domains`
+- `/en/platform/domains`
+
+Expected files:
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform/domains.astro
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/platform/domains.astro
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/DomainTaxonomyPage.astro
+```
+
+Follow the existing `PlatformPage.astro` and `TrustPage.astro` route/component pattern.
+
+## 3. Add Localized Content
+
+Use the existing copy file:
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts
+```
+
+Add German and English taxonomy copy with:
+
+- hero copy
+- metadata
+- status legend
+- Microsoft 365 domain matrix
+- future-provider rows
+- buyer-facing cards
+- CTA labels and destinations
+
+## 4. Use Safe Status Defaults
+
+Use these public status meanings:
+
+- Current focus / Aktueller Fokus
+- Planned domain / Geplante Domaene
+- Architecture direction / Architektur-Richtung
+- Not currently available / Derzeit nicht verfuegbar
+- Not claimed / Nicht beansprucht
+
+Default statuses:
+
+- Intune / Endpoint Policies: current focus only if repo/product truth supports it
+- Entra / Identity & Access: planned domain unless verified current
+- Conditional Access: planned domain unless verified current
+- SharePoint / OneDrive Sharing: planned domain unless verified current
+- Enterprise Apps / Service Principals: planned domain unless verified current
+- Security Posture Evidence: planned domain unless verified current
+- Provider Permissions & Readiness: current or planned based on repo/product truth
+- Review Packs & Governance Evidence: current or planned based on repo/product truth
+- Google Workspace / Google Cloud: architecture direction unless verified current
+- AWS: architecture direction unless verified current
+- Okta / Identity Providers: architecture direction unless verified current
+- Other SaaS policy systems: architecture direction unless verified current
+
+## 5. Integrate Lightly
+
+Add only light discoverability:
+
+- homepage teaser if it fits current copy structure
+- platform-page teaser or CTA
+- footer/nav link only if current IA supports it without clutter
+
+Every CTA must use a real route, real anchor, or real contact destination.
+
+## 6. Update Smoke Coverage
+
+Expected test updates:
+
+```text
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/interaction.spec.ts
+/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/smoke-helpers.ts
+```
+
+Cover:
+
+- `/platform/domains`
+- `/en/platform/domains`
+- metadata for both routes
+- public links
+- mobile readability
+- no horizontal overflow
+- status labels
+- no false provider claims
+
+## 7. Run Validation
+
+Run only scripts that exist:
+
+```bash
+corepack pnpm --filter @tenantatlas/website build
+corepack pnpm --filter @tenantatlas/website test
+```
+
+Optional if formatting changed broadly:
+
+```bash
+corepack pnpm --filter @tenantatlas/website format:check
+```
+
+Run static source scan:
+
+```bash
+grep -RIn \
+  -e 'href="#"' \
+  -e 'Intune Management Tool' \
+  -e 'Google supported' \
+  -e 'AWS supported' \
+  -e 'Okta supported' \
+  -e 'multi-cloud supported' \
+  -e 'all cloud providers' \
+  -e 'every SaaS platform' \
+  -e 'provider-agnostic restore' \
+  -e 'universal policy governance' \
+  -e 'automatic remediation' \
+  -e 'automatic restore' \
+  -e 'self-healing' \
+  -e 'real-time drift' \
+  -e 'immutable backups' \
+  -e 'gerichtsfeste Nachweise' \
+  -e 'lueckenlose Evidenz' \
+  apps/website/src apps/website/public 2>/dev/null || true
+```
+
+If generated output is committed, scan it too:
+
+```bash
+grep -RIn \
+  -e 'href="#"' \
+  -e 'Intune Management Tool' \
+  -e 'Google supported' \
+  -e 'AWS supported' \
+  -e 'Okta supported' \
+  -e 'multi-cloud supported' \
+  -e 'all cloud providers' \
+  -e 'every SaaS platform' \
+  -e 'provider-agnostic restore' \
+  -e 'universal policy governance' \
+  -e 'automatic remediation' \
+  -e 'automatic restore' \
+  -e 'self-healing' \
+  -e 'real-time drift' \
+  -e 'immutable backups' \
+  -e 'gerichtsfeste Nachweise' \
+  -e 'lueckenlose Evidenz' \
+  apps/website/dist 2>/dev/null || true
+```
+
+## 8. Browser Smoke
+
+If preview is available:
+
+```bash
+WEBSITE_PORT=${WEBSITE_PORT:-4321} corepack pnpm --filter @tenantatlas/website preview
+```
+
+Verify:
+
+- `/platform/domains` loads
+- `/en/platform/domains` loads
+- homepage/platform teaser link works
+- nav/footer links work if added
+- desktop layout is readable
+- mobile layout is readable
+- status labels are understandable
+- Intune is not the whole product category
+- Google/AWS/Okta are not presented as live support
+- no CTA uses a fake route
--- a/specs/406-provider-policy-domain-public-taxonomy/research.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/research.md
@ -0,0 +1,91 @@
+# Research: Provider & Policy Domain Public Taxonomy
+
+## Decision: Use `/platform/domains` and `/en/platform/domains`
+
+**Rationale**: The existing public website already has `/platform` and `/en/platform` routes, uses Astro file-based routing, and contains nested documentation routes. A nested platform taxonomy route keeps the content connected to product positioning without cluttering the top-level IA.
+
+**Alternatives considered**:
+
+- `/policy-domains`: clear but less connected to the platform page and current IA.
+- `/domains`: short but too generic for public SEO and buyer context.
+- Inline-only platform section: lower route overhead but weaker discoverability and harder metadata/smoke coverage.
+
+## Decision: Reuse the existing localized page-component pattern
+
+**Rationale**: Current public pages use thin route files that pass `locale` into page components, for example `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/platform.astro` and `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en/platform.astro`. A `DomainTaxonomyPage.astro` component can follow the same pattern for German default and English routes.
+
+**Alternatives considered**:
+
+- MDX content route: useful for docs, but less aligned with current marketing pages and CTA/navigation patterns.
+- Inline route-only markup: works, but duplicates localization and layout structure across German and English routes.
+- CMS/content collection: out of scope and unnecessary for one bounded page.
+
+## Decision: Keep taxonomy data in existing website copy data
+
+**Rationale**: The website already centralizes public copy in `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts`. Adding localized taxonomy copy there keeps route metadata, status labels, domain rows, future-provider rows, and CTA labels near existing homepage/platform/trust copy.
+
+**Alternatives considered**:
+
+- Separate JSON file: simpler for tabular data but splits page copy from existing localized page copy.
+- Runtime data source: out of scope and would imply a stronger product truth than a website-only claim taxonomy.
+- Hardcoded component arrays: acceptable for narrow content, but weaker for German/English parity.
+
+## Decision: Use website-only status labels
+
+**Rationale**: The public taxonomy needs visible buyer-facing statuses: Current focus, Planned domain, Architecture direction, Not currently available, and Not claimed, with German equivalents. These labels are presentation/content truth only and must not become runtime enums, provider capability states, or persisted product data.
+
+**Alternatives considered**:
+
+- No status labels: leaves current/planned/future claims ambiguous.
+- Detailed public roadmap stages: creates stronger commitment and governance overhead than needed.
+- Runtime capability registry: explicitly out of scope and unnecessary for public claim discipline.
+
+## Decision: Default uncertain Microsoft-adjacent domains to planned-domain wording
+
+**Rationale**: The spec requires repo/product truth before marking a domain current. In planning, only Intune/Microsoft 365 positioning is safe as current public focus. Entra, Conditional Access, SharePoint/OneDrive, Enterprise Apps, Service Principals, Security Posture Evidence, Provider Permissions, and Review Packs should default to planned-domain wording unless implementation verifies current availability.
+
+**Alternatives considered**:
+
+- Mark all Microsoft domains current: risks false capability claims.
+- Mark all adjacent domains not available: too conservative and obscures roadmap direction.
+- Use architecture direction for all non-Intune domains: less useful for Microsoft 365 domain roadmap clarity.
+
+## Decision: Default Google/AWS/Okta to architecture direction
+
+**Rationale**: The public page may explain provider-extensible design, but Google Workspace, Google Cloud, AWS, Okta, and other SaaS systems must not look live unless verified. Architecture-direction wording communicates future possibility without support claims.
+
+**Alternatives considered**:
+
+- Omit non-Microsoft providers: avoids risk but fails the spec's goal of explaining future provider direction.
+- Mark as planned domains: too close to a roadmap commitment.
+- Use official logos or integration badges: rejected because they imply partnership or availability.
+
+## Decision: Reuse current Playwright smoke coverage patterns
+
+**Rationale**: Existing website smoke tests already check public routes, metadata, links, placeholder URLs, claim guardrails, horizontal overflow, mobile navigation, and localized routes. Extending those tests is the narrowest proof for a static website taxonomy.
+
+**Alternatives considered**:
+
+- Add Laravel/Pest tests: wrong layer; platform runtime is out of scope.
+- Add dedicated unit tests for copy objects: more brittle than route-level public behavior for this feature.
+- Manual-only smoke: insufficient for claim guardrails and route metadata regression.
+
+## Decision: Validate with existing package scripts only
+
+**Rationale**: `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/package.json` exposes `build`, `test`, `test:smoke`, `format:check`, and related scripts. The plan should not invent `check`; the build script already runs `astro check` before `astro build`.
+
+**Alternatives considered**:
+
+- `pnpm --filter @tenantatlas/website check`: not present in current package scripts.
+- Root script changes: explicitly out of scope and would break workspace contracts.
+- Platform/Sail commands: wrong scope for public website-only work.
+
+## Decision: Use static claim scans as implementation blockers
+
+**Rationale**: The feature exists to prevent overclaiming. Static scans for `href="#"`, `Google supported`, `AWS supported`, `Okta supported`, `multi-cloud supported`, `all cloud providers`, `universal policy governance`, `Intune Management Tool`, `automatic remediation`, `automatic restore`, `real-time drift`, `immutable backups`, `gerichtsfeste Nachweise`, and `lueckenlose Evidenz` should run against website source and public assets, and against generated output if committed.
+
+**Alternatives considered**:
+
+- Rely only on code review: too easy to miss SEO/meta or generated HTML phrasing.
+- Block every provider name: not correct; provider names are allowed when framed as architecture direction.
+- Add a new linter: unnecessary for one bounded website feature.
--- a/specs/406-provider-policy-domain-public-taxonomy/spec.md
+++ b/specs/406-provider-policy-domain-public-taxonomy/spec.md
@ -0,0 +1,303 @@
+# Feature Specification: Provider & Policy Domain Public Taxonomy
+
+**Feature Branch**: `406-provider-policy-domain-public-taxonomy`  
+**Created**: 2026-05-26  
+**Status**: Draft  
+**Input**: User description: "Create a public website taxonomy for provider and policy domains that positions Tenantial as Microsoft 365 first, treats Intune as the first strong policy focus, labels adjacent Microsoft 365 domains safely, and frames Google/AWS/Okta only as future architecture direction unless verified."
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: MSP, enterprise IT, security, governance, and DACH evaluators need to understand Tenantial's provider and policy-domain scope without reducing the product to an Intune utility or assuming unsupported multi-provider availability.
+- **Today's failure**: Public copy can either over-focus on Intune and make Tenantial look endpoint-only, or speak too broadly about providers and imply Google, AWS, Okta, or arbitrary SaaS policy systems are available today.
+- **User-visible improvement**: A buyer can see Microsoft 365 as the first market, Intune as the first strong policy domain, adjacent Microsoft 365 policy domains as planned or current only when verified, and non-Microsoft providers as future direction without live-support claims.
+- **Smallest enterprise-capable version**: One public taxonomy surface or substantial platform-page section with a status legend, Microsoft 365 domain matrix, future-provider direction, buyer-facing explanation, safe metadata, and light public-site integration.
+- **Explicit non-goals**: No provider runtime implementation, no Google/AWS/Okta integration, no platform migrations, no Microsoft Graph permission logic, no CMS, no fake provider logos, no fake roadmap page, and no unsupported support claims.
+- **Permanent complexity imported**: One public taxonomy page or section, one bounded public status vocabulary, and one public provider/domain claim boundary model. No models, persistence, services, provider registries, runtime statuses, enums, or platform abstractions are introduced.
+- **Why now**: Spec 404 corrected public sales positioning and Spec 405 corrected trust posture. The next public-site risk is scope confusion around Intune, Microsoft 365, and future providers.
+- **Why not local**: A short homepage sentence cannot safely explain current focus, planned domains, architecture direction, and non-claims without creating ambiguity across homepage, platform copy, footer, and SEO metadata.
+- **Approval class**: Core Enterprise.
+- **Red flags triggered**: New public taxonomy/status vocabulary, provider overclaim risk, future-provider language, and public category ambiguity.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
+- **Decision**: approve.
+
+### Red Flag Defense
+
+This spec intentionally proceeds despite taxonomy and status-language red flags because the risk is public false positioning, not internal architecture ambition. The taxonomy is website-only, buyer-facing, and bounded to claim discipline. It must not become a runtime provider framework, capability registry, persisted status system, or platform taxonomy.
+
+## Scope
+
+This spec defines a public website taxonomy for Tenantial provider and policy-domain positioning.
+
+- **Relevant application for later implementation**: public website only
+- **Depends on**: Spec 404 - Public Website Sales Copy & Positioning Rewrite; Spec 405 - DACH Trust, Datenschutz & Security Website Surface
+- **Must not depend on**: platform runtime changes
+- **Primary audience**: MSPs, enterprise IT, security, governance, procurement, and DACH Mittelstand evaluators
+- **Public message**: Microsoft 365 first. Intune as a strong starting domain. Provider-extensible by design. No false Google/AWS/Okta availability claims.
+- **Out of scope**: new provider support, platform runtime code, database changes, provider capability registries, Microsoft Graph permission changes, CMS work, fake logos, fake badges, placeholder links, and root workspace contract changes
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: N/A - public website surface outside authenticated workspace, tenant, or canonical-view product flows
+- **Primary Routes**: preferred public route `/platform/domains`; fallback to a real website route such as `/policy-domains`, `/domains`, or a substantial platform-page section if current website conventions require it
+- **Data Ownership**: no workspace-owned, tenant-owned, provider-owned, customer, backup, evidence, audit, or runtime product data is created, read, changed, or persisted
+- **RBAC**: public read-only content only; no membership, role, capability, authorization, or authenticated product behavior changes
+
+For canonical-view specs, the spec MUST define:
+
+- **Default filter behavior when tenant-context is active**: N/A - no tenant-context or canonical product view is introduced
+- **Explicit entitlement checks preventing cross-tenant leakage**: N/A - no authenticated tenant, workspace, or provider data is involved
+
+## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
+
+- **Cross-cutting feature?**: yes
+- **Interaction class(es)**: public navigation, footer links, platform-page links, homepage teaser, public metadata, CTA links, public status labels
+- **Systems touched**: public website shell, current public route conventions, homepage or platform-page teaser, footer or navigation exposure, and public SEO metadata
+- **Existing pattern(s) to extend**: existing public website layout, navigation, footer, section, card/grid, badge/status, and metadata conventions
+- **Shared contract / presenter / builder / renderer to reuse**: current public website components and content conventions
+- **Why the existing shared path is sufficient or insufficient**: the public website already has a shell and content patterns; this feature needs one taxonomy destination inside that shell, not a parallel microsite or new design system
+- **Allowed deviation and why**: a dedicated taxonomy route or substantial platform-page section is allowed because provider/domain scope needs one focused explanation
+- **Consistency impact**: Microsoft 365-first wording, Intune-as-domain wording, planned/future status labels, CTA behavior, and claim boundaries must stay consistent across homepage, platform copy, taxonomy page, footer, and metadata
+- **Review focus**: verify that all links are real, no unsupported provider is presented as live, status labels are visible, and the page does not create a second public IA language
+
+## 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`)*
+
+- **Touches OperationRun start/completion/link UX?**: no
+- **Shared OperationRun UX contract/layer reused**: N/A
+- **Delegated start/completion UX behaviors**: N/A
+- **Local surface-owned behavior that remains**: none
+- **Queued DB-notification policy**: N/A
+- **Terminal notification path**: N/A
+- **Exception required?**: none
+
+## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
+
+- **Shared provider/platform boundary touched?**: yes
+- **Boundary classification**: mixed public vocabulary only
+- **Seams affected**: public provider names, public policy-domain grouping, status labels, current-versus-planned wording, future-provider direction, and claim boundaries
+- **Neutral platform terms preserved or introduced**: provider, managed environment, provider connection, policy domain, policy evidence, governance review, audit trail, controlled recovery, review pack, claim boundary
+- **Provider-specific semantics retained and why**: Microsoft 365 and Intune remain concrete because they are the first public market and first strong policy focus; Intune is framed as one domain inside Microsoft 365, not as the entire product category
+- **Why this does not deepen provider coupling accidentally**: the taxonomy separates providers from policy domains, labels Microsoft-adjacent domains by status, and treats Google/AWS/Okta as architecture direction unless verified as live
+- **Follow-up path**: document-in-feature for route/IA decision; follow-up-spec only if later work needs runtime provider support, detailed provider capability documentation, or public roadmap governance
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+N/A - public website taxonomy surface only; no authenticated operator-facing product surface is changed.
+
+## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing product surface change.
+
+## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
+
+N/A - public buyer-facing website copy only; no operator diagnostics, support mode, or raw evidence surface is added here.
+
+## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing product surface change.
+
+## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing product surface change.
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no
+- **New persisted entity/table/artifact?**: no
+- **New abstraction?**: no
+- **New enum/state/reason family?**: yes - a bounded public status vocabulary for website claim discipline only
+- **New cross-domain UI framework/taxonomy?**: yes - a public website taxonomy for providers and policy domains only
+- **Current operator problem**: public evaluators cannot tell which policy domains are current, planned, future direction, unavailable, or not claimed
+- **Existing structure is insufficient because**: free-form homepage or platform copy cannot reliably separate Intune current focus, adjacent Microsoft 365 domains, and future provider directions without either narrowing or overclaiming
+- **Narrowest correct implementation**: one public taxonomy page or one substantial platform section using existing website patterns, with status labels and explicit claim boundaries
+- **Ownership cost**: future website copy must keep statuses, metadata, links, and provider claims in sync with repo/product truth
+- **Alternative intentionally rejected**: a full public roadmap system or runtime provider capability registry, because the current need is public claim clarity rather than new product machinery
+- **Release truth**: current public website truth with bounded preparation for later public domain and roadmap pages
+
+### Compatibility posture
+
+This feature assumes a pre-production environment.
+
+Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
+
+Canonical replacement is preferred over preservation.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: Browser
+- **Validation lane(s)**: browser, confidence
+- **Why this classification and these lanes are sufficient**: public taxonomy quality is proven by reachable website routes, visible status labels, real links, static claim scans, website checks/builds that already exist, and desktop/mobile smoke review
+- **New or expanded test families**: none beyond website-only static checks and any existing website smoke coverage
+- **Fixture / helper cost impact**: none
+- **Heavy-family visibility / justification**: none
+- **Special surface test profile**: N/A - public website surface
+- **Standard-native relief or required special coverage**: ordinary website coverage only; verify route reachability, readable desktop/mobile layout, real CTA links, status labels, Microsoft 365-first positioning, and no false provider availability claims
+- **Reviewer handoff**: confirm only website-facing files change, no platform runtime files change, all taxonomy links are real, and any domain marked current is supported by repo/product truth
+- **Budget / baseline / trend impact**: none expected
+- **Escalation needed**: follow-up-spec if implementation needs runtime provider support, public roadmap governance, or non-website contract changes
+- **Active feature PR close-out entry**: Smoke Coverage
+- **Planned validation commands**:
+  - inspect root package metadata and website package metadata before running scripts
+  - run existing website check/build/test scripts only if present
+  - run static scans for placeholder links and risky public claims across website source and public assets
+  - run desktop/mobile browser smoke for the taxonomy page and any homepage/platform/nav/footer links if local preview is available
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Buyer Understands Current Scope (Priority: P1)
+
+An MSP, enterprise IT, or governance buyer opens the taxonomy surface and can immediately understand that Tenantial starts with Microsoft 365 governance and Intune is the first strong policy focus rather than the entire product category.
+
+**Why this priority**: This is the central positioning correction after Spec 404 and prevents Tenantial from shrinking publicly into an Intune-only tool.
+
+**Independent Test**: Can be fully tested by opening the taxonomy surface and confirming that the hero, domain matrix, and buyer-facing explanation all state Microsoft 365 first and Intune as one policy domain.
+
+**Acceptance Scenarios**:
+
+1. **Given** a public visitor evaluating Tenantial, **When** they read the taxonomy page hero, **Then** they see Microsoft 365 as the first market and Intune as a strong first policy focus.
+2. **Given** a visitor reading the Microsoft 365 domain matrix, **When** they inspect the Intune row, **Then** Intune is labeled as current focus and bounded as one endpoint/device policy domain inside Microsoft 365.
+3. **Given** a visitor scanning the page quickly, **When** they only read headings and status labels, **Then** they can still tell that Tenantial is not presented as Intune-only.
+
+---
+
+### User Story 2 - Evaluator Distinguishes Current, Planned, And Future Domains (Priority: P1)
+
+A security, governance, or procurement evaluator needs to know which policy domains are current focus, planned domains, architecture direction, unavailable, or not claimed.
+
+**Why this priority**: Clear domain status prevents false expectations and makes sales and trust conversations safer.
+
+**Independent Test**: Can be fully tested by reviewing the status legend and every domain/provider row for a visible status and claim boundary.
+
+**Acceptance Scenarios**:
+
+1. **Given** a visitor reading the status legend, **When** they compare labels, **Then** each label explains whether a domain is current focus, planned, architecture direction, unavailable, or not claimed.
+2. **Given** a visitor reviewing Microsoft 365-adjacent domains, **When** they inspect Entra, Conditional Access, SharePoint/OneDrive, Enterprise Apps, Service Principals, Security Posture Evidence, Provider Permissions, or Review Packs, **Then** each domain has a status and a claim boundary.
+3. **Given** a domain whose current implementation is not verified, **When** the visitor reads that row, **Then** the row uses planned-domain or architecture-direction wording rather than current availability wording.
+
+---
+
+### User Story 3 - Future Providers Are Presented Honestly (Priority: P1)
+
+A prospect wants to know whether Google Workspace, Google Cloud, AWS, Okta, or other SaaS providers are supported today. The taxonomy must answer without turning future extensibility into a live-support claim.
+
+**Why this priority**: Provider overclaiming creates sales, trust, and implementation risk.
+
+**Independent Test**: Can be fully tested by reading the future-provider section and confirming that non-Microsoft providers are labeled as architecture direction unless later implementation verifies live support.
+
+**Acceptance Scenarios**:
+
+1. **Given** a visitor reading future provider direction, **When** they inspect Google Workspace, Google Cloud, AWS, Okta, or other SaaS providers, **Then** the page clearly states there is no current availability claim unless verified.
+2. **Given** a visitor looking for live multi-provider support, **When** they read the page metadata, headings, future-provider cards, and CTAs, **Then** they do not see unsupported phrases that imply Google/AWS/Okta are live today.
+3. **Given** a provider card or row for a future provider, **When** the visitor reads it, **Then** it uses architecture-direction language and avoids official provider logos or fake integration badges.
+
+---
+
+### User Story 4 - Public Visitor Can Reach The Taxonomy From Existing IA (Priority: P2)
+
+A public visitor should be able to discover the taxonomy from the homepage, platform page, navigation, or footer where current website IA supports it.
+
+**Why this priority**: Taxonomy clarity only reduces scope confusion if it is reachable from the pages where buyers form product expectations.
+
+**Independent Test**: Can be fully tested by following all exposed links to the taxonomy page or section on desktop and mobile.
+
+**Acceptance Scenarios**:
+
+1. **Given** a public visitor on the homepage or platform page, **When** they follow the policy-domain teaser or CTA, **Then** they arrive at a real taxonomy route or section.
+2. **Given** a visitor using exposed navigation or footer links, **When** they open the taxonomy link, **Then** the link resolves without placeholders or broken anchors.
+3. **Given** a mobile visitor, **When** they open the taxonomy surface, **Then** the domain matrix, status labels, and CTAs remain readable and understandable.
+
+### Edge Cases
+
+- What happens when repo/product truth does not prove a Microsoft 365-adjacent domain is live? The domain must be labeled as planned domain or architecture direction, not current focus.
+- What happens when the current website does not support nested routes cleanly? The implementation must use a real fallback route or a substantial existing platform-page section and must not create a placeholder route.
+- What happens when no real CTA target exists for a proposed anchor or route? The CTA must be omitted or pointed to a real destination.
+- What happens when a provider name could imply official partnership or live integration? The page must use text-only cautious wording and avoid official logos, badges, and customer-like integration claims.
+- How does the page handle language strategy? It must follow the current website language conventions and use equivalent English or German status labels consistently.
+
+## Assumptions
+
+- Microsoft 365 is the first public market based on prior website positioning work.
+- Intune can be publicly described as the first strong policy focus only when implementation verifies current repo/product truth.
+- Entra, Conditional Access, SharePoint/OneDrive, Enterprise Apps, Service Principals, Security Posture Evidence, Provider Permissions, and Review Packs default to planned-domain wording unless implementation verifies current availability.
+- Google Workspace, Google Cloud, AWS, Okta, and other SaaS policy systems default to architecture-direction wording unless implementation verifies current availability.
+- The current public website has a real platform route or can support one real taxonomy route without changing platform runtime.
+- The active website language may be German-first, English-first, or mixed; the taxonomy must follow the current site convention instead of introducing a full localization program.
+
+## Requirements *(mandatory)*
+
+This feature introduces no Microsoft Graph calls, no write/change product behavior, no persistence, no OperationRun flow, no RBAC mutation, and no provider runtime capability. Its only structural addition is a bounded public taxonomy and status vocabulary for website claim discipline.
+
+### Functional Requirements
+
+#### Scope And Route
+
+- **FR-001**: The implementation MUST remain public-website-only and MUST NOT require platform runtime changes.
+- **FR-002**: The public website MUST provide a provider and policy-domain taxonomy as either a dedicated real route or a substantial section on the existing platform page.
+- **FR-003**: The preferred taxonomy destination MUST be `/platform/domains` when current website route conventions support it.
+- **FR-004**: If `/platform/domains` is not compatible with current website conventions, the implementation MUST choose a real fallback destination and document the route/IA decision.
+- **FR-005**: The taxonomy destination MUST be discoverable through at least one existing public-site entry point such as homepage teaser, platform-page link, navigation, or footer.
+- **FR-006**: Every taxonomy CTA, nav link, footer link, and in-page link MUST resolve to a real page, real section, or real contact destination; placeholder links are forbidden.
+
+#### Required Public Structure
+
+- **FR-007**: The taxonomy surface MUST include a hero that states Microsoft 365 first and explains that Tenantial is built for policy domains beyond Intune.
+- **FR-008**: The hero MUST frame Intune as a strong first policy focus and MUST NOT frame Intune as the entire product category.
+- **FR-009**: The taxonomy surface MUST include a visible status legend with meanings for current focus, planned domain, architecture direction, not currently available, and not claimed, or equivalent German labels following the active website language.
+- **FR-010**: The taxonomy surface MUST include a Microsoft 365 domain matrix or equivalent structured presentation.
+- **FR-011**: Every Microsoft 365 domain row or card MUST include domain name, provider, public status, governance value, what Tenantial helps with, and claim boundary.
+- **FR-012**: The taxonomy surface MUST include a future-provider direction section that explains provider extensibility without implying live support.
+- **FR-013**: The taxonomy surface MUST include a buyer-facing section explaining what the taxonomy means for MSPs and enterprise IT.
+
+#### Domain Coverage
+
+- **FR-014**: The Microsoft 365 domain matrix MUST include Intune / Endpoint Policies and label it as current focus only if repo/product truth supports that status.
+- **FR-015**: The Microsoft 365 domain matrix MUST include Identity & Access Policy / Entra and use planned-domain wording unless current availability is verified.
+- **FR-016**: The Microsoft 365 domain matrix MUST include Conditional Access & Sign-in Controls and use planned-domain wording unless current availability is verified.
+- **FR-017**: The Microsoft 365 domain matrix MUST include Tenant-level Sharing & Collaboration for SharePoint/OneDrive and use planned-domain wording unless current availability is verified.
+- **FR-018**: The Microsoft 365 domain matrix MUST include Enterprise Apps & Service Principals and use planned-domain wording unless current availability is verified.
+- **FR-019**: The Microsoft 365 domain matrix MUST include Security Posture Evidence and frame it as evidence/signal coverage rather than remediation ownership.
+- **FR-020**: The Microsoft 365 domain matrix MUST include Provider Permissions & Readiness and explain provider permissions as provider-specific requirements rather than universal platform truth.
+- **FR-021**: The Microsoft 365 domain matrix MUST include Review Packs & Governance Evidence and frame it around evidence, findings, accepted risks, decisions, and reviews.
+
+#### Future Provider Direction
+
+- **FR-022**: Google Workspace, Google Cloud, AWS, Okta, identity providers, and other SaaS policy systems MUST NOT be presented as live support unless current repo/product truth verifies that support.
+- **FR-023**: Future-provider cards or rows MUST use architecture-direction wording by default.
+- **FR-024**: Future-provider copy MUST state that the public product focus remains Microsoft 365 unless a domain is explicitly marked as available.
+- **FR-025**: The page MUST NOT use official provider logos, fake integration badges, fake customer badges, or brand-like partner signals unless licensing, brand usage, and live availability are verified.
+
+#### Claim Guardrails
+
+- **FR-026**: Public copy MUST use safe wording such as Microsoft 365 first, Intune as first strong policy focus, policy domains, provider connections, managed environments, policy evidence, drift visibility, governance reviews, review packs, audit trail, controlled recovery, future provider direction, and architecture direction.
+- **FR-027**: Public copy MUST avoid visible internal jargon such as provider-neutral artifact source taxonomy, target scope neutrality, capability registry, source family, detector key, governed subject vocabulary, route-owned scope, and workspace-first cutover.
+- **FR-028**: Public copy MUST NOT claim Google supported, AWS supported, Okta supported, multi-cloud supported, all cloud providers, every SaaS platform, provider-agnostic restore, universal policy governance, automatic remediation, automatic restore, self-healing, real-time drift, immutable backups, gerichtsfeste Nachweise, or lueckenlose Evidenz unless separately verified and explicitly scoped.
+- **FR-029**: The taxonomy must not use Intune Management Tool as the primary product category.
+- **FR-030**: Any domain marked current MUST be backed by current repo/product truth identified during implementation; uncertain domains MUST use the safer status.
+
+#### Integration And Metadata
+
+- **FR-031**: Homepage or platform-page integration MUST remain lightweight and MUST NOT duplicate the full taxonomy.
+- **FR-032**: Navigation or footer exposure SHOULD be added only when current website IA supports it without clutter or fake dropdown entries.
+- **FR-033**: Taxonomy-page metadata MUST mention Microsoft 365, Intune, Entra, Conditional Access, SharePoint, Enterprise Apps, and future provider direction without claiming Google/AWS/Okta live support.
+- **FR-034**: Metadata MUST NOT use unsupported SEO phrases such as Google Workspace support, AWS support, multi-cloud support, or universal policy governance.
+- **FR-035**: The final implementation report MUST document the chosen route/IA decision, claim-scan results, validation commands, and confirmation that platform runtime was untouched.
+
+### Key Entities *(include if feature involves data)*
+
+- **Provider**: A system or platform Tenantial connects to or may later connect to; public examples include Microsoft 365, Microsoft Intune, Microsoft Entra, SharePoint/OneDrive, Google Workspace/Google Cloud, AWS, Okta, and other SaaS policy systems.
+- **Policy Domain**: A buyer-facing governance surface such as endpoint/device policies, identity/access policies, Conditional Access, sharing/collaboration posture, enterprise applications/service principals, security posture evidence, provider permissions/readiness, or review packs/evidence.
+- **Public Status Label**: A website-only label that tells buyers whether a domain is current focus, planned domain, architecture direction, not currently available, or not claimed.
+- **Governance Value**: The buyer-facing reason the domain matters, expressed in terms of drift visibility, evidence, review readiness, audit context, controlled recovery preparation, or risk governance.
+- **Claim Boundary**: The explicit limit on what Tenantial claims for a provider or domain so that current support, planned direction, and non-claims are not confused.
+- **Taxonomy Destination**: The public page or substantial platform-page section where provider and policy-domain status are explained.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: A first-time evaluator can identify Microsoft 365 as the first market and Intune as one policy domain within 60 seconds of opening the taxonomy surface.
+- **SC-002**: 100% of listed policy domains include a provider, status, governance value, Tenantial help statement, and claim boundary.
+- **SC-003**: 100% of Google/AWS/Okta or other non-Microsoft provider references are labeled as architecture direction or a stricter non-availability status unless live availability is verified.
+- **SC-004**: The public taxonomy surface contains zero placeholder links, fake provider badges, fake logos, fake customer-like integration claims, or unsupported live-support claims.
+- **SC-005**: A reviewer can correctly classify at least eight listed domains into current focus, planned domain, architecture direction, not currently available, or not claimed after reading the status legend once.
+- **SC-006**: Desktop and mobile smoke review confirms the hero, status legend, domain matrix, future-provider section, buyer-facing section, and CTAs are readable without layout overlap.
+- **SC-007**: The implementation changes no platform runtime behavior and introduces no new persisted entities, provider integrations, runtime status families, or provider capability machinery.