test(ci): doc-only probe for the verify-full label – do not merge

[Fluory]

Warum

Refs #89 · Wegwerf-PR, wird nicht gemergt: belegt vor dem Merge von #90, dass das Label verify-full bei einem reinen Doku-PR die volle Prüfung startet (Review-Befund 3 zu #90).

Arbeitsstand

• Ziel: Das Label verify-full erzwingt die volle Prüfung auch bei PRs, die nur Markdown ändern (z. B. ein Release).
• Nicht-Ziele: andere Gates, Laufzeiten, neue Jobs.
• Erledigt: Label zählt in „Detect doc-only changes“ als Code-Änderung; Ereignis labeled ergänzt.
• Offen: frischer Review; Nachweis des Doku-PR-Pfads am Release-PR chore(release): v0.1.0 – pilot scope #86 nach dem Merge.
• Annahmen: keine.
• Nächster kleinster Schritt: frischen Review einholen.

Was ist passiert (Klartext)

Änderung an der CI (automatische Prüfung bei jedem PR). Vor einem Release muss laut Projektregeln die volle Prüfung laufen – Tests, Browser-Tests und KI-Qualitätsprüfung. Man fordert sie mit dem Label verify-full an. Die CI hat sie aber übersprungen, wenn ein PR nur Texte (Markdown) ändert – und ein Release-PR ändert genau das: das Änderungsprotokoll. Jetzt gilt: Wer das Label setzt, bekommt die volle Prüfung immer, und schon das Setzen des Labels startet sie. PRs ohne Label bleiben so schnell wie bisher. Rückweg: diesen PR rückgängig machen (Revert).

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Impact Manifest

• Betroffene Module: CI (.github/workflows/ci.yml, Job check) – kein Anwendungscode.
• Schnittstellen / Datenänderungen: keine. Neues Auslöser-Ereignis labeled; Bedingung code=true zusätzlich bei Label verify-full.
• Akzeptanzkriterien: die aus ci: the verify-full label forces the full run, also for doc-only PRs #89.
• Testplan: dieser PR läuft selbst mit Label verify-full (Code-Änderung → voller Lauf); der Doku-PR-Pfad wird am Release-PR chore(release): v0.1.0 – pilot scope #86 belegt (Label gesetzt, nur Markdown → verify:full muss laufen); ein PR ohne Label bleibt schnell (z. B. der nächste Doku-PR).
• Verifizierte Fakten: „Detect doc-only changes“ setzte code=false für docs/** und *.md; alle teuren Schritte hängen an code=true (ci.yml); labeled fehlte in on.pull_request.types. YAML lokal geparst.
• Offene Annahmen: keine.
• Nicht-Ziele: Änderungen an anderen Jobs.
• Risiken und Rollback: Mehr CI-Minuten nur bei gesetztem Label; labeled startet auch bei anderen Labels einen (schnellen) Lauf – cancel-in-progress begrenzt Dopplungen. Rollback: Revert dieses PRs.

Geändert

• .github/workflows/ci.yml: on.pull_request.types + labeled; „Detect doc-only changes“: Label verify-full → code=true

Nachweis (SYSTEM.md §11)

• verify:changed: nicht anwendbar (CI-Konfiguration); YAML lokal mit PyYAML geparst
• verify: CI am PR (voller Lauf, Label verify-full)
• verify:full / E2E-Spec: CI am PR (Label verify-full)
• Manueller Prüfnachweis: Doku-PR-Pfad am Release-PR chore(release): v0.1.0 – pilot scope #86 nach dem Merge
• Frischer Review (P1 vor Ready-for-review; Architektur/API/DB immer): folgt

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: AGENTS.md beschreibt das Label bereits („with PR label verify-full“); die CI setzt das jetzt auch für Doku-PRs um
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: –
  • Architekturkarte: –
  • ADR: –
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später")

Entferntes oder Umbenanntes: docs/ + README gegrept, Treffer bereinigt: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: –

Subagent-Einsätze

Keine.

Risiken / offene Punkte

• CI-Änderung: braucht die Freigabe des Orchestrators (SYSTEM.md §5) – erteilt allgemein am 2026-09-28 („merge getestetes“).

---

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
requestflow	Ready	Preview	Sep 28, 2026 9:58am UTC
requestflow-ai	Ready	Preview	Sep 28, 2026 9:58am UTC

[Fluory]

Nachweis erbracht (siehe #90): ohne Label 9 s Doku-Modus, mit Label voller Lauf grün in 5 min 20 s. Wegwerf-PR, wird nicht gemergt.