TenantAtlas/specs/405-dach-trust-datenschutz-security-website-surface/quickstart.md

Quickstart: DACH Trust, Datenschutz & Security Website Surface

Goal

Implement Spec 405 inside apps/website only by deepening the existing public trust route, preserving current route/localization contracts, and proving the result with website-only build and smoke checks.

1. Verify repo truth first

Run from the repository root:

git status --short --branch
cat package.json
cat pnpm-workspace.yaml
cat apps/website/package.json
find apps/website -maxdepth 3 -type f | sort | sed -n '1,240p'

Confirm:

• the website package name is @tenantatlas/website
• WEBSITE_PORT still defaults to 4321
• /trust already exists and remains the canonical trust route
• no apps/platform file is required for the change

2. Review the existing trust implementation seams

Inspect the current public shell before editing:

sed -n '1,260p' apps/website/src/data_files/site-copy.ts
sed -n '1,220p' apps/website/src/components/pages/TrustPage.astro
sed -n '1,260p' apps/website/src/components/pages/HomePage.astro
sed -n '1,200p' apps/website/src/i18n.ts
sed -n '1,260p' apps/website/tests/smoke/public-routes.spec.ts
sed -n '1,260p' apps/website/tests/smoke/smoke-helpers.ts

3. Implement the content and page structure

Expected edit targets:

• apps/website/src/data_files/site-copy.ts
• apps/website/src/components/pages/TrustPage.astro
• apps/website/src/components/pages/HomePage.astro
• navigation/footer inputs only if the current trust exposure needs adjustment
• apps/website/tests/smoke/public-routes.spec.ts
• apps/website/tests/smoke/interaction.spec.ts
• apps/website/tests/smoke/smoke-helpers.ts

Implementation guidance:

1. Expand trust copy for both de and en.
2. Keep /trust and /en/trust as the route pair.
3. Render claim-safe sections for hosting posture, privacy posture, document readiness, data categories, provider permissions, RBAC, auditability, retention, subprocessors, support access, and security handoff.
4. Use the six allowed claim statuses only.
5. Reuse /contact or a real mailto: destination for requests; do not create fake downloads.
6. Keep homepage trust discoverability lightweight and route users to the canonical trust page instead of duplicating the full content.

4. Run static scans before browser tests

Use a targeted forbidden-claim scan:

rg -n \
  -e 'href=\"#\"' \
  -e 'lorem ipsum' \
  -e 'DSGVO-konform' \
  -e 'DSGVO compliant' \
  -e 'GDPR compliant' \
  -e 'ISO certified' \
  -e 'ISO 27001 certified' \
  -e 'BSI certified' \
  -e 'NIS2 compliant' \
  -e 'hosted in Germany' \
  -e 'in Deutschland gehostet' \
  -e 'no customer data stored' \
  -e 'keine Kundendaten' \
  -e 'no personal data' \
  -e 'keine personenbezogenen Daten' \
  -e 'automatic restore' \
  -e 'autonomous remediation' \
  -e 'Google supported' \
  -e 'AWS supported' \
  apps/website/src apps/website/public apps/website/dist

Any intentional match must have a documented proof source or be rewritten.

5. Validate with website-only build and smoke coverage

corepack pnpm build:website
corepack pnpm --filter @tenantatlas/website test

If manual preview is needed:

corepack pnpm dev:website

Then verify:

• /trust loads on desktop and mobile
• /en/trust mirrors the intended trust posture
• homepage trust teaser links to the canonical trust route
• footer/navigation trust links are real
• no placeholder links remain
• no false compliance/certification/provider claims are visible

6. Final scope check

Before handing off, confirm that only website-facing files changed:

git status --short -- apps/website apps/platform
git diff --name-only
git diff --check

Expected result:

• apps/website files changed as planned
• apps/platform untouched
• no dependency, workspace-script, or build-contract drift