Teilpaket von #140. Entschieden: D20 und D21 (Betreiber, 2026-09-28), E1–E4 (Betreiber, 2026-09-30).
Erledigt (geschlossen 2026-10-02). Gebaut und veröffentlicht am 2026-09-30, alle Läufe grün. Die Workflows laufen nachweislich auch nach Zeitplan: sp-live-image am 2026-10-01 mit dem monatlichen Neubau (Lauf 471) und am 2026-10-02 ohne Neubau (Lauf 490), tracker-live nächtlich am 2026-10-01 und 2026-10-02 (Läufe 472 und 491).
Version: 8.0.0-beta.3 (minor), dazu 8.0.0-beta.4 (patch) für die E1-Korrektur
Commits:
b0c6477: die Umsetzung
a126734, 6554791, 5a4c518: drei CI-Korrekturen nach dem ersten echten Lauf
config.tasks_config_path() liest die Variable. Sie wird relativ zum Arbeitsverzeichnis aufgelöst, ~ wird expandiert. Sonst gilt <root>/.wikitool-tasks.json.
Eine gesetzte Variable ohne Datei ist ein ValidationError, der den Pfad nennt, und niemals „kein Tracker“.
Die Meldungen von task, review und doctor nennen die tatsächlich gelesene Datei. doctor meldet einen aktiven Override.
Nachgezogen in conftest.py (_WIKITOOL_ENV), testing-conventions.md, tools/CONTRACT.md und INSTALL.md § Konfiguration.
task new legt ein normales und ein WAITING-Item mit überfälligem Follow-up an.
task list findet beide.
review meldet waiting_overdue für genau dieses Item.
task close schließt beide.
Die Sicherheitsregeln sind Code:
Geschrieben wird nur ins Markerprojekt Chemenu Live-Test.
Jedes Item trägt das Präfix [live-test <run-id>].
Es wird nie gelöscht.
Fehlt das Markerprojekt, bricht die Suite vor dem ersten Schreibzugriff ab.
Antwortet vor dem SP-Start schon etwas auf Port 3876, startet die Suite nicht.
Profilpfade mit ~ werden abgelehnt.
Headless SP (tests/sp_headless.py): gepackte App, Seed-Backup, Bestätigung des Restore-Dialogs über CDP (in Python), Log-Auszug in jeder Abbruchmeldung.
Aufgenommene Fixtures (tests/fixtures/sp/): echte Antworten von v19.1.0 und ein Backup, das die App selbst geschrieben hat, mit MANIFEST.json (Version, Datum, die eine nachträgliche Änderung). test_sp_recorded.py spielt sie bei jedem Push ab, einschließlich der Demo-Projekte; record_sp_fixtures.py nimmt sie neu auf.
CI und Image.
ci.yml startet Radicale in einem eigenen Schritt und führt danach die CalDAV-Live-Suite mit CHEMENU_LIVE_REQUIRE=caldav aus.
täglich, wenn der Update-Kanal eine Version nennt, die noch nicht in der Registry liegt
monatlich zwingend
per Dispatch mit sp_version, ohne :latest umzusetzen
tracker-live.yml läuft nächtlich und per Dispatch im Image, mit CHEMENU_LIVE_REQUIRE=sp,caldav.
Prozedur:instructions/dev/tracker-testing.md (in stack-dev Schritt 2 eingetragen), DEVELOPMENT.md, doc-pull-through.md. Dazu /.wikitool-tasks.d/ in .gitignore, mit Canary in docs verify.
Demo-Korpus nach E1: drei Seiten unter kb/gtd/technik/, provenance: general, mit Issue-Links:
Chemenu 8.0.0 - Installation und Windows (active, aus #140)
Aufgabenverwaltung mit Tracker-Anbindung (completed, aus #119/#124)
Die aktive Seite hat die damals offenen Pakete aus #140 (#151–#154, #157–#159) als Items und „Prüfpunkte T1–T12 vom Betreiber“ als WAITING mit Follow-up 2026-09-15; #160 liegt im Backlog (Someday).
Die abgeschlossene und die ruhende Seite haben keine Items.
Das Follow-up liegt so weit zurück, weil waiting_overdue erst nach stalled_waiting_days (14) greift. Der Seed ist ein fester Teststand und folgt dem Fortschritt von #140 bewusst nicht.
Abweichungen vom Entwurf, beim Bau entschieden
Tracker werden über Umgebungsvariablen benannt, statt über alle /.wikitool-tasks.d/*.json zu iterieren.
Die drei Wege:
CHEMENU_LIVE_SP_BINARY: Die Suite startet ihr eigenes SP.
CHEMENU_LIVE_CALDAV_*: Radicale in der CI.
CHEMENU_LIVE_PROFILE=<name>: ein eigener Tracker aus /.wikitool-tasks.d/<name>.json.
Grund: Ein Profil eines echten Trackers soll nie durch ein bloßes pytest beschrieben werden, sondern nur auf ausdrücklichen Wunsch.
CHEMENU_LIVE_REQUIRE macht in der CI aus „nicht konfiguriert“ ein Rot statt eines Skips.
Kein Snapshot-Live-Lauf. Der Snapshot-Zugriff ist nur lesend, das Szenario braucht aber einen Schreibpfad. Den Snapshot-Leser prüft test_the_snapshot_reader_reads_a_backup_the_app_wrote bei jedem Push gegen ein Backup, das die App selbst geschrieben hat.
tracker-live ohne sp_version-Eingabe und ohne Fixture-Artefakt.
Statt des Hinweisschritts vergleicht der Lauf die installierte Version mit dem Update-Kanal und warnt bei Abweichung.
Fixtures werden nach tracker-testing.md § Refreshing the fixtures von Hand nachgezogen.
Eine ältere Version prüft man über sp-live-image mit sp_version und docker run auf :<version>.
Die SP-Hilfen liegen unter tools/chemenu/tests/ und werden mit der Testsuite ausgeliefert. Das ist die Option „nachweislich harmlos“ aus dem Entwurf:
In einem frischen dist export laufen test_tracker_live.py und test_sp_recorded.py mit 17 bestanden und 3 übersprungen (die Live-Tests).
.gitea/ und instructions/dev/ fehlen im Export.
Bekannte Kleinigkeit, bewusst so gelassen: Die Skip-Meldung nennt instructions/dev/tracker-testing.md, und diese Datei fehlt in einer Instanz.
Seed nach E1 mit einer Nachbearbeitung. Die REST-API kann kein Backlog-Item anlegen. Deshalb ist das Item für #160 im Backup, das die App geschrieben hat, von taskIds nach backlogTaskIds verschoben; MANIFEST.json nennt das.
Versuch act_runner und :latest geklärt: Der Runner zieht mit forcePull=true und ohne Anmeldung (Lauf 442, bestätigt in den Läufen 472 und 491 nach Zeitplan). Die Ausweichlösung mit einem Mini-Job entfällt.
Akzeptanzkriterien
Zwei Tracker im selben Checkout nacheinander über WIKITOOL_TASKS_CONFIG, ohne Dateitausch. Belegt durch tracker-live (Läufe 442 und 448: SP und CalDAV in einem pytest-Lauf, Override je Test) und durch review von Hand gegen ein Seed-Profil.
Override auf eine fehlende Datei: review, task list und doctor nennen den Pfad, keiner meldet „no tracker configured“. Belegt durch die Override-Tests in test_review.py, test_task_cmd.py und test_doctor.py.
git status bleibt nach einem Live-Lauf sauber.
Ohne Tracker überspringt pytest die Live-Suite mit Grund; mit Tracker läuft sie (Läufe 441, 442 und 448). Die Profil-Art ist über Tests gegen Fakes belegt (load_profile, ~-Ablehnung, Namensprüfung), aber in diesem Paket nicht gegen einen echten eigenen Tracker gelaufen.
Ohne Markerprojekt bricht die Suite vor dem ersten Schreibzugriff ab. Ist Port 3876 belegt, startet SP nicht. Beides belegt durch Tests gegen Fakes.
Nach einem grünen Lauf ist kein Item des Laufs mehr offen, und nichts wurde gelöscht (Assertion im Szenario).
Das Push-CI führt die CalDAV-Live-Suite aus. In Lauf 441 steht sie als gelaufen: [tracker-live] CalDAV … radicale 3.8.1, 1 bestanden. Vorher waren 435, 438 und 439 rot; die Ursachen waren kein curl im Job-Image und GITHUB_ENV im selben Schritt. Behoben in a126734 und 5a4c518.
chemenu-sp-live:19.1.0 und :latest liegen in der Registry (Lauf 440), die Version entspricht latest-linux.yml, die sha512-Prüfung der .deb ist bestanden, und das Paket ist torben/chemenu zugeordnet (Betreiber, 2026-09-30). Der erste Build-Versuch (437) scheiterte an fehlendem unzip für die 1Password-Action; behoben in 6554791.
sp-live-image:
baut bei unverändertem Kanal nicht neu (Lauf 443 per Dispatch, Lauf 490 nach Zeitplan am 2026-10-02: build=false, „Build and push“ übersprungen)
baut, wenn die Version fehlt (Lauf 440)
baut mit sp_version=19.0.1 nur :19.0.1 und lässt :latest stehen (Lauf 444)
baut monatlich zwingend: Lauf 471 nach Zeitplan am 2026-10-01, build=true (monthly rebuild), Tag :19.1.0
tracker-live zieht ohne Anmeldung, nennt die SP-Version, ohne apt im Lauf, und ist per Dispatch grün (Läufe 442 und 448) und nach Zeitplan grün: Lauf 472 (2026-10-01) und Lauf 491 (2026-10-02), jeweils forcePull=true ohne Anmeldung, installed: 19.1.0, update channel: 19.1.0, SP 19.1.0 und Radicale 3.8.1, 2 passed, 2 skipped (übersprungen sind die nicht konfigurierten Arten; die beiden mit CHEMENU_LIVE_REQUIRE verlangten liefen). Gegen SP mit snapshot: entfällt, siehe Abweichungen.
Die SP-Fixtures sind committet, tragen SP-Version und Datum (MANIFEST.json) und werden bei jedem Push ohne App geprüft.
Die drei Projektseiten aus E1 existieren, und lint ist sauber. review mit dem Seed-Profil trifft die Richtung kb→Tracker: Die aktive Seite findet ihr Projekt mit 8 offenen Items, waiting_overdue meldet die Prüfpunkte, und die abgeschlossene und die ruhende Seite bleiben still. Die Richtung Tracker→kb (unpaged_project) feuert mit dem Seed nicht, weil das Markerprojekt jünger als drei Wochen ist; test_review.py deckt sie ab.
tracker-testing.md beschreibt beide Provider bis zum grünen Lauf, die Regel für den Dispatch durch den Agenten, den Umgang mit einer roten Nacht, die Paketzuordnung und den Neuaufbau des Seeds. dist export liefert weder die Datei noch das Dockerfile noch die Workflows aus. Die SP-Hilfen gehen mit und sind inert, siehe Abweichungen.
testing-conventions.md nennt die Live-Suite als die eine ausdrückliche Ausnahme.
Version
minor 8.0.0-beta.3 und patch 8.0.0-beta.4 im 8.0.0-Kandidaten (#140 D19). Die CI-Korrekturen unter .gitea/ brauchen keinen Bump. Das Schließen selbst hat keine Datei berührt.
Teilpaket von #140. Entschieden: D20 und D21 (Betreiber, 2026-09-28), E1–E4 (Betreiber, 2026-09-30).
**Erledigt (geschlossen 2026-10-02).** Gebaut und veröffentlicht am 2026-09-30, alle Läufe grün. Die Workflows laufen nachweislich auch nach Zeitplan: `sp-live-image` am 2026-10-01 mit dem monatlichen Neubau (Lauf 471) und am 2026-10-02 ohne Neubau (Lauf 490), `tracker-live` nächtlich am 2026-10-01 und 2026-10-02 (Läufe 472 und 491).
- Version: 8.0.0-beta.3 (minor), dazu 8.0.0-beta.4 (patch) für die E1-Korrektur
- Commits:
- `b0c6477`: die Umsetzung
- `a126734`, `6554791`, `5a4c518`: drei CI-Korrekturen nach dem ersten echten Lauf
- `dea98d4`: Kommentar zum Pull-Verhalten
- `40413f9`: Demo-Korpus nach E1
- Vorher gebaut: #162 (`529793b`, geschlossen)
## Was gebaut ist
1. **Konfigurations-Override `WIKITOOL_TASKS_CONFIG`.**
- `config.tasks_config_path()` liest die Variable. Sie wird relativ zum Arbeitsverzeichnis aufgelöst, `~` wird expandiert. Sonst gilt `<root>/.wikitool-tasks.json`.
- Eine gesetzte Variable ohne Datei ist ein `ValidationError`, der den Pfad nennt, und niemals „kein Tracker“.
- Die Meldungen von `task`, `review` und `doctor` nennen die tatsächlich gelesene Datei. `doctor` meldet einen aktiven Override.
- Nachgezogen in `conftest.py` (`_WIKITOOL_ENV`), `testing-conventions.md`, `tools/CONTRACT.md` und `INSTALL.md` § Konfiguration.
2. **Live-Suite `live_tracker`** (`tests/test_tracker_live.py`, `tests/tracker_live.py`).
- Das Szenario ist je Tracker gleich:
1. `task new` legt ein normales und ein WAITING-Item mit überfälligem Follow-up an.
2. `task list` findet beide.
3. `review` meldet `waiting_overdue` für genau dieses Item.
4. `task close` schließt beide.
- Die Sicherheitsregeln sind Code:
- Geschrieben wird nur ins Markerprojekt `Chemenu Live-Test`.
- Jedes Item trägt das Präfix `[live-test <run-id>]`.
- Es wird nie gelöscht.
- Fehlt das Markerprojekt, bricht die Suite vor dem ersten Schreibzugriff ab.
- Antwortet vor dem SP-Start schon etwas auf Port 3876, startet die Suite nicht.
- Profilpfade mit `~` werden abgelehnt.
3. **Headless SP** (`tests/sp_headless.py`): gepackte App, Seed-Backup, Bestätigung des Restore-Dialogs über CDP (in Python), Log-Auszug in jeder Abbruchmeldung.
4. **Aufgenommene Fixtures** (`tests/fixtures/sp/`): echte Antworten von v19.1.0 und ein Backup, das die App selbst geschrieben hat, mit `MANIFEST.json` (Version, Datum, die eine nachträgliche Änderung). `test_sp_recorded.py` spielt sie bei jedem Push ab, einschließlich der Demo-Projekte; `record_sp_fixtures.py` nimmt sie neu auf.
5. **CI und Image.**
- `ci.yml` startet Radicale in einem eigenen Schritt und führt danach die CalDAV-Live-Suite mit `CHEMENU_LIVE_REQUIRE=caldav` aus.
- `sp-live-image.yml` baut `gitea.nehmer.net/torben/chemenu-sp-live`:
- täglich, wenn der Update-Kanal eine Version nennt, die noch nicht in der Registry liegt
- monatlich zwingend
- per Dispatch mit `sp_version`, ohne `:latest` umzusetzen
- `tracker-live.yml` läuft nächtlich und per Dispatch im Image, mit `CHEMENU_LIVE_REQUIRE=sp,caldav`.
6. **Prozedur:** `instructions/dev/tracker-testing.md` (in `stack-dev` Schritt 2 eingetragen), `DEVELOPMENT.md`, `doc-pull-through.md`. Dazu `/.wikitool-tasks.d/` in `.gitignore`, mit Canary in `docs verify`.
7. **Demo-Korpus nach E1:** drei Seiten unter `kb/gtd/technik/`, `provenance: general`, mit Issue-Links:
- `Chemenu 8.0.0 - Installation und Windows` (active, aus #140)
- `Aufgabenverwaltung mit Tracker-Anbindung` (completed, aus #119/#124)
- `Reproduktionslauf des Korpus` (dormant, aus #69)
Der Seed trägt die gleichnamigen Projekte:
- Die aktive Seite hat die damals offenen Pakete aus #140 (#151–#154, #157–#159) als Items und „Prüfpunkte T1–T12 vom Betreiber“ als WAITING mit Follow-up 2026-09-15; #160 liegt im Backlog (Someday).
- Die abgeschlossene und die ruhende Seite haben keine Items.
Das Follow-up liegt so weit zurück, weil `waiting_overdue` erst nach `stalled_waiting_days` (14) greift. Der Seed ist ein fester Teststand und folgt dem Fortschritt von #140 bewusst nicht.
## Abweichungen vom Entwurf, beim Bau entschieden
- **Tracker werden über Umgebungsvariablen benannt, statt über alle `/.wikitool-tasks.d/*.json` zu iterieren.**
- Die drei Wege:
- `CHEMENU_LIVE_SP_BINARY`: Die Suite startet ihr eigenes SP.
- `CHEMENU_LIVE_CALDAV_*`: Radicale in der CI.
- `CHEMENU_LIVE_PROFILE=<name>`: ein eigener Tracker aus `/.wikitool-tasks.d/<name>.json`.
- Grund: Ein Profil eines echten Trackers soll nie durch ein bloßes `pytest` beschrieben werden, sondern nur auf ausdrücklichen Wunsch.
- `CHEMENU_LIVE_REQUIRE` macht in der CI aus „nicht konfiguriert“ ein Rot statt eines Skips.
- **Kein Snapshot-Live-Lauf.** Der Snapshot-Zugriff ist nur lesend, das Szenario braucht aber einen Schreibpfad. Den Snapshot-Leser prüft `test_the_snapshot_reader_reads_a_backup_the_app_wrote` bei jedem Push gegen ein Backup, das die App selbst geschrieben hat.
- **`tracker-live` ohne `sp_version`-Eingabe und ohne Fixture-Artefakt.**
- Statt des Hinweisschritts vergleicht der Lauf die installierte Version mit dem Update-Kanal und warnt bei Abweichung.
- Fixtures werden nach `tracker-testing.md` § Refreshing the fixtures von Hand nachgezogen.
- Eine ältere Version prüft man über `sp-live-image` mit `sp_version` und `docker run` auf `:<version>`.
- **Die SP-Hilfen liegen unter `tools/chemenu/tests/` und werden mit der Testsuite ausgeliefert.** Das ist die Option „nachweislich harmlos“ aus dem Entwurf:
- In einem frischen `dist export` laufen `test_tracker_live.py` und `test_sp_recorded.py` mit 17 bestanden und 3 übersprungen (die Live-Tests).
- `.gitea/` und `instructions/dev/` fehlen im Export.
- Bekannte Kleinigkeit, bewusst so gelassen: Die Skip-Meldung nennt `instructions/dev/tracker-testing.md`, und diese Datei fehlt in einer Instanz.
- **Seed nach E1 mit einer Nachbearbeitung.** Die REST-API kann kein Backlog-Item anlegen. Deshalb ist das Item für #160 im Backup, das die App geschrieben hat, von `taskIds` nach `backlogTaskIds` verschoben; `MANIFEST.json` nennt das.
- **Versuch `act_runner` und `:latest` geklärt:** Der Runner zieht mit `forcePull=true` und ohne Anmeldung (Lauf 442, bestätigt in den Läufen 472 und 491 nach Zeitplan). Die Ausweichlösung mit einem Mini-Job entfällt.
## Akzeptanzkriterien
- [x] Zwei Tracker im selben Checkout nacheinander über `WIKITOOL_TASKS_CONFIG`, ohne Dateitausch. Belegt durch `tracker-live` (Läufe 442 und 448: SP und CalDAV in einem pytest-Lauf, Override je Test) und durch `review` von Hand gegen ein Seed-Profil.
- [x] Override auf eine fehlende Datei: `review`, `task list` und `doctor` nennen den Pfad, keiner meldet „no tracker configured“. Belegt durch die Override-Tests in `test_review.py`, `test_task_cmd.py` und `test_doctor.py`.
- [x] `git status` bleibt nach einem Live-Lauf sauber.
- [x] Ohne Tracker überspringt pytest die Live-Suite mit Grund; mit Tracker läuft sie (Läufe 441, 442 und 448). Die Profil-Art ist über Tests gegen Fakes belegt (`load_profile`, `~`-Ablehnung, Namensprüfung), aber in diesem Paket nicht gegen einen echten eigenen Tracker gelaufen.
- [x] Ohne Markerprojekt bricht die Suite vor dem ersten Schreibzugriff ab. Ist Port 3876 belegt, startet SP nicht. Beides belegt durch Tests gegen Fakes.
- [x] Nach einem grünen Lauf ist kein Item des Laufs mehr offen, und nichts wurde gelöscht (Assertion im Szenario).
- [x] Das Push-CI führt die CalDAV-Live-Suite aus. In Lauf 441 steht sie als gelaufen: `[tracker-live] CalDAV … radicale 3.8.1`, 1 bestanden. Vorher waren 435, 438 und 439 rot; die Ursachen waren kein curl im Job-Image und `GITHUB_ENV` im selben Schritt. Behoben in `a126734` und `5a4c518`.
- [x] `chemenu-sp-live:19.1.0` und `:latest` liegen in der Registry (Lauf 440), die Version entspricht `latest-linux.yml`, die sha512-Prüfung der `.deb` ist bestanden, und das Paket ist `torben/chemenu` zugeordnet (Betreiber, 2026-09-30). Der erste Build-Versuch (437) scheiterte an fehlendem `unzip` für die 1Password-Action; behoben in `6554791`.
- [x] `sp-live-image`:
- baut bei unverändertem Kanal nicht neu (Lauf 443 per Dispatch, Lauf 490 nach Zeitplan am 2026-10-02: `build=false`, „Build and push“ übersprungen)
- baut, wenn die Version fehlt (Lauf 440)
- baut mit `sp_version=19.0.1` nur `:19.0.1` und lässt `:latest` stehen (Lauf 444)
- baut monatlich zwingend: Lauf 471 nach Zeitplan am 2026-10-01, `build=true (monthly rebuild)`, Tag `:19.1.0`
- [x] `tracker-live` zieht ohne Anmeldung, nennt die SP-Version, ohne apt im Lauf, und ist per Dispatch grün (Läufe 442 und 448) **und nach Zeitplan grün**: Lauf 472 (2026-10-01) und Lauf 491 (2026-10-02), jeweils `forcePull=true` ohne Anmeldung, `installed: 19.1.0, update channel: 19.1.0`, SP 19.1.0 und Radicale 3.8.1, `2 passed, 2 skipped` (übersprungen sind die nicht konfigurierten Arten; die beiden mit `CHEMENU_LIVE_REQUIRE` verlangten liefen). ~~Gegen SP mit `snapshot`~~: entfällt, siehe Abweichungen.
- [x] Die SP-Fixtures sind committet, tragen SP-Version und Datum (`MANIFEST.json`) und werden bei jedem Push ohne App geprüft.
- [x] Die drei Projektseiten aus E1 existieren, und `lint` ist sauber. `review` mit dem Seed-Profil trifft die Richtung kb→Tracker: Die aktive Seite findet ihr Projekt mit 8 offenen Items, `waiting_overdue` meldet die Prüfpunkte, und die abgeschlossene und die ruhende Seite bleiben still. Die Richtung Tracker→kb (`unpaged_project`) feuert mit dem Seed nicht, weil das Markerprojekt jünger als drei Wochen ist; `test_review.py` deckt sie ab.
- [x] `tracker-testing.md` beschreibt beide Provider bis zum grünen Lauf, die Regel für den Dispatch durch den Agenten, den Umgang mit einer roten Nacht, die Paketzuordnung und den Neuaufbau des Seeds. `dist export` liefert weder die Datei noch das Dockerfile noch die Workflows aus. Die SP-Hilfen gehen mit und sind inert, siehe Abweichungen.
- [x] `testing-conventions.md` nennt die Live-Suite als die eine ausdrückliche Ausnahme.
## Version
minor 8.0.0-beta.3 und patch 8.0.0-beta.4 im 8.0.0-Kandidaten (#140 D19). Die CI-Korrekturen unter `.gitea/` brauchen keinen Bump. Das Schließen selbst hat keine Datei berührt.
Changelog: Body zur Umsetzung vorbereitet (2026-09-30).
Neu:
Entwurf je Punkt, mit Dateien und Invariante: Override-Pfad, /.wikitool-tasks.d/, Marker live_tracker, Szenario im tmp_path-Korpus, Sicherheitsinvariante mit Markerprojekt und Titelpräfix.
Abschnitt „Recherche Super Productivity“.
Offene Entscheidungen E1–E4.
Kriterien für einen fehlenden Override-Pfad, die Sicherheitsinvariante und testing-conventions.md.
Korrigiert:
D21s Annahme „SP läuft nicht headless“ ist widerlegt; daraus folgt E3.
Frei erfundene Demo-Projekte in kb/ stehen im Konflikt mit Invariante 3 und corpus-policy.md; daraus folgt E1.
Der Stand zeigt jetzt auf 8be5e6e.
Befund ausgelagert:#162, der Umschlag {ok, data} im SP-API-Pfad.
Wegen der offenen Entscheidungen E1–E4: kind/build → kind/decision.
**Changelog:** Body zur Umsetzung vorbereitet (2026-09-30).
- **Neu:**
- Entwurf je Punkt, mit Dateien und Invariante: Override-Pfad, `/.wikitool-tasks.d/`, Marker `live_tracker`, Szenario im `tmp_path`-Korpus, Sicherheitsinvariante mit Markerprojekt und Titelpräfix.
- Abschnitt „Recherche Super Productivity“.
- Offene Entscheidungen E1–E4.
- Kriterien für einen fehlenden Override-Pfad, die Sicherheitsinvariante und `testing-conventions.md`.
- **Korrigiert:**
- D21s Annahme „SP läuft nicht headless“ ist widerlegt; daraus folgt E3.
- Frei erfundene Demo-Projekte in `kb/` stehen im Konflikt mit Invariante 3 und `corpus-policy.md`; daraus folgt E1.
- Der Stand zeigt jetzt auf `8be5e6e`.
- **Befund ausgelagert:** #162, der Umschlag `{ok, data}` im SP-API-Pfad.
Wegen der offenen Entscheidungen E1–E4: `kind/build` → `kind/decision`.
E1: Demo-Projekte aus dem Issue-Tracker, ausgehend von #140. Namensvorschlag in der Tabelle.
E2: Radicale als Prozess im Job.
E4: Fixtures aus einem echten Lauf aufnehmen.
E3 neu gefasst: SP als fertiges .deb statt Eigenbau. Headless-Start, Seed über Backup-Restore mit CDP-Bestätigung sowie den Fallstrick libasound2t64 habe ich live in debian:trixie-slim gegen v19.1.0 geprüft. Offen ist nur noch der Takt (nightly oder push).
Der manuelle Desktop-Lauf für E4 entfällt.
#162 ist live bestätigt und soll vorher gebaut werden.
Kriterien ergänzt: Portwache auf 3876, SP-Live mit beiden Zugriffsarten, Projektseiten.
**Changelog:**
- **Entschieden (Betreiber, 2026-09-30):**
- E1: Demo-Projekte aus dem Issue-Tracker, ausgehend von #140. Namensvorschlag in der Tabelle.
- E2: Radicale als Prozess im Job.
- E4: Fixtures aus einem echten Lauf aufnehmen.
- **E3 neu gefasst:** SP als fertiges `.deb` statt Eigenbau. Headless-Start, Seed über Backup-Restore mit CDP-Bestätigung sowie den Fallstrick `libasound2t64` habe ich live in `debian:trixie-slim` gegen v19.1.0 geprüft. Offen ist nur noch der Takt (nightly oder push).
- Der manuelle Desktop-Lauf für E4 entfällt.
- #162 ist live bestätigt und soll vorher gebaut werden.
- Kriterien ergänzt: Portwache auf 3876, SP-Live mit beiden Zugriffsarten, Projektseiten.
Vorgebautes Test-Image chemenu-sp-live:<sp-version> in der Gitea-Registry, nach dem Muster von gitea-mcp (container-builder, Remote-BuildKit, 1Password mit globalem OP_SERVICE_ACCOUNT_TOKEN).
Das Image wird monatlich per Cron und per Dispatch neu gebaut.
Der neue Workflow tracker-live läuft nächtlich und per Dispatch durch den Agenten, sobald das SP-Umfeld berührt ist.
Neu ist der Punkt „Sichtbarkeit und Zuordnung“: Anonymer Pull, weil der Bereich öffentlich ist. Nach dem ersten Push ordnet der Betreiber das Paket einmalig torben/chemenu zu.
Alle Entscheidungen sind getroffen, deshalb kind/decision → kind/build.
**Changelog:**
- E1 ist mit den drei Namen bestätigt.
- E3 ist entschieden:
- Vorgebautes Test-Image `chemenu-sp-live:<sp-version>` in der Gitea-Registry, nach dem Muster von `gitea-mcp` (`container-builder`, Remote-BuildKit, 1Password mit globalem `OP_SERVICE_ACCOUNT_TOKEN`).
- Das Image wird monatlich per Cron und per Dispatch neu gebaut.
- Der neue Workflow `tracker-live` läuft nächtlich und per Dispatch durch den Agenten, sobald das SP-Umfeld berührt ist.
- Neu ist der Punkt „Sichtbarkeit und Zuordnung“: Anonymer Pull, weil der Bereich öffentlich ist. Nach dem ersten Push ordnet der Betreiber das Paket einmalig `torben/chemenu` zu.
Alle Entscheidungen sind getroffen, deshalb `kind/decision` → `kind/build`.
Changelog: E3 folgt jetzt dem Update-Kanal statt eines Pins (Betreiber, 2026-09-30). Die Desktop-Clients aktualisieren sich selbst, und SP veröffentlicht etwa wöchentlich; ein Pin würde gegen eine veraltete Version testen.
sp-live-image liest täglich latest-linux.yml und baut nur bei einer neuen Version, geprüft per sha512 und getaggt als :<version> und :latest. Monatlich baut er zwingend neu für die Debian-Updates. Dispatch mit sp_version baut ältere Versionen nach.
tracker-live testet nächtlich gegen :latest und nennt die Version im Log.
Ein Rot nach einem neuen Release führt zu einem kind/defect-Issue, nicht zu einem Rück-Pin.
Die Fixtures aus E4 halten den Stand ihrer Aufnahme fest; tracker-live liefert neuere als Artefakt.
Per Versuch zu klären: ob act_runner:latest bei jedem Lauf neu zieht.
**Changelog:** E3 folgt jetzt dem Update-Kanal statt eines Pins (Betreiber, 2026-09-30). Die Desktop-Clients aktualisieren sich selbst, und SP veröffentlicht etwa wöchentlich; ein Pin würde gegen eine veraltete Version testen.
- `sp-live-image` liest täglich `latest-linux.yml` und baut nur bei einer neuen Version, geprüft per sha512 und getaggt als `:<version>` und `:latest`. Monatlich baut er zwingend neu für die Debian-Updates. Dispatch mit `sp_version` baut ältere Versionen nach.
- `tracker-live` testet nächtlich gegen `:latest` und nennt die Version im Log.
- Ein Rot nach einem neuen Release führt zu einem `kind/defect`-Issue, nicht zu einem Rück-Pin.
- Die Fixtures aus E4 halten den Stand ihrer Aufnahme fest; `tracker-live` liefert neuere als Artefakt.
- Per Versuch zu klären: ob `act_runner` `:latest` bei jedem Lauf neu zieht.
Changelog: Der Body steht auf dem Stand nach dem Bau (b0c6477, 8.0.0-beta.3), das Issue bleibt offen.
Neu:
Die Abschnitte „Was gebaut ist“ und „Abweichungen vom Entwurf“.
Kriterien mit Beleg aus den Läufen 440–444, darunter der erste grüne tracker-live (442) gegen SP 19.1.0 und Radicale 3.8.1.
Der Versuch zu act_runner ist geklärt: forcePull=true, anonym.
Behoben nach dem ersten echten CI-Lauf:
a126734: kein curl im Job-Image
6554791: unzip für die 1Password-Action
5a4c518: GITHUB_ENV wirkt erst im Folgeschritt
Offen:
E1 weicht vom Entschiedenen ab (Betreiberentscheidung)
die Paketzuordnung
die ersten Läufe nach Zeitplan am 2026-10-01
**Changelog:** Der Body steht auf dem Stand nach dem Bau (`b0c6477`, 8.0.0-beta.3), das Issue bleibt offen.
- **Neu:**
- Die Abschnitte „Was gebaut ist“ und „Abweichungen vom Entwurf“.
- Kriterien mit Beleg aus den Läufen 440–444, darunter der erste grüne `tracker-live` (442) gegen SP 19.1.0 und Radicale 3.8.1.
- Der Versuch zu `act_runner` ist geklärt: `forcePull=true`, anonym.
- **Behoben nach dem ersten echten CI-Lauf:**
- `a126734`: kein curl im Job-Image
- `6554791`: `unzip` für die 1Password-Action
- `5a4c518`: `GITHUB_ENV` wirkt erst im Folgeschritt
- **Offen:**
- E1 weicht vom Entschiedenen ab (Betreiberentscheidung)
- die Paketzuordnung
- die ersten Läufe nach Zeitplan am 2026-10-01
Changelog: Der Demo-Korpus folgt jetzt E1 (Variante A, Betreiber 2026-09-30), und das Paket ist zugeordnet.
Neu (40413f9, 8.0.0-beta.4):
Die drei entschiedenen Seiten ersetzen die zwei falsch benannten.
Neuer Seed mit den Items aus #140; die Fixtures sind neu aufgenommen.
test_sp_recorded.py prüft die Demo-Projekte.
Grün: CI 446 und 447, tracker-live 448.
Abgehakt: Paketzuordnung und E1.
Offen: nur noch die ersten Läufe nach Zeitplan am 2026-10-01.
**Changelog:** Der Demo-Korpus folgt jetzt E1 (Variante A, Betreiber 2026-09-30), und das Paket ist zugeordnet.
- **Neu (`40413f9`, 8.0.0-beta.4):**
- Die drei entschiedenen Seiten ersetzen die zwei falsch benannten.
- Neuer Seed mit den Items aus #140; die Fixtures sind neu aufgenommen.
- `test_sp_recorded.py` prüft die Demo-Projekte.
- **Grün:** CI 446 und 447, `tracker-live` 448.
- **Abgehakt:** Paketzuordnung und E1.
- **Offen:** nur noch die ersten Läufe nach Zeitplan am 2026-10-01.
Changelog (2026-10-02): Das letzte Kriterium ist erfüllt. Die Läufe nach Zeitplan sind grün: sp-live-image 471 (monatlicher Neubau) und 490 (kein Neubau), tracker-live 472 und 491 (SP 19.1.0, Radicale 3.8.1, je 2 bestanden). Die Belege stehen jetzt im Kriterium, der Abschnitt „Offen“ ist entfernt. Geschlossen.
**Changelog (2026-10-02):** Das letzte Kriterium ist erfüllt. Die Läufe nach Zeitplan sind grün: `sp-live-image` 471 (monatlicher Neubau) und 490 (kein Neubau), `tracker-live` 472 und 491 (SP 19.1.0, Radicale 3.8.1, je 2 bestanden). Die Belege stehen jetzt im Kriterium, der Abschnitt „Offen“ ist entfernt. Geschlossen.
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.
Teilpaket von #140. Entschieden: D20 und D21 (Betreiber, 2026-09-28), E1–E4 (Betreiber, 2026-09-30).
Erledigt (geschlossen 2026-10-02). Gebaut und veröffentlicht am 2026-09-30, alle Läufe grün. Die Workflows laufen nachweislich auch nach Zeitplan:
sp-live-imageam 2026-10-01 mit dem monatlichen Neubau (Lauf 471) und am 2026-10-02 ohne Neubau (Lauf 490),tracker-livenächtlich am 2026-10-01 und 2026-10-02 (Läufe 472 und 491).b0c6477: die Umsetzunga126734,6554791,5a4c518: drei CI-Korrekturen nach dem ersten echten Laufdea98d4: Kommentar zum Pull-Verhalten40413f9: Demo-Korpus nach E1529793b, geschlossen)Was gebaut ist
Konfigurations-Override
WIKITOOL_TASKS_CONFIG.config.tasks_config_path()liest die Variable. Sie wird relativ zum Arbeitsverzeichnis aufgelöst,~wird expandiert. Sonst gilt<root>/.wikitool-tasks.json.ValidationError, der den Pfad nennt, und niemals „kein Tracker“.task,reviewunddoctornennen die tatsächlich gelesene Datei.doctormeldet einen aktiven Override.conftest.py(_WIKITOOL_ENV),testing-conventions.md,tools/CONTRACT.mdundINSTALL.md§ Konfiguration.Live-Suite
live_tracker(tests/test_tracker_live.py,tests/tracker_live.py).task newlegt ein normales und ein WAITING-Item mit überfälligem Follow-up an.task listfindet beide.reviewmeldetwaiting_overduefür genau dieses Item.task closeschließt beide.Chemenu Live-Test.[live-test <run-id>].~werden abgelehnt.Headless SP (
tests/sp_headless.py): gepackte App, Seed-Backup, Bestätigung des Restore-Dialogs über CDP (in Python), Log-Auszug in jeder Abbruchmeldung.Aufgenommene Fixtures (
tests/fixtures/sp/): echte Antworten von v19.1.0 und ein Backup, das die App selbst geschrieben hat, mitMANIFEST.json(Version, Datum, die eine nachträgliche Änderung).test_sp_recorded.pyspielt sie bei jedem Push ab, einschließlich der Demo-Projekte;record_sp_fixtures.pynimmt sie neu auf.CI und Image.
ci.ymlstartet Radicale in einem eigenen Schritt und führt danach die CalDAV-Live-Suite mitCHEMENU_LIVE_REQUIRE=caldavaus.sp-live-image.ymlbautgitea.nehmer.net/torben/chemenu-sp-live:sp_version, ohne:latestumzusetzentracker-live.ymlläuft nächtlich und per Dispatch im Image, mitCHEMENU_LIVE_REQUIRE=sp,caldav.Prozedur:
instructions/dev/tracker-testing.md(instack-devSchritt 2 eingetragen),DEVELOPMENT.md,doc-pull-through.md. Dazu/.wikitool-tasks.d/in.gitignore, mit Canary indocs verify.Demo-Korpus nach E1: drei Seiten unter
kb/gtd/technik/,provenance: general, mit Issue-Links:Chemenu 8.0.0 - Installation und Windows(active, aus #140)Aufgabenverwaltung mit Tracker-Anbindung(completed, aus #119/#124)Reproduktionslauf des Korpus(dormant, aus #69)Der Seed trägt die gleichnamigen Projekte:
Das Follow-up liegt so weit zurück, weil
waiting_overdueerst nachstalled_waiting_days(14) greift. Der Seed ist ein fester Teststand und folgt dem Fortschritt von #140 bewusst nicht.Abweichungen vom Entwurf, beim Bau entschieden
/.wikitool-tasks.d/*.jsonzu iterieren.CHEMENU_LIVE_SP_BINARY: Die Suite startet ihr eigenes SP.CHEMENU_LIVE_CALDAV_*: Radicale in der CI.CHEMENU_LIVE_PROFILE=<name>: ein eigener Tracker aus/.wikitool-tasks.d/<name>.json.pytestbeschrieben werden, sondern nur auf ausdrücklichen Wunsch.CHEMENU_LIVE_REQUIREmacht in der CI aus „nicht konfiguriert“ ein Rot statt eines Skips.test_the_snapshot_reader_reads_a_backup_the_app_wrotebei jedem Push gegen ein Backup, das die App selbst geschrieben hat.tracker-liveohnesp_version-Eingabe und ohne Fixture-Artefakt.tracker-testing.md§ Refreshing the fixtures von Hand nachgezogen.sp-live-imagemitsp_versionunddocker runauf:<version>.tools/chemenu/tests/und werden mit der Testsuite ausgeliefert. Das ist die Option „nachweislich harmlos“ aus dem Entwurf:dist exportlaufentest_tracker_live.pyundtest_sp_recorded.pymit 17 bestanden und 3 übersprungen (die Live-Tests)..gitea/undinstructions/dev/fehlen im Export.instructions/dev/tracker-testing.md, und diese Datei fehlt in einer Instanz.taskIdsnachbacklogTaskIdsverschoben;MANIFEST.jsonnennt das.act_runnerund:latestgeklärt: Der Runner zieht mitforcePull=trueund ohne Anmeldung (Lauf 442, bestätigt in den Läufen 472 und 491 nach Zeitplan). Die Ausweichlösung mit einem Mini-Job entfällt.Akzeptanzkriterien
WIKITOOL_TASKS_CONFIG, ohne Dateitausch. Belegt durchtracker-live(Läufe 442 und 448: SP und CalDAV in einem pytest-Lauf, Override je Test) und durchreviewvon Hand gegen ein Seed-Profil.review,task listunddoctornennen den Pfad, keiner meldet „no tracker configured“. Belegt durch die Override-Tests intest_review.py,test_task_cmd.pyundtest_doctor.py.git statusbleibt nach einem Live-Lauf sauber.load_profile,~-Ablehnung, Namensprüfung), aber in diesem Paket nicht gegen einen echten eigenen Tracker gelaufen.[tracker-live] CalDAV … radicale 3.8.1, 1 bestanden. Vorher waren 435, 438 und 439 rot; die Ursachen waren kein curl im Job-Image undGITHUB_ENVim selben Schritt. Behoben ina126734und5a4c518.chemenu-sp-live:19.1.0und:latestliegen in der Registry (Lauf 440), die Version entsprichtlatest-linux.yml, die sha512-Prüfung der.debist bestanden, und das Paket isttorben/chemenuzugeordnet (Betreiber, 2026-09-30). Der erste Build-Versuch (437) scheiterte an fehlendemunzipfür die 1Password-Action; behoben in6554791.sp-live-image:build=false, „Build and push“ übersprungen)sp_version=19.0.1nur:19.0.1und lässt:lateststehen (Lauf 444)build=true (monthly rebuild), Tag:19.1.0tracker-livezieht ohne Anmeldung, nennt die SP-Version, ohne apt im Lauf, und ist per Dispatch grün (Läufe 442 und 448) und nach Zeitplan grün: Lauf 472 (2026-10-01) und Lauf 491 (2026-10-02), jeweilsforcePull=trueohne Anmeldung,installed: 19.1.0, update channel: 19.1.0, SP 19.1.0 und Radicale 3.8.1,2 passed, 2 skipped(übersprungen sind die nicht konfigurierten Arten; die beiden mitCHEMENU_LIVE_REQUIREverlangten liefen).Gegen SP mit: entfällt, siehe Abweichungen.snapshotMANIFEST.json) und werden bei jedem Push ohne App geprüft.lintist sauber.reviewmit dem Seed-Profil trifft die Richtung kb→Tracker: Die aktive Seite findet ihr Projekt mit 8 offenen Items,waiting_overduemeldet die Prüfpunkte, und die abgeschlossene und die ruhende Seite bleiben still. Die Richtung Tracker→kb (unpaged_project) feuert mit dem Seed nicht, weil das Markerprojekt jünger als drei Wochen ist;test_review.pydeckt sie ab.tracker-testing.mdbeschreibt beide Provider bis zum grünen Lauf, die Regel für den Dispatch durch den Agenten, den Umgang mit einer roten Nacht, die Paketzuordnung und den Neuaufbau des Seeds.dist exportliefert weder die Datei noch das Dockerfile noch die Workflows aus. Die SP-Hilfen gehen mit und sind inert, siehe Abweichungen.testing-conventions.mdnennt die Live-Suite als die eine ausdrückliche Ausnahme.Version
minor 8.0.0-beta.3 und patch 8.0.0-beta.4 im 8.0.0-Kandidaten (#140 D19). Die CI-Korrekturen unter
.gitea/brauchen keinen Bump. Das Schließen selbst hat keine Datei berührt.Changelog: D20 und D21 sind wie empfohlen entschieden (Betreiber, 2026-09-28). Darum
kind/decision→kind/build.Changelog: Body zur Umsetzung vorbereitet (2026-09-30).
/.wikitool-tasks.d/, Markerlive_tracker, Szenario imtmp_path-Korpus, Sicherheitsinvariante mit Markerprojekt und Titelpräfix.testing-conventions.md.kb/stehen im Konflikt mit Invariante 3 undcorpus-policy.md; daraus folgt E1.8be5e6e.{ok, data}im SP-API-Pfad.Wegen der offenen Entscheidungen E1–E4:
kind/build→kind/decision.Changelog:
.debstatt Eigenbau. Headless-Start, Seed über Backup-Restore mit CDP-Bestätigung sowie den Fallstricklibasound2t64habe ich live indebian:trixie-slimgegen v19.1.0 geprüft. Offen ist nur noch der Takt (nightly oder push).Changelog:
chemenu-sp-live:<sp-version>in der Gitea-Registry, nach dem Muster vongitea-mcp(container-builder, Remote-BuildKit, 1Password mit globalemOP_SERVICE_ACCOUNT_TOKEN).tracker-liveläuft nächtlich und per Dispatch durch den Agenten, sobald das SP-Umfeld berührt ist.torben/chemenuzu.Alle Entscheidungen sind getroffen, deshalb
kind/decision→kind/build.Changelog: E3 folgt jetzt dem Update-Kanal statt eines Pins (Betreiber, 2026-09-30). Die Desktop-Clients aktualisieren sich selbst, und SP veröffentlicht etwa wöchentlich; ein Pin würde gegen eine veraltete Version testen.
sp-live-imageliest täglichlatest-linux.ymlund baut nur bei einer neuen Version, geprüft per sha512 und getaggt als:<version>und:latest. Monatlich baut er zwingend neu für die Debian-Updates. Dispatch mitsp_versionbaut ältere Versionen nach.tracker-livetestet nächtlich gegen:latestund nennt die Version im Log.kind/defect-Issue, nicht zu einem Rück-Pin.tracker-liveliefert neuere als Artefakt.act_runner:latestbei jedem Lauf neu zieht.Changelog: Der Body steht auf dem Stand nach dem Bau (
b0c6477, 8.0.0-beta.3), das Issue bleibt offen.tracker-live(442) gegen SP 19.1.0 und Radicale 3.8.1.act_runnerist geklärt:forcePull=true, anonym.a126734: kein curl im Job-Image6554791:unzipfür die 1Password-Action5a4c518:GITHUB_ENVwirkt erst im FolgeschrittChangelog: Der Demo-Korpus folgt jetzt E1 (Variante A, Betreiber 2026-09-30), und das Paket ist zugeordnet.
40413f9, 8.0.0-beta.4):test_sp_recorded.pyprüft die Demo-Projekte.tracker-live448.Changelog (2026-10-02): Das letzte Kriterium ist erfüllt. Die Läufe nach Zeitplan sind grün:
sp-live-image471 (monatlicher Neubau) und 490 (kein Neubau),tracker-live472 und 491 (SP 19.1.0, Radicale 3.8.1, je 2 bestanden). Die Belege stehen jetzt im Kriterium, der Abschnitt „Offen“ ist entfernt. Geschlossen.