Thore CimbalandClaude Opus 5
8280ead37d
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
171 lines
10 KiB
Markdown
171 lines
10 KiB
Markdown
---
|
||
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.
|