ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
website-dev
TenantAtlas/specs/405-dach-trust-datenschutz-security-website-surface/research.md
ahmido 714b910734 405: DACH Trust, Datenschutz & Security Website Surface (#400) 
## Summary
- add a dedicated public trust, privacy, and security surface for DACH evaluation
- expand homepage trust discoverability and localized trust handoff copy
- add and update smoke coverage plus Spec Kit artifacts for feature 405

## Validation
- corepack pnpm --dir apps/website build
- WEBSITE_PORT=4322 corepack pnpm exec playwright test tests/smoke/public-routes.spec.ts tests/smoke/interaction.spec.ts

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #400
2026-05-26 00:11:27 +00:00

6.8 KiB
Raw Permalink Blame History

Phase 0 Research: DACH Trust, Datenschutz & Security Website Surface

Decision: Keep the existing /trust and /en/trust routes instead of introducing /vertrauen

Rationale: The current website already renders /trust, exposes it from German and English navigation/footer copy, and includes it in the Playwright route inventory. Keeping that route preserves discoverability, smoke coverage, metadata wiring, and existing public links while still allowing the visible German label to remain Vertrauen.

Alternatives considered:

  • Introduce /vertrauen as a new German-first canonical route: rejected because it would add redirect, sitemap, and smoke complexity without a strong repo-level routing need.
  • Support both /trust and /vertrauen: rejected because it would create duplicate public truth and route-maintenance overhead for a content-only change.

Decision: Keep trust copy in src/data_files/site-copy.ts and locale-aware page components

Rationale: The public website already centralizes navigation labels, page titles, meta descriptions, and route copy in apps/website/src/data_files/site-copy.ts, while thin route files render shared Astro page components. Reusing that structure keeps trust content localized, testable, and aligned with the existing public shell.

Alternatives considered:

  • Move trust content into MDX or docs collections: rejected because the trust surface is a core marketing/legal-readiness page, not a docs entry.
  • Introduce a CMS or external content loader: rejected because the feature needs wording discipline, not a new authoring system.

Decision: Expand TrustPage.astro in place and use page-local section composition where shared blocks are too shallow

Rationale: The current TrustPage.astro is a small wrapper around MainLayout, MainSection, and FeaturesStats. That is a stable starting point, but Spec 405 needs more sections than the current generic blocks provide. Page-local sections inside TrustPage.astro are the narrowest way to deepen the page without building a cross-site trust component system prematurely.

Alternatives considered:

  • Build a new reusable trust-section library first: rejected by proportionality and current-release scope.
  • Force the entire page into existing generic section blocks: rejected because the current shared blocks do not express the required trust structure cleanly enough.

Decision: Use a bounded six-state claim-status vocabulary as a presentation rule, not a runtime framework

Rationale: The public false-assurance risk is real, but it does not justify persistence, enums in platform runtime, or a badge framework. A bounded vocabulary of documented, on request, in preparation, planned, not claimed, and not applicable gives reviewers a consistent public language while staying page-local and content-driven.

Alternatives considered:

  • Free-form prose only: rejected because it makes it too easy to blur verified facts with roadmap or request-only material.
  • A generic status/badge registry: rejected because the feature only needs claim-safe public wording on a single route family.

Decision: Reuse the existing /contact route or real mailto: destinations for trust handoff

Rationale: The current website already exposes /contact, warns users not to send secrets, and uses real business-contact wording in site copy. Reusing that path avoids fake downloads, fake security inboxes, and placeholder legal flows. If a dedicated security mailbox is not verified, the trust page can still hand off via the existing contact route.

Alternatives considered:

  • Add downloadable AVV/DPA/TOM files now: rejected because the spec explicitly forbids fake files or placeholder downloads.
  • Add a new backend request form: rejected because the website is static and backend/runtime scope is out of bounds.

Decision: Treat the public HTTP route surface as the contract and document it with OpenAPI-style GET endpoints

Rationale: The feature has no backend API, but it does expose a stable public HTTP surface: homepage entry, trust page, and contact handoff across German and English mirrors. An OpenAPI route contract is the narrowest structured artifact that still documents the observable public interface without implying a new runtime API.

Alternatives considered:

  • Omit contracts entirely: rejected because the planning workflow explicitly expects contracts/ output.
  • Invent POST APIs for trust requests: rejected because the static website does not expose them and the spec forbids runtime/API coupling.

Decision: Extend the existing Playwright smoke suite and forbidden-claim checks instead of adding a new validation stack

Rationale: apps/website/tests/smoke already covers rendered routes, metadata, placeholder links, forbidden public claims, viewport behavior, and route intent. Extending those helpers for trust-specific claim scans and route expectations is the narrowest sufficient proof.

Alternatives considered:

  • Add unit tests for copy objects only: rejected because the user-visible surface is the public HTML output, not the data file in isolation.
  • Add Laravel/Pest coverage: rejected because the feature does not touch apps/platform.

Decision: Keep localization mirrored through the existing i18n.ts and siteCopy structure

Rationale: The site already supports de and en, derives locale from the path, and localizes internal links with localizeHref(). Spec 405 needs mirrored trust posture across both locales, but it does not justify a new i18n system or route-generation model.

Alternatives considered:

  • Update German only: rejected because /en/trust is already a public route and should not drift into weaker or inconsistent trust wording.
  • Build a new translation workflow: rejected because the current locale helpers already solve the problem.

Current Source Observations

  • /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/trust.astro already routes to /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages/TrustPage.astro.
  • /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts already holds nav/footer labels, trust-page metadata, homepage trust teaser copy, and both locale dictionaries.
  • /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/i18n.ts keeps de as the default locale and mirrors public routes under /en/....
  • /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke/public-routes.spec.ts and smoke-helpers.ts already enforce placeholder-link bans and forbidden-claim scanning, including the current /trust route.
  • Root workspace scripts preserve the WEBSITE_PORT convention and call the website app through the @tenantatlas/website workspace package; those contracts should remain unchanged.