ahmido
714b910734
## 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
82 lines
6.8 KiB
Markdown
82 lines
6.8 KiB
Markdown
# 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.
|