project_offer Frontend-Decomposition — Layer A (MVP) + Layer B (Post-MVP)

Kontext

Story P2503-108 (F-290) synchronisiert SF-Publications via BH4SF REST-Pull nach Drupal (ADR-0029). Das Backend-Modul solcom_project_offer (Sub-Tasks P2503-128/129) ist bereits committed. Die Frontend-Seite — also die Darstellung der synced Project-Offers für Besucher — wurde im Refinement-Grilling als eigenständige Scope-Schicht identifiziert.

Das Figma liefert zwei entscheidende Frames für diesen Layer:

• Frame 1019-78888 (Detail-Page): Komposition aus bubble-profile, card-meta-list, meta-row, button, Cross-Sell-Slot und Sticky-CTA-Bar. Entspricht konzeptionell dem Vacancy-Detail-Layout (ADR-0014), aber ohne editorialen Workflow (ADR-0026).
• Frame 985-50077 (List-Card): prop-driven Card-Variante mit card-meta-list. Ist eine Variante des bestehenden byte_theme/card-SDC (ADR-0009), kein eigenes SDC.

Das Refinement hat die naive Annahme „project_offer = vacancy 1:1 klonen" korrigiert. Die Unterschiede zur Vacancy-Detail-Page (ADR-0014) sind:

• Kein Featured-Slot (Vacancy hat Hero-Billboard-Slot oben)
• Kein Related-View im Detail (Vacancy hat „Ähnliche Stellen"-Block)
• Cross-Sell-Block statt Related-View: PPP-eigener Custom-Block-Plugin
• Sticky-CTA-Bar in Detail: eigener Canvas-Slot, keine generische Drupal-Block-Region

Gleichzeitig gibt es 9 weiterte Features (Layer B: Geo-Filter, Skill-Badges, Merkliste, …), die technisch komplex sind und für den MVP-Go-Live 08.07.2026 nicht benötigt werden. Sie einzeln in einen Riesen-PR zu packen würde die Review-Last erheblich erhöhen und den MVP-Termin gefährden.

Die zentrale Frage war: Aufteilen in Layer A + B, oder lieber alles auf einmal ausliefern, um spätere Nacharbeit zu vermeiden?

Entscheidung

Zweistufige Frontend-Lieferung. Layer A ist MVP-Pflicht (Sub-Tasks P2503-137 bis P2503-145 im laufenden PR), Layer B wird als separate Story nach MVP-Go-Live geplant (Sub-Tasks P2503-147 bis P2503-152).

Layer A — MVP (in Branch feature/P2503-108)

Layer B — Post-MVP (separate Story nach 08.07.2026)

Vacancy-Parität als Implementierungs-Schablone

Bundle project_offer spiegelt vacancy — Pathauto-Patterns (/projektpartnerportal/{title} analog /stellenangebote/{title}), gleiche SDC-Bausteine (bubble-profile, card-meta-list, button, meta-row). Das Vacancy-Canvas-Template (ADR-0014) dient als Blaupause für project_offer.full, aber die Slot-Konfiguration weicht ab (kein Featured-Hero-Slot, Cross-Sell statt Related-View). Die Canvas-Card-Template-Variante folgt dem Muster von vacancy.card (prop-driven, keine eigenen SDC-Bausteine, nur Konfiguration via Canvas-API).

Rejected alternatives

1 — Alles auf einmal (Layer A + Layer B) im MVP-PR

Scope würde 13 Sub-Tasks (P2503-137 bis P2503-152) plus den Pre-Build-Gate P2503-146 (FCSB-Live-Describe) in einem einzigen PR bündeln. Konsequenz:

• Geo-Filter (P2503-149) hat unbekannte Drupal-Geocoder-Abhängigkeiten, die zu Blocker-Risiko bis Go-Live werden.
• Merkliste (P2503-150) und Projekt-Alert (P2503-152) sind User-Features mit eigenem Auth-Scope — beide hängen von F-400 (User-Linking Phase 2) ab.
• Review-Last für den PR steigt linear mit Sub-Task-Anzahl; Scope-Creep-Risiko ist dokumentiert.
• Rejected: Go-Live 08.07.2026 ist harter Termin. Lieber solider MVP als verzögerter Vollausbau.

2 — Komplett eigenes Bundle ohne Vacancy-Parität

Statt project_offer als Vacancy-Spiegel zu modellieren, könnte ein eigenständiges Bundle mit eigenen Feldnamen, eigenen View-Modes und eigenen SDCs gebaut werden.

• Vorteil: maximale Entkopplung.
• Nachteil: Theme-Drift — zwei fast identische SDC-Konfigurationen (vacancy.full und project_offer.full) divergieren über Zeit, Pflege verdoppelt sich.
• Nachteil: Keine Code-Wiederverwertung der vorhandenen Vacancy-Canvas-Templates und SDC-Patterns, die bereits validated sind (ADR-0014, ADR-0013).
• Rejected: Vacancy-Parität ist praxiserprobte Schablone, die Drift-Risiko minimal hält.

3 — Reaktive State-Bibliothek (Vue/React) für Filter

Für den project_offers_listing-View könnten die 5 Filter als Vue- oder React-Komponenten implementiert werden, die per API die Ergebnisliste nachladen.

• Vorteil: flüssigere UX beim Filtern, kein Full-Page-Reload.
• Nachteil: JS-Bundle für einen einzigen View-Filter, der primär SEO-relevante Ergebnisse ausliefert (Publications sind indexiert). BEF + AJAX-View reicht funktional aus.
• Nachteil: erhöhte Komplexität beim Decoupled-Setup (API-Endpoint, CORS, Auth für anonyme User) weit over-engineered für den vorliegenden Use Case.
• Rejected: BEF + AJAX-View ist der etablierte Drupal-Weg für gefilterte Views, kein eigenständiges JS-Framework nötig.

4 — Canvas-Card als eigenes SDC statt Variante von byte_theme/card

Für Frame 985-50077 (List-Card) könnte ein eigenes byte_theme/card-project-offer-SDC angelegt werden.

• Nachteil: Card-Familie (ADR-0009, ADR-0017) hat klare Zuständigkeiten. Ein fünftes Card-SDC für einen single-bundle Use Case widerspricht dem Pattern.
• Figma-Analyse hat bestätigt: Frame 985-50077 ist strukturell identisch mit der bestehenden Card-Variante — nur die Prop-Belegung unterscheidet sich (Publication-spezifische Felder).
• Rejected: Prop-driven Variante via Canvas-Card-Template ist das richtige Pattern (ADR-0009).

Consequences

Sofortige Konsequenzen (Layer A)

• Zwei neue Canvas-Templates: canvas.content_template.node.project_offer.full (P2503-140) und canvas.content_template.node.project_offer.card (P2503-141) wurden als Config-YAML in config/sync/ angelegt. Figma-Frames 1019-78888 resp. 985-50077 sind die visuellen Ankerpunkte.
• Pathauto-Pattern: /projektpartnerportal/[node:title] (P2503-142). Neue URL-Struktur ist nach Go-Live kaum noch änderbar — Entscheidung ist bindend.
• View project_offers_listing: 5 BEF-Filter (Branche, Skills, Remote-Anteil, Ort/PLZ, Vollzeit/Teilzeit). Geo-Proximity-Filter explizit Layer B.
• Custom-Block-Plugin PPP-Cross-Sell: im Custom-Modul solcom_project_offer als BlockBase-Plugin (P2503-144). Dieser Block ersetzt den Related-View-Slot in Detail-Page und List-Page.
• Kein Editorial-Workflow (ADR-0026): project_offer-Nodes werden nicht durch Redakteure bearbeitet. Der Drupal-Publish-Status folgt dem SF-Lifecycle (SC_PublicationStatus__c == "Online"). Die Vacancy-Editorial-Ausnahme gilt analog.

Bewusste Restrisiken

• Layer-B-Schulden: Die 6 Post-MVP-Features sind in Jira als Sub-Tasks erfasst (P2503-147 bis P2503-152), aber noch nicht Bestandteil eines priorisierten Sprints. Risiko: Layer B wird nach Go-Live deprioritisiert und bleibt dauerhaft offen.
• Geo-Filter-Blocker: P2503-149 (Suchradius-Filter) hat unbekannte Geocoder-Drupal-Abhängigkeiten und könnte bei Aufnahme in Layer B seinerseits einen Pre-Build-Gate brauchen.
• Vacancy-Parität-Drift: Wenn Vacancy-Canvas-Templates (ADR-0014) sich weiterentwickeln, muss project_offer.full manuell nachgezogen werden. Kein automatischer Sync.

Folge-Stories (nicht in diesem ADR)

• Layer-B-Sprint-Planung nach Go-Live (Termin offen).
• User-Linking Phase 2 (F-400) als Voraussetzung für Merkliste (P2503-150) und Projekt-Alert (P2503-152).
• FCSB-Live-Describe (P2503-127) als Pre-Build-Gate für Layer-B-Features, die auf Field-Drift sensitiv sind.

Amendment 2026-05-14

Customer-Lens

Voraussichtliche Lens-Anwendung (zur Vorbereitung der Konsultation):

• Figma-Parity-Lens: Frames 1019-78888 und 985-50077 müssen im Canvas-Output erkennbar wiedergegeben werden. Sticky-CTA-Bar in Detail und Cross-Sell-Block in List sind für die Besucher-Journey relevant.
• A11y-Lens: Card-Meta-List-SDC und Bubble-Profile-SDC tragen WCAG-2.1-AA-Verantwortung. BEF-Filter-Widgets müssen keyboard-navigierbar sein.
• Performance-Lens (N/A für Layer A): BEF + AJAX-View wird clientseitig keine signifikante JS-Last hinzufügen. Layer B (Geo-Filter) könnte Maps-Integration erfordern — dann Performance-Lens relevant.