Teil B aus dem Design #171, auf MVP reduziert durch Betreiberentscheidung vom 2026-10-05. Baut auf #177 auf (geschlossen, 8.0.0-beta.41/.42): raw status [--json], raw capture --update, raw accept --replaces-bundle und der Entscheidungspunkt "new edition of a captured bundle" in wiki-ingest existierten bereits.
Ergebnis (geschlossen 2026-10-05): Gebaut und publiziert als 8.0.0-beta.43, Commit 8fec406, CI grün (Runs 549, 550). Beim Abschluss korrigiert: ein veralteter Satz im CHANGES.md-Changeset von #177, Commit ccede04, CI grün (Run 551). Ein Rest im Python-Code ist als #181 ausgelagert.
Entscheidung (Betreiber, 2026-10-05)
Pull-Schema ohne Automatik. Konfiguration (das _capture.json jedes erfassten Bundles) und Ablauf (raw status → raw capture --update → raw accept --replaces-bundle → Ingest gegen den Editionsdiff) bleiben wie in #177 gebaut. Der Betreiber startet den Lauf selbst, in einer normalen, beaufsichtigten Sitzung auf main, und das Ergebnis wird direkt dort publiziert. Wann aktualisiert wird, entscheidet vorerst der Betreiber. Alles Übrige erkennt die Sitzung selbst: welche Repos sich geändert haben, alter und neuer Commit, welche Dateien und Seiten betroffen sind - der Betreiber nennt nie eine Commit-ID.
Begründung: Das volle Design (Intake-Branch, PR als Freigabe, main mechanisch einmergen, Ablehnungserkennung, unbeaufsichtigter Lauf) war zu viel Komplexität für den Nutzen.
Zurückgestellt, nicht gebaut (Wiederaufnahme nur durch ein neues Issue): unbeaufsichtigter Lauf mit Auslöser, intake/-Branch und PR als Freigabe (#171 D5), sync --merge-from mit Auflösung nach Dateiart (#171 D8), Ablehnung per geschlossener PR, Vorbedingung eigener Checkout. Freigabe ist im MVP die normale: die Diskussion in Schritt 4 von wiki-ingest und die Gates beim publish.
Abgetrennt: Der Befund, dass reconcile() an generierten Dateien scheitert (Exit 1 beim --ff-only, bzw. Rebase-Review-Gate), gilt unabhängig vom Intake und steht in #180.
Befund (Ausgangslage)
Alle Teile existierten; es fehlte nur der Einstieg. Kein Text sagte einer Sitzung, was bei "aktualisiere die erfassten Repos" zu tun ist: Der Entscheidungspunkt in instructions/wiki-ingest/SKILL.md begann mit "raw status reported it" - wer raw status aufruft, stand nirgends, und die description: der Skill nannte keinen solchen Auslöser. Es fehlte kein Code:
raw status meldet je geändertem Bundle alt -> neu, A/M/D gruppiert nach Quellseite mit zitierenden Seiten, und druckt die beiden Folgezeilen (raw capture --update <raw-bundle>, raw accept incoming/<bundle> --replaces-bundle <raw-bundle>). Unerreichbare Repos sind eine Zeile neben den anderen, Exit 0.
raw capture --update und raw accept --replaces-bundle nehmen Pfade, keine Commits.
Der Entscheidungspunkt sagte außerdem "Read the edition diff with git diff on the bundle". Neu hinzugekommene Dateien sind nach dem Accept aber noch nicht verfolgt und erscheinen deshalb nicht in git diff; sie stehen in der A-Liste der Accept-Ausgabe. In Skill und raw/CONTRACT.md ist das präzisiert. Dieselbe Formulierung steht noch in der Erfolgsmeldung und im Command Record von raw accept (Python) - ausgelagert nach #181, weil dieses Issue keinen Code ändern sollte.
Gebaut
Ein neuer Abzweig in Schritt 1 von wiki-ingest, gebaut wie der bestehende "The user named nothing"-Abzweig mit raw pending - kein eigener Skill, keine eigene Instruction:
"Der Betreiber bittet, die erfassten Repos zu aktualisieren" (oder nennt eines davon):
tools/wikitool raw status - nichts geändert → der Lauf endet hier; sagen, wie viele Bundles unverändert sind, und jede Fehlerzeile (nicht erreichbar, Manifest/URL abgewiesen, kein passendes Ref) mit ihrem Grund nennen - die braucht den Betreiber, nicht einen Workaround.
Ein Bundle pro Lauf - entsprechend "One run is one source" der Skill: das genannte, sonst das erste geänderte in der Ausgabe von raw status. Ansagen, welches, alt -> neu als Kurz-SHA aus der Ausgabe, wie viele weitere geändert sind, und Fehlerzeilen wie in Punkt 1. Nichts fragen; der Halt vor dem Schreiben ist Schritt 4. Die weiteren Bundles sind je ein eigener Lauf, den der Betreiber mit derselben Bitte startet - so bleibt jeder Lauf im Iterations-Budget und hat sein eigenes publish. Im Bau ergänzt: Ist das genannte Bundle unverändert oder auf einer Fehlerzeile, endet der Lauf damit; es wird kein anderes ungefragt an seiner Stelle genommen.
Die von raw status gedruckte Zeile raw capture --update <raw-bundle> ausführen; dann ist incoming/<bundle>/ die Quelle dieses Laufs und Schritt 1 läuft normal weiter (Größenprüfung eingeschlossen). Eine Refusal (z. B. incoming/<bundle> existiert schon aus einem früheren Lauf) wird dem Betreiber gezeigt, nicht umgangen.
Ab Schritt 5 trägt der vorhandene Entscheidungspunkt "new edition of a captured bundle" (Accept mit --replaces-bundle, Seiten nachziehen, touch-Zeilen für A/D, ein Commit).
Dazu:
description: der Skill, die Trigger-Zeile und die "Example triggers" nennen den Auslöser ("update the captured repositories", "pull the repo docs").
Der Entscheidungspunkt ist präzisiert: Editionsdiff = git diff -- <raw-bundle> für M/D plus die A-Liste der Accept-Ausgabe; er verweist auf den neuen Abzweig in Schritt 1 als den Weg, auf dem raw status gelaufen ist.
raw/CONTRACT.md § "Getting a repository in" (Editionsdiff präzisiert + Absatz "When to update is the user's call; the rest is not") und README.md (Satz: "Update the captured repositories" an das LLM) sagen, wie ein Betreiber aktualisiert.
Beim Abschluss: Das CHANGES.md-Changeset von #177 behauptete "--json is for the coming intake run". Der gebaute Lauf liest aber die Textausgabe, und der unbeaufsichtigte Lauf, für den --json gedacht war, ist zurückgestellt. Jetzt steht dort, was --json ausgibt (ccede04). Kein docs/-Text behandelt Capture/Intake; sonst war nichts veraltet.
Akzeptanzkriterien
instructions/wiki-ingest/SKILL.md Schritt 1 enthält den Abzweig mit den vier Punkten oben; description: und "Example triggers" nennen den Auslöser; der Entscheidungspunkt nennt den Editionsdiff einschließlich neuer Dateien. (8fec406)
Keine Stelle des Ablaufs verlangt vom Betreiber eine Commit-ID oder einen Pfad, den raw status nicht selbst ausgibt. (Abzweig: "never ask the user for a commit id or a path"; in der Erprobung kam jeder Pfad aus der Ausgabe)
Ein Lauf nimmt genau ein geändertes Bundle und nennt die Zahl der übrigen; ein nicht erreichbares Repo stoppt den Lauf für die anderen nicht. (Text des Abzweigs; mechanisch trägt es raw status, das Fehler als Zeile meldet und mit Exit 0 endet)
Erprobt an einer echten Drift, in einem Scratch-Root (CHEMENU_ROOT, nicht in dieser Instanz). Vorher: Der Scratch-Root (Session-Scratchpad drift-root/, mit hineinkopiertem types/, weil raw capture die Capture-Werte aus types/source.md liest) hat main bei 8ce202a mit --ref main --path README.md --path 'instructions/wiki-ingest/**' als raw/2026/10/chemenu-docs/ erfasst, akzeptiert und lokal committet. Nach dem Publish von 8fec406: raw status meldete 8ce202a34e48 -> 8fec406463f4, M README.md und M instructions/wiki-ingest/SKILL.md, "0 unchanged", und die beiden Next:-Zeilen. Die gedruckte Zeile raw capture --update raw/2026/10/chemenu-docs schrieb die neue Edition, die gedruckte Zeile raw accept incoming/chemenu-docs --replaces-bundle raw/2026/10/chemenu-docs ersetzte sie ("0 added, 2 modified, 0 removed"). git diff --stat auf dem Bundle zeigte beide Dateien plus _capture.json. Keine Commit-ID wurde von Hand eingegeben. Nicht erprobt ist das Nachziehen der Seiten: Der Scratch-Root hat keine Quellseite ("not covered by any source page").
instructions sync ausgeführt; pytest (2272 passed, 3 skipped), docs verify und instructions verify lokal grün; CI auf 8fec406 grün (Runs 549, 550), auf ccede04 grün (Run 551).
Betroffene Stellen
instructions/wiki-ingest/SKILL.md (Frontmatter description:, Trigger-Zeile, Schritt 1, Entscheidungspunkt "new edition of a captured bundle", Example triggers)
raw/CONTRACT.md § "Getting a repository in: raw capture"
README.md, CHANGES.md (Changeset über version bump; Korrektur im #177-Changeset)
veröffentlichte Skill-Kopien über tools/wikitool instructions sync (generiert)
--minor: neuer Arbeitsablauf (Einstieg in einen bestehenden Skill), nur Instruction-Text, keine Schnittstelle geändert oder entfernt. Drop-in in beide Richtungen: Einer älteren Version fehlt nur der Abzweig. Der Bump hat den laufenden Kandidaten von 8.0.0-beta.42 auf 8.0.0-beta.43 gesetzt, ohne ihn weiter zu eskalieren (max-wins). Die Korrektur in CHANGES.md liegt außerhalb des Version-Gates und brauchte keinen Bump.
Teil B aus dem Design #171, **auf MVP reduziert durch Betreiberentscheidung vom 2026-10-05**. Baut auf #177 auf (geschlossen, `8.0.0-beta.41`/`.42`): `raw status [--json]`, `raw capture --update`, `raw accept --replaces-bundle` und der Entscheidungspunkt "new edition of a captured bundle" in `wiki-ingest` existierten bereits.
**Ergebnis (geschlossen 2026-10-05):** Gebaut und publiziert als `8.0.0-beta.43`, Commit `8fec406`, CI grün (Runs [549](https://gitea.nehmer.net/torben/chemenu/actions/runs/549), [550](https://gitea.nehmer.net/torben/chemenu/actions/runs/550)). Beim Abschluss korrigiert: ein veralteter Satz im `CHANGES.md`-Changeset von #177, Commit `ccede04`, CI grün (Run [551](https://gitea.nehmer.net/torben/chemenu/actions/runs/551)). Ein Rest im Python-Code ist als #181 ausgelagert.
## Entscheidung (Betreiber, 2026-10-05)
Pull-Schema ohne Automatik. Konfiguration (das `_capture.json` jedes erfassten Bundles) und Ablauf (`raw status` → `raw capture --update` → `raw accept --replaces-bundle` → Ingest gegen den Editionsdiff) bleiben wie in #177 gebaut. **Der Betreiber startet den Lauf selbst, in einer normalen, beaufsichtigten Sitzung auf `main`, und das Ergebnis wird direkt dort publiziert.** Wann aktualisiert wird, entscheidet vorerst der Betreiber. **Alles Übrige erkennt die Sitzung selbst**: welche Repos sich geändert haben, alter und neuer Commit, welche Dateien und Seiten betroffen sind - der Betreiber nennt nie eine Commit-ID.
Begründung: Das volle Design (Intake-Branch, PR als Freigabe, `main` mechanisch einmergen, Ablehnungserkennung, unbeaufsichtigter Lauf) war zu viel Komplexität für den Nutzen.
**Zurückgestellt, nicht gebaut** (Wiederaufnahme nur durch ein neues Issue): unbeaufsichtigter Lauf mit Auslöser, `intake/`-Branch und PR als Freigabe (#171 D5), `sync --merge-from` mit Auflösung nach Dateiart (#171 D8), Ablehnung per geschlossener PR, Vorbedingung eigener Checkout. Freigabe ist im MVP die normale: die Diskussion in Schritt 4 von `wiki-ingest` und die Gates beim `publish`.
**Abgetrennt:** Der Befund, dass `reconcile()` an generierten Dateien scheitert (Exit 1 beim `--ff-only`, bzw. Rebase-Review-Gate), gilt unabhängig vom Intake und steht in #180.
## Befund (Ausgangslage)
Alle Teile existierten; es fehlte nur der **Einstieg**. Kein Text sagte einer Sitzung, was bei "aktualisiere die erfassten Repos" zu tun ist: Der Entscheidungspunkt in `instructions/wiki-ingest/SKILL.md` begann mit "`raw status` reported it" - wer `raw status` aufruft, stand nirgends, und die `description:` der Skill nannte keinen solchen Auslöser. Es fehlte kein Code:
- `raw status` meldet je geändertem Bundle `alt -> neu`, A/M/D gruppiert nach Quellseite mit zitierenden Seiten, und druckt die beiden Folgezeilen (`raw capture --update <raw-bundle>`, `raw accept incoming/<bundle> --replaces-bundle <raw-bundle>`). Unerreichbare Repos sind eine Zeile neben den anderen, Exit 0.
- `raw capture --update` und `raw accept --replaces-bundle` nehmen Pfade, keine Commits.
Der Entscheidungspunkt sagte außerdem "Read the edition diff with `git diff` on the bundle". Neu hinzugekommene Dateien sind nach dem Accept aber noch nicht verfolgt und erscheinen deshalb nicht in `git diff`; sie stehen in der `A`-Liste der Accept-Ausgabe. In Skill und `raw/CONTRACT.md` ist das präzisiert. Dieselbe Formulierung steht noch in der Erfolgsmeldung und im Command Record von `raw accept` (Python) - **ausgelagert nach #181**, weil dieses Issue keinen Code ändern sollte.
## Gebaut
Ein neuer Abzweig in **Schritt 1 von `wiki-ingest`**, gebaut wie der bestehende "The user named nothing"-Abzweig mit `raw pending` - kein eigener Skill, keine eigene Instruction:
**"Der Betreiber bittet, die erfassten Repos zu aktualisieren"** (oder nennt eines davon):
1. `tools/wikitool raw status` - nichts geändert → der Lauf endet hier; sagen, wie viele Bundles unverändert sind, und jede Fehlerzeile (nicht erreichbar, Manifest/URL abgewiesen, kein passendes Ref) mit ihrem Grund nennen - die braucht den Betreiber, nicht einen Workaround.
2. **Ein Bundle pro Lauf** - entsprechend "One run is one source" der Skill: das genannte, sonst das erste geänderte in der Ausgabe von `raw status`. Ansagen, welches, `alt -> neu` als Kurz-SHA aus der Ausgabe, wie viele weitere geändert sind, und Fehlerzeilen wie in Punkt 1. Nichts fragen; der Halt vor dem Schreiben ist Schritt 4. Die weiteren Bundles sind je ein eigener Lauf, den der Betreiber mit derselben Bitte startet - so bleibt jeder Lauf im Iterations-Budget und hat sein eigenes `publish`. Im Bau ergänzt: Ist das genannte Bundle unverändert oder auf einer Fehlerzeile, endet der Lauf damit; es wird kein anderes ungefragt an seiner Stelle genommen.
3. Die von `raw status` gedruckte Zeile `raw capture --update <raw-bundle>` ausführen; dann ist `incoming/<bundle>/` die Quelle dieses Laufs und Schritt 1 läuft normal weiter (Größenprüfung eingeschlossen). Eine Refusal (z. B. `incoming/<bundle>` existiert schon aus einem früheren Lauf) wird dem Betreiber gezeigt, nicht umgangen.
4. Ab Schritt 5 trägt der vorhandene Entscheidungspunkt "new edition of a captured bundle" (Accept mit `--replaces-bundle`, Seiten nachziehen, `touch`-Zeilen für `A`/`D`, ein Commit).
Dazu:
- `description:` der Skill, die Trigger-Zeile und die "Example triggers" nennen den Auslöser ("update the captured repositories", "pull the repo docs").
- Der Entscheidungspunkt ist präzisiert: Editionsdiff = `git diff -- <raw-bundle>` für `M`/`D` plus die `A`-Liste der Accept-Ausgabe; er verweist auf den neuen Abzweig in Schritt 1 als den Weg, auf dem `raw status` gelaufen ist.
- `raw/CONTRACT.md` § "Getting a repository in" (Editionsdiff präzisiert + Absatz "When to update is the user's call; the rest is not") und `README.md` (Satz: "Update the captured repositories" an das LLM) sagen, wie ein Betreiber aktualisiert.
- Beim Abschluss: Das `CHANGES.md`-Changeset von #177 behauptete "`--json` is for the coming intake run". Der gebaute Lauf liest aber die Textausgabe, und der unbeaufsichtigte Lauf, für den `--json` gedacht war, ist zurückgestellt. Jetzt steht dort, was `--json` ausgibt (`ccede04`). Kein `docs/`-Text behandelt Capture/Intake; sonst war nichts veraltet.
## Akzeptanzkriterien
- [x] `instructions/wiki-ingest/SKILL.md` Schritt 1 enthält den Abzweig mit den vier Punkten oben; `description:` und "Example triggers" nennen den Auslöser; der Entscheidungspunkt nennt den Editionsdiff einschließlich neuer Dateien. (`8fec406`)
- [x] Keine Stelle des Ablaufs verlangt vom Betreiber eine Commit-ID oder einen Pfad, den `raw status` nicht selbst ausgibt. (Abzweig: "never ask the user for a commit id or a path"; in der Erprobung kam jeder Pfad aus der Ausgabe)
- [x] Ein Lauf nimmt genau ein geändertes Bundle und nennt die Zahl der übrigen; ein nicht erreichbares Repo stoppt den Lauf für die anderen nicht. (Text des Abzweigs; mechanisch trägt es `raw status`, das Fehler als Zeile meldet und mit Exit 0 endet)
- [x] **Erprobt an einer echten Drift**, in einem Scratch-Root (`CHEMENU_ROOT`, nicht in dieser Instanz). Vorher: Der Scratch-Root (Session-Scratchpad `drift-root/`, mit hineinkopiertem `types/`, weil `raw capture` die Capture-Werte aus `types/source.md` liest) hat `main` bei `8ce202a` mit `--ref main --path README.md --path 'instructions/wiki-ingest/**'` als `raw/2026/10/chemenu-docs/` erfasst, akzeptiert und lokal committet. Nach dem Publish von `8fec406`: `raw status` meldete `8ce202a34e48 -> 8fec406463f4`, `M README.md` und `M instructions/wiki-ingest/SKILL.md`, "0 unchanged", und die beiden `Next:`-Zeilen. Die gedruckte Zeile `raw capture --update raw/2026/10/chemenu-docs` schrieb die neue Edition, die gedruckte Zeile `raw accept incoming/chemenu-docs --replaces-bundle raw/2026/10/chemenu-docs` ersetzte sie ("0 added, 2 modified, 0 removed"). `git diff --stat` auf dem Bundle zeigte beide Dateien plus `_capture.json`. Keine Commit-ID wurde von Hand eingegeben. Nicht erprobt ist das Nachziehen der Seiten: Der Scratch-Root hat keine Quellseite ("not covered by any source page").
- [x] `instructions sync` ausgeführt; `pytest` (2272 passed, 3 skipped), `docs verify` und `instructions verify` lokal grün; CI auf `8fec406` grün (Runs 549, 550), auf `ccede04` grün (Run 551).
## Betroffene Stellen
- `instructions/wiki-ingest/SKILL.md` (Frontmatter `description:`, Trigger-Zeile, Schritt 1, Entscheidungspunkt "new edition of a captured bundle", Example triggers)
- `raw/CONTRACT.md` § "Getting a repository in: `raw capture`"
- `README.md`, `CHANGES.md` (Changeset über `version bump`; Korrektur im #177-Changeset)
- veröffentlichte Skill-Kopien über `tools/wikitool instructions sync` (generiert)
- kein Python-Code (der Code-Rest steht in #181)
## Versionsteil
**`--minor`**: neuer Arbeitsablauf (Einstieg in einen bestehenden Skill), nur Instruction-Text, keine Schnittstelle geändert oder entfernt. Drop-in in beide Richtungen: Einer älteren Version fehlt nur der Abzweig. Der Bump hat den laufenden Kandidaten von `8.0.0-beta.42` auf `8.0.0-beta.43` gesetzt, ohne ihn weiter zu eskalieren (max-wins). Die Korrektur in `CHANGES.md` liegt außerhalb des Version-Gates und brauchte keinen Bump.
Changelog: Gegen den Baum geprüft (8ce202a). status/blocked entfernt - #177 ist geschlossen. kind/build → kind/decision wegen der neuen offenen Fragen F1-F3 (Abtrennen von Punkt 3, Mass-Update-Gate auf dem Intake-Branch, ein Repo pro Lauf wegen des Iterations-Budgets). Befund korrigiert: Der häufige Fall (ungespeichertes Ingest, main bewegt) endet heute mit Exit 1 am --ff-only, nicht im Rebase-Review-Gate - im Scratch-Repo reproduziert; Punkt 3 deckt jetzt beide Fälle ab und nennt Invarianten. Neu entschieden (Technik): Vorbedingung sauberer Checkout und kein Aufräumen nach einem Halt; Ersterfassung ist nicht Teil des Laufs; sync --merge-from committet selbst, bei Textkonflikt --continue/--abort; maschinenlesbare intake:-Zeile im PR-Text für die Ablehnung. Bestätigt: kb/log.md wird angehängt, die Reihenfolge "main zuerst" stimmt. Neue Kriterien: sauberer Checkout, Ablehnung, Punkt-3-Fall-1.
**Changelog:** Gegen den Baum geprüft (`8ce202a`). `status/blocked` entfernt - #177 ist geschlossen. `kind/build` → `kind/decision` wegen der neuen offenen Fragen F1-F3 (Abtrennen von Punkt 3, Mass-Update-Gate auf dem Intake-Branch, ein Repo pro Lauf wegen des Iterations-Budgets). Befund korrigiert: Der häufige Fall (ungespeichertes Ingest, `main` bewegt) endet heute mit Exit 1 am `--ff-only`, nicht im Rebase-Review-Gate - im Scratch-Repo reproduziert; Punkt 3 deckt jetzt beide Fälle ab und nennt Invarianten. Neu entschieden (Technik): Vorbedingung sauberer Checkout und kein Aufräumen nach einem Halt; Ersterfassung ist nicht Teil des Laufs; `sync --merge-from` committet selbst, bei Textkonflikt `--continue`/`--abort`; maschinenlesbare `intake:`-Zeile im PR-Text für die Ablehnung. Bestätigt: `kb/log.md` wird angehängt, die Reihenfolge "`main` zuerst" stimmt. Neue Kriterien: sauberer Checkout, Ablehnung, Punkt-3-Fall-1.
torben
changed title from Intake-Lauf: unbeaufsichtigter Repo-Abgleich als PR, main mechanisch einmergen statt neu erzeugen to Erfasste Repos aktualisieren: manueller Pull-Lauf auf main als Einstieg in wiki-ingest (MVP)2026-10-05 16:46:33 +00:00
Changelog: Betreiberentscheidung: MVP, manueller Pull-Lauf auf main, keine Automatik. Body neu geschrieben, F1-F3 sind damit gegenstandslos. Zurückgestellt: Intake-Branch/PR, sync --merge-from, Ablehnungserkennung, unbeaufsichtigter Lauf. Der reconcile()-Befund ist nach #180 abgetrennt. Neu: ein Abzweig in wiki-ingest Schritt 1 (raw status → ein Bundle pro Lauf → raw capture --update), Präzisierung des Editionsdiffs (neue Dateien), Erprobung an einer echten Drift im Scratch-Root. Neu gelabelt: area/workflow → area/kb (Intake nach raw/ wie #177), kind/decision → kind/build, size/L → size/S (nur Instruction-Text). Titel angepasst.
**Changelog:** Betreiberentscheidung: MVP, manueller Pull-Lauf auf `main`, keine Automatik. Body neu geschrieben, F1-F3 sind damit gegenstandslos. Zurückgestellt: Intake-Branch/PR, `sync --merge-from`, Ablehnungserkennung, unbeaufsichtigter Lauf. Der `reconcile()`-Befund ist nach #180 abgetrennt. Neu: ein Abzweig in `wiki-ingest` Schritt 1 (`raw status` → ein Bundle pro Lauf → `raw capture --update`), Präzisierung des Editionsdiffs (neue Dateien), Erprobung an einer echten Drift im Scratch-Root. Neu gelabelt: `area/workflow` → `area/kb` (Intake nach `raw/` wie #177), `kind/decision` → `kind/build`, `size/L` → `size/S` (nur Instruction-Text). Titel angepasst.
Changelog: Gebaut und publiziert als 8.0.0-beta.43 (8fec406), CI grün (Runs 549, 550); alle fünf Kriterien abgehakt, Drift-Erprobung mit Ergebnis im Body. Neu im Entwurf: Ein genanntes, aber unverändertes oder fehlerhaftes Bundle beendet den Lauf, statt still ein anderes zu nehmen. Neu unter "Befund": Die Erfolgsmeldung von raw accept --replaces-bundle hat dieselbe git diff-Ungenauigkeit, gehört aber zum Python-Code und bleibt deshalb außerhalb des Umfangs. Ob sie ein eigenes Issue wird, entscheidet stack-close bzw. der Betreiber.
**Changelog:** Gebaut und publiziert als `8.0.0-beta.43` (`8fec406`), CI grün (Runs 549, 550); alle fünf Kriterien abgehakt, Drift-Erprobung mit Ergebnis im Body. Neu im Entwurf: Ein genanntes, aber unverändertes oder fehlerhaftes Bundle beendet den Lauf, statt still ein anderes zu nehmen. Neu unter "Befund": Die Erfolgsmeldung von `raw accept --replaces-bundle` hat dieselbe `git diff`-Ungenauigkeit, gehört aber zum Python-Code und bleibt deshalb außerhalb des Umfangs. Ob sie ein eigenes Issue wird, entscheidet `stack-close` bzw. der Betreiber.
Changelog: Abschluss. Body in den Endzustand gebracht: "Stand" ist jetzt "Ergebnis", Ausgangslage und Gebautes sind getrennt, der offene Code-Rest ist nach #181 ausgelagert. Veraltet war nur ein Satz im #177-Changeset in CHANGES.md ("--json is for the coming intake run"); korrigiert in ccede04, CI grün (Run 551). Kein docs/-Text betroffen.
**Changelog:** Abschluss. Body in den Endzustand gebracht: "Stand" ist jetzt "Ergebnis", Ausgangslage und Gebautes sind getrennt, der offene Code-Rest ist nach #181 ausgelagert. Veraltet war nur ein Satz im #177-Changeset in `CHANGES.md` ("`--json` is for the coming intake run"); korrigiert in `ccede04`, CI grün (Run 551). Kein `docs/`-Text betroffen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Teil B aus dem Design #171, auf MVP reduziert durch Betreiberentscheidung vom 2026-10-05. Baut auf #177 auf (geschlossen,
8.0.0-beta.41/.42):raw status [--json],raw capture --update,raw accept --replaces-bundleund der Entscheidungspunkt "new edition of a captured bundle" inwiki-ingestexistierten bereits.Ergebnis (geschlossen 2026-10-05): Gebaut und publiziert als
8.0.0-beta.43, Commit8fec406, CI grün (Runs 549, 550). Beim Abschluss korrigiert: ein veralteter Satz imCHANGES.md-Changeset von #177, Commitccede04, CI grün (Run 551). Ein Rest im Python-Code ist als #181 ausgelagert.Entscheidung (Betreiber, 2026-10-05)
Pull-Schema ohne Automatik. Konfiguration (das
_capture.jsonjedes erfassten Bundles) und Ablauf (raw status→raw capture --update→raw accept --replaces-bundle→ Ingest gegen den Editionsdiff) bleiben wie in #177 gebaut. Der Betreiber startet den Lauf selbst, in einer normalen, beaufsichtigten Sitzung aufmain, und das Ergebnis wird direkt dort publiziert. Wann aktualisiert wird, entscheidet vorerst der Betreiber. Alles Übrige erkennt die Sitzung selbst: welche Repos sich geändert haben, alter und neuer Commit, welche Dateien und Seiten betroffen sind - der Betreiber nennt nie eine Commit-ID.Begründung: Das volle Design (Intake-Branch, PR als Freigabe,
mainmechanisch einmergen, Ablehnungserkennung, unbeaufsichtigter Lauf) war zu viel Komplexität für den Nutzen.Zurückgestellt, nicht gebaut (Wiederaufnahme nur durch ein neues Issue): unbeaufsichtigter Lauf mit Auslöser,
intake/-Branch und PR als Freigabe (#171 D5),sync --merge-frommit Auflösung nach Dateiart (#171 D8), Ablehnung per geschlossener PR, Vorbedingung eigener Checkout. Freigabe ist im MVP die normale: die Diskussion in Schritt 4 vonwiki-ingestund die Gates beimpublish.Abgetrennt: Der Befund, dass
reconcile()an generierten Dateien scheitert (Exit 1 beim--ff-only, bzw. Rebase-Review-Gate), gilt unabhängig vom Intake und steht in #180.Befund (Ausgangslage)
Alle Teile existierten; es fehlte nur der Einstieg. Kein Text sagte einer Sitzung, was bei "aktualisiere die erfassten Repos" zu tun ist: Der Entscheidungspunkt in
instructions/wiki-ingest/SKILL.mdbegann mit "raw statusreported it" - werraw statusaufruft, stand nirgends, und diedescription:der Skill nannte keinen solchen Auslöser. Es fehlte kein Code:raw statusmeldet je geändertem Bundlealt -> neu, A/M/D gruppiert nach Quellseite mit zitierenden Seiten, und druckt die beiden Folgezeilen (raw capture --update <raw-bundle>,raw accept incoming/<bundle> --replaces-bundle <raw-bundle>). Unerreichbare Repos sind eine Zeile neben den anderen, Exit 0.raw capture --updateundraw accept --replaces-bundlenehmen Pfade, keine Commits.Der Entscheidungspunkt sagte außerdem "Read the edition diff with
git diffon the bundle". Neu hinzugekommene Dateien sind nach dem Accept aber noch nicht verfolgt und erscheinen deshalb nicht ingit diff; sie stehen in derA-Liste der Accept-Ausgabe. In Skill undraw/CONTRACT.mdist das präzisiert. Dieselbe Formulierung steht noch in der Erfolgsmeldung und im Command Record vonraw accept(Python) - ausgelagert nach #181, weil dieses Issue keinen Code ändern sollte.Gebaut
Ein neuer Abzweig in Schritt 1 von
wiki-ingest, gebaut wie der bestehende "The user named nothing"-Abzweig mitraw pending- kein eigener Skill, keine eigene Instruction:"Der Betreiber bittet, die erfassten Repos zu aktualisieren" (oder nennt eines davon):
tools/wikitool raw status- nichts geändert → der Lauf endet hier; sagen, wie viele Bundles unverändert sind, und jede Fehlerzeile (nicht erreichbar, Manifest/URL abgewiesen, kein passendes Ref) mit ihrem Grund nennen - die braucht den Betreiber, nicht einen Workaround.raw status. Ansagen, welches,alt -> neuals Kurz-SHA aus der Ausgabe, wie viele weitere geändert sind, und Fehlerzeilen wie in Punkt 1. Nichts fragen; der Halt vor dem Schreiben ist Schritt 4. Die weiteren Bundles sind je ein eigener Lauf, den der Betreiber mit derselben Bitte startet - so bleibt jeder Lauf im Iterations-Budget und hat sein eigenespublish. Im Bau ergänzt: Ist das genannte Bundle unverändert oder auf einer Fehlerzeile, endet der Lauf damit; es wird kein anderes ungefragt an seiner Stelle genommen.raw statusgedruckte Zeileraw capture --update <raw-bundle>ausführen; dann istincoming/<bundle>/die Quelle dieses Laufs und Schritt 1 läuft normal weiter (Größenprüfung eingeschlossen). Eine Refusal (z. B.incoming/<bundle>existiert schon aus einem früheren Lauf) wird dem Betreiber gezeigt, nicht umgangen.--replaces-bundle, Seiten nachziehen,touch-Zeilen fürA/D, ein Commit).Dazu:
description:der Skill, die Trigger-Zeile und die "Example triggers" nennen den Auslöser ("update the captured repositories", "pull the repo docs").git diff -- <raw-bundle>fürM/Dplus dieA-Liste der Accept-Ausgabe; er verweist auf den neuen Abzweig in Schritt 1 als den Weg, auf demraw statusgelaufen ist.raw/CONTRACT.md§ "Getting a repository in" (Editionsdiff präzisiert + Absatz "When to update is the user's call; the rest is not") undREADME.md(Satz: "Update the captured repositories" an das LLM) sagen, wie ein Betreiber aktualisiert.CHANGES.md-Changeset von #177 behauptete "--jsonis for the coming intake run". Der gebaute Lauf liest aber die Textausgabe, und der unbeaufsichtigte Lauf, für den--jsongedacht war, ist zurückgestellt. Jetzt steht dort, was--jsonausgibt (ccede04). Keindocs/-Text behandelt Capture/Intake; sonst war nichts veraltet.Akzeptanzkriterien
instructions/wiki-ingest/SKILL.mdSchritt 1 enthält den Abzweig mit den vier Punkten oben;description:und "Example triggers" nennen den Auslöser; der Entscheidungspunkt nennt den Editionsdiff einschließlich neuer Dateien. (8fec406)raw statusnicht selbst ausgibt. (Abzweig: "never ask the user for a commit id or a path"; in der Erprobung kam jeder Pfad aus der Ausgabe)raw status, das Fehler als Zeile meldet und mit Exit 0 endet)CHEMENU_ROOT, nicht in dieser Instanz). Vorher: Der Scratch-Root (Session-Scratchpaddrift-root/, mit hineinkopiertemtypes/, weilraw capturedie Capture-Werte austypes/source.mdliest) hatmainbei8ce202amit--ref main --path README.md --path 'instructions/wiki-ingest/**'alsraw/2026/10/chemenu-docs/erfasst, akzeptiert und lokal committet. Nach dem Publish von8fec406:raw statusmeldete8ce202a34e48 -> 8fec406463f4,M README.mdundM instructions/wiki-ingest/SKILL.md, "0 unchanged", und die beidenNext:-Zeilen. Die gedruckte Zeileraw capture --update raw/2026/10/chemenu-docsschrieb die neue Edition, die gedruckte Zeileraw accept incoming/chemenu-docs --replaces-bundle raw/2026/10/chemenu-docsersetzte sie ("0 added, 2 modified, 0 removed").git diff --statauf dem Bundle zeigte beide Dateien plus_capture.json. Keine Commit-ID wurde von Hand eingegeben. Nicht erprobt ist das Nachziehen der Seiten: Der Scratch-Root hat keine Quellseite ("not covered by any source page").instructions syncausgeführt;pytest(2272 passed, 3 skipped),docs verifyundinstructions verifylokal grün; CI auf8fec406grün (Runs 549, 550), aufccede04grün (Run 551).Betroffene Stellen
instructions/wiki-ingest/SKILL.md(Frontmatterdescription:, Trigger-Zeile, Schritt 1, Entscheidungspunkt "new edition of a captured bundle", Example triggers)raw/CONTRACT.md§ "Getting a repository in:raw capture"README.md,CHANGES.md(Changeset überversion bump; Korrektur im #177-Changeset)tools/wikitool instructions sync(generiert)Versionsteil
--minor: neuer Arbeitsablauf (Einstieg in einen bestehenden Skill), nur Instruction-Text, keine Schnittstelle geändert oder entfernt. Drop-in in beide Richtungen: Einer älteren Version fehlt nur der Abzweig. Der Bump hat den laufenden Kandidaten von8.0.0-beta.42auf8.0.0-beta.43gesetzt, ohne ihn weiter zu eskalieren (max-wins). Die Korrektur inCHANGES.mdliegt außerhalb des Version-Gates und brauchte keinen Bump.Changelog: Gegen den Baum geprüft (
8ce202a).status/blockedentfernt - #177 ist geschlossen.kind/build→kind/decisionwegen der neuen offenen Fragen F1-F3 (Abtrennen von Punkt 3, Mass-Update-Gate auf dem Intake-Branch, ein Repo pro Lauf wegen des Iterations-Budgets). Befund korrigiert: Der häufige Fall (ungespeichertes Ingest,mainbewegt) endet heute mit Exit 1 am--ff-only, nicht im Rebase-Review-Gate - im Scratch-Repo reproduziert; Punkt 3 deckt jetzt beide Fälle ab und nennt Invarianten. Neu entschieden (Technik): Vorbedingung sauberer Checkout und kein Aufräumen nach einem Halt; Ersterfassung ist nicht Teil des Laufs;sync --merge-fromcommittet selbst, bei Textkonflikt--continue/--abort; maschinenlesbareintake:-Zeile im PR-Text für die Ablehnung. Bestätigt:kb/log.mdwird angehängt, die Reihenfolge "mainzuerst" stimmt. Neue Kriterien: sauberer Checkout, Ablehnung, Punkt-3-Fall-1.Intake-Lauf: unbeaufsichtigter Repo-Abgleich als PR, main mechanisch einmergen statt neu erzeugento Erfasste Repos aktualisieren: manueller Pull-Lauf auf main als Einstieg in wiki-ingest (MVP)Changelog: Betreiberentscheidung: MVP, manueller Pull-Lauf auf
main, keine Automatik. Body neu geschrieben, F1-F3 sind damit gegenstandslos. Zurückgestellt: Intake-Branch/PR,sync --merge-from, Ablehnungserkennung, unbeaufsichtigter Lauf. Derreconcile()-Befund ist nach #180 abgetrennt. Neu: ein Abzweig inwiki-ingestSchritt 1 (raw status→ ein Bundle pro Lauf →raw capture --update), Präzisierung des Editionsdiffs (neue Dateien), Erprobung an einer echten Drift im Scratch-Root. Neu gelabelt:area/workflow→area/kb(Intake nachraw/wie #177),kind/decision→kind/build,size/L→size/S(nur Instruction-Text). Titel angepasst.Changelog: Gebaut und publiziert als
8.0.0-beta.43(8fec406), CI grün (Runs 549, 550); alle fünf Kriterien abgehakt, Drift-Erprobung mit Ergebnis im Body. Neu im Entwurf: Ein genanntes, aber unverändertes oder fehlerhaftes Bundle beendet den Lauf, statt still ein anderes zu nehmen. Neu unter "Befund": Die Erfolgsmeldung vonraw accept --replaces-bundlehat dieselbegit diff-Ungenauigkeit, gehört aber zum Python-Code und bleibt deshalb außerhalb des Umfangs. Ob sie ein eigenes Issue wird, entscheidetstack-closebzw. der Betreiber.Changelog: Abschluss. Body in den Endzustand gebracht: "Stand" ist jetzt "Ergebnis", Ausgangslage und Gebautes sind getrennt, der offene Code-Rest ist nach #181 ausgelagert. Veraltet war nur ein Satz im #177-Changeset in
CHANGES.md("--jsonis for the coming intake run"); korrigiert inccede04, CI grün (Run 551). Keindocs/-Text betroffen.