Skip to content

vt-d-pd-3-prototype

Generate a deployable prototype following VisiTrans Corporate Design. Stack-aware — Angular 21 + PrimeNG for B2B SaaS product UIs (VisiMatch, VisiFair, VisiArea, VisiTrans Data, etc.) and Astro 4 + Tailwind + Shadcn/UI for marketing websites (visitrans.de, visimatch.com, visifair.com). Includes mock data, responsive layouts, dark/light themes, and 95% code-reuse target for handoff.

Plugin: vt-product-dev
Category: Product Design Workflow
Command: /vt-d-pd-3-prototype


Product Design: Prototype Creation

Create production-quality prototypes that developers can reuse (95% code retention). Prototypes follow VisiTrans Corporate Design and serve as both stakeholder demos and development handoff.

Stacks (pick one per project — see Step 0b: Stack Selection):

Stack Use For Key Tech
Angular (default for apps) B2B SaaS product UIs that need state, forms, dashboards, app shell Angular 21 + PrimeNG (Styled Mode) + PrimeFlex
Astro (default for sites) Marketing/corporate websites (visitrans.de, visimatch.com, visifair.com) Astro 4 + Tailwind + Shadcn/UI + React Islands

Both stacks consume the same VisiTrans design tokens via the vt-b-visitrans-design-system skill (~/.claude/skills/vt-b-visitrans-design-system/colors_and_type.css + assets/logos/).

Workflow Position

/vt-d-pd-0-start → /vt-d-pd-1-research → /vt-d-pd-pid → /vt-d-pd-2-prd → /vt-d-pd-3-prototype → /vt-d-pd-4-validate → /vt-d-pd-6-handoff → /vt-d-activate
                                                          └── You are here
                                                    Output: 04-prototyp/

Invocation

/vt-d-pd-3-prototype                            # Create new prototype (asks for stack)
/vt-d-pd-3-prototype --stack angular            # Force Angular 21 + PrimeNG
/vt-d-pd-3-prototype --stack astro              # Force Astro + Tailwind + Shadcn
/vt-d-pd-3-prototype --feature NAME             # Add feature to existing prototype
/vt-d-pd-3-prototype --deploy                   # Deploy for sharing

Configuration

# Project paths
prototype_folder: "04-prototyp"
prd_path: "03-PRD/PRD.md"
design_system_path: "ONEDRIVE_ROOT/03-Corporate Design/03-cd-manual/VisiTrans_CD_*.pdf"

VisiTrans Corporate Design Tokens

From VisiTrans_CD_03.11.2025_EW01.pdf:

Colors

:root {
  /* Primary Colors */
  --vt-black: #101216;
  --vt-orange: #FC9E00; /* CMYK 0 38 100 0 */
  --vt-white: #FFFFFF;

  /* Secondary - Gray Scale */
  --vt-gray-90: #2D2D2D;
  --vt-gray-70: #5C5C5C;
  --vt-gray-50: #8A8A8A;
  --vt-gray-30: #B8B8B8;
  --vt-gray-10: #E6E6E6;

  /* Secondary - Orange Scale */
  --vt-orange-dark: #CC5200;
  --vt-orange-light: #FF944D;

  /* Action Color */
  --vt-magenta: #E6007E;
}

Typography

:root {
  --vt-font-family: 'Inter', sans-serif;

  /* Font Weights */
  --vt-font-thin: 100;
  --vt-font-extralight: 200;
  --vt-font-light: 300;
  --vt-font-regular: 400;
  --vt-font-medium: 500;
  --vt-font-semibold: 600;
  --vt-font-bold: 700;
  --vt-font-extrabold: 800;
  --vt-font-black: 900;
}

Brand Products

  • VisiTrans (parent company) - Orange
  • VisiMatch (matching platform)
  • VisiFair (trade fair management)
  • VisiArea (venue management)

Iteration Loop Integration

Step 0: Check Design State (Before Starting)

Before beginning prototype work, check the design state:

# Load design state
Read: .design-state.yaml

# Check for pending inbox items
if inbox.pending_items exists:
  Run: /vt-d-pd-inbox-scan to process first

If this is an iteration (returning to prototype):

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration Context: pd-3-prototype
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Returning to prototype phase (Iteration {n})

Trigger: {trigger from state file}
Reason: {reason from state file}

Previous prototype version: {artifacts.prototype.version}
Issues to address:
• {items from iteration trigger}

Focus: Update affected components and screens
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Quality Gate: pd-3-prototype

Mark phase as complete when: - [ ] VisiTrans CD tokens correctly applied - [ ] All PRD features have screens - [ ] Responsive layouts work (mobile, tablet, desktop) - [ ] Prototype deployed and accessible

Update state file on completion:

quality_gates:
  pd-3-prototype:
    passed: true
    passed_at: "{timestamp}"
    criteria:
      cd_compliant: true
      all_features_represented: true
      deployed: true

artifacts:
  prototype:
    version: "{increment}"
    hash: "{compute directory hash}"
    status: "deployed"
    deploy_url: "{url}"


PRD Delta Tracking (Active Throughout Prototyping)

During prototyping, user feedback often reveals requirement changes that affect the PRD. Track these continuously:

  1. At prototype start: Create 03-PRD/PRD-DELTA.md if it doesn't exist, with this header:

    # PRD Delta Log
    
    Changes to requirements discovered during prototyping and validation.
    Review and incorporate into PRD before proceeding to /vt-d-pd-6-handoff.
    
    ---
    

  2. After each user interaction: If the user provided any of the following, append an entry to PRD-DELTA.md:

  3. Factual corrections ("actually there are 60, not 3")
  4. Scope changes ("we also need X")
  5. New requirements ("it should also support Y")
  6. Assumption corrections ("that's not how it works, it's actually...")
  7. Data/content changes ("the categories are different")
  8. Technical constraints ("the API doesn't support that")

  9. Entry format:

    ## [YYYY-MM-DD HH:MM] Category: Brief Title
    
    - **PRD Section**: [affected section]
    - **Was**: [original assumption or value]
    - **Now**: [corrected/new information]
    - **Impact**: [what this changes about the design]
    - **Source**: User feedback during prototype iteration
    

Categories: Scope Change, New Requirement, Requirement Update, Assumption Correction, Data Change, Constraint Discovered

  1. At prototype completion: Show summary of accumulated deltas and remind user to review before /vt-d-pd-6-handoff.

Execution Instructions

Step 0b: Stack Selection

Determine the stack before scaffolding. Resolution order:

  1. --stack flag — if angular or astro was passed, use it.
  2. PRD signal — if PRD Section 4 mentions any of: dashboard, app shell, role-based access, forms-heavy workflow, mobile app target → recommend angular. If it mentions: marketing, SEO, landing page, blog, content collections, public website → recommend astro.
  3. Project context — if working inside V024-Websites-dev/, default to astro. Inside any apps/ of a B2B SaaS repo (VisiMatch, VisiFair, VisiArea, VisiTrans Data, VisiTrans Guide), default to angular.
  4. Ask — if still ambiguous, use AskUserQuestion to confirm. Recommended option goes first with "(Recommended)".

Persist the selection to .design-state.yaml:

prototype:
  stack: angular  # or astro
  stack_reason: "PRD describes role-based dashboards and form workflows"

After Step 0b, jump to Path A (Angular, Steps 1–7 below) or Path B (Astro, in its own section after Path A's Quality Checklist). The vt-b-visitrans-design-system skill is consumed by both paths.


Path A — Angular 21 + PrimeNG (B2B SaaS apps)

Step 1: Analyze PRD and Features

  1. Read PRD to understand features to prototype
  2. Identify key user flows from Section 3 (Lösungsvision)
  3. List required screens from Feature table (Section 4)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Prototype Creation - Product Design Phase 3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Project: [name]
PRD: 03-PRD/PRD.md
Output: 04-prototyp/

Features to Prototype:
─────────────────────────────────────────────────────────────────
1. [Feature 1] - [N screens] (from PRD Section 4)
2. [Feature 2] - [N screens]
3. [Feature 3] - [N screens]

Design System: VisiTrans CD
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 2: Initialize Prototype Project

Create project structure in 04-prototyp/:

04-prototyp/
├── angular.json
├── package.json
├── tsconfig.json
├── tsconfig.app.json
├── vitest.config.ts
├── public/
│   ├── fonts/
│   │   └── Inter/             # VisiTrans font
│   └── images/
│       └── logo.svg           # VisiTrans logo (source: BRAND_ASSETS_ROOT — see CLAUDE.md)
├── src/
│   ├── app/
│   │   ├── core/
│   │   │   ├── theme/
│   │   │   │   └── vt-preset.ts   # PrimeNG VisiTrans preset
│   │   │   ├── services/
│   │   │   │   └── mock-data.service.ts
│   │   │   └── interceptors/
│   │   ├── shared/
│   │   │   └── components/        # Shared UI components
│   │   ├── features/
│   │   │   └── [feature]/
│   │   │       ├── [feature].component.ts
│   │   │       ├── [feature].component.html
│   │   │       └── [feature].routes.ts
│   │   ├── app.component.ts
│   │   ├── app.config.ts         # providePrimeNG() setup
│   │   └── app.routes.ts
│   ├── styles.css                 # VisiTrans CD styles + PrimeNG
│   ├── main.ts
│   └── index.html
└── README.md

Step 3: Install PrimeNG Preset with VisiTrans CD

src/app/core/theme/vt-preset.ts — generate it, do not copy it:

python3 TOOLKIT_ROOT/scripts/design_system/generate_primeng_preset.py \
  --product visitrans --output src/app/core/theme/vt-preset.ts

The generator is the canonical — and only — source for the preset: it reads the token file and emits both the light and the dark colorScheme (each with its own surface ramp and formField block), plus the darkModeSelector wiring and its verification steps in the file header. Run it with no --output to read the preset without writing a file. /vt-d-bootstrap invokes this same generator; it deliberately carries no inline copy to hand-transcribe — a second copy drifts from the tokens the moment either changes.

src/styles/vt-variables.css — copy ~/.claude/skills/vt-b-visitrans-design-system/colors_and_type.css into src/styles/ (or import it directly if using a monorepo asset pipeline). This file ships the complete CSS custom property set for both themes. Dark is :root; light is the :root[data-theme="light"] opt-in. A logged-in product UI is the one surface that offers both — implement the switcher from vt-b-visitrans-design-system § "Light↔dark switcher (logged-in product UI)"; do not re-author it here — a second copy drifts silently.

src/app/app.config.ts — use the template from /vt-d-bootstrap section "Angular App - app.config.ts" which wires providePrimeNG() with the preset.

Step 4: Create Base Components

Generate reusable Angular standalone components following VisiTrans CD, wrapping PrimeNG components:

  • VtButtonComponent — wraps p-button, inputs for variant and size
  • VtCardComponent — wraps p-card, input for elevation
  • VtInputComponent — wraps p-inputtext + p-floatlabel, inputs for label and error
  • VtNavigationComponent — uses p-menubar with routerLink/routerLinkActive

All components use Angular 21 conventions: - Standalone (no NgModule) - inject() for DI (no constructor injection) - Modern template syntax (@if, @for, @switch) - Signals for reactive state where needed

(See /vt-b-visitrans-design-system --components for full component templates)

Step 5: Generate Feature Screens

For each feature in PRD Section 4:

  1. Create feature folder: src/app/features/[feature]/
  2. Generate standalone route components (.component.ts + .component.html)
  3. Create lazy-loaded route file ([feature].routes.ts)
  4. Create mock data service in core/services/
  5. Implement responsive layouts using PrimeFlex grid

See /vt-d-kw-prototype Steps 5–6 for feature screen and mock data service examples.

Step 6: Deploy Mode (--deploy)

When --deploy is specified:

  1. Build production version: npm run build
  2. Deploy to Vercel/Netlify/GitHub Pages
  3. Return preview URL for stakeholder sharing

Step 7: Summary

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Prototype Created
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Location: 04-prototyp/
Framework: Angular 21 + PrimeNG (Styled Mode)
Styling: PrimeNG preset + VisiTrans design tokens

Components Created:
─────────────────────────────────────────────────────────────────
• Base UI: VtButton, VtCard, VtInput, VtNavigation (PrimeNG wrappers)
• Feature 1: [N screens]
• Feature 2: [N screens]

Design System Applied:
✓ VisiTrans colors via PrimeNG three-tier token preset
✓ Inter font family
✓ Consistent spacing and typography
✓ Responsive layouts (PrimeFlex grid)

Development Handoff:
─────────────────────────────────────────────────────────────────
This prototype is designed for 95% code reuse:
• Standalone components follow production patterns
• PrimeNG preset matches production theming
• Mock data services match API contracts

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEXT STEPS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Review prototype: npm run dev
2. Deploy for sharing: /vt-d-pd-3-prototype --deploy
3. Validate with users: /vt-d-pd-4-validate
4. Prepare handoff: /vt-d-pd-6-handoff
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Update PRD Feature Table

After prototype creation, update PRD Section 4 Feature table: - Add Prototyp column links to specific prototype screens - Links follow pattern: 04-prototyp/src/app/features/[feature]/[feature].component.ts

Integration with Product Design Workflow

/vt-d-pd-2-prd        ← PRD defines what to prototype
/vt-d-pd-3-prototype  ← YOU ARE HERE - Create prototype
/vt-d-pd-4-validate   ← Test prototype with users

Integration with Design Agents

Prototype Refinement Loop

After the prototype is generated, refine it with the chain of helper skills and agents below before handing off to /vt-d-pd-4-validate. This is a recommendation, not a mandate (Empfehlung, nicht Zwang) — apply only the helpers whose trigger fires, in any order.

Full sequence, per-helper triggers, and a worked VisiMatch example live in the guide: Prototype Refinement Loop.

The canonical refinement helper set (5 skills + 3 agents = 8) — keep in sync with the identical table in the guide; the tests/spec-134/ drift-guard test parses both:

Helper Type
visitrans-design-system skill
frontend-design skill
gemini-imagegen skill
webapp-testing skill
container-logistics-ux-expert skill
design-iterator agent
figma-design-sync agent
design-implementation-reviewer agent

One-line trigger per helper (details in the guide):

  • visitrans-design-system (skill) — CD compliance (tokens, logos, theme); almost always, first.
  • frontend-design (skill) — distinctive UI polish; when the UI feels generic.
  • gemini-imagegen (skill) — hero / placeholder imagery; when imagery is missing.
  • design-iterator (agent) — systematic visual refinement; visible gaps or >1–2 manual passes without convergence.
  • figma-design-sync (agent) — Figma parity; only when a Figma source exists.
  • design-implementation-reviewer (agent) — impl-vs-Figma review; only when a Figma source exists.
  • container-logistics-ux-expert (skill) — domain UX critique; explicitly, when PRD domain = container/logistics.
  • webapp-testing (skill) — interaction smoke test; last, before /vt-d-pd-4-validate.

Recommended order: visitrans-design-systemfrontend-design / gemini-imagegendesign-iteratorfigma-design-syncdesign-implementation-reviewercontainer-logistics-ux-expertwebapp-testing. Only the first and last apply to nearly every prototype; the middle steps are conditional on their triggers.

Decision-Log & Journal Integration

During prototype iteration the why behind small changes (layout, component choice, token switches) is easily lost, leaving the PRD and user-manual to drift from what was actually built (SPEC-135, Wave 1). This wires two existing skills into the pd-3 loop. Both steps are opt-in and opt-out-able — apply them per iteration, skip them freely ("jeder Schritt opt-out-bar").

(a) Start the journal side-car (opt-in, at iteration start). When beginning an iteration with --feature NAME, optionally start /vt-c-session-journal in its pd-3 Iteration Side-Car Mode, which appends rationale to the feature side-car:

docs/vt-c-journal/pd3/journal-pd3-<feature>.md

Start is manual/opt-in, never automatic (SPEC-135 Decision 4). The journal's standard triggers ("after significant code changes", "after design decisions", "when rationale is explained") then collect the reasoning as you work.

(b) Capture the decision at iteration end (manual signal). When the iteration is done, manually invoke /vt-d-pd-capture-decisions in pd-3 prototype-iteration mode. There is no iteration-counter or auto-trigger in Wave 1 — the user signals iteration end (SPEC-135 Decision 3). That mode reads the side-car above plus the iteration's git-diff and drafts one record per logical iteration:

docs/decisions/NNN-prototype-<feature>-iter-<N>.md

You review and edit the draft before commit. One record per iteration — not per file-edit.

Full chain, worked example, and the deferred US-3/US-4 follow-ups live in the guide: Prototype Decision-Log.

Testing Configuration (Angular 21)

Angular 21 uses Vitest as its default test runner. The vitest.config.ts in the project structure must be configured for zoneless testing:

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    include: ['src/**/*.spec.ts'],
    globals: true,
    environment: 'jsdom',
    setupFiles: ['src/test-setup.ts'],
  },
});
// src/test-setup.ts
import '@angular/compiler';
import { TestBed } from '@angular/core/testing';
import { provideZonelessChangeDetection } from '@angular/core';

TestBed.configureTestingModule({
  providers: [provideZonelessChangeDetection()],
});

package.json scripts must use vitest, not ng test:

{
  "scripts": {
    "test": "vitest",
    "test:watch": "vitest --watch",
    "test:coverage": "vitest --coverage"
  }
}

Include at least one sample component test demonstrating Signals and zoneless patterns.


Path B — Astro 4 + Tailwind + Shadcn/UI (marketing websites)

Use this path for public marketing/corporate sites: visitrans.de, visimatch.com, visifair.com, future product landings. Reference codebase: V024-Websites-dev (Astro monorepo).

Step 1: Analyze PRD and Features

  1. Read PRD to understand pages and content collections
  2. Identify SEO-critical entry points (hero, pricing, careers, blog, legal)
  3. Identify which interactive surfaces need React Islands (forms, calculators, animated demos) vs static Astro components
  4. Confirm brand and surface: visitrans (German), visimatch (English), visifair (accent, German). Theme comes from the surface, never the brand — a marketing website, a presentation or a logged-out product screen is dark for every brand; only logged-in product UI offers switchable light.

Step 2: Initialize Prototype Project

For a standalone prototype, scaffold a single Astro app at 04-prototyp/. For work inside the monorepo, scaffold under apps/0X-{brand}/:

04-prototyp/                     (or apps/0X-{brand}/ in V024 monorepo)
├── astro.config.mjs
├── tailwind.config.ts
├── package.json
├── tsconfig.json
├── public/
│   ├── fonts/Inter/             (self-hosted .woff2 — see CD non-negotiable #11)
│   └── logos/                   (copy from ~/.claude/skills/vt-b-visitrans-design-system/assets/logos/)
├── src/
│   ├── styles/
│   │   ├── tokens.css           (re-export from vt-b-visitrans-design-system/colors_and_type.css)
│   │   └── globals.css          (Tailwind layers + brand resets)
│   ├── components/
│   │   ├── ui/                  (Shadcn-derived primitives — Button, Card, Input)
│   │   ├── brand/               (VtLogo, VtLockup, VtEyebrow — wraps the static lockup PNGs)
│   │   ├── sections/            (Hero, FeatureGrid, CustomerLogoBar, FAQ)
│   │   └── islands/             (React Islands — interactive widgets only)
│   ├── content/                 (Astro Content Collections — features, customers, blog)
│   ├── layouts/
│   │   ├── BaseLayout.astro     (loads tokens, head metadata; dark by default)
│   │   └── MarketingLayout.astro
│   ├── pages/
│   │   ├── index.astro
│   │   └── [slug].astro
│   └── env.d.ts
└── README.md

Step 3: Apply VisiTrans Tokens

The full design system lives in the toolkit skill. Wire it in (do not duplicate values):

# Copy token CSS into prototype (or symlink in monorepo)
cp ~/.claude/skills/vt-b-visitrans-design-system/colors_and_type.css src/styles/tokens.css

# Copy lockups
cp -r ~/.claude/skills/vt-b-visitrans-design-system/assets/logos/* public/logos/

Tailwind config reads the same custom properties:

// tailwind.config.ts
import type { Config } from 'tailwindcss'

export default {
  content: ['./src/**/*.{astro,tsx,ts,mdx}'],
  theme: {
    extend: {
      colors: {
        'vt-orange':   'var(--vt-orange)',     // #FF9E00
        'vt-magenta':  'var(--vt-magenta)',    // #FF00FF (pure)
        'vt-yellow':   'var(--vt-yellow)',     // status only
        'vt-green':    'var(--vt-green)',      // status only
        'vt-cyan':     'var(--vt-cyan)',       // status only
      },
      fontFamily: { sans: ['Inter', 'sans-serif'] },
      letterSpacing: { tight: '-0.025em', eyebrow: '0.18em' },
    },
  },
} satisfies Config

BaseLayout.astro needs no theme attribute for a website — dark is the CSS default in colors_and_type.css for every brand, including VisiTrans corporate and VisiFair. Set data-theme="light" only on a logged-in product surface, and pair it with the switcher rather than hardcoding light (see vt-b-visitrans-design-system § Light↔dark switcher). Dark adds the 64×64 grid + radial orange spotlight signatures from the brand bible.

Step 4: Create Base Components

Build the minimal Shadcn-derived primitive set, themed with VisiTrans tokens. Components live in src/components/ui/ and are imported by Astro pages and React Islands alike:

  • Button — three intents: primary (orange + glow on dark, magenta on light), secondary (outline), ghost. No transforms; only ~150ms color fades.
  • Card — flat surface, border on light / bg-white/[0.02] on dark.
  • Input — Inter Medium 16px; magenta focus ring on light, orange on dark.
  • Eyebrow — uppercase, 12px, weight 600, tracking-eyebrow, orange.
  • VtLockup — picks the right assets/logos/ PNG by brand × theme (e.g., bl-or on light, wh-or on dark). Never typeset wordmarks by hand.

Icons: Lucide via CDN, 2px stroke, currentColor. No icon library bundled.

Step 5: Generate Section Components & Pages

For each PRD section/page:

  1. Create section component(s) in src/components/sections/ (Astro for static, React Island for interactive)
  2. Create page in src/pages/ composing sections under a layout
  3. For repeating data (features, customers, testimonials), define a Content Collection in src/content/ and use getCollection()
  4. Use text-wrap: balance on display headlines, pretty on body. Self-host Inter .woff2.

Customer logo bar: COSCO / ZIM / ONE for VisiMatch; Landesmesse Stuttgart / Messe Berlin / NürnbergMesse for VisiFair. Tagline lockup: "Software für komplexe Operationen — Made in Germany".

Step 6: Deploy Mode (--deploy)

npm run build
# Vercel:    vercel --prod
# Netlify:   netlify deploy --prod
# Cloudflare: wrangler pages deploy dist

Step 7: Summary (Astro)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Prototype Created — Astro
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stack:    Astro 4 + Tailwind + Shadcn/UI + React Islands
Brand:    {visitrans|visimatch|visifair}
Theme:    {light|dark}
Tokens:   src/styles/tokens.css (sourced from vt-b-visitrans-design-system)

Pages Created:
─────────────────────────────────────────────────────────────────
• Static:      [N pages]   (Astro components, SEO-friendly)
• Islands:     [N widgets] (React, interactive only)
• Collections: [N entries] (features, customers, etc.)

Brand Compliance:
✓ Locked palette only (no invented colors)
✓ Inter self-hosted (no Google Fonts in production)
✓ Lockups from assets/logos/ (no hand-typeset wordmarks)
✓ Cross-brand-link prohibition respected

Handoff to V024-Websites-dev:
─────────────────────────────────────────────────────────────────
• Components map 1:1 to packages/01-ui/
• Pages map to apps/0X-{brand}/src/pages/
• Content collections re-importable directly
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Testing Configuration (Astro)

  • Vitest for component-level tests (src/components/**/*.spec.ts)
  • Playwright for end-to-end (tests/e2e/*.spec.ts) — required for any page with React Islands
  • Lighthouse CI in package.json scripts; performance budget ≥ 95, SEO ≥ 100
  • One sample test per layer at minimum
{
  "scripts": {
    "test": "vitest",
    "test:e2e": "playwright test",
    "lhci": "lhci autorun"
  }
}

Quality Checklist

Universal (both stacks)

  • [ ] VisiTrans tokens applied via vt-b-visitrans-design-system/colors_and_type.css (no hardcoded hex)
  • [ ] Inter font loaded — self-hosted .woff2 in production
  • [ ] Logo lockups pulled from assets/logos/ (never hand-typeset wordmarks)
  • [ ] No invented colors; only the locked Black/Orange/White primary + Magenta accent + status secondaries (Yellow/Green/Cyan)
  • [ ] Voice & tone match brand bible (no exclamation marks, no emoji, Sie in German)
  • [ ] Cross-brand links between VisiMatch and VisiFair are absent
  • [ ] Responsive at mobile/tablet/desktop
  • [ ] Mock data realistic (real customer names where available: COSCO, ZIM, ONE, Messe Berlin, etc.)
  • [ ] All pages/screens from PRD accessible

Path A: Angular only

  • [ ] PrimeNG preset generated (vt-preset.ts) — wraps tokens in three-tier model
  • [ ] Components are standalone (no NgModule), use inject(), modern template syntax
  • [ ] Vitest configured zoneless; one sample component test passes
  • [ ] PrimeFlex grid used for responsive layouts

Path B: Astro only

  • [ ] Tailwind config reads CSS custom properties (no value duplication)
  • [ ] Static-vs-Islands split is intentional (Islands only for interactive widgets)
  • [ ] Content Collections used for repeating data (features, customers)
  • [ ] BaseLayout renders dark with no data-theme attribute (a website is dark for every brand), and the dark-theme signatures (grid + radial spotlight) match the brand bible
  • [ ] Lighthouse: performance ≥ 95, SEO ≥ 100