Block-Marken im gebackenen HTML + render-block-variant
Die zwei cms-Haelften der Baustein-A/B-Ausspielung.
1) `renderBlocksToHtml` legt um jeden TOP-LEVEL-Baustein ein Marken-Paar
`<!--ay-block:<_id>-->…<!--/ay-block:<_id>-->`. Ohne einen stabilen
Schluessel im HTML kann die Auslieferung eine Baustein-Region nicht
wiederfinden — genau daran scheiterte `target.blockKey` bisher.
Bewusst HTML-KOMMENTARE statt des vorgeschlagenen `data-ay-block`-Attributs:
ein Wrapper-Element aenderte das DOM (Geschwister-Selektoren, Raster) und
braeche die Regressions-Zusicherung; ein Attribut am aeussersten Element
setzte voraus, dass jeder Baustein GENAU EIN Wurzel-Element liefert — ueber
die 47 Faelle des Zeichners ist das nicht zugesichert. Kommentare sind
DOM-neutral und begrenzen die Region exakt.
Der Hex-Riegel auf der Kennung ist kein Schoenheitsfilter: ein Schluessel mit
`-->` schloesse die Marke und liesse beliebiges HTML aus dem Kommentar.
2) `POST /webpages/:id/actions/render-block-variant` backt EINE Varianten-
Fassung eines Bausteins zu HTML. Gebacken wird beim ANLEGEN des Experiments,
nicht beim Ausliefern: die consumer-app rendert Bausteine nicht selbst, und
ein Backen beim Veroeffentlichen koppelte den Experiment-Lebenszyklus an das
Veroeffentlichen — wer ein Experiment startet, ohne die Seite erneut zu
veroeffentlichen, haette keine Variante im HTML. Dieselbe Form, die auf der
Seiten-Ebene bereits ausgebracht ist.
25 neue Proben (14 rein + Verdrahtung, 10 am Handler, alle mit Umkehrprobe).
⚠ Die Handler-Suite mockt jetzt getCustomerById/getDefaultEventConsumer/
remoteReplace: ohne sie lief EIN Fall 37 s in echte Netz-Zeitgrenzen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1) `renderBlocksToHtml` legt um jeden TOP-LEVEL-Baustein ein Marken-Paar
`<!--ay-block:<_id>-->…<!--/ay-block:<_id>-->`. Ohne einen stabilen
Schluessel im HTML kann die Auslieferung eine Baustein-Region nicht
wiederfinden — genau daran scheiterte `target.blockKey` bisher.
Bewusst HTML-KOMMENTARE statt des vorgeschlagenen `data-ay-block`-Attributs:
ein Wrapper-Element aenderte das DOM (Geschwister-Selektoren, Raster) und
braeche die Regressions-Zusicherung; ein Attribut am aeussersten Element
setzte voraus, dass jeder Baustein GENAU EIN Wurzel-Element liefert — ueber
die 47 Faelle des Zeichners ist das nicht zugesichert. Kommentare sind
DOM-neutral und begrenzen die Region exakt.
Der Hex-Riegel auf der Kennung ist kein Schoenheitsfilter: ein Schluessel mit
`-->` schloesse die Marke und liesse beliebiges HTML aus dem Kommentar.
2) `POST /webpages/:id/actions/render-block-variant` backt EINE Varianten-
Fassung eines Bausteins zu HTML. Gebacken wird beim ANLEGEN des Experiments,
nicht beim Ausliefern: die consumer-app rendert Bausteine nicht selbst, und
ein Backen beim Veroeffentlichen koppelte den Experiment-Lebenszyklus an das
Veroeffentlichen — wer ein Experiment startet, ohne die Seite erneut zu
veroeffentlichen, haette keine Variante im HTML. Dieselbe Form, die auf der
Seiten-Ebene bereits ausgebracht ist.
25 neue Proben (14 rein + Verdrahtung, 10 am Handler, alle mit Umkehrprobe).
⚠ Die Handler-Suite mockt jetzt getCustomerById/getDefaultEventConsumer/
remoteReplace: ohne sie lief EIN Fall 37 s in echte Netz-Zeitgrenzen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>