# Research: Evaluation, Procurement & Rollout Readiness Website Surface ## Decision: Use `/evaluierung` and `/en/evaluation` **Rationale**: The current public website already uses root-level buyer and commercial routes such as `/contact`, `/pricing`, and `/trust`, with English counterparts under `/en/*`. The evaluation journey spans demo, pilot, trust, and procurement readiness rather than one product feature, so it fits the top-level buyer-route family better than a nested `/platform/*` path. **Alternatives considered**: - `/platform/evaluation`: too tightly nested under product detail for a broader buyer-readiness flow. - `/procurement`: too narrow relative to evaluation and rollout readiness. - `/start` or `/demo-pilot`: weaker SEO and weaker alignment with the existing public route family. ## Decision: Reuse the localized thin-route plus shared-page-component pattern **Rationale**: Existing public pages already use thin locale route files plus shared page components, for example `platform.astro`, `trust.astro`, `contact.astro`, and their English wrappers. The evaluation page is section-heavy in both German and English, so one shared `EvaluationPage.astro` is the narrowest way to avoid duplicating large amounts of markup. **Alternatives considered**: - Duplicate full German and English route markup: acceptable, but repetitive and harder to maintain. - MDX/docs content route: mismatched with the current marketing-page CTA and metadata pattern. - Inline-only homepage or platform section: weaker SEO, weaker smoke coverage, and weaker discoverability. ## Decision: Keep all localized page copy in `site-copy.ts` **Rationale**: The website already centralizes public copy, metadata, navigation labels, footer links, homepage copy, platform copy, trust copy, review-pack copy, and use-case copy in `apps/website/src/data_files/site-copy.ts`. Adding a dedicated `evaluation` section there keeps the new page aligned with the existing locale strategy and avoids a second content source. **Alternatives considered**: - Page-local constants: simpler for one file, but weaker for German/English parity and CTA consistency. - Separate JSON or YAML content file: splits public copy away from the current marketing-content source of truth. - Runtime content source or CMS: out of scope for a website-only feature. ## Decision: Use `/contact` as the real conversion path for demo, pilot, and security-document requests **Rationale**: The existing public site already routes buyer-facing demo and walkthrough CTAs to `/contact` and `/en/contact`. The current public CTA pattern is route-based rather than `mailto:`-based, so `Demo buchen`, `Pilot anfragen`, and `Security-Unterlagen anfragen` should all map to the same real contact destination unless implementation discovers another real route. **Alternatives considered**: - `mailto:` links: technically possible, but not the prevailing public CTA pattern. - Fake demo-booking widget: explicitly forbidden. - New dedicated request form route: out of scope unless it already exists. ## Decision: Keep discovery contextual and global, but skip a new main-nav item **Rationale**: The current main nav is already dense. The stronger discovery path is contextual: homepage teaser, platform-page teaser, review-pack page crosslink, MSP page crosslink, Mittelstand page crosslink, and a footer link for global reachability. **Alternatives considered**: - Main-nav item: globally visible, but too expensive for current IA density. - Footer only: too weak for a commercially important page. - Homepage/platform only: helpful, but weaker for audience-specific discovery. ## Decision: Reuse existing smoke helpers and route metadata inventory as the narrowest proof **Rationale**: `apps/website/tests/smoke/public-routes.spec.ts` and `apps/website/tests/smoke/smoke-helpers.ts` already validate route rendering, metadata, placeholder-link bans, forbidden public claims, trust handoffs, and layout stability. Extending those tests is the narrowest proof for this feature. **Alternatives considered**: - Manual-only browser review: insufficient for metadata and claim-guardrail regressions. - New unit tests for copy objects: more brittle than public-route smoke for this use case. - Platform-side tests: wrong layer because `apps/platform` is explicitly out of scope. ## Decision: Use only existing website commands for validation **Rationale**: `apps/website/package.json` currently exposes `build`, `test`, `test:smoke`, `format:check`, and `preview`. The plan must not invent a `check` script because `astro check` already runs inside `build`. **Alternatives considered**: - `pnpm --filter @tenantatlas/website check`: not present. - Root script changes: out of scope and would break workspace contracts. - Platform/Sail validation: wrong scope for a static website-only page. ## Decision: Treat static claim scans as implementation blockers **Rationale**: The main risk in this feature is overclaiming rather than runtime breakage. Static scans over `apps/website/src`, `apps/website/public`, and optionally `apps/website/dist` should block placeholder links, internal architecture jargon, false legal or provider claims, fake self-service promises, and invented downloads. **Alternatives considered**: - Code review only: too easy to miss metadata or generated-output regressions. - New custom linter: too heavy for one bounded website feature. - Placeholder-link scan only: insufficient because the main risk is claim language. ## Decision: Reuse existing trust and review-story routes as adjacent handoffs **Rationale**: `/trust`, `/en/trust`, `/platform/review-packs`, and their locale-aware discovery surfaces already exist today. They are the safest real destinations for trust, security, privacy, and review-story follow-up questions from the new page. **Alternatives considered**: - Omit trust and review crosslinks: safer, but weaker than the spec goal of connecting evaluation readiness to adjacent proof surfaces. - Invent a security-pack download or procurement portal route: explicitly forbidden. ## Decision: Keep the docs evaluation checklist as documentation, not as the feature route **Rationale**: The docs route `/guides/first-project-checklist/` already touches evaluation language, but it is a documentation asset rather than a buyer-facing public conversion page. The new route should sit in the marketing/site IA, not inside docs. **Alternatives considered**: - Reusing the docs route as the public destination: wrong tone, weaker CTA handling, and weaker buyer-path visibility. - Linking only to docs from existing marketing pages: too indirect for the primary sales goal.