Publishing Pipeline — IIO

Vollständige technische Dokumentation der zweigliedrigen Publishing-Architektur: (A) WWW-Static-Pipeline (4 Streams → Publication Gate → Deploy) und (B) Theme-ETL-Pipeline (6 Stages: Source Verify → Extract → Asset Transform → Canonicalize → Render → SBOM). Alle Transformer, Filter, Gates und Schnittstellen — mit direkten Links zu den Quell-Dateien.

4 Content-Streams 6 ETL-Stages W3C DTCG Tokens HITL Gate SBOM Provenance Fan-out / Fan-in

1 · Vollständige Publishing-Architektur — Schaubild

Zwei unabhängige, aber zusammenwirkende Pipelines. Die Theme-ETL (B) erzeugt den CSS-Artifact, der als Stream 3: theme in die WWW-Pipeline (A) einläuft.

PIPELINE B
Theme-ETL (6 Stages)
Source Verify → Extract → Asset Transform → Canonicalize → Render → SBOM/Provenance.
↓ style.css als Stream 3
PIPELINE A
WWW-Static (4 Streams + Gate)
content, assets, theme, routing_seo → canonical normalization → Publication Gate → Deploy/Verify.
fail-closed: ohne HITL-GO kein Deploy
╔══════════════════════════════════════════════════════════════════════════════════════════╗ ║ (B) THEME-ETL-PIPELINE · iio/base/theme-ingestion/ ║ ║ Brand Source (Figma / Website / Design-Kit) ║ ║ │ ║ ║ ▼ stream-contract.theme.yml (iio/theme/families/*/stream-contract.theme.yml) ║ ║ Stage 1: SOURCE VERIFICATION · validate-stream-contract.sh ║ ║ │ • URL-Check • Placeholder-frei • IP-Gate RG-007 • YAML-Schema ║ ║ ▼ ║ ║ Stage 2: EXTRACT · execute-stream-contract.sh --stage=extract ║ ║ │ • raw_theme_v1 Stream befüllen ║ ║ │ → assets/brand/*, assets/icons/raw/* ║ ║ ▼ ║ ║ Stage 3: ASSET TRANSFORM · execute-asset-transform.sh ║ ║ │ • SVG-Optimierung • PNG-Rasterisierung • ICO • Dark-Varianten ║ ║ │ • Icon-Sprite • assets-manifest.yml (SHA-256 SBOM) ║ ║ ▼ ║ ║ Stage 4: CANONICALIZE · execute-stream-contract.sh --stage=canonicalize ║ ║ │ • Hex → semantische CSS Custom Properties (W3C DTCG) ║ ║ │ • canonical_theme_v1 Stream erzeugen ║ ║ │ → assets/design-tokens.yml ║ ║ ▼ ║ ║ Stage 5: RENDER · execute-stream-contract.sh --stage=render ║ ║ │ • assets/style.css schreiben (deterministisch) ║ ║ │ → theme/families/*/assets/style.css ◄── INPUT für WWW-Pipeline Stream 3 ║ ║ ▼ ║ ║ Stage 6: SBOM / PROVENANCE · execute-stream-contract.sh --stage=evidence ║ ║ │ • stream-contract: source_verified=true, css_generated=true ║ ║ │ • ingestion-log.yml • assets-manifest.yml (SHA-256) ║ ║ ▼ ║ ║ HITL GATE (Zolo) · IP-Brand? → RG-007 · Production? → RG-004 ║ ╚══════════════════════════════════════════════════════════════════════════════════════════╝ │ CSS-Artifact (style.css) fließt in ▼ ╔══════════════════════════════════════════════════════════════════════════════════════════╗ ║ (A) WWW-STATIC-PIPELINE · iio/base/www-publishing/ ║ ║ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ ║ ║ │ STREAM 1 │ │ STREAM 2 │ │ STREAM 3 │ │ STREAM 4 │ ║ ║ │ content │ │ assets │ │ theme ◄─────┼──┼─(von B) │ ║ ║ │ HTML-Seiten │ │ Bilder/Icons │ │ CSS-Tokens │ │ routing_seo │ ║ ║ │ Texte/Strukt │ │ Downloads │ │ style.css │ │ URLs/Meta/sitemap │ ║ ║ └──────┬───────┘ └───────┬──────┘ └──────┬───────┘ └──────────┬───────────┘ ║ ║ └──────────────────┴────────────────┴───────────────────────┘ ║ ║ │ Fan-in ║ ║ ▼ ║ ║ CANONICAL NORMALIZATION · validate-www.sh ║ ║ • HTML-Validierung (W3C) • CSS-Drift (validate-manual-css.sh) ║ ║ • SEO-Pflichtfelder • Asset-Integrität (SHA-256) ║ ║ │ ║ ║ ▼ site_complete_v1 ║ ║ PUBLICATION GATE (HITL — Zolo) ║ ║ Gate 1: HTML-Validierung PASS ║ ║ Gate 2: CSS-Drift PASS ║ ║ Gate 3: SEO-Pflichtfelder vorhanden ║ ║ Gate 4: Zolo GO ║ ║ │ ║ ║ ▼ ║ ║ DEPLOY · publish-www.sh (rsync + Caddy reload) ║ ║ │ ║ ║ ▼ ║ ║ VERIFY ║ ║ • URL 200/301/302 • SSL-Zertifikat • Sitemap erreichbar ║ ╚══════════════════════════════════════════════════════════════════════════════════════════╝

2 · WWW-Pipeline — Die 4 Streams im Detail

Fan-out-Muster: Alle 4 Streams laufen parallel, werden dann durch canonical_normalization zusammengeführt (Fan-in) und als site_complete_v1 an den Publication Gate übergeben. Prinzip: Theme-Independence — der Stream-Contract bleibt stabil, nur der render-Step ändert sich bei CMS-Wechsel.

STREAM 1
content
HTML-Seiten, Texte, strukturierte Inhalte. Kanal-deklariert (DE/EN/AGT). Kein Mixed-Language-Artefakt zulässig.
Quelle: manual/*.html, public/*.html
Kanal-Policy: language-publishing.html
Placement Rule: Q1 (Artefakt im richtigen Node)
STREAM 2
assets
Bilder, Icons, Downloads. Jedes Asset hat SHA-256 in assets-manifest.yml. Keine direkten Binary-Commits ohne SBOM-Eintrag.
Quelle: theme/families/*/assets/
Manifest-Schema: SBOM (Software Bill of Materials)
Transform: execute-asset-transform.sh
STREAM 3
theme
CSS-Custom-Properties, style.css. Input kommt von der Theme-ETL-Pipeline (B). Kein hardcodiertes Hex — nur var(--iio-*) Tokens.
Quelle: theme/families/*/assets/style.css
Generiert durch: Theme-ETL Stage 5 (Render)
Token-Policy: CSS-TOKEN-POLICY.md
Validation: validate-manual-css.sh
STREAM 4
routing_seo
URLs, Meta-Tags, sitemap.xml, robots.txt. Alle öffentlichen URLs müssen resolvierbar sein (200/301/302). Sitemap nach Publish prüfen.
Quelle: public/sitemap.xml, public/robots.txt
Link-Check: check-cross-root-links.sh
Gate: SEO-Pflichtfelder vorhanden (validate-www.sh)
FAN-IN / JOIN
site_complete_v1
Alle 4 Streams normalisiert und zusammengeführt. Erst danach wird der HITL Publication Gate ausgelöst.

3 · Publication Gate — HITL-Checks im Detail

Der Gate ist fail-closed: Kein automatisches Deploy ohne explizites GO. Jeder Gate-Entscheid ist eine Transaction mit Timestamp, Operator-ID und Begründung. Referenz: hitl-gate-definitions.yaml, Review Gate Reference.

🔒 Publication Gate — 4 Pflicht-Checks
  • Gate 1 — HTML-Validierung PASS: W3C-konform, keine broken Tags, kein inline-style mit Hex-Farben. Script: validate-www.sh
  • Gate 2 — CSS-Drift PASS: Kein :root { --iio-*: }-Override in Seiten-<style>, kein hardcodiertes Hex. Script: validate-manual-css.sh
  • Gate 3 — SEO-Pflichtfelder vorhanden: <title>, <meta description>, kanonische URL, lang-Attribut gesetzt. Script: validate-www.sh
  • Gate 4 — Zolo GO: Named Reviewer (kein Self-Approve). Explicit GO/BLOCK als Transaction in hitl-gate-definitions.yaml. Gate-ID: RG-004

Zusätzliche Pflicht-Gates (themenspezifisch)

Gate-IDAuslöserWas geprüft wirdReferenz
RG-004Jedes Production-DeployZolo GO, HTML-Valid, CSS-Drift, SEOhitl-gate-definitions.yaml
RG-007IP-geschützte Brand-QuelleLizenz-Review, Nutzungsrecht deklarierthitl-gate-release-criteria.yaml
RG-008Re-Ingestion nach Source-UpdateKomplette ETL-Pipeline neu durchlaufentheme-transformer-reference.html
CSS-DRIFTJeder Commit in manual/Token-Policy eingehaltenCSS-TOKEN-POLICY.md

4 · Theme-ETL-Pipeline — 6 Stages im Detail

Vollständig deterministisch: gleicher Input → gleicher Output. Kein manuelles Kopieren von Farben oder Assets. Jede Eigenschaft hat eine deklarierte Quelle, einen nachvollziehbaren Transformationsweg und einen SHA-256 Hash im SBOM. Skill-Quelle: iio/base/theme-ingestion/SKILL.md

STAGE 1 SOURCE VERIFICATION validate-stream-contract.sh

Bevor ein einziges Byte extrahiert wird: Quell-Verifikation. Schlägt fehl → gesamte Pipeline BLOCK.

  • URL-Erreichbarkeit der Brand-Quelle prüfen
  • Placeholder-Freiheit im stream-contract.theme.yml bestätigen
  • IP-Review-Gate RG-007 auslösen wenn 3rd-party Brand
  • YAML-Schema-Konformität gegen stream-contract-Schema
  • Quelle: source_key im Contract deklariert und eindeutig
Input: stream-contract.theme.yml → Validation-Report
STAGE 2 EXTRACT execute-stream-contract.sh --stage=extract

Das E in ETL. Rohe Design-Tokens aus der Brand-Quelle extrahieren und unveränderlich in den raw_theme_v1 Stream ablegen.

  • Rohe Design-Tokens extrahieren: Farben (Hex), Typografie, Spacing
  • Logo-SVGs, Icon-Sets, Partnerlogos herunterladen
  • raw_theme_v1 Stream befüllen (unveränderlicher Snapshot)
  • Timestamp + Operator + Source-URL als Provenance-Record
Output Stream: raw_theme_v1 → assets/brand/*, assets/icons/raw/*
STAGE 3 ASSET TRANSFORM execute-asset-transform.sh

Binäre Asset-Verarbeitung. Parallel zu Stage 4 ausführbar. Details → Transformer Reference

  • SVG-Optimierung (svgo / python xmllint-Fallback)
  • Rasterisierung: SVG → PNG in Zielauflösungen (16 / 32 / 64 / 128 / 256 px)
  • ICO-Generierung: favicon.ico aus 16+32px PNG
  • Dark-Varianten-Ableitung (fill-color inversion)
  • Icon-Sprite-Kompilierung: icons.svg + icons.css
  • Partnerlogos normieren: einheitliche Größe + Format
  • SBOM erzeugen: assets-manifest.yml mit SHA-256 per Artefakt
Output: assets/icons/, assets/logos/, assets-manifest.yml (SHA-256 SBOM)
STAGE 4 CANONICALIZE (Transform) execute-stream-contract.sh --stage=canonicalize

Das T in ETL. Rohe Brand-Werte → semantische, platform-unabhängige Design-Tokens nach W3C DTCG-Standard. Basis für alle Downstream-Renderings.

  • Rohe Hex-Werte → semantische CSS Custom Properties (W3C DTCG: $type: color, $value, $description)
  • Rohe Font-Namen → IIO-Token-Namen (--iio-font-base, etc.)
  • Layout-Werte → CSS Grid/Spacing Custom Properties
  • Dark-Mirror-Ableitung wenn stream-contract es deklariert
  • canonical_theme_v1 Stream erzeugen
  • Alle Transformer aus theme-transformer-map.yml werden hier durchlaufen
Output Stream: canonical_theme_v1 → assets/design-tokens.yml (W3C DTCG-aligned)
STAGE 5 RENDER (Load) execute-stream-contract.sh --stage=render

Das L in ETL. Deterministisch: gleicher canonical_theme_v1 → gleicher style.css Output. Dieser CSS-Artifact ist der Input für WWW-Pipeline Stream 3.

  • assets/style.css schreiben:
  •   @import solution-provider (Token-Fundament bleibt unverändert)
  •   :root { --iio-accent: …; --iio-font-base: …; } (nur Theme-Overrides)
  • Alle Token-Overrides direkt aus design-tokens.yml (kein manuelles Edit)
  • Kein Hardcode: Validierung durch validate-manual-css.sh
Output: assets/style.css ← fließt in WWW-Pipeline Stream 3
STAGE 6 SBOM / PROVENANCE execute-stream-contract.sh --stage=evidence

Lückenloser Herkunftsnachweis (Software Bill of Materials). Jedes Artefakt ist von der Brand-Quelle bis zum CSS-Token rückverfolgbar.

  • stream-contract.theme.yml aktualisieren: source_verified=true, css_generated=true
  • ingestion-log.yml: Timestamp, Operator, Stage-Sequenz, Abweichungen
  • assets-manifest.yml: SHA-256 aller Artefakte (SBOM)
  • Unveränderlicher Audit-Trail: kein Überschreiben ohne neue Transaction
Output: stream-contract.yml (updated), ingestion-log.yml, assets-manifest.yml
HITL GATE Human-in-the-Loop Review

Pflicht bei IP-geschützten Brand-Quellen und bei Production-Deploy. Kein automatischer Bypass.

  • Pflicht: IP-geschützte Brand-Quellen → Gate RG-007
  • Pflicht: Production-Deployment → Gate RG-004
  • Pflicht: Jede Re-Ingestion nach Source-Update → Gate RG-008
HITL — fail-closed — kein Self-Approve

5 · Stream-Contract Anatomie

Jede Theme-Familie hat genau eine stream-contract.theme.yml. Sie ist die deklarative Quelle der Wahrheit für die ETL-Pipeline — kein Schritt darf vom Contract abweichen.

META
theme_family, theme_id, version, source_key, ip_review_gate, status
STREAMS
raw_theme_v1 → canonical_theme_v1 (Normalisierungs-Pfad)
TRANSFORMS
Input-Stream → Output-Stream + Processor-Liste (rules)
JOINS
Fan-in-Punkt
Welche Streams zusammengeführt werden + output_schema
EVIDENCE
ingestion_date, ingested_by, source_verified, css_generated + Timestamps

Beispiel: publishing stream-contract.theme.yml

meta:
  theme_family: b2b
  theme_id: publishing
  version: 1.0.0
  source_key: publishing-brand-2026
  ip_review_gate: false
  status: active

streams:
  raw_theme_publishing_v1:
    source: null          # muss befüllt werden (Stage 2)
    schema: { color_palette: hex-set, typography: css-font-stack, ... }

  canonical_theme_publishing_v1:
    normalized_from: raw_theme_publishing_v1
    schema: { design_tokens: w3c-dtcg-aligned, ... }

transforms:
  publishing_source_to_canonical:
    input: raw_theme_publishing_v1
    output: canonical_theme_publishing_v1
    rules:
      - normalize_color_syntax: "hex → rgb-var"
      - abstract_typography:   "font-family → iio-token-name"
      - map_layout_grid:       "source-grid → css-custom-properties"
      - preserve_brand_source_trace: publishing-brand-2026

evidence:
  source_verified: false    # wird durch Stage 1+2 auf true gesetzt
  css_generated: false      # wird durch Stage 5 auf true gesetzt

Vollständige Datei: iio/theme/families/b2b/publishing/stream-contract.theme.yml

6 · Alle Theme-Familien & ihre Stream-Contracts

Jede Familie hat eine eigene Stream-Contract-Datei. Status zeigt ob die ETL-Pipeline already durchgelaufen ist (source_verified + css_generated = true).

Familie Namespace Status IP-Gate Stream-Contract CSS-Artifact
solution-provider b2b / core active Token-Fundament (kein eigener Contract) style.css
publishing b2b active nein stream-contract.theme.yml style.css
pm24 / Präzision b2b active nein stream-contract.theme.yml style.css
neon iio active nein stream-contract.theme.yml style.css
scrap nerd draft nein stream-contract.theme.yml style.css
back-to-the-future archive archived stream-contract.theme.yml archiviert
intelego / classic intelego active ja (RG-007) stream-contract.theme.yml style.css
intelego / drama (intelego-modern) intelego active ja (RG-007) stream-contract.theme.yml style.css
lynaear / linear lynaear active ja (RG-007) stream-contract.theme.yml style.css
lynaear / lynäar lynaear active ja (RG-007) stream-contract.theme.yml style.css
lynaear / raenil lynaear active ja (RG-007) stream-contract.theme.yml style.css
storyworld / balkangrill storyworld active nein stream-contract.theme.yml style.css
storyworld / genesis storyworld active ja (RG-007) stream-contract.theme.yml style.css
storyworld / knight-rider storyworld active ja (RG-007) stream-contract.theme.yml style.css
storyworld / magic storyworld active ja (RG-007) stream-contract.theme.yml style.css
storyworld / ponyhof storyworld active nein stream-contract.theme.yml style.css
archive / back-to-the-future archive archived ja (RG-007) stream-contract.theme.yml style.css

Vollständige Registry mit Pipeline-Status: theme-registry.html
Transformer-Details pro Familie: theme-transformer-reference.html

7 · Scripts & Ausführungsreihenfolge

ScriptZweckPipeline-PhasePfad
validate-stream-contract.sh Stage 1: Quell-Verifikation Theme-ETL base/theme-ingestion/scripts/
execute-stream-contract.sh Stage 2,4,5,6: ETL Hauptpipeline Theme-ETL base/theme-ingestion/scripts/
execute-asset-transform.sh Stage 3: Asset-Verarbeitung Theme-ETL base/theme-ingestion/scripts/
validate-manual-css.sh CSS-Token-Policy prüfen (Gate 2) WWW-Pipeline manual/validate-manual-css.sh
validate-www.sh HTML-Valid + SEO (Gates 1+3) WWW-Pipeline base/www-publishing/scripts/
publish-www.sh Deploy (rsync + Caddy reload) WWW-Pipeline Deploy base/www-publishing/scripts/
check-cross-root-links.sh Alle Cross-Root-Links validieren Pre-Deploy Check specs/scripts/
start-space-web.sh Lokaler Vorschau-Server Entwicklung specs/scripts/

Empfohlene Ausführungsreihenfolge (vollständiger Publish-Cycle)

# 1. Theme-ETL (wenn Brand-Quelle geändert)
bash iio/base/theme-ingestion/scripts/validate-stream-contract.sh
bash iio/base/theme-ingestion/scripts/execute-stream-contract.sh --stage=extract
bash iio/base/theme-ingestion/scripts/execute-asset-transform.sh
bash iio/base/theme-ingestion/scripts/execute-stream-contract.sh --stage=canonicalize
bash iio/base/theme-ingestion/scripts/execute-stream-contract.sh --stage=render
bash iio/base/theme-ingestion/scripts/execute-stream-contract.sh --stage=evidence

# 2. WWW-Pipeline Validation
bash iio/manual/validate-manual-css.sh
bash iio/base/www-publishing/scripts/validate-www.sh

# 3. Link-Check
bash specs/scripts/check-cross-root-links.sh

# 4. HITL Gate (manuell: Zolo GO)

# 5. Deploy
bash iio/base/www-publishing/scripts/publish-www.sh