docs: FB-12 — the upgrade path was described, never walked

The baseline moved v0.1.1 to v0.3.1 on 2026-08-21, the first real run of
a procedure that had been considered settled since v0.1.2. It failed at
three places: WORKFLOW.md could not be copied byte-for-byte because it
links to the framework's own decision records; pruefe_sperrliste forbade
the upgrade itself, unable to tell an addition under docs/sources from a
change; and the three declared-extended files had to be reconciled by
hand because nothing reports that upstream touched them.

One root cause: the procedure was described and never executed. Two of
the three are fixed, the third is open — which is FB-11 on a new subject.

Our own positive-control rule, not applied: the adoption question was
closed on the description of a procedure. Nobody ran it.

FRAMEWORK-BEFUNDE.md

@@ -36,6 +36,13 @@ ist; die vollständige Zuordnung steht im Übergabe-Dokument.
 oben zählt ein Befund erst, wenn die nächste Iteration ihn tatsächlich abdeckt. Das
 Refinement prüft das gegen die Dispositionen, die jedes Issue trägt.
 
+**Nachtrag 2026-08-21:** Die nächsten Iterationen liegen inzwischen vor — neckbeard
+**v0.1.3, v0.2.0, v0.3.0 und v0.3.1**, und wir sind von der v0.1.1-Baseline dorthin
+gehoben. Damit ist die Bedingung „die nächste Iteration deckt ihn ab" für einen Teil der
+elf erstmals prüfbar. Die Durchsicht Befund für Befund gegen die Dispositionen der Issues
+0019–0029 steht aus und gehört ins Refinement; hier ist bewusst noch kein Stand geändert
+worden.
+
 ## Übersicht
 
 | # | Befund | Klasse | Stand |
@@ -51,6 +58,7 @@ Refinement prüft das gegen die Dispositionen, die jedes Issue trägt.
 | FB-09 | Gelesene Anweisungen werden nicht befolgt | Arbeitsweise | offen |
 | FB-10 | Gesperrte Dateien werden bearbeitet | Arbeitsweise | **Werkzeug steht** |
 | FB-11 | Regeln ohne maschinellen Widerspruch werden nicht befolgt | Durchsetzung | offen |
+| FB-12 | Der Upgrade-Pfad ins Rahmenwerk war beschrieben, nie begangen | Verfahrenslücke | teilweise |
 
 ---
 
@@ -382,7 +390,86 @@ für die verwandte Klasse und **FB-08**.
 
 ---
 
+---
+
+## FB-12 — Der Upgrade-Pfad ins Rahmenwerk war beschrieben, nie begangen
+
+**Beschreibung.** Am 2026-08-21 wurde die Baseline zum ersten Mal seit der Migration
+angehoben: v0.1.1 → v0.3.1, drei Minor-Stände auf einmal. Das Verfahren dafür steht in
+`AGENTS.md` §5 und galt seit dem 2026-08-13 als erledigt — die entsprechende
+Rahmenwerks-Frage wurde damals mit v0.1.2 geschlossen. **Beim ersten wirklichen Versuch
+scheiterte es an drei Stellen:**
+
+1. **`WORKFLOW.md` ließ sich nicht byte-genau übernehmen.** Seit neckbeard v0.1.3 verweist
+   es auf ADRs des Rahmenwerks selbst; seit v0.3.0 auf eine zweite. Diese Dateien gibt es
+   hier nicht und wird es nie geben — unsere ADRs tragen eigene Nummern und eigene Inhalte.
+   `validate.py` meldete zwei tote Verweise. Die Wahl war: rotes Tor oder gebrochene Kopie.
+2. **`scripts/pruefe_sperrliste.py` verbot das Upgrade selbst.** `docs/sources/` ist
+   unveränderlich, und ein Upgrade muss dort zwingend eine neue Baseline anlegen. Die
+   Prüfung las `git diff --name-only` und konnte einen **Zugang** nicht von einer
+   **Änderung** unterscheiden: 17 gemeldete Verstöße für einen völlig korrekten Vorgang.
+3. **Die drei erklärt-erweiterten Dateien mussten von Hand abgeglichen werden.**
+   `schema.yaml`, `scripts/validate.py` und `scripts/gen_status.py` stehen laut
+   `HERKUNFT.md` bewusst außerhalb des Byte-Vergleichs. Also meldet auch nichts, wenn
+   upstream sie ändert. Nur ein Diff `v0.1.1..v0.3.1` zeigte, dass zwei von ihnen betroffen
+   waren.
+
+**Ursachen-Einschätzung.** Eine gemeinsame Wurzel: **Das Verfahren war beschrieben und nie
+ausgeführt.** Drei Minor-Stände lang hat niemand die Probe gemacht, und jede der drei
+Stellen ist genau die Sorte Fehler, die nur beim Ausführen sichtbar wird.
+
+Punkt 1 ist im Rahmenwerk selbst **unsichtbar**: Dort lösen beide Verweise auf, seine
+eigene Prüfung ist grün. Falsch sind sie ausschließlich in einem fremden Checkout — also
+bei uns. Punkt 2 ist eine Prüfung, deren Geltungsbereich nie gegen den einen Vorgang
+getestet wurde, den sie erlauben *muss*; verwandt mit **FB-02**, nur andersherum — sie
+meldet nicht fälschlich Erfolg, sondern fälschlich einen Verstoß. Punkt 3 ist **FB-11** an
+neuem Gegenstand: eine Pflicht ohne maschinellen Widerspruch, die genau so lange getragen
+wird, wie jemand daran denkt.
+
+⚠️ Und es ist unsere eigene Positivkontroll-Regel, nicht angewandt: Die Adoptionsfrage
+wurde seinerzeit auf die *Beschreibung* eines Verfahrens hin geschlossen. Ein Verfahren,
+das nur beschrieben wurde, ist eine Vermutung — dieselbe Aussage, die **FB-02** für
+Prüfungen macht.
+
+**Belege.**
+
+| Punkt | Messung |
+|---|---|
+| 1 | `validate: 2 error(s)` gegen byte-genaues v0.3.0-`WORKFLOW.md`, in diesem Repo gemessen |
+| 2 | `pruefe_sperrliste: 17 Verstoss/Verstoesse` für den reinen Baseline-Zugang |
+| 3 | `git diff --stat v0.1.1 v0.3.1` → `validate.py` +29, `schema.yaml` +50, `gen_status.py` unverändert |
+
+**Stand: teilweise.**
+
+- **Punkt 1 ist im Rahmenwerk behoben** (v0.3.1): `schema.yaml` führt eine `vendored`-Liste
+  und eine Projektabschnitts-Marke, `validate.py` weist repo-relative Verweise im
+  Upstream-Teil einer vendorierten Datei zurück. Der Fix hatte prompt seinen eigenen
+  Folgefehler — er verbot zunächst auch die elf berechtigten Verweise in unserem
+  Projektabschnitt — und wurde erst dadurch richtig, dass er an unserem Repo gemessen wurde.
+- **Punkt 2 ist hier behoben:** `pruefe_sperrliste.py` liest `--name-status`; Änderung und
+  Löschung bleiben gesperrt, nur der Zugang ist erlaubt. Vier Kontrollen belegt. Upstream
+  `check_locked.py` zieht dieselbe Grenze und sichert sie zu — unsere Fassung wusste es
+  nur nicht.
+- **Punkt 3 ist offen.** Der Abgleich ist gemacht und in `HERKUNFT.md` protokolliert, aber
+  beim nächsten Upgrade erinnert nichts daran.
+
+**Vorschlag für die nächste Iteration.** Zwei Dinge, beide klein:
+
+1. **Das Upgrade als Vorgang mit Abnahme, nicht als Beschreibung.** Wer den Adoptionspfad
+   ändert, führt ihn einmal gegen ein zweites Repo aus und zitiert den Lauf. Das ist
+   dieselbe Forderung, die das Rahmenwerk seit v0.1.3 an jede Prüfung stellt — sie fehlt
+   ausgerechnet bei dem Verfahren, das jeden Übernehmer betrifft.
+2. **Der Handabgleich braucht einen Widerspruch.** Denkbar als Prüfung, die die
+   erklärt-erweiterten Dateien gegen die *vorige* Baseline hält und meldet, wenn upstream
+   sie zwischen zwei Ständen angefasst hat. Sie kann nicht entscheiden, ob wir richtig
+   nachgezogen haben — aber sie kann sagen, dass es zu tun war. Das genügt: Der Fehler ist
+   Vergessen, nicht Falschmachen.
+
+➡️ Verwandt mit **FB-11** (Regel ohne Widerspruch) und **FB-02** (nie rot gesehen). Neu ist
+hier der Gegenstand: nicht eine Regel im Arbeitsalltag, sondern das Verfahren, mit dem wir
+überhaupt an neue Regeln kommen.
+
 *Angelegt 2026-08-20 auf Wunsch von sorb, nach einer Sitzung, in der mehrere dieser
 Befunde gleichzeitig sichtbar wurden. Erstbefüllung stammt von der Seite, die die
 Abweichungen verursacht hat — das ist kein Argument gegen die Befunde, aber ein Grund,
-sie im Refinement gegenzulesen.*
+sie im Refinement gegenzulesen.*