TenantAtlas/specs/213-website-foundation-v0/spec.md

Feature Specification: Initial Website Foundation & v0 Product Site

Feature Branch: 213-website-foundation-v0
Created: 2026-04-18
Status: Draft
Input: User description: "Establish the initial public TenantAtlas website foundation and ship the first trust-first v0 product site in apps/website."

Spec Candidate Check (mandatory — SPEC-GATE-001)

• Problem: The website track does not yet explain TenantAtlas credibly to enterprise and MSP buyers, so the product lacks a trustworthy public entry point.
• Today's failure: A first-time visitor cannot quickly tell what TenantAtlas is, how it differs from generic backup or reporting tools, or whether it is serious enough for enterprise evaluation.
• User-visible improvement: Visitors can understand the product model, assess trust posture, and reach a qualified next step without digging through incomplete or placeholder pages.
• Smallest enterprise-capable version: A public website v0 with a clear home page, core product/trust/solutions/integrations/contact/legal pages, shared layout primitives, and a direct contact path.
• Explicit non-goals: No product-app behavior, no deep runtime coupling to the platform, no public roadmap/community hub, no full docs/blog/CMS rollout, no multi-language launch, no template clone, and no speculative trust-center claims.
• Permanent complexity imported: A stable public information architecture, reusable website primitives, shared messaging structure, legal page responsibilities, and website-specific validation expectations.
• Why now: TenantAtlas needs a credible public surface before broader rollout, trust conversations, and later expansion into docs, changelog, or resource content.
• Why not local: A one-off landing page or copy-only patch would not create a stable public story, reusable page composition, or an extensible enterprise-ready website track.
• Approval class: Core Enterprise
• Red flags triggered: #4 sounds like foundation work; #5 broad concept vocabulary. The scope stays justified because it is constrained to the smallest publishable site that improves public product clarity, trust, and conversion.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: workspace
• Primary Routes: /, /product, /solutions, /security-trust, /integrations, /contact, /legal, /privacy, /terms
• Data Ownership: Workspace-owned public content, assets, reusable components, and site configuration inside apps/website; no tenant-owned records or platform runtime data.
• RBAC: Public-read runtime only. No authenticated membership or capability checks are required for v0 website browsing; content changes remain repo-controlled.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: yes
• New enum/state/reason family?: no
• New cross-domain UI framework/taxonomy?: yes
• Current operator problem: Prospects and internal teams lack a stable, trustworthy public site that explains the product, trust posture, and next step without resorting to ad hoc copy or app screenshots.
• Existing structure is insufficient because: The current website track is too minimal to support coherent product messaging, reusable page composition, clear trust framing, or later content expansion without rework.
• Narrowest correct implementation: One bounded website v0 with shared layout and content primitives, a small core route set, a clear contact path, and explicit messaging constraints; no app simulation, no CMS, and no broad content platform.
• Ownership cost: Ongoing maintenance of public copy, reusable website primitives, legal content, and a small public information architecture.
• Alternative intentionally rejected: A single landing page or imported theme was rejected because it would not create durable enterprise messaging, trustworthy trust surfaces, or an extensible public structure aligned with the product.
• Release truth: Current-release truth

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser
• Validation lane(s): fast-feedback
• Why this classification and these lanes are sufficient: The feature is proven by public-page rendering, route reachability, content hierarchy, and responsive navigation rather than by tenant data or business-rule execution.
• New or expanded test families: Lightweight Playwright website smoke coverage for core published routes and contact/legal reachability, plus the existing static-build proof.
• Fixture / helper cost impact: Minimal. Public pages do not require seeded tenant, workspace, or authentication state.
• Heavy-family visibility / justification: none
• Reviewer handoff: Reviewers must confirm that core pages render, primary navigation has no dead ends, contact/legal routes remain reachable, the website build passes, and the website smoke suite passes while staying website-specific rather than borrowing platform-heavy lanes.
• Budget / baseline / trend impact: Small increase limited to website build and any added public-site smoke checks.
• Escalation needed: none
• Planned validation commands: corepack pnpm build:website and cd apps/website && corepack pnpm exec playwright test

User Scenarios & Testing (mandatory)

User Story 1 - Understand the Product Quickly (Priority: P1)

A first-time enterprise or MSP visitor lands on the public site and can understand what TenantAtlas does, why it differs from generic backup or reporting tools, and what to do next without seeing the product app.

Why this priority: If the public site fails to create immediate product clarity, deeper trust and conversion flows do not matter.

Independent Test: This can be tested by visiting the Home page and Product page only and confirming that the product category, audience, and primary next step are understandable from public content alone.

Acceptance Scenarios:

1. Given a first-time visitor lands on Home, When they scan the primary sections, Then they can identify what TenantAtlas does, who it serves, and why it exists.
2. Given a visitor is unsure whether TenantAtlas is only a backup tool, When they open Product, Then the site explains a connected governance model rather than a loose feature list.
3. Given a visitor wants proof of seriousness, When they move from Home into deeper pages, Then the site provides trust and ecosystem context without hype or placeholder claims.

---

User Story 2 - Evaluate Fit by Audience (Priority: P2)

An enterprise IT buyer, MSP operator, or governance stakeholder can navigate the public site to decide whether TenantAtlas fits their environment and operating model.

Why this priority: Qualified evaluation reduces mismatched leads and makes the site useful beyond top-level awareness.

Independent Test: This can be tested by navigating from the primary menu to Solutions and Integrations and confirming that audience-specific fit signals are present without requiring private collateral.

Acceptance Scenarios:

1. Given an MSP visitor opens Solutions, When they review the page, Then they find multi-tenant governance and operational-fit scenarios relevant to service providers.
2. Given an enterprise IT visitor opens Solutions, When they review the page, Then they see enterprise operating-model language clearly separated from MSP framing.
3. Given a technical evaluator opens Integrations, When they assess ecosystem fit, Then they see real integration direction only and no speculative wishlist.

---

User Story 3 - Reach a Qualified Next Step (Priority: P3)

A serious buyer can move from any core page to a clear contact or demo path with realistic expectations about who should reach out and why.

Why this priority: Conversion should feel confident and intentional, not aggressive or ambiguous.

Independent Test: This can be tested by starting on any core page and reaching the contact path without dead ends, broken hierarchy, or unclear calls to action.

Acceptance Scenarios:

1. Given a visitor is on any core page, When they look for the next step, Then a visible CTA guides them toward contact or demo.
2. Given a visitor reaches Contact / Demo, When they review the page, Then they can tell who should get in touch, what topics the conversation covers, and what response to expect.
3. Given a visitor wants legal reassurance before submitting interest, When they use the footer or contact flow, Then privacy and terms information are reachable.

Edge Cases

• What happens when a visitor lands directly on an interior page from search or a shared link? The page must still orient the visitor, reconnect them to the main product story, and expose a clear next step.
• How does the site handle claims that cannot yet be substantiated? The content must omit or soften the claim instead of implying unverified security, compliance, or automation guarantees.
• What happens when optional future sections such as blog, changelog, or docs are not yet live? Navigation and internal links must not expose dead or placeholder routes.
• How does the site behave on narrow screens or slower connections? Core navigation, copy hierarchy, and contact/legal reachability must remain usable without animation- or script-dependent gating.

Requirements (mandatory)

This feature does not introduce product-app operator surfaces, Microsoft-tenant actions, queued work, or runtime authorization changes. The public website remains a separate, workspace-owned surface with no required auth, session, or API coupling to the platform for v0.

Functional Requirements

• FR-001: The public website MUST position TenantAtlas as a trust-first governance-of-record product for Microsoft tenant and Intune configuration state, emphasizing clarity around backup, restore, version history, auditability, drift visibility, findings, exceptions, evidence, and reviews.
• FR-002: The v0 release MUST publish a Home page, Product page, Solutions page, Security & Trust page, Integrations page, Contact / Demo page, and a Legal surface. The Legal surface MUST expose Privacy and Terms content plus any jurisdiction-specific public legal notice required before launch, either within the Legal hub or via a linked dedicated notice page.
• FR-003: The site MUST provide a global page shell that includes a Home link through the brand mark, consistent primary navigation, and footer navigation that keeps core pages and legal pages reachable.
• FR-004: Home MUST explain the product category, frame the problem, present the major product pillars, establish why the product matters now, and direct visitors into deeper product, trust, and contact paths.
• FR-005: Product MUST explain the product as one connected operating model rather than as an unstructured feature inventory.
• FR-006: Solutions MUST speak to at least MSP and Enterprise IT audiences, showing how the product fits each operating model without collapsing them into one generic story.
• FR-007: Security & Trust MUST communicate product principles, trust posture, and handling of sensitive connections only at a level the team can substantiate at launch.
• FR-008: Integrations MUST show the real ecosystem fit for the product and MUST avoid speculative or wishlist-only integrations.
• FR-009: Contact / Demo MUST explain who should get in touch, common reasons to reach out, and what kind of discussion or follow-up the visitor should expect.
• FR-010: Legal content MUST be reachable from the footer and from relevant conversion paths before a visitor submits interest.
• FR-011: The website MUST use shared layout, content, conversion, and trust primitives so pages are assembled from reusable building blocks instead of page-by-page duplication.
• FR-012: The visual direction MUST feel calm, readable, technically serious, and enterprise-appropriate, while avoiding over-animation, consumer-style hype, and decorative patterns that undercut credibility.
• FR-013: Public copy MUST avoid misleading claims and banned framing such as guaranteed security outcomes, false reassurance, fully automated governance promises, or consumer/startup hype language.
• FR-014: The v0 website MUST remain independent from platform runtime concerns. It MUST NOT require product-app sessions, shared auth, or deep runtime coupling to explain the product or capture contact intent.
• FR-015: Content organization for v0 MAY remain page-managed, but the live structure MUST allow later expansion into concepts, changelog, resources, blog, or docs without rebuilding the published core-page information architecture.
• FR-016: Every published core page MUST include clear page purpose, semantic structure, discoverability basics, including page metadata, robots handling, and sitemap coverage, and a visible next step deeper into the product, trust story, or contact flow.
• FR-017: The website track MUST preserve existing workspace contracts, including the package identity, website port convention, workspace script names, and monorepo layout assumptions relied on elsewhere in the repo.
• FR-018: The launch version MUST be fully polished in one primary visual theme. Alternate theme support may be prepared, but it is not required for v0.
• FR-019: The v0 website MUST remain fully useful without introducing an unnecessary client-side application layer for core navigation, reading, and contact intent.

Key Entities (include if feature involves data)

• Core Public Page: A top-level public route with a defined narrative purpose, section hierarchy, and next-step CTA.
• Narrative Section: A reusable content block that communicates product explanation, trust evidence, audience fit, or conversion intent.
• Conversion Path: The CTA and destination flow that moves an interested visitor from discovery into contact or demo.
• Legal Surface: The set of public pages that provide privacy, terms, and any other required legal disclosures supporting launch.

Assumptions & Dependencies

• Actual company/legal facts needed for privacy, terms, and any jurisdiction-specific notice will be available before release.
• Contact handling may begin with a lightweight team-owned intake path, provided the public site sets clear expectations for purpose and follow-up.
• Product and trust claims will be limited to capabilities and operational truths that can be substantiated at launch.
• Future article, changelog, and documentation areas may remain unpublished in v0.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: A first-time visitor can identify what TenantAtlas does, who it is for, and the primary next step from the Home page within 60 seconds of reading.
• SC-002: The v0 release publishes at least seven core public surfaces, including legal access points, with no dead-end navigation from the primary menu or footer.
• SC-003: A visitor can reach a contact or demo path from any core page in two clicks or fewer.
• SC-004: Every core page includes a visible next-step CTA and at least one deeper path into the product, trust, or contact story.
• SC-005: No released page contains placeholder copy, unsubstantiated trust or compliance claims, or speculative integration promises.
• SC-006: Core pages remain readable and navigable on both desktop and mobile widths without horizontal scrolling or hidden primary navigation.