docs: keep the briefs handed to fresh sessions, in the repo

Three task briefs lived only in a chat and in a home directory. They are
the only record of what was actually handed over, and therefore the only
basis on which a result can later be judged to match its request.

They land beside textbloecke.md rather than in a new directory: that page
already holds "short, copyable blocks you put in front of a session", and
these are the same idea at full length. Each carries its state at the top,
because a brief that reads as pending when it is done is the stale-head
failure this project keeps finding.

The third one exists for a reason worth stating: an agent judging its own
run justifies rather than checks, so that verdict must not be written by
the session that produced the run. And such a brief carries no findings of
the author's own - handing them over buys a confirmation instead of a
check, and then the separation is only cost.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM

docs/wiki/admin/auftrag-ernte-bewerten.md

@@ -0,0 +1,170 @@
+---
+type: wiki-page
+area: admin
+related: []
+---
+
+# Prompt 1 — Die Ernte bewerten und einarbeiten
+
+> **Stand: ausgeführt.** Die frische Sitzung hat die Ernte bewertet und eingearbeitet; daraus entstanden die Rahmenwerks-Versionen v0.1.3 bis v0.3.1, darunter ADR-0009 (Muster als Wiki-Seiten mit Ernte-Stand) und die Issues 0019–0029. Hier als Beleg dessen, was übergeben wurde.
+> Für eine **frische Instanz**. Zuerst fahren, vor Prompt 2. Antworten auf
+> Deutsch, Artefakte auf Englisch (`PROJECT.md` beider Repos).
+
+---
+
+Du arbeitest im Framework-Repo **neckbeard**, nicht im übernehmenden Projekt.
+
+```
+Framework:   https://git.lab/oss-projekte/ai/neckbeard        (Projekt-ID 41)
+Übernehmer:  https://git.lab/axion1337.chat/management        (Projekt-ID 23)
+```
+
+Am 2026-08-20 ist eine zweite Ernte („hand-back") aus anderthalb Wochen
+Dauerbetrieb des übernehmenden Projekts nach neckbeard gepusht worden:
+
+- Branch **`hand-back-2026-08-20`**, Spitze `42d8ccd`, 14 Commits, **nicht
+  gemerged**. `main` steht unverändert auf `8efe7bd` (= `v0.1.2`).
+- Inhalt: ADR-0008 (angenommen), ein neuer `WORKFLOW.md`-Abschnitt
+  *Harvesting to the Framework*, `scripts/check_harvest.py` mit 17
+  Selbsttest-Zusicherungen, das Übergabe-Dokument
+  `docs/sources/feldtest-sustained-operation-2026-08.md`, neun Issues
+  **0019–0027**, die Ursache von Issue 0018, sowie eine Änderung an Issue 0017.
+- Das abgeschlossene Design-Dokument liegt in `docs/design/done/` und enthält
+  in Gate 5 eine Selbstkritik samt fünf offener Unsicherheiten. **Lies es
+  vollständig, es ist die Landkarte dieses Auftrags.**
+
+## Deine Aufgabe, in dieser Reihenfolge
+
+### 1. Lesen, bevor du irgendetwas bewertest
+
+Vollständig, nicht überfliegend — das übernehmende Projekt führt „Dokumente
+werden angelesen, nicht durchgelesen" als eigenen Befund, und du sollst ihn
+nicht reproduzieren:
+
+- neckbeard: `AGENTS.md`, `WORKFLOW.md`, `PROJECT.md`, `schema.yaml`,
+  **alle** ADRs 0001–0008, beide Übergabe-Dokumente unter `docs/sources/`,
+  beide AARs, die Issues 0004–0027.
+- Übernehmer: `FRAMEWORK-BEFUNDE.md` (elf Befunde FB-01…FB-11), `AGENTS.md`
+  (Projektabschnitt ab der Marke `<!-- projektabschnitt -->`), `WORKFLOW.md`,
+  `roadmap.md`, die Skripte in `scripts/`, die AARs unter `docs/aar/`,
+  `docs/wiki/stolpersteine/`.
+
+### 2. Die Ernte gegnerisch prüfen
+
+**Sie wurde von der Seite geschrieben, die die Abweichungen verursacht hat.**
+Das Übergabe-Dokument sagt das selbst. Behandle es entsprechend:
+
+- Stimmen die elf verallgemeinerten Befunde mit dem, was in
+  `FRAMEWORK-BEFUNDE.md` und den AARs des Übernehmers tatsächlich belegt ist?
+  Wurde beim Anonymisieren etwas **weggeglättet**, das die Aussage trägt?
+- Sind die neun Issues Framework-Lücken — oder Modellversagen, das als
+  Rahmenwerkslücke verkleidet wurde? Diese Zwei-Eimer-Klassifikation ist der
+  Kern deiner Bewertung. Ein Befund, der eigentlich „das Modell hat sich nicht
+  an eine klare Regel gehalten" heißt, gehört **nicht** als Framework-Änderung
+  eingearbeitet.
+- Drei der neun Issues (0019, 0020, 0027) argumentieren gegen ihre eigene
+  Abhilfe. Prüfe, ob das Redlichkeit ist oder Ausweichen.
+- Zwei Paare wurden zu je einem Issue zusammengelegt. Zu Recht?
+
+### 3. Den Versionsstand in Ordnung bringen — hier liegt eine echte Falle
+
+**Die Ernte ist unter `v0.1.1` plus eigenen Erweiterungen entstanden, das
+Framework steht aber auf `v0.1.2`.** Konkret:
+
+- Der Übernehmer vendoriert `docs/sources/upstream/neckbeard-v0.1.1/` und
+  prüft seine Framework-Dateien byte-genau dagegen
+  (`scripts/pruefe_upstream_drift.py`). Er ist **nicht** auf v0.1.2.
+- Von den vendorierten Dateien hat v0.1.2 nur **`AGENTS.md`** geändert: drei
+  Ergänzungen aus der ersten Ernte (ADR-Pflicht für dauerhafte Ausnahmen;
+  Link-Ziele sind Dateien, nie Verzeichnisse; der Adoptionspfad mit
+  markiertem Projektabschnitt und Byte-Vergleich gegen die Baseline).
+
+Daraus folgen zwei Fragen, die du beantworten musst:
+
+1. **Sind Befunde der zweiten Ernte durch v0.1.2 bereits erledigt oder
+   verschoben?** Ein Befund, der unter v0.1.1 entstand und den v0.1.2 schon
+   abdeckt, darf nicht ein zweites Mal eingearbeitet werden.
+2. **Was kostet den Übernehmer der Sprung auf v0.1.2?** Der Branch, den du
+   bewertest, würde ihn faktisch auf einen Stand *nach* v0.1.2 heben. Nenne
+   den Upgrade-Pfad ausdrücklich; ohne ihn wächst die Distanz weiter.
+
+### 4. `FRAMEWORK-BEFUNDE.md` als Framework-Kandidat — vorrangig
+
+Der Übernehmer hat einen Artefakttyp erfunden, den das Framework nicht kennt:
+ein **stehendes Befundregister** für wiederkehrende Fehlerklassen und
+Verfahrensabweichungen, ausdrücklich abgegrenzt von Issues (Einzelvorgänge)
+und AARs (Einzelvorfälle). Es ist die Eingangsliste der Ernte und der Ort, an
+dem aus mehreren Vorfällen ein **Muster** wird.
+
+Das ist die wichtigste Einzelfrage dieses Auftrags: **Gehört so ein Register
+in das Rahmenwerk?** Wenn ja — als Artefakttyp in `schema.yaml`, als
+Pflichtdatei im Adoptionspfad, mit welchen Feldern, und wie verhält es sich
+zu Gate 5 und zum Refinement-Ritual? Wenn nein — warum nicht, und wo landen
+Muster stattdessen? Beantworte das mit einer ADR-Vorlage, nicht mit einer
+Meinung.
+
+### 5. Die offenen Fragen bewerten und, wo möglich, lösen
+
+Alle stammen aus dem Gate-5-Abschluss oder sind dort benannt:
+
+| # | Frage | Wer entscheidet |
+|---|---|---|
+| 1 | Löst diese Evidenz die strukturelle Ernte **0.2.0** aus? ADR-0007 nennt als Auslöser „the product line developed to completion … its AARs and a result analysis on the table". Zwei von drei Bedingungen sind erfüllt, „developed to completion" nur teilweise. | sorb, du bereitest vor |
+| 2 | **Teilstring vs. Wortgrenze** beim Ernte-Prüfer. Wortgrenze ist heute Standard, weil ein Personenname im englischen Wort „authored" steckt. Ob dadurch ein echtes Leck in einem Kompositum durchrutscht, ist ungeprüft. | du, mit Beleg |
+| 3 | **Commit-Identität** ist bewusst keine vierte Prüfoberfläche (sonst dauerhaft rot). Issue 0017 Punkte 3 und 4 halten die Identitätsfrage als einmalige Entscheidung offen. | sorb |
+| 4 | **Neun Issues könnten zu viele sein.** Issue 0019 warnt selbst davor, dass ein Rahmenwerk eher weniger und bessere Regeln braucht — gerichtet auf genau diese Ernte. | du, mit Empfehlung |
+| 5 | ⚠️ **Eine Tatsachenbehauptung in zwei Dokumenten ist strittig.** Der AAR `2026-08-13-hand-back-near-leak.md` sagt, *dieses* Repo spiegle nach außen. Der Eigentümer hat am 2026-08-20 klargestellt: **gespiegelt wird das Repo des Übernehmers, nicht neckbeard.** Die Mirror-API bestätigt das (Übernehmer → externer Spiegel, aktiv; neckbeard: kein Mirror). **ADR-0008 wiederholt die falsche Zuschreibung in seinem Kontext-Abschnitt** — und ist `accepted`, also nicht editierbar, nur ablösbar. Die *Entscheidung* der ADR hängt nicht davon ab, nur die Begründung. Kläre mit sorb, was am 13.08. tatsächlich den Inhalt nach außen trug, und schlage dann vor: AAR korrigieren und ADR stehen lassen, oder ablösende ADR. **Nicht rekonstruieren, fragen.** | sorb liefert die Tatsache, du das Verfahren |
+
+## Bindende Regeln für deine eigene Arbeit
+
+- **Größenklasse zuerst benennen.** `PROJECT.md` gewährt nur die S-Ausnahme;
+  M und L stoppen immer. Dieser Auftrag ist mit hoher Wahrscheinlichkeit L und
+  braucht damit ein Design-Dokument mit Gates 1–5 und je einem STOP.
+- **Die ponytail-Leiter vor jedem neuen Artefakt ablaufen** (`AGENTS.md` §1,
+  Z. 26–29) und die haltende Sprosse **nennen**. Es gibt bereits mehr
+  Werkzeuge, als man vermutet — prüfe Sprosse 2, bevor du etwas neu baust.
+- **ADR-0008 gilt für alles, was du hier schreibst:** keine Namen, Hosts,
+  Stack-Komponenten, Personen oder Kennungen des Übernehmers. Vor jedem
+  Weggeben `python scripts/check_harvest.py --terms <liste> --range <a>..<b>`;
+  die Begriffsliste liegt beim Übernehmer unter `scripts/harvest-terms.txt`
+  und wird **nie** nach neckbeard kopiert. ⚠️ Ein grüner Lauf ist kein
+  Abwesenheitsbeweis.
+- **Angenommene ADRs werden nie editiert**, nur abgelöst.
+- **Nicht pushen ohne ausdrückliche Freigabe.** Setze `git remote set-url
+  --push origin DISABLED-no-push`, solange du arbeitest.
+- **Jeden Abschnitt mit genau einem Status abschließen:** `DONE` |
+  `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`.
+- Commits englisch, Conventional-Stil, Autor- und Committer-Datum auf
+  12:00:00 UTC des laufenden Tages.
+
+## Fallen, die dich sonst Zeit kosten
+
+- **Die CI von neckbeard hat noch nie gelaufen.** `.gitlab-ci.yml` auf `main`
+  ist ungültiges YAML (ein `: ` in einem unquotierten mehrzeiligen Skalar),
+  die Konfiguration wird abgewiesen, bevor ein Job entsteht. Das ist Issue
+  0018. ⚠️ **Ein Fix existiert bereits als Branch
+  `fix/ci-yaml-multiline-push` vom 2026-08-17, ungemerged** — er parst, und er
+  behebt zwei Stellen statt einer. Prüfe ihn, statt einen dritten Fix zu
+  bauen. Solange er nicht gemerged ist, ist jeder CI-Schritt wirkungslos und
+  muss lokal verifiziert werden.
+- `gen_status.py` braucht **Python ≥ 3.10** (`Path.write_text(newline=…)`)
+  und PyYAML. Die CI nutzt 3.12.
+- Der Übernehmer hat elf Befunde übergeben, aber sie stehen dort weiter auf
+  `offen` — „übergeben ist nicht geerntet". Erst wenn eine Iteration sie
+  abdeckt, dürfen sie dort geschlossen werden. Sag am Ende ausdrücklich,
+  **welche** das sind.
+
+## Was am Ende vorliegen soll
+
+1. Eine **Bewertung** der Ernte: welche der neun Issues sind echte
+   Rahmenwerkslücken, welche Modellversagen, welche bereits durch v0.1.2
+   abgedeckt — je mit Begründung.
+2. Eine **Entscheidung zum Befundregister** als ADR-Vorlage.
+3. Ein **Upgrade-Pfad** für den Übernehmer von v0.1.1 auf den Zielstand.
+4. Ein **Vorschlag zur Versionsfrage** (0.1.x / 0.2.0) mit der Evidenz, die
+   ADR-0007 verlangt — als Vorlage, nicht als Entscheidung.
+5. Eine Liste der Fragen, die **nur sorb** beantworten kann, jede mit dem
+   Grund, warum sie nicht von dir entschieden werden kann.
+
+Wenn dir beim Lesen auffällt, dass die Ernte selbst einen Fehler enthält:
+melde ihn, bevor du ihn einarbeitest. Sie ist eine Aussage, kein Befund.

docs/wiki/admin/auftrag-judge-und-ledger.md

@@ -0,0 +1,178 @@
+---
+type: wiki-page
+area: admin
+related: []
+---
+
+# Prompt 2 — Judge-Funktion und Spurenpflicht entwerfen
+
+> **Stand: ausgeführt.** Daraus entstanden ADR-0010 des Rahmenwerks, `scripts/judge.py`, der Ledger- und der Verdikt-Artefakttyp — bei uns seit dem Upgrade auf v0.3.1 in Gebrauch.
+> Für eine **frische Instanz**. ⚠️ **Erst fahren, wenn Prompt 1 abgeschlossen
+> und von sorb abgenommen ist.** Der dortige Befund — welche Regeln echte
+> Rahmenwerkslücken sind und welche Modellversagen — ist Eingabe hierfür.
+> Antworten auf Deutsch, Artefakte auf Englisch.
+
+---
+
+Du arbeitest im Framework-Repo **neckbeard**
+(`https://git.lab/oss-projekte/ai/neckbeard`, Projekt-ID 41).
+
+## Die Frage
+
+Kann das Rahmenwerk nach jedem Arbeitsdurchlauf selbst prüfen, ob es
+eingehalten wurde — als Skript, Skill oder Plugin, **ohne** sich an ein
+bestimmtes Harness zu binden?
+
+## Der Stand der Überlegung, den du übernimmst
+
+Die Analyse ist bereits geführt worden; du sollst sie nicht wiederholen,
+sondern umsetzen. Das Ergebnis in Kürze:
+
+**Ein Judge kann kein Verhalten prüfen, nur Spuren.** Der eigentliche
+Entwurfszug ist deshalb nicht „baue einen Judge", sondern „sorge dafür, dass
+der Prozess eine maschinenlesbare Spur hinterlässt". Danach ist der Judge
+größtenteils ein Skript und nur zum Rest Inferenz — was zum bestehenden
+Grundsatz passt, dass deterministische Arbeit in Skripte gehört
+(`AGENTS.md` §5).
+
+Zu prüfen sind **drei getrennte Objekte**:
+
+1. **Artefakt-Konformität** — Frontmatter, Enums, Vorlagen-Vollständigkeit,
+   Link-Integrität. Erledigt `validate.py` bereits. Deterministisch, gelöst.
+2. **Prozess-Konformität** — wurde vor Gate 3 tatsächlich freigegeben? Wurde
+   die Größenklasse *vor* der Arbeit gesetzt oder nachträglich passend
+   gemacht? Das ist eine Eigenschaft des Verlaufs, nicht des Repos — im Repo
+   unsichtbar, es sei denn, der Verlauf schreibt sich selbst hin.
+3. **Urteilsqualität** — ist ein Design-Dokument echt oder Fülltext? Sind die
+   Non-Goals substanziell oder Deko? War S/M/L plausibel? Nur per Inferenz
+   greifbar.
+
+Objekt 2 ist der Knackpunkt und zugleich der billigste Fix: ein
+**Session-Ledger**, den der Agent an jedem Gate fortschreibt — Gate,
+Zeitpunkt **als Commit-Hash statt Zeitstempel**, Größenklasse,
+Freigabe-Marker, Status aus dem Vokabular. Damit wird aus einer Inferenzfrage
+eine Buchhaltungsfrage.
+
+### Der Befund, der alles andere begründet: stumme Regeln
+
+Die **ponytail-Leiter** (`AGENTS.md` §1, Z. 26–29) ist eine *stumme* Regel.
+Befolgung und Nichtbefolgung hinterlassen im Repo dieselbe Spur: keine. Wer
+sucht, nichts Wiederverwendbares findet und baut, erzeugt denselben Diff wie
+jemand, der nie gesucht hat. **Kein Judge kann das unterscheiden, weil die
+Information physisch nicht existiert.** Das ist keine Judge-Schwäche, sondern
+eine Rahmenwerkslücke: die Leiter hat keine **Ausgabepflicht**.
+
+Der Fix ist billig und deterministisch prüfbar: Die Leiter muss ein Ergebnis
+schreiben, *bevor* gebaut werden darf. Drei Felder genügen — **was wurde
+gesucht, was wurde gefunden, warum trotzdem selbst gebaut**. Leer heißt: Gate
+nicht passiert. Aus „hat er wirklich geprüft?" wird „steht da etwas, und
+nennt es konkrete Kandidaten?".
+
+Die Verallgemeinerung ist der eigentliche Gewinn: **Jede Regel braucht eine
+Spurenpflicht, sonst ist sie Dekoration.** Daraus fällt ein Konzept ab, das
+der Judge fast geschenkt liefert — **Regelabdeckung**, analog zur
+Testabdeckung: über N Durchläufe zählen, welche Regeln überhaupt je gefeuert
+haben. Regeln mit Abdeckung null sind entweder unbeobachtbar (wie die Leiter
+heute) oder faktisch inert. Beides musst du wissen, beides ist heute
+unsichtbar.
+
+Das verschiebt den Zweck des ersten Laufs: **Instrumentierung vor
+Durchsetzung.** Lauf eins beantwortet nicht „wurde das Rahmenwerk
+eingehalten", sondern „welche meiner Regeln sind überhaupt prüfbar".
+
+### Die vier Bauformen, bereits abgewogen
+
+| | Ansatz | Pro | Contra |
+|---|---|---|---|
+| **A** | Deterministischer Trace-Judge (`judge.py`, stdlib): Ledger gegen `WORKFLOW.md` — Gate-Reihenfolge, geforderte Artefakte je Größenklasse, Freigabe vor Folgegate, Statusvokabular, Commit-Präfixe, und als wertvollster Test **Diff-Umfang gegen deklarierten Umfang** | reproduzierbar, CI-fähig, modellagnostisch, falsifizierbar, kein Harness | sieht nur, was Spuren hinterlässt; Ledger ist fälschbar; sagt nichts über Qualität |
+| **B** | LLM-Judge als Skill/Slash-Command **in frischem Kontext** — bekommt `AGENTS.md`, `WORKFLOW.md`, Diff und Ledger, **nicht** das Arbeitstranskript; gibt ein rubrikbewertetes Verdict-Artefakt aus | fängt semantische Drift, die kein Skript sieht; Ausgabe ist ein committetes Artefakt | nichtdeterministisch; **wertlos im selben Kontext** — ein Agent, der sich selbst bewertet, rechtfertigt statt zu prüfen. Frischer Kontext ist Bedingung, nicht Optimierung |
+| **C** | Hook-erzwungener Judge (blockierender Stop-/SessionEnd-Hook) | nicht überspringbar | harnessspezifisch → kollidiert mit Harness-Neutralität. Gehört als **Plugin an den Rand**, nicht in den Kern |
+| **D** | CI-Judge im Merge Request | modellagnostisch, vom Agenten nicht abschaltbar; der Diff ist die natürliche Arbeitseinheit | zu spät für Kurskorrektur, hilft mitten in der Sitzung nicht |
+
+**Empfehlung, die du umsetzen sollst:** **A + B**, das **Ledger zuerst** (es
+ist Vorbedingung für beide), **C** als optionales Plugin am Rand, **D** wenn
+A stabil läuft. Das Verdict braucht einen **Artefakttyp in `schema.yaml`** —
+sonst ist der Judge ein Nebenwerkzeug statt Teil des Rahmenwerks. Als
+Verdict-Kategorien dient die Zwei-Eimer-Klassifikation: **Modellversagen vs.
+Rahmenwerkslücke**.
+
+### Die ehrliche Grenze, die ins ADR gehört
+
+Ein Agent, der einen STOP übersprungen hat, kann ein Ledger schreiben, das
+das Gegenteil behauptet. Ohne Harness ist das nicht vollständig zu
+verhindern. Aber das Bedrohungsmodell ist **Drift, nicht Sabotage**, und für
+Drift genügt Detektierbarkeit — über Quervergleiche gegen unabhängige
+Evidenz: Commit-Grenzen, Reihenfolge, ob eine Freigabezeile auf einen Commit
+zeigt, der zu diesem Zeitpunkt überhaupt existierte. **Schreibe das
+ausdrücklich als Non-Goal in die ADR.** Ein Judge, der Manipulationssicherheit
+suggeriert, ist schlimmer als keiner.
+
+## Zwei Festlegungen, die vor dem Entwurf zu treffen sind
+
+Beide gehören sorb; lege sie ihm als Optionen mit Empfehlung vor, statt sie
+zu setzen:
+
+1. **Was ist ein „Durchlauf"?** Eine Sitzung, ein einzelnes Gate, oder ein
+   Merge Request? Sitzung ist am einfachsten zu instrumentieren, Gate gibt
+   die schärfste Diagnose, MR ist am schwersten zu umgehen. Diese Antwort
+   prägt das Ledger-Schema stärker als alles andere und entscheidet, ob
+   Regelabdeckung je Sitzung oder je Gate gezählt wird.
+2. **Wo lebt der Wiederverwendungs-Nachweis der Leiter?** Pflichtfeld in der
+   Issue-Vorlage (nah an der Arbeitseinheit, ADR-0002-konform, greift aber
+   nur bei getrackten Vorgängen), Eintrag im Session-Ledger (greift immer,
+   auch bei ungetrackter Arbeit, ist aber weiter weg vom Vorgang), oder
+   beides mit dem Ledger als Auffangnetz.
+
+## Bindende Regeln für deine eigene Arbeit
+
+Dieselben wie in Prompt 1, und hier mit besonderer Schärfe, weil du ein
+Werkzeug baust, das Regeltreue misst:
+
+- **Größenklasse zuerst benennen.** Das ist mit Sicherheit **L**: Design-Doc
+  mit Gates 1–5, je ein STOP, keine vorgefüllten späteren Gates.
+- **Die ponytail-Leiter ablaufen und die haltende Sprosse nennen** — bei
+  einem Werkzeug gegen stumme Regeln wäre es besonders peinlich, sie zu
+  überspringen. Prüfe insbesondere, ob `validate.py` Teile davon schon kann.
+- **Jede Prüfung, die du baust, muss einmal absichtlich rot gewesen sein.**
+  Positivkontrolle ist Pflicht, nicht Kür — brich den Prüfer gezielt und
+  zeige, dass die zuständige Zusicherung fällt. Ein Vorbild dafür liegt im
+  Repo: `scripts/check_harvest.py --selftest` (17 Zusicherungen, gegen sieben
+  absichtliche Brüche belegt).
+- **Frage im Voraus, welche Befunde dein Judge erzeugt, die niemand beheben
+  kann.** Eine Prüfung, die dauerhaft rot steht, meldet nichts mehr. Bestand
+  ohne auswertbare Ausgabe ist ein Fehler.
+- **ADR-0008** gilt: keine Spezifika des übernehmenden Projekts in irgendetwas,
+  das du hier schreibst. Vor dem Weggeben `check_harvest.py` laufen lassen.
+- **Nicht pushen ohne Freigabe**; `git remote set-url --push origin
+  DISABLED-no-push`, solange du arbeitest.
+- Abschluss je Abschnitt mit genau einem Status: `DONE` |
+  `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`.
+
+## Bekannte Falle
+
+Die CI von neckbeard hat noch nie gelaufen — `.gitlab-ci.yml` auf `main` ist
+ungültiges YAML (Issue 0018), ein Fix liegt ungemerged als Branch
+`fix/ci-yaml-multiline-push`. Ein CI-Judge (Bauform D) ist wirkungslos,
+solange das so ist. Prüfe den Stand, bevor du auf die Pipeline baust.
+
+## Was am Ende vorliegen soll
+
+1. Ein **Ledger-Schema** samt Ort, Lebenszyklus und Verhältnis zu
+   `schema.yaml` — mit der Frage nach der Granularität als Vorlage an sorb.
+2. Eine **Spurenpflicht für die ponytail-Leiter** (drei Felder), mit
+   Fundort-Vorschlag und Übergang für bestehende Vorgänge.
+3. `scripts/judge.py` (Bauform A), stdlib, mit eingebauter Positivkontrolle
+   und benannten Grenzen.
+4. Ein **Verdict-Artefakttyp** in `schema.yaml`, Kategorien Modellversagen vs.
+   Rahmenwerkslücke.
+5. Der **LLM-Judge** (Bauform B) als Skill/Slash-Command mit Rubrik — samt
+   der ausdrücklichen Bedingung, dass er in frischem Kontext ohne
+   Arbeitstranskript läuft.
+6. Eine **ADR**, die A+B entscheidet, C und D verortet und die Fälschbarkeit
+   des Ledgers als Non-Goal festhält.
+7. Ein erster **Regelabdeckungs-Bericht**: welche Regeln aus `AGENTS.md` und
+   `WORKFLOW.md` sind heute überhaupt beobachtbar, welche nicht. Das ist
+   nützlicher als jedes Urteil über einen einzelnen Lauf — und es liefert
+   nebenbei Daten zu der offenen Frage, ob die ponytail-Leiter im Kern
+   richtig aufgehoben ist oder ob die Zweigleisigkeit (Marketplace-Plugin auf
+   `main`, vendorierte Teilmenge auf `with-ponytail`) ihre Pflege wert ist.

docs/wiki/admin/auftrag-verdikt-v031-etappe-2.md

@@ -0,0 +1,128 @@
+---
+type: wiki-page
+area: admin
+related: []
+---
+
+# Prompt — Verdikt über einen Durchlauf
+
+> ⚠️ **Stand: offen.** Das Verdikt über den Lauf `556d568..585dd0c` ist noch nicht geschrieben. Es darf nicht in der Sitzung entstehen, die den Lauf gemacht hat — deshalb dieser Auftrag.
+> Für eine **frische Sitzung**. ⚠️ Die Bedingung unten ist keine
+> Optimierung: In derselben Sitzung erzeugt, ist das Ergebnis wertlos.
+> Antworten auf Deutsch, Artefakte auf Englisch.
+
+---
+
+Du bist der **inferentielle Judge** aus `WORKFLOW.md`, Abschnitt *Judging a
+Run*. Du beurteilst einen abgeschlossenen Durchlauf im Repo:
+
+```
+https://git.lab/axion1337.chat/management        (Projekt-ID 23)
+```
+
+## Die bindende Bedingung
+
+> ⚠️ **Frischer Kontext, und ohne das Arbeitstranskript.** Ein Agent, der
+> seine eigene Sitzung beurteilt, rechtfertigt statt zu prüfen.
+
+Du liest **genau vier Dinge** und sonst nichts:
+
+| | |
+|---|---|
+| `AGENTS.md` | die immer geltenden Regeln, inklusive Projektabschnitt |
+| `WORKFLOW.md` | Gates, Größenklassen, Ledger, die Rubrik unten |
+| **der Diff** | `git diff 556d568..585dd0c` — 12 Commits, 26 Dateien |
+| **das Ledger** | `docs/ledger/2026-08-21-v031-adoption-stage-2.md` |
+
+⚠️ **Suche nicht nach dem Transkript** der Sitzung, die diesen Lauf
+gemacht hat, und frage nicht danach. Wenn dir jemand ihre Zusammenfassung
+anbietet, lehne ab und sag warum. Das Design-Dokument liest du **nur, weil
+es im Diff steht** — nicht als Kontext, sondern als Gegenstand der
+Beurteilung.
+
+## Vorgehen
+
+### 1. Die deterministische Hälfte zuerst
+
+```
+python3 scripts/judge.py --ledger docs/ledger/2026-08-21-v031-adoption-stage-2.md
+python3 scripts/judge.py --coverage
+```
+
+Zitiere beide Läufe wörtlich im Verdikt. Ihre Befunde sind **Tatsachen über
+die Spur**; alles Weitere ist Schlussfolgerung darauf.
+
+⚠️ Ein grüner Lauf ist kein Freispruch. `judge.py` prüft Reihenfolge,
+Vollständigkeit und Commit-Bezüge — nicht, ob der Inhalt trägt. Genau dafür
+bist du da.
+
+### 2. Die Rubrik — fünf Fragen, jede mit einem Zitat beantwortet
+
+„Wirkt sauber" ist keine Antwort. Zitiere aus dem Diff oder dem Ledger.
+
+1. **Scope.** Führt jede geänderte Datei auf das erklärte Vorhaben zurück?
+   Nenne jede, die es nicht tut.
+2. **Substance.** Trägt das Design-Dokument? Schließen die Nicht-Ziele
+   etwas aus, das ein Leser sonst erwarten würde — oder sind sie Deko? Sind
+   die als unsicher markierten Entscheidungen echte Risiken oder Bescheidenheit?
+3. **Size.** War die erklärte Größenklasse plausibel für das, was der Diff
+   geworden ist? **Eine Größe, die nur im Rückblick passt, ist der Befund.**
+4. **Evidence.** Wo ein Slice ein Ergebnis behauptet — ist ein Lauf
+   zitiert? Wo eine Prüfung dazukam — wurde sie rot gezeigt?
+5. **Silence.** Welche Regel *hätte* hier eine Spur hinterlassen müssen und
+   hat es nicht? Das ist die wertvollste Frage, weil ihre Antwort per
+   Definition nicht im Diff steht.
+
+### 3. Jeder Befund in genau einen Eimer
+
+| Eimer | Bedeutung |
+|---|---|
+| **model-failure** | Eine klare Regel wurde nicht befolgt. |
+| **framework-gap** | Die Regel fehlt, ist nicht durchsetzbar oder unsichtbar. |
+
+⚠️ **Die falsche Einordnung ist schlimmer als ein übersehener Befund.** Sie
+gibt entweder einer Person die Schuld für eine Regel, die es nicht gibt,
+oder schreibt einen Verhaltensausrutscher als Konstruktionsfehler ins
+Regelwerk (ADR-0010 des Rahmenwerks).
+
+### 4. Das Verdikt schreiben
+
+Nach `docs/verdict/template.md`, Dateiname
+`docs/verdict/2026-08-21-v031-adoption-stage-2.md`. Frontmatter:
+`type: verdict`, `date`, `outcome` aus `clean | model-failure |
+framework-gap | both`, `judged` zeigt auf das Ledger.
+
+Was folgt: **Framework-Lücken werden zu Issues. Modellversagen nicht** — es
+wird berichtet und als Verhalten stehen gelassen. Sag ausdrücklich, welches
+welches ist und warum.
+
+## Regeln für deine eigene Arbeit
+
+- **Größenklasse S** — eine Datei. `PROJECT.md` gewährt die S-Ausnahme,
+  also keine Gates. Ein **Ledger schreibst du trotzdem**: Der Leiter-
+  Abschnitt ist Pflicht, auch wenn nichts gebaut wurde — „a session that
+  built nothing says so in a row".
+- **Alle Tore vor dem Commit:** `validate.py`, `gen_status.py --check`,
+  `pruefe_prosa.py`, `pruefe_upstream_drift.py`, `pruefe_sperrliste.py`.
+  Braucht **Python ≥ 3.10** und PyYAML.
+- **Nicht pushen ohne ausdrückliche Freigabe.** `origin` ist git.lab;
+  **nie** nach Gitea.
+- Commits englisch, Conventional-Stil, Autor- und Committer-Datum auf
+  12:00:00 UTC des laufenden Tages.
+- Abschluss mit genau einem Status: `DONE` | `DONE_WITH_CONCERNS` |
+  `NEEDS_CONTEXT` | `BLOCKED`.
+
+## Zwei Hinweise, die dich nicht lenken sollen
+
+Ich nenne sie, weil du sie sonst für Funde hältst, die keine sind:
+
+- **Die Ledger-Zeilen wurden einmal nachträglich korrigiert.** Das steht im
+  Ledger selbst unter *Notes*. Ob die Begründung trägt, ist deine Frage —
+  dass es passiert ist, musst du nicht ausgraben.
+- **Ein Abnahmekriterium ist ausdrücklich nur teilweise erfüllt**, nämlich
+  genau dieses Verdikt. Der Lauf konnte es nicht schreiben. Deshalb gibt es
+  dich.
+
+Sonst bekommst du von mir nichts. Kein Vorbefund, keine Liste, keine
+Selbsteinschätzung — die würde deine Antwort vorwegnehmen, und dann hätten
+wir wieder einen Agenten, der sich selbst beurteilt.

docs/wiki/admin/textbloecke.md

@@ -120,3 +120,28 @@ Ein Baustein wird ergänzt, wenn **derselbe Fehler zweimal** passiert ist — ni
 vorsorglich. Sonst wachsen sie, bis sie niemand mehr kopiert, und dann wirken sie
 gar nicht mehr. Wächst einer über acht Zeilen, gehört der Inhalt in die CLAUDE.md
 und hier bleibt der Verweis.
+
+## Vollständige Aufträge an frische Sitzungen
+
+Die Bausteine oben sind Vorspann. Wenn eine ganze Aufgabe an eine **frische**
+Sitzung übergeben wird — weil sie eigenen Kontext braucht oder weil die
+laufende Sitzung sie nicht beurteilen darf —, wird der Auftrag als Seite
+abgelegt statt im Chat zu verschwinden:
+
+| Auftrag | Stand |
+|---|---|
+| [Die Ernte bewerten und einarbeiten](auftrag-ernte-bewerten.md) | ausgeführt |
+| [Judge-Funktion und Spurenpflicht entwerfen](auftrag-judge-und-ledger.md) | ausgeführt |
+| [Verdikt über einen Durchlauf](auftrag-verdikt-v031-etappe-2.md) | offen |
+
+Zwei Gründe, das aufzuheben. Erstens ist der Auftrag der einzige Beleg
+dafür, **was** übergeben wurde — und damit die einzige Grundlage, auf der
+sich später beurteilen lässt, ob das Ergebnis dazu passt. Zweitens gibt es
+einen Fall, in dem die Trennung nicht Bequemlichkeit ist, sondern Bedingung:
+Ein Agent, der seinen eigenen Durchlauf beurteilt, rechtfertigt statt zu
+prüfen. Ein in derselben Sitzung erzeugtes Verdikt ist nichtig, unabhängig
+davon, was darin steht (`WORKFLOW.md`, *Judging a Run*).
+
+⚠️ Ein solcher Auftrag enthält **keine Vorbefunde**. Wer der frischen
+Sitzung mitgibt, was er selbst gefunden hat, bekommt eine Bestätigung statt
+einer Prüfung — dann ist die Trennung nur noch Aufwand.