User Story
Als Nutzer moechte ich die SOLCOM-Mitarbeitenden mit Foto, Funktion und Kontaktinformationen sehen koennen, um Ansprechpartner schnell zu finden und Vertrauen aufzubauen.
Technische Beschreibung
Generischer Custom-Content-Type node.type.person mit Feldern Name, Funktion, Foto, Telefon, Email, LinkedIn-URL. View-Mode card_quote rendert via neuer prop-driven SDC byte_theme:card-person (zweiter prop-driven Sibling neben card, nach ADR-0009-Pattern). Editor-Platzierungs-Anker ist eine Canvas-Code-Component CardPerson.jsx, die node.person via JSON:API laedt.
Granulare Vacancy↔Person-Verknuepfung (Personio-Mapping per recruiter_id, ER-Feld pro Vacancy) ist deferred zu Folge-Story. Im MVP nutzen wir config_pages.career_settings.field_default_recruiter als simplen Fallback.
Architektur (locked 2026-05-25)
Decision-Authority: ADR-0046. Verwandte ADRs: ADR-0009 (prop-driven Card-Pattern), ADR-0026 (Vacancy-Editorial-Exclusion), ADR-0004 (Conditional-Schema-Anti-Pattern).
node.type.person ← Story-Scope
field_name string, required
field_funktion string, required
field_photo image, required
field_phone telephone, required (klickbar als tel:-Link)
field_email email, optional (klickbar als mailto:-Link)
field_linkedin_url link, optional (klickbar als externer Link)
entity_view_display.node.person.card_quote ← Story-Scope
rendert via SDC: byte_theme:card-person
components/card-person/ ← Story-Scope
card-person.component.yml (prop-driven, kein bubble-card-frame)
card-person.twig (Figma-Layout 62110-27008 + Kontakt-Stack)
card-person.css (Tailwind @apply, .solcom-card-person)
tests/src/Kernel/CardPersonComponentTest.php
canvas-components/CardPerson.jsx ← Story-Scope
prop: personNid (number)
fetch via JsonApiClient + SWR → node.person
render: <card-person name=... funktion=... photo=...
phone=... email=... linkedin_url=... />
config_pages.career_settings.field_default_recruiter ← MVP-Fallback
ER → node.person (eine Default-Person, im Vacancy-Detail
auto-instanziert via Canvas-Template)
Vacancy↔Person granulare Verknuepfung ← Folge-Story
(Personio-Mapping per recruiter_id, ER-Feld auf node.vacancy,
Verhandlung von ADR-0026)
Risiken & Verifikations-Punkte
Risiko VC-1 (Vacancy-Canvas-Auto-Instanziierung)
Der MVP-Fallback nimmt an, dass canvas.canvas.node.vacancy.full.yml den CardPerson-Block mit der Default-NID aus config_pages.career_settings.field_default_recruiter automatisch in der Sidebar rendert. Vor Build verifizieren: Enthaelt das Canvas-Template diesen Eintrag, oder muss ein Editor pro Vacancy einen Block manuell setzen? Letzteres bricht den MVP-Workflow und stellt ADR-0026 in Frage. Verantwortlich: erster Sub-Task der Story.
Risiko CP-1 (config_pages-Pflege-UI)
Editor:innen muessen config_pages.career_settings erreichen koennen. Default-Toolbar enthaelt vermutlich keinen Eintrag. Sub-Task „Toolbar-Link / Editor-Onboarding fuer Career-Settings" ist Pflicht.
Risiko A11Y-1 (Kontakt-Stack-Semantik)
Tel/Email/LinkedIn-Stack braucht korrekte tel:/mailto:-Schemas, aria-label fuer icon-only LinkedIn-Link und WCAG-2.1-AA-Kontrast (Figma zeigt weisse Schrift auf dunklem BG, das ist im byte_theme zu validieren). Diff-Zeit-Sache fuer den drupal-twig-sdc-reviewer.
Risiko SWR-1 (Fetch-Performance)
Pro CardPerson-Instance ein JSON:API-Request. Im MVP nur eine Instance pro Vacancy-Detail-Page → unproblematisch. Bei spaeterer Team-Uebersicht (Folge-Story) N+1-Risiko: Sammel-Request via filter[id-in] oder Pre-Hydration im Canvas-Template einplanen.
Risiko DSGVO-1 (Recruiter-Kontakte oeffentlich)
Telefonnummern und Email-Adressen einzelner Mitarbeitender werden oeffentlich gerendert. Stakeholder-Klaerung (HR / Datenschutz) vor Live-Schaltung empfohlen. Liegt ausserhalb des Story-Scopes, aber als „Geschaeftsrisiko" hier vermerkt.