Automatischer Push: 45 Datei(en) geändert

- .claude/agents/planer.md
- .claude/agents/quorum-stimme.md
- .claude/skills/bookstack-upload/SKILL.md
- .claude/skills/bookstack-upload/scripts/bookstack/archiv.py
- .claude/skills/bookstack-upload/scripts/bookstack/auswahl.py
- .claude/skills/bookstack-upload/scripts/bookstack/beschreibung.py
- .claude/skills/bookstack-upload/scripts/bookstack/bilder.py
- .claude/skills/bookstack-upload/scripts/bookstack/ergebnis.py
- .claude/skills/bookstack-upload/scripts/bookstack/hochladen.py
- .claude/skills/bookstack-upload/scripts/bookstack/konvertierung.py
- .claude/skills/bookstack-upload/scripts/bookstack/struktur.py
- .claude/skills/bookstack-upload/scripts/bookstack/verweise.py
- … und 33 weitere

Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py.

Co-Authored-By: Claude Opus 5 <[email protected]>

AI/Regelwerk/codedoku.md

@@ -1,11 +1,11 @@
 ---
 type: resource
-status: pending-review
+status: reference
 title: Codedoku und Dateikopf
 summary: Wie Produktivdateien aussehen — Dateikopf mit genau drei Angaben, CHANGELOG statt Versionsnummern in der Datei, was aus dem Code verschwindet, was drinbleibt, und wohin die Codedoku gehört.
 tags: [regelwerk, codeworkflow, code-projekte, dokumentation]
 created: 2026-08-30
-updated: 2026-09-29
+updated: 2026-09-30
 ---
 
 # Codedoku und Dateikopf
@@ -80,6 +80,7 @@ Faustregel: **was** und **wie** gehören in die Doku, **warum ausgerechnet so**
 ## Die Codedoku
 
 - Ort: Projektordner unter `docs/code/`, eine Datei je Modul oder Skript, gleicher Name.
+- Direkt unter dem Frontmatter, ohne Frontmatter in der ersten Zeile, steht ein relativer Markdown-Link aufs Projekt-README, zum Beispiel `Projekt: [README](../../README.md)`. Der Dateikopf im Code nennt die Codedoku nur als Pfad, ohne diese Zeile ist sie im Graphen eine Waise. Regel: [[AI/Regelwerk/navigation|navigation.md]], Abschnitt „Links schreiben und Dateien verschieben“.
 - Vier Überschriften, darunter Stichpunkte, keine Textblöcke:
   - **Wofür** — eine Zeile
   - **Ablauf** — nummerierte Liste von oben nach unten

AI/Regelwerk/codeworkflow.md

@@ -5,7 +5,7 @@ title: Codeworkflow
 summary: Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen und Effort, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.
 tags: [regelwerk, codeworkflow, code-projekte]
 created: 2026-08-03
-updated: 2026-09-29
+updated: 2026-09-30
 ---
 
 # Codeworkflow
@@ -108,7 +108,7 @@ Nach jeder programmatischen Änderung an einem Plan: eingebettete Codeblöcke pa
 
 **Ablaufdokumente werden in Ausführungsreihenfolge geprüft, nicht Block für Block.** Ein Installationskapitel wechselte mitten im Text das Arbeitsverzeichnis. Jeder Codeblock war für sich richtig — genau deshalb fällt so etwas beim Lesen nicht auf und beim Kunden schon. Ein Dokument, das jemand von oben nach unten abarbeitet, wird einmal von oben nach unten durchgespielt.
 
-**6 Abschließen.** Bevor Pascal irgendetwas als fertig sieht, fährst du die „Fertig heißt“-Liste aus dem Plan in der Reihenfolge aus [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 3: alle Checks ausführen, Durchgefallenes reparieren, alle noch einmal ausführen, je Check eine Zeile mit Ergebnis und Beleg, und alles benennen, was du nicht prüfen konntest. Fallen im ersten Durchlauf mehr als zwei Checks durch, flickst du nicht, sondern benennst den Teil des Ablaufs, der das verursacht hat — das ist „Läuft etwas schief, hörst du auf und planst neu“ mit einer Zahl daran. Die Liste ersetzt Schritt 4 nicht; sie ist das, was Pascal davon zu sehen bekommt.
+**6 Abschließen.** Steht ein Meilenstein an, läuft vorher das Quorum (siehe „Quorum am Meilenstein“ unten); ohne freies Urteil gibt es kein Merge, keinen Push, kein Einspielen und keine Abgabe. Bevor Pascal irgendetwas als fertig sieht, fährst du die „Fertig heißt“-Liste aus dem Plan in der Reihenfolge aus [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 3: alle Checks ausführen, Durchgefallenes reparieren, alle noch einmal ausführen, je Check eine Zeile mit Ergebnis und Beleg, und alles benennen, was du nicht prüfen konntest. Fallen im ersten Durchlauf mehr als zwei Checks durch, flickst du nicht, sondern benennst den Teil des Ablaufs, der das verursacht hat — das ist „Läuft etwas schief, hörst du auf und planst neu“ mit einer Zahl daran. Die Liste ersetzt Schritt 4 nicht; sie ist das, was Pascal davon zu sehen bekommt.
 
 Der Koordinator committet (Subagenten nie), ergänzt `tasks/lessons.md` um jeden Befund aus Schritt 4 und den Abschnitt „Review" in `todo.md`. Im „Review" steht auch, was in diesem Durchlauf neu gebaut wurde und wieder gebraucht wird (Prüfskript, Vorlage, Auftragstext) — das sind Kandidaten für die Ablage nach Abschnitt 4 derselben Datei. Pascal entscheidet, was davon gespeichert wird.
 
@@ -160,6 +160,32 @@ Seit 2026-09-26 auf Pascals Freigabe:
 - **Ein Paket hat höchstens etwa fünf Tasks.** Wird es größer, teilst du es vor dem Planen in Pakete, die je für sich prüfbar und committbar sind.
 - **Das Drehbuch eines Einbautags pflegt der Koordinator direkt**, ohne Planer und Executer. Jede Änderung trägt ein Datum. Es liegt nicht in dem Zweig, den es einspielt, sondern im Vault unter `AI/secondbrain/<projekt-tag>-memory/drehbuecher/`. Grund: Am 2026-09-27 ließen sich zwei Drehbücher der Trading Plattform nicht berichtigen, weil jeder Commit auf ihren Zweig die Fast-Forward-Kette der Einbauwoche gebrochen hätte. Vor dem Einbau spielst du es einmal in Ausführungsreihenfolge durch (siehe „Ablaufdokumente“ oben).
 
+### Quorum am Meilenstein
+
+**Stand 2026-09-30: umgesetzt, aber noch nicht abgenommen.** Die Prüfung der letzten Nachbesserung und der erste echte Lauf stehen aus (Plan unter `.vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/`). Bis zur Abnahme läuft das Quorum nur auf Pascals Zuruf, und seine Sperre gilt noch nicht. Dieser Absatz fällt mit der Abnahme weg.
+
+Pascals Entscheidung vom 2026-09-29. Was die Wellenprüfung übersehen hat, soll nicht in die Zielumgebung, auf master oder zum Kunden. Dafür prüfen drei Modelle aus zwei Familien unabhängig denselben Unterschied: Opus und Sonnet als `quorum-stimme`, dazu Codex über das Plugin. Die Wellenprüfung bleibt, das Quorum kommt dazu. Der Ablauf steht in `.claude/workflows/quorum.js`, die Werkzeuge unter `.vault-tools/quorum/`. Vor der Opus-Stimme liest der Workflow `verbrauch` ab; gebremst heißt kein Urteil und ein Neustart nach dem Fenster.
+
+**Auslöser, genau drei:**
+
+- **Einspielen:** vor einem Einbautag oder bevor ein Stand auf einen Server, in Produktion oder in einen Echtgeld-Pfad geht.
+- **Neue Version auf master:** vor Merge und Push einer neuen Minor- oder Major-Version laut CHANGELOG. Patch-Versionen lösen nichts aus.
+- **Kundendokument:** vor der Übergabe eines Dokuments oder Dokumentensatzes an einen Kunden.
+
+Regelwerk-Änderungen im Vault lösen kein Quorum aus.
+
+**Kein Unterschied wird zweimal geprüft.** Der Lauf nimmt nur, was seit dem letzten Quorum dazukam: bei Code den Diff vom Stand des letzten Berichts bis HEAD, bei Dokumenten beim ersten Mal den ganzen Satz, danach die Dateien mit geänderter Prüfsumme. Das erste Quorum eines Code-Projekts braucht deshalb eine `basis`, etwa den Commit der letzten abgenommenen Version. Der Arbeitsbaum muss außerhalb von `docs/quorum/` sauber sein, weil die Stimmen ihn lesen. Ist der Unterschied leer, übernimmt der Lauf das Urteil des letzten Quorums, ohne eine Stimme zu starten.
+
+**Urteil.** Was zwei Stimmen an derselben Datei und Stelle melden, gilt, mit der höchsten Schwere der Gruppe. Einzelbefunde der Schwere blockierend und wichtig prüft ein Sonnet-Agent nach; Hinweise mit nur einer Stimme gehen ungeprüft in den Bericht. Ein Befund ohne Beleg zählt nicht für die Mehrheit. Frei heißt: kein bestätigter blockierender Befund und keiner, der ungeprüft blieb. Mit weniger als zwei abgegebenen Stimmen gibt es kein Urteil.
+
+**Ersatz.** Gibt Codex keine gültige Stimme ab, springt Haiku ein. Gültig heißt: Der Status des Plugins ist vor dem Lauf gelesen, der Job endet `completed`, sein Log ist gelesen und trägt kein „usage limit“, und die Antwort zitiert die Lesemarke aus dem Paket. Mit `codex: false` springt Haiku sofort ein, etwa wenn das Kontingent bekannt aufgebraucht ist. Der Bericht sagt, wenn Haiku statt Codex drinsteht. Steht das oft da, ist das Quorum faktisch nur mit Claude besetzt.
+
+**Sperre.** Solange das Urteil nicht frei ist, also ein bestätigter oder ungeprüft gebliebener blockierender Befund offen ist oder der Lauf kein Urteil hat, gibt es kein Merge, keinen Push, kein Einspielen und keine Abgabe. Die Korrekturen entscheidest du, umgesetzt werden sie über die Standardschleife. Danach läuft kein neues Quorum: Eine `quorum-stimme` auf Sonnet, über das Agent-Werkzeug mit der Auftragsart Nachkontrolle gestartet, bestätigt je behobenem Befund, dass er behoben ist. Den Korrektur-Diff prüft das nächste Quorum mit, weil dessen Basis der Stand dieses Laufs ist.
+
+**Bericht.** Der Workflow liefert `bericht_md`, `bericht_pfad` und `ablegen_befehl`. Du schreibst `bericht_md` in eine Datei und legst sie mit dem Befehl ab. Er setzt `stand` aus `paket.json` ein, damit die Liste der Prüfsummen durch kein Modell abgeschrieben werden muss. Danach committest du den Bericht: im Code-Projekt unter `docs/quorum/`, beim Kundendokument unter `quorum/` im Projektordner, Dateiname `JJJJ-MM-TT-<anlass>.md`. Der Bericht verlinkt README bzw. Übersicht. Sein Frontmatter trägt `nummer`, `basis` und `stand`, und daran setzt der nächste Lauf an. Ein Lauf ohne Urteil liefert keinen Bericht, die Basis bleibt dann die alte. Je Stimme stehen darin Befunde, bestätigte und Alleinfunde, also bestätigte Befunde, die nur diese Stimme hatte, dazu die Codex-Laufzeit und der Verbrauch vor und nach dem Lauf.
+
+**Was bleibt:** die Echtgeld-Regeln und die volle Schleife für Geld-, Sicherheits- und Netzpfade. Gekürzt wird erst, wenn die Ertragskurve es trägt. Nach fünf Quoren liest du die Berichte, schreibst die Auswertung als Dump und legst Pascal einen Vorschlag hin. Die Frage dabei: Findet das Quorum, was die Wellenprüfung übersieht, und welche Stimme trägt die Alleinfunde? Über Kürzungen entscheidet Pascal.
+
 ### Was die Schleife bisher gefunden hat
 
 Belege aus dem Projekt „Bookstack Upload" (2026-08-05), fünf Fehler, **keiner davon aus der Testsuite** — die war grün, während drei davon im Code saßen:
@@ -247,7 +273,7 @@ Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck.
 
 Was die Messung nicht belegt: Die Prüfstände waren klein, ein Modul mit 73 Zeilen. Bei Plänen und Reviews über viele Dateien kann der Abstand zwischen den Stufen anders aussehen. Die Recherche-Aufgabe (acht Fragen, Antworten verteilt auf fünf Regelwerk-Dateien) war zu leicht: Haiku und Sonnet beantworteten sie in jeder Stufe 8 von 8. Belegt ist dort nur, dass Nachschlagen keinen hohen Effort braucht.
 
-**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Gespeicherte Workflows unter `.claude/workflows/`: `plankritik`, `executer-welle`, `pruefung`, `welle-mit-pruefung`, `planung` für die Erstplanung und `verbrauch` für die Ablesung des Planverbrauchs. Sie setzen genau das um; wie viele Opus-Agenten sie gleichzeitig starten, regelt „Verbrauch und Opus-Plätze" unten. Was sie darüber hinaus tun:
+**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`, `quorum-stimme`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Gespeicherte Workflows unter `.claude/workflows/`: `plankritik`, `executer-welle`, `pruefung`, `welle-mit-pruefung`, `planung` für die Erstplanung, `verbrauch` für die Ablesung des Planverbrauchs und `quorum` für die Prüfung am Meilenstein (siehe „Quorum am Meilenstein“ oben). Sie setzen genau das um; wie viele Opus-Agenten sie gleichzeitig starten, regelt „Verbrauch und Opus-Plätze" unten. Was sie darüber hinaus tun:
 
 - `plankritik` baut auf Wunsch die Kopie mit angewendetem Plan selbst (`materialisieren` mit Ausschlüssen) und lässt einen billigen Hilfsagenten die Planwerkzeuge fahren; die Linsen bekommen die Rohausgabe. Danach fasst sie doppelte Befunde zusammen und lässt jeden wichtigen oder blockierenden von einem zweiten `pruefer` zu widerlegen versuchen: „bestätigt" nur mit eigener Reproduktion, „widerlegt" nur mit Gegenbeleg, sonst „offen". Das filtert Fehlalarme, bevor du den Plan korrigierst, und kostet je Befund einen Opus-Lauf.
 - `welle-mit-pruefung` fasst Schritt 3 und 4 zusammen: Kopie aus dem Stand **vor** der Welle, `executer-welle`, Byte-Vergleich und Suite durch den Hilfsagenten, dann `pruefung` mit diesen Rohbelegen. Ist die Welle unvollständig, prüft er nicht und sagt das.
@@ -274,6 +300,7 @@ Wo das gilt:
 
 - **`plankritik`:** Die Linsen laufen nach Verbrauch. Die dritte Linse wartete vorher im Mittel 14,5 Minuten auf einen Platz (fünf echte Pläne). Die Widerlegung bleibt bei höchstens zwei.
 - **`planung`:** Vorgegeben sind zwei Plätze, nach Verbrauch gesenkt und nach je vier fertigen Planern neu gelesen.
+- **`quorum`:** Liest vor der Opus-Stimme mit `wunsch` eins ab. Gebremst heißt: keine Stimme, kein Urteil, Neustart nach dem Fenster.
 - **Ad-hoc-Workflows mit vielen Opus-Agenten** (Reviews, Erstplanungen): Vor jeder Staffel `workflow({ scriptPath: "D:/Claude/.claude/workflows/verbrauch.js" }, { anlass, wunsch })` aufrufen und dessen `plaetze` nehmen, bis zur Eichung mit `wunsch` zwei. Ein Kind eines Workflows kann das nicht, dort gilt zwei.
 - **Opus-Agenten über das Agent-Werkzeug:** Vorher selbst `get_usage` lesen; bei hohem Verbrauch weniger starten, höchstens zwei. Die Stufen stehen in `verbrauch.js`.
 - **`pruefung` und `welle-mit-pruefung`** lesen nur ab, für die Messreihe. Sie bremsen nicht.

AI/Regelwerk/navigation.md

@@ -5,7 +5,7 @@ status: reference
 summary: "Wie du suchst, wenn die MOCs nicht reichen: Grep, linkcheck, was vom alten Navigator-Toolkit noch gilt, Obsidian-CLI und Obsidian-Skills, Links schreiben und Dateien verschieben."
 tags: [regelwerk, navigation, werkzeuge]
 created: 2026-08-30
-updated: 2026-09-13
+updated: 2026-09-30
 ---
 
 # Navigator-Werkzeuge
@@ -32,11 +32,24 @@ python .vault-tools/linkcheck/faelle.py
 
 Der erste Befehl meldet die echten toten Wikilinks, weil er Codeblöcke ausnimmt. Der zweite fährt die Angriffsfälle gegen die Codeblock-Erkennung. Entwurf, Herkunft je Regel und benannte Lücken: `.vault-tools/linkcheck/ENTWURF-codeblock-erkennung.md`.
 
+## Waisen: waisen.py
+
+Eine Waise ist eine Notiz ohne Kante im Graphen, weder eingehend noch ausgehend. `waisen.py` zählt sie so, wie Obsidian den Graphen baut, und zieht die Muster aus `waisen-ausnahmen.txt` ab.
+
+```bash
+PYTHONIOENCODING=utf-8 python .vault-tools/linkcheck/waisen.py --vault . --liste
+python .vault-tools/linkcheck/faelle_waisen.py
+```
+
+- Der Sitzungsstart zeigt dieselbe Zahl als Zeile „Waisen außerhalb der Ausnahmen“. Steigt sie, hat eine neue Datei ihren Hub nicht verlinkt (Regel unten unter „Links schreiben und Dateien verschieben“).
+- In `waisen-ausnahmen.txt` stehen nur allgemeine Muster, keine Kunden- oder Projektnamen, weil `.vault-tools/` veröffentlicht wird.
+- Entwurf, Herkunft je Regel und benannte Lücken: `.vault-tools/linkcheck/ENTWURF-waisen.md`. Ein Fangnetz, kein Nachweis: Wie der Graph aussieht, zeigt nur Obsidian.
+
 ## Sitzungs-Hooks
 
 Unter `.vault-tools/session-hooks/` liegen zwei Hooks, eingetragen in `.claude/settings.json`:
 
-- **`sitzungsstart.py`** (SessionStart) gibt beim Start nur Zahlen in den Kontext: ob die Tagesnotiz existiert, offene Inbox-Notizen, Notizen mit `#needs-review`, `#review` ohne `#review-done`, Regelwerk-Dateien auf `pending-review` und die Sitzungsdateien von heute, damit eine Namenskollision auffällt.
+- **`sitzungsstart.py`** (SessionStart) gibt beim Start nur Zahlen in den Kontext: ob die Tagesnotiz existiert, offene Inbox-Notizen, Notizen mit `#needs-review`, `#review` ohne `#review-done`, Regelwerk-Dateien auf `pending-review` und die Sitzungsdateien von heute, damit eine Namenskollision auffällt. Dazu kommt die Zahl der Waisen außerhalb der Ausnahmen aus `waisen.py`, nur die Zahl, keine Liste.
 - **`regelwerk_nach_edit.py`** (PostToolUse) startet `regelwerk_check.py` nach jedem Edit oder Write an `CLAUDE.md`, `AI/Regelwerk/`, `.claude/agents/` oder `.claude/skills/` und meldet Befunde zurück. Solange eine Regelwerk-Datei auf `pending-review` steht, meldet er genau diesen Befund jedes Mal mit.
 
 Beide nehmen die Vault-Wurzel aus ihrem eigenen Pfad, nicht aus `cwd`, weil `cwd` einem `cd` in einen Projektordner folgt. Regressionstreiber: `faelle_sitzungsstart.py` und `faelle_nach_edit.py`. Entwurf und benannte Lücken: `.vault-tools/session-hooks/ENTWURF.md`. Ein Fangnetz, kein Nachweis.
@@ -68,6 +81,31 @@ Das Toolkit ist fremd und schreibgeschützt. Deshalb wird es nicht gepatcht, son
 
 ## Links schreiben und Dateien verschieben
 
+### Jede neue Datei hängt an ihrem Hub
+
+**Wer eine Datei anlegt, verlinkt darin ihren Hub, und zwar nach oben.** Das gilt für dich, für jeden Subagenten, Skill und Workflow. Der Erzeuger kennt den Hub beim Anlegen, der Hub selbst braucht keine Pflege, und seine Rückverweise zeigen alle Kinder. Ein Pfad in Backticks ist kein Link.
+
+| Datei | Hub | Linkform |
+|---|---|---|
+| Plan-Übersicht `00-uebersicht.md`, Einzeldatei-Plan in einem Code-Projekt | Projekt-README | relativer Markdown-Link |
+| Plan oder Spec unter `docs/` an der Vault-Wurzel | `README.md` der Vault-Wurzel | relativer Markdown-Link |
+| alles andere im Planordner (Task, Anforderung, Prüfbericht, Nachbesserung) | `00-uebersicht.md` desselben Ordners | relativer Markdown-Link |
+| Codedoku `docs/code/*.md`, Spec, Quorum-Bericht, CHANGELOG, Administrator-Anleitung | Projekt-README | relativer Markdown-Link |
+| SEO-Einzelbefund | Bericht des Laufs | Wikilink mit vollem Pfad |
+| Bericht eines SEO-Laufs | SEO-Seed | Wikilink mit vollem Pfad |
+| Arbeitsdatei oder Plan-Übersicht eines Projekts im IT Workspace, auch unter `_arbeitsstand/` | Übersicht (`_MOC-*.md`) bzw. README des Projekts | Wikilink mit vollem Pfad |
+| Dump | Tagesnotiz | Wikilink `[[Inbox/JJJJ-MM-TT]]` |
+| Notiz oder Spec in der Inbox | Tagesnotiz des Tages, an dem sie entsteht | Wikilink aus dem Agentenprotokoll der Tagesnotiz, also nach unten |
+
+- **Wo die Zeile steht:** direkt unter dem Frontmatter, ohne Frontmatter in der ersten Zeile. In einer Taskdatei lautet sie `Übersicht: [00-uebersicht.md](00-uebersicht.md)`, in einer Übersicht `Projekt: [README](../../../README.md)`, die Tiefe passend zum Ort.
+- **Relative Markdown-Links in Code-Projekten und unter `docs/` an der Vault-Wurzel, entgegen der Vault-Gewohnheit.** Der Projektstatus steht im Ordnerpräfix, und aus `active - X` wird irgendwann `inactive - X`. Wikilinks mit vollem Pfad brechen dabei, wenn nicht in Obsidian umbenannt wird. Gitea zeigt Markdown-Links an, Wikilinks nicht. Leerzeichen und Umlaute im Pfad schreibst du URL-kodiert, ein Leerzeichen als `%20`.
+- **Überall sonst** bleibt es beim Wikilink mit vollem Pfad, auch in Projekten im IT Workspace, deren `_arbeitsstand` ein eigenes Git-Repo ist: Diese Ordner tragen kein Statuspräfix.
+- **Notizen in der Inbox verlinkt die Tagesnotiz nach unten**, weil eine Inbox-Notiz noch keinen festen Ort hat. Wird sie einsortiert, gilt die Zeile ihres neuen Orts.
+- **SEO-Befunde verlinkt der Bericht nach unten**, weil der Audit-Skill außerhalb des Vaults liegt und seine Befunddateien ohne Link ablegt. Wie, steht in [[AI/Regelwerk/seo|seo.md]], Abschnitt 1, Punkt 5.
+- **Bewusste Ausnahmen** sind `Bookstack/` (Warteschlange und Archiv) und Programmausgaben unter `data/` in Code-Projekten. Sie stehen als Muster in `.vault-tools/linkcheck/waisen-ausnahmen.txt` und zählen nicht als Waisen.
+
+### Links allgemein
+
 - **Wikilinks mit vollem Vault-Pfad:** `[[AI/Regelwerk/navigation|navigation.md]]`. In Tabellenzellen schreibst du den Alias-Trenner als `\|`.
 - **Nicht-Markdown-Anhänge** verlinkst du mit Dateiendung (`[[…/audit-data.json]]`) oder nennst sie als Pfad in Backticks. Ein Wikilink ohne Endung löst nur auf `.md` auf.
 - **Kein Wikilink ins Harness-Gedächtnis.** Obsidian sieht den Ordner nicht, der Link wäre tot. Nenne den Namen in Backticks.

AI/Regelwerk/seo.md

@@ -1,11 +1,11 @@
 ---
 type: resource
-status: pending-review
+status: reference
 title: SEO-Arbeit an WordPress-Kundensites über WPVibe
 summary: Regeln für SEO-Audits und deren Umsetzung auf WordPress-Sites (Rank Math, Salient/WPBakery, WP Super Cache, WPCode) über den WPVibe-Connector — Arbeitsweise, Werkzeugwege, Messregeln, bekannte Fallen. Nur laden, wenn eine Website auditiert oder nach einem Audit umgebaut wird.
 tags: [regelwerk, seo, wordpress, wpvibe, rank-math]
 created: 2026-09-07
-updated: 2026-09-29
+updated: 2026-09-30
 ---
 
 # SEO-Arbeit an WordPress-Kundensites über WPVibe
@@ -20,7 +20,7 @@ Alles hier stammt aus der Arbeit an einer Kundensite zwischen dem 02.09. und dem
 2. **Eigene Erfolgsmeldungen sind auch Behauptungen.** Die Mittagssitzung vom 07.09. meldete „Team-Verlinkung live" und „Angebote gefixt"; beides stimmte nicht. Ein Nach-Fix-Audit läuft unabhängig und übernimmt nichts aus der Fix-Liste.
 3. **Drei Sorten von Punkten sauber trennen:** was über den Connector geht (Inhalte, Optionen, Cache); was nur Pascal kann (`.htaccess`, Snippet-Freigabe und -Aktivierung, WebFTP, Google-Konten); was nur der Betreiber kann (echte Angebote, Firmenname, GBP-Pin). Die zweite und dritte Sorte landen in einer `FUER-PASCAL.md` mit fertigen Blöcken und Kontrollbefehl je Block.
 4. **Nichts erfinden.** Keine Rabatte, Lieferkosten, Lieferzeiten, Bewertungszahlen oder Praktiken, die nicht auf der Website, in der Preisliste oder beim Betreiber belegt sind. Was fehlt, wird als Lücke benannt („braucht Betreiberdaten"). Stammpreise sind keine Angebote.
-5. **Ablage je Audit-Lauf** unter `IT Workspace/SEO & Websitehosting/<domain>-audit/<TTMMJJJJ>/`: `ABSCHLUSSBERICHT.md`, `UMSETZUNGSPLAN.md` mit Ergebnistabelle (Befund, Maßnahme, Beleg), `FUER-PASCAL.md`, bei Textarbeit `TEXTE-QA.md` mit dem Wortlaut. Nach-Fix-Läufe in `<TTMMJJJJ>-nachher/`. Nach jedem Lauf bekommt der Seed `IT Workspace/SEO & Websitehosting/_MOC-seo-websitehosting.md` einen Eintrag für diesen Lauf: Datum, Art des Laufs, gemessener Score, Link auf `ABSCHLUSSBERICHT.md`, darunter eingerückt die Links auf die übrigen Dokumente desselben Laufordners (`UMSETZUNGSPLAN.md`, `FUER-PASCAL.md`, `TEXTE-QA.md` und so weiter) ohne eigene Zusammenfassung. Den neuesten Lauf stellst du nach oben. `findings/`, Rohdaten und die Preisliste bekommen keinen Seed-Eintrag. Befunde früherer Läufe sind oft längst behoben (Punkt 1) und sollen nicht prominent verlinkt sein.
+5. **Ablage je Audit-Lauf** unter `IT Workspace/SEO & Websitehosting/<domain>-audit/<TTMMJJJJ>/`: `ABSCHLUSSBERICHT.md`, `UMSETZUNGSPLAN.md` mit Ergebnistabelle (Befund, Maßnahme, Beleg), `FUER-PASCAL.md`, bei Textarbeit `TEXTE-QA.md` mit dem Wortlaut. Nach-Fix-Läufe in `<TTMMJJJJ>-nachher/`. Nach jedem Lauf bekommt der Seed `IT Workspace/SEO & Websitehosting/_MOC-seo-websitehosting.md` einen Eintrag für diesen Lauf: Datum, Art des Laufs, gemessener Score, Link auf `ABSCHLUSSBERICHT.md`, darunter eingerückt die Links auf die übrigen Dokumente desselben Laufordners (`UMSETZUNGSPLAN.md`, `FUER-PASCAL.md`, `TEXTE-QA.md` und so weiter) ohne eigene Zusammenfassung. Den neuesten Lauf stellst du nach oben. `findings/`, Rohdaten und die Preisliste bekommen keinen Seed-Eintrag. Befunde früherer Läufe sind oft längst behoben (Punkt 1) und sollen nicht prominent verlinkt sein. Der Bericht verlinkt sie trotzdem, damit sie im Graphen nicht lose hängen: Nach jedem Lauf bekommt `ABSCHLUSSBERICHT.md` am Ende einen Abschnitt `## Befunddateien dieses Laufs` mit einem Wikilink mit vollem Pfad je Datei unter `findings/`. Der Audit-Skill liegt außerhalb des Vaults und legt die Befunddateien ohne Link ab ([[AI/Regelwerk/navigation|navigation.md]], „Links schreiben und Dateien verschieben“).
 6. **`/seo audit`-Subagenten laufen in ihr 15-Turn-Limit** (Schema, Content, Visual, SXO am 07.09.). Per SendMessage an die Task-ID fortsetzen lassen, das Teilergebnis nicht als Endstand nehmen.
 
 ## 2 WPVibe-Connector

AI/Regelwerk/sonnet-5-5.md

@@ -49,7 +49,7 @@ Was die Messung nicht belegt:
 - `recherche` ist auf 5.5 nicht gemessen.
 
 - Die schwachen Link-Ergebnisse bei `low` und `medium` hängen mit dieser Behelfsform zusammen. Mit der korrigierten Vorlage ist die Probe nicht wiederholt.
-- **Offen für Pascal:** Der Alias hat umgestellt, bevor gemessen war. Die Messung trägt `medium` nur schwach. Bleiben beim Alias (Sonnet 5.5) oder `model: claude-sonnet-5` in `executer.md` und `recherche.md` festsetzen — entscheidet Pascal.
+- **Entschieden von Pascal am 2026-09-30:** Es bleibt beim Alias `sonnet` (Sonnet 5.5) mit `medium`, obwohl der Alias vor der Messung umgestellt hatte und die Messung `medium` nur schwach trägt.
 
 Rohwerte je Lauf: [[AI/secondbrain/regelwerk-memory/2026-09-29-sonnet-5-5-messung|Messbericht Sonnet 5.5]].