TenantAtlas/specs/409-evaluation-procurement-rollout/research.md

# 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.