Changelog
What changed — grouped by release, filterable by component and repository.
No milestone 18
Kanon-Werte im Brief mediathek-und-episodenkarte (verdict extend, surface fe-existing)
`foundation-slot` wird kanonischer awaiting-Wert — die Etiketten-Sackgasse schliesst
DER BEFUND: fuer "wartet auf einen freien Fundament-Platz" gab es KEINEN tragfaehigen Wert,
und beide Auswege endeten im Ausschluss.
- `foundation-slot` lag ausserhalb von AWAITING_ENUM -> jede Automatik uebersprang ihn
fail-closed, ohne Fehler und ohne Spur.
- `deferred` liegt im Enum, fehlt aber in BATCH_READY_AWAITING -> Kaskaden-Kollektor UND
Grant-Waehler sind blind dafuer.
Gemessen 2026-08-22: 54 blockierte Briefe warten auf den Platz, verteilt auf VIER Etiketten
(32 dependency, 9 none, 9 deferred, 1 trigger). Ein Brief dokumentiert den vergeblichen
Wechsel woertlich: "war `foundation-slot` - ein Wert AUSSERHALB von AWAITING_ENUM ... `deferred`
ist der etablierte Wert" (knowledgebase-eigene-ki-aktionen-je-sammlung, /resync 2026-08-18).
Jemand tauschte unsichtbar gegen unsichtbar.
DIE SEMANTIK KANNTE DEN WERT LAENGST: `awaitingKind()` gibt fuer ihn seit jeher die Klasse
'foundation-slot' zurueck (trigger-conditions.mjs:200) - nur das SYNTAX-Tor liess ihn nicht zu.
Diese Aenderung schliesst genau diese Luecke, sie erfindet nichts Neues.
GEAENDERT (drei Listen, bewusst nicht vier):
- AWAITING_ENUM (Quelle der Wahrheit) + AWAITING_ENUM_MIRROR (Spiegel) -> Wert erlaubt
- BATCH_READY_AWAITING -> Kollektor und Grant-Waehler sehen ihn
- NICHT AWAITING_CLAIMABLE: der Brief bleibt gesperrt, er wartet ja wirklich
- 🔴 NICHT PROMOTE_RESOLVES_AWAITING: erst so gebaut, dann ZURUECKGENOMMEN. Der Drift-Waechter
(coord-promote-unresolved-gate 5b) verbietet jede Erweiterung ausdruecklich, weil damit das
Loch wieder aufrisse, das die awaiting-Sperre geschlossen hat (purchase-approval, 3x geclaimt
/ 5 Rueckgaben). Folge, im Protokoll dokumentiert: der Promote WARNT laut, dass der Wert
stehen bleibt - wer den Platz gewaehrt, setzt `awaiting: none` mit.
WAECHTER-TESTS NACHGEZOGEN — und das war der heikle Teil: DREI Testreihen fuehrten
`foundation-slot` als BEISPIEL fuer einen erfundenen Wert. Sie zielten auf die AD-HOC-ERFINDUNG,
nicht auf das Konzept; sie sind auf `pl-grant` umgestellt (der 2026-08-19-Neufund, weiterhin
ungueltig) und um Positiv-Proben ergaenzt, die die Aufnahme festnageln.
Verify: awaiting-canon-guard 17/17 · promote-unresolved-gate + awaiting-guard 25/25 ·
volle Reihe 4804/4810. Die 6 verbleibenden Fehlschlaege sind VORBESTEHEND — gegen den
gestashten sauberen Baum gemessen, dort dieselben 6 (394/930/931/1234/1245/4200).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
und beide Auswege endeten im Ausschluss.
- `foundation-slot` lag ausserhalb von AWAITING_ENUM -> jede Automatik uebersprang ihn
fail-closed, ohne Fehler und ohne Spur.
- `deferred` liegt im Enum, fehlt aber in BATCH_READY_AWAITING -> Kaskaden-Kollektor UND
Grant-Waehler sind blind dafuer.
Gemessen 2026-08-22: 54 blockierte Briefe warten auf den Platz, verteilt auf VIER Etiketten
(32 dependency, 9 none, 9 deferred, 1 trigger). Ein Brief dokumentiert den vergeblichen
Wechsel woertlich: "war `foundation-slot` - ein Wert AUSSERHALB von AWAITING_ENUM ... `deferred`
ist der etablierte Wert" (knowledgebase-eigene-ki-aktionen-je-sammlung, /resync 2026-08-18).
Jemand tauschte unsichtbar gegen unsichtbar.
DIE SEMANTIK KANNTE DEN WERT LAENGST: `awaitingKind()` gibt fuer ihn seit jeher die Klasse
'foundation-slot' zurueck (trigger-conditions.mjs:200) - nur das SYNTAX-Tor liess ihn nicht zu.
Diese Aenderung schliesst genau diese Luecke, sie erfindet nichts Neues.
GEAENDERT (drei Listen, bewusst nicht vier):
- AWAITING_ENUM (Quelle der Wahrheit) + AWAITING_ENUM_MIRROR (Spiegel) -> Wert erlaubt
- BATCH_READY_AWAITING -> Kollektor und Grant-Waehler sehen ihn
- NICHT AWAITING_CLAIMABLE: der Brief bleibt gesperrt, er wartet ja wirklich
- 🔴 NICHT PROMOTE_RESOLVES_AWAITING: erst so gebaut, dann ZURUECKGENOMMEN. Der Drift-Waechter
(coord-promote-unresolved-gate 5b) verbietet jede Erweiterung ausdruecklich, weil damit das
Loch wieder aufrisse, das die awaiting-Sperre geschlossen hat (purchase-approval, 3x geclaimt
/ 5 Rueckgaben). Folge, im Protokoll dokumentiert: der Promote WARNT laut, dass der Wert
stehen bleibt - wer den Platz gewaehrt, setzt `awaiting: none` mit.
WAECHTER-TESTS NACHGEZOGEN — und das war der heikle Teil: DREI Testreihen fuehrten
`foundation-slot` als BEISPIEL fuer einen erfundenen Wert. Sie zielten auf die AD-HOC-ERFINDUNG,
nicht auf das Konzept; sie sind auf `pl-grant` umgestellt (der 2026-08-19-Neufund, weiterhin
ungueltig) und um Positiv-Proben ergaenzt, die die Aufnahme festnageln.
Verify: awaiting-canon-guard 17/17 · promote-unresolved-gate + awaiting-guard 25/25 ·
volle Reihe 4804/4810. Die 6 verbleibenden Fehlschlaege sind VORBESTEHEND — gegen den
gestashten sauberen Baum gemessen, dort dieselben 6 (394/930/931/1234/1245/4200).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rang2 — CEO-Entscheid JobOffers=Beobachtung eingearbeitet, Brief entsperrt
CEO 2026-08-23: `JobOffers` IST Markt-BEOBACHTUNG (Job-Scraper-Zufluss), NICHT der Traeger
eigener Stellenangebote. Damit ist die einzige offene Produkt-Frage dieses Briefes
beantwortet und der `joboffers`-Teil faellt ENDGUELTIG aus dem Umfang — die fuenf Aktionen
(send/accept/reject/counter-offer/expire) brauchen einen EIGENEN Traeger, das ist ein
Folge-Brief (neue Entitaet ⇒ Fundament), nicht dieser hier.
Der Entscheid deckt sich mit dem am 2026-08-04 gemessenen Bestand, den der Brief selbst
fuehrt: 22 leere Stubs, KEIN `_customerID`, und die Form (`source`/`sourceId`/`applyLink`/
`descriptionHTML`) beschreibt ein eingelesenes FREMDES Angebot.
Drei Folgeaenderungen, damit der Brief nicht auf toten Praemissen stehen bleibt:
- awaiting `ceo-decision` → `none` (nichts Menschliches mehr offen)
- trigger `BLOCKED-ON-CEO-DECISION` → READY samt Begruendung
- claim_paths interfaces+models (Altlast, Fundament seit Kaskade 28 geliefert) → die drei
echten Ziel-Repos, AUS DER REGISTRY ABGELEITET statt geraten: Vacations→hr.js,
SupplierAgreements→purchase.js, Documents→crm.js; Umkehrprobe mit erfundenem Plural 0.
Danach gemessen: der Brief meldet nur noch NOT-READY:paths gegen eine LAUFENDE Sitzung
(bewerbermanagement-w4 haelt domains/hr/api) — ein echter, transienter Konflikt statt einer
toten Praemisse. Er loest sich, wenn jene Sitzung endet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
eigener Stellenangebote. Damit ist die einzige offene Produkt-Frage dieses Briefes
beantwortet und der `joboffers`-Teil faellt ENDGUELTIG aus dem Umfang — die fuenf Aktionen
(send/accept/reject/counter-offer/expire) brauchen einen EIGENEN Traeger, das ist ein
Folge-Brief (neue Entitaet ⇒ Fundament), nicht dieser hier.
Der Entscheid deckt sich mit dem am 2026-08-04 gemessenen Bestand, den der Brief selbst
fuehrt: 22 leere Stubs, KEIN `_customerID`, und die Form (`source`/`sourceId`/`applyLink`/
`descriptionHTML`) beschreibt ein eingelesenes FREMDES Angebot.
Drei Folgeaenderungen, damit der Brief nicht auf toten Praemissen stehen bleibt:
- awaiting `ceo-decision` → `none` (nichts Menschliches mehr offen)
- trigger `BLOCKED-ON-CEO-DECISION` → READY samt Begruendung
- claim_paths interfaces+models (Altlast, Fundament seit Kaskade 28 geliefert) → die drei
echten Ziel-Repos, AUS DER REGISTRY ABGELEITET statt geraten: Vacations→hr.js,
SupplierAgreements→purchase.js, Documents→crm.js; Umkehrprobe mit erfundenem Plural 0.
Danach gemessen: der Brief meldet nur noch NOT-READY:paths gegen eine LAUFENDE Sitzung
(bewerbermanagement-w4 haelt domains/hr/api) — ein echter, transienter Konflikt statt einer
toten Praemisse. Er loest sich, wenn jene Sitzung endet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zwei Briefe hingen an einem Aufloeser, der ihre Abhaengigkeit per Bauart nie finden kann
BEFUND (systemisch, aber klein): der Pruefer loest `DEPENDS-ON <slug>` gegen SITZUNGS-
Kennungen in sessions/done/ auf. Wird ein Brief innerhalb einer FUNDAMENT-KASKADE geliefert,
wandert er nach queue/done/, ohne je eine eigene Sitzung getragen zu haben — gemessen 0
Sitzungen fuer beide Ziele, bei status:done. Ein stamm-basierter Aufloeser findet das nie,
und der abhaengige Brief meldet fuer immer `trigger:waiting`.
GROESSE der Klasse gemessen (nicht geschaetzt): 36 blockierte Briefe tragen ein DEPENDS-ON,
6 davon haben ein Ziel in queue/done/, und genau 2 davon haben keine Sitzung. Diese zwei.
Beide Abhaengigkeiten stattdessen EMPIRISCH am installierten Fundament belegt
(@tolinax/ayoune-interfaces 2026.451.0), je mit Positiv- und Umkehrprobe:
- presse-portale: `PressReleases` in data/modelsAndRights/marketing.js (1 Treffer;
Positiv-Kontrolle `Partners` 2; Umkehrprobe erfundener Name 0). Geliefert von Kaskade 64.
- white-label: IDomain.d.ts fuehrt `serviceType` (Z.66) UND `rootTarget` (Z.94)
(Positiv-Kontrolle 51 Feldzeilen; Umkehrprobe 0). Der Auslöser fragte ohnehin nach
PUBLIKATION, nicht nach Brief-Status — also so gemessen.
⚠ Beim Schreiben in die dokumentierte Zitat-Falle gelaufen und wieder heraus: das woertliche
Zitat des alten Auslösers wurde vom Pruefer als AKTIVER Auslöser gelesen, der Brief blieb
`waiting`. Genau das haelt `backup-pending-haenger-und-erster-lauf-beleg` in seinem eigenen
trigger fest. Marker-Schreibweise deshalb vermieden; danach beide READY.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kennungen in sessions/done/ auf. Wird ein Brief innerhalb einer FUNDAMENT-KASKADE geliefert,
wandert er nach queue/done/, ohne je eine eigene Sitzung getragen zu haben — gemessen 0
Sitzungen fuer beide Ziele, bei status:done. Ein stamm-basierter Aufloeser findet das nie,
und der abhaengige Brief meldet fuer immer `trigger:waiting`.
GROESSE der Klasse gemessen (nicht geschaetzt): 36 blockierte Briefe tragen ein DEPENDS-ON,
6 davon haben ein Ziel in queue/done/, und genau 2 davon haben keine Sitzung. Diese zwei.
Beide Abhaengigkeiten stattdessen EMPIRISCH am installierten Fundament belegt
(@tolinax/ayoune-interfaces 2026.451.0), je mit Positiv- und Umkehrprobe:
- presse-portale: `PressReleases` in data/modelsAndRights/marketing.js (1 Treffer;
Positiv-Kontrolle `Partners` 2; Umkehrprobe erfundener Name 0). Geliefert von Kaskade 64.
- white-label: IDomain.d.ts fuehrt `serviceType` (Z.66) UND `rootTarget` (Z.94)
(Positiv-Kontrolle 51 Feldzeilen; Umkehrprobe 0). Der Auslöser fragte ohnehin nach
PUBLIKATION, nicht nach Brief-Status — also so gemessen.
⚠ Beim Schreiben in die dokumentierte Zitat-Falle gelaufen und wieder heraus: das woertliche
Zitat des alten Auslösers wurde vom Pruefer als AKTIVER Auslöser gelesen, der Brief blieb
`waiting`. Genau das haelt `backup-pending-haenger-und-erster-lauf-beleg` in seinem eigenen
trigger fest. Marker-Schreibweise deshalb vermieden; danach beide READY.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zwei weitere Fundament-Praemissen richtiggestellt
paymenttransactions-consumerid — Auslöser UEBERHOLT, und der Brief widerlegt ihn selbst.
Er verlangte "einen FUNDAMENT-PLATZ (Einzelschreiber auf interfaces + models)", waehrend
sein eigener STOPP-Block auf Zeile 53 vier positive Quelltext-Belege fuehrt, dass die
Fundament-Haelfte seit Kaskade 28 geliefert ist (IPaymentTransaction._consumerID:48 ·
IConsumer.recipients:848 · PaymentTransactions.ts:29 + Index :37 · Consumers.ts:996).
Offen sind nur die zwei Verbraucher-Teile: die Schreib-Seite von `_consumerID` und der
Reiter "Empfaenger", der weiterhin `Notifications` zeigt. Beides ohne Fundament-Platz.
claim_paths BEWUSST nicht ersetzt — der Rumpf benennt fuer die zwei offenen Haelften keine
eindeutigen Ziel-Repos; ein Ersatz waere geraten. Als erster Schritt im Lauf zu setzen.
oauth-app-kontingente-bau — Schwelle NACHGEMESSEN statt geglaubt (rein lesend, Prod):
`oauthclients` = 1, `oauthtokens` = 0. Der Auslöser verlangt BEIDE > 0, er ist NICHT
erfuellt — der Brief liegt zu Recht. Gegenueber der 08-03-Messung (0/0) hat sich die eine
Haelfte bewegt. Nebenbefund festgehalten, NICHT behoben: claim_paths fuehrt platform/core
bei `foundation: false`; der Widerspruch ist latent, solange die Schwelle sperrt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Er verlangte "einen FUNDAMENT-PLATZ (Einzelschreiber auf interfaces + models)", waehrend
sein eigener STOPP-Block auf Zeile 53 vier positive Quelltext-Belege fuehrt, dass die
Fundament-Haelfte seit Kaskade 28 geliefert ist (IPaymentTransaction._consumerID:48 ·
IConsumer.recipients:848 · PaymentTransactions.ts:29 + Index :37 · Consumers.ts:996).
Offen sind nur die zwei Verbraucher-Teile: die Schreib-Seite von `_consumerID` und der
Reiter "Empfaenger", der weiterhin `Notifications` zeigt. Beides ohne Fundament-Platz.
claim_paths BEWUSST nicht ersetzt — der Rumpf benennt fuer die zwei offenen Haelften keine
eindeutigen Ziel-Repos; ein Ersatz waere geraten. Als erster Schritt im Lauf zu setzen.
oauth-app-kontingente-bau — Schwelle NACHGEMESSEN statt geglaubt (rein lesend, Prod):
`oauthclients` = 1, `oauthtokens` = 0. Der Auslöser verlangt BEIDE > 0, er ist NICHT
erfuellt — der Brief liegt zu Recht. Gegenueber der 08-03-Messung (0/0) hat sich die eine
Haelfte bewegt. Nebenbefund festgehalten, NICHT behoben: claim_paths fuehrt platform/core
bei `foundation: false`; der Widerspruch ist latent, solange die Schwelle sperrt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zwei Briefe mit ueberholtem Fundament-Blocker richtiggestellt
callagent-drei-tote-felder — EINGEHAENGT. Sein Auslöser nannte
"foundation-batch-cascade-31" als Halter von platform/interfaces; der Bestand steht bei
68. Vor allem aber braucht der Brief gar keinen Platz: sein eigener Defer-Grund sagt
"Nach dem ABBILDEN-Entscheid gibt es KEINEN interfaces/models-Anteil — die Arbeit liegt in
drei anderen Repos", und Rumpf-Zeile 84 benennt sie woertlich (communication-server /
mobile-app / domains/ai/api). claim_paths entsprechend gesetzt — vorher standen dort
interfaces+models, was ihn bei JEDER laufenden Fundament-Sitzung mit NOT-READY:paths
kollidieren liess (4x zurueckgelegt). Danach gemessen: nur noch ein ECHTER, transienter
Konflikt mit einer aktiven Sitzung, den der Pruefer selbst als verengbar ausweist.
Der Teilbefund `sttProvider ist nicht abbildbar` bleibt ausdruecklich offen.
rang2-restposten-zustandsfelder — ZWEITE Korrektur am selben Tag, sie nimmt meine erste
zurueck. Der Commit 158ae945cd hob ihn auf `dependency` mit der Begruendung "reiner
Platz-Warter"; das war SACHLICH FALSCH. Gemessen: die Fundament-Haelfte ist geliefert
(3 von 4 Entitaeten), der Rest braucht keinen Platz. Offen ist eine PRODUKT-Entscheidung,
die der Brief selbst benennt: `joboffers` wurde am Bestand gestoppt (22 leere Stubs, kein
`_customerID`) — gehoeren die fuenf Aktionen ueberhaupt an diese Entitaet? Daher
`ceo-decision`, damit /interview ihn ueberhaupt sieht.
Die Fundament-Pfade blieben dort BEWUSST stehen: der Brief benennt kein einziges
Nicht-Fundament-Repo, ein Ersatz waere geraten gewesen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"foundation-batch-cascade-31" als Halter von platform/interfaces; der Bestand steht bei
68. Vor allem aber braucht der Brief gar keinen Platz: sein eigener Defer-Grund sagt
"Nach dem ABBILDEN-Entscheid gibt es KEINEN interfaces/models-Anteil — die Arbeit liegt in
drei anderen Repos", und Rumpf-Zeile 84 benennt sie woertlich (communication-server /
mobile-app / domains/ai/api). claim_paths entsprechend gesetzt — vorher standen dort
interfaces+models, was ihn bei JEDER laufenden Fundament-Sitzung mit NOT-READY:paths
kollidieren liess (4x zurueckgelegt). Danach gemessen: nur noch ein ECHTER, transienter
Konflikt mit einer aktiven Sitzung, den der Pruefer selbst als verengbar ausweist.
Der Teilbefund `sttProvider ist nicht abbildbar` bleibt ausdruecklich offen.
rang2-restposten-zustandsfelder — ZWEITE Korrektur am selben Tag, sie nimmt meine erste
zurueck. Der Commit 158ae945cd hob ihn auf `dependency` mit der Begruendung "reiner
Platz-Warter"; das war SACHLICH FALSCH. Gemessen: die Fundament-Haelfte ist geliefert
(3 von 4 Entitaeten), der Rest braucht keinen Platz. Offen ist eine PRODUKT-Entscheidung,
die der Brief selbst benennt: `joboffers` wurde am Bestand gestoppt (22 leere Stubs, kein
`_customerID`) — gehoeren die fuenf Aktionen ueberhaupt an diese Entitaet? Daher
`ceo-decision`, damit /interview ihn ueberhaupt sieht.
Die Fundament-Pfade blieben dort BEWUSST stehen: der Brief benennt kein einziges
Nicht-Fundament-Repo, ein Ersatz waere geraten gewesen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sieben Briefe beanspruchten Fundament-Pfade, deren Arbeit laengst geliefert ist
Jeder der sieben traegt `foundation: false` UND sagt im eigenen Rumpf, dass sein
Fundament-Anteil erledigt ist ("Der Fundament-Teil dieses Briefes ist GELIEFERT",
"KEIN Fundament-Diff", "FUNDAMENT-ANTEIL GELIEFERT"). Stehen geblieben war nur der
`claim_paths`-Eintrag auf platform/interfaces|models|core.
DER SCHADEN ist der in CLAUDE.md (Kaskade 68) beschriebene: ein `foundation:false`-Brief,
der einen Fundament-Pfad weiter beansprucht, faellt beim Promote mit
`NOT-READY:paths:<sitzung>:<pfad>`, sobald irgendeine Fundament-Sitzung laeuft — und die
laufen rund fuenfmal taeglich. Er wird eingesammelt, kollidiert, wird zurueckgelegt,
wiederholt. Gemessen: von sieben geprueften Briefen dieser Klasse sind ALLE SIEBEN
mehrfach zurueckgelegt (2-4x).
Eine Stichprobe zusaetzlich am Quelltext belegt statt am Brieftext geglaubt:
sdui-aktions-schiene verlangt ein Verb-Feld an `actionDef` — es steht seit laengerem in
platform/core/src/lib/api/registerModuleStates.ts:899 und wird :914 verwendet.
WIRKUNG GEMESSEN: drei der sieben melden nach der Verengung `READY`
(dashboard-geteilter-seitenfilter, stackdump-restmenge, statusseite-tages-rollup);
vorher keiner. Alle sieben behalten nicht-leere claim_paths.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fundament-Anteil erledigt ist ("Der Fundament-Teil dieses Briefes ist GELIEFERT",
"KEIN Fundament-Diff", "FUNDAMENT-ANTEIL GELIEFERT"). Stehen geblieben war nur der
`claim_paths`-Eintrag auf platform/interfaces|models|core.
DER SCHADEN ist der in CLAUDE.md (Kaskade 68) beschriebene: ein `foundation:false`-Brief,
der einen Fundament-Pfad weiter beansprucht, faellt beim Promote mit
`NOT-READY:paths:<sitzung>:<pfad>`, sobald irgendeine Fundament-Sitzung laeuft — und die
laufen rund fuenfmal taeglich. Er wird eingesammelt, kollidiert, wird zurueckgelegt,
wiederholt. Gemessen: von sieben geprueften Briefen dieser Klasse sind ALLE SIEBEN
mehrfach zurueckgelegt (2-4x).
Eine Stichprobe zusaetzlich am Quelltext belegt statt am Brieftext geglaubt:
sdui-aktions-schiene verlangt ein Verb-Feld an `actionDef` — es steht seit laengerem in
platform/core/src/lib/api/registerModuleStates.ts:899 und wird :914 verwendet.
WIRKUNG GEMESSEN: drei der sieben melden nach der Verengung `READY`
(dashboard-geteilter-seitenfilter, stackdump-restmenge, statusseite-tages-rollup);
vorher keiner. Alle sieben behalten nicht-leere claim_paths.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Selbst-Hosting-Restprofile als vier Wellen geschnitten
Vier Wellen-Briefe (crm+marketing / content+ecommerce / Betrieb / Fachmodule)
plus ein CEO-Entscheid-Brief zum stillgelegten support-center-api im Compose.
Faktenlage neu gemessen statt aus der Vorlage vom 08-05 uebernommen: 19 statt
17 Profile, core 11 statt 10, 66 statt 65 Abbilder, 19,37 GB gemessen statt
~21 GB hochgerechnet, Namens-Luecken bereits geschlossen (66/66).
Der Ausloeser des Ueberbau-Briefes war NICHT eingetreten (drei Betreiber-
Residuals seit 16 Tagen offen). Die neuen Briefe verankern ihr DEPENDS-ON
deshalb auf dem Residual statt auf dem Brief, der es hinterlassen hat —
Befoerderungs-Trockenlauf weist alle vier mit Namen des Blockers ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
plus ein CEO-Entscheid-Brief zum stillgelegten support-center-api im Compose.
Faktenlage neu gemessen statt aus der Vorlage vom 08-05 uebernommen: 19 statt
17 Profile, core 11 statt 10, 66 statt 65 Abbilder, 19,37 GB gemessen statt
~21 GB hochgerechnet, Namens-Luecken bereits geschlossen (66/66).
Der Ausloeser des Ueberbau-Briefes war NICHT eingetreten (drei Betreiber-
Residuals seit 16 Tagen offen). Die neuen Briefe verankern ihr DEPENDS-ON
deshalb auf dem Residual statt auf dem Brief, der es hinterlassen hat —
Befoerderungs-Trockenlauf weist alle vier mit Namen des Blockers ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sechs reine Fundament-Platz-Warter aus der Etiketten-Sackgasse befreit
`deferred` steht im AWAITING_ENUM, fehlt aber in BATCH_READY_AWAITING
(coord-admin.mjs:6716) — die sechs Briefe waren damit fuer den Kaskaden-
Kollektor UND den Grant-Waehler dauerhaft unsichtbar, obwohl ihr trigger
READY sagt und einzig der Fundament-Platz fehlt.
Fuer Fundament-Platz-Warter gab es nur zwei Etiketten, und BEIDE fuehren in
den Ausschluss: `foundation-slot` liegt ausserhalb des Enums (fail-closed),
`deferred` faellt aus BATCH_READY_AWAITING. Ein Brief dokumentiert den
vergeblichen Wechsel woertlich (knowledgebase-eigene-ki-aktionen-je-sammlung,
/resync 2026-08-18). Gehoben auf `dependency` — der Wert, der bei 32
Geschwistern nachweislich traegt.
Wirkung gemessen (foundation-batch --dry-run): 5 der 6 sind jetzt als
[core]/[field] IM Kollektor. Positiv-Kontrolle haelt: der echt geparkte
devopsalerts-entity-retire-candidate bleibt [awaiting-human] EXCLUDED, das
Tor ist also nicht pauschal geoeffnet.
Der sechste (rang2-restposten-zustandsfelder-fundament) bleibt draussen und
legt einen eigenen Befund frei: er beansprucht platform/interfaces+models,
traegt aber `foundation: false` — 11 Briefe liegen so, davon 7 mehrfach
zurueckgelegt. Nicht in diesem Commit behoben (Koordinations-Entscheid).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(coord-admin.mjs:6716) — die sechs Briefe waren damit fuer den Kaskaden-
Kollektor UND den Grant-Waehler dauerhaft unsichtbar, obwohl ihr trigger
READY sagt und einzig der Fundament-Platz fehlt.
Fuer Fundament-Platz-Warter gab es nur zwei Etiketten, und BEIDE fuehren in
den Ausschluss: `foundation-slot` liegt ausserhalb des Enums (fail-closed),
`deferred` faellt aus BATCH_READY_AWAITING. Ein Brief dokumentiert den
vergeblichen Wechsel woertlich (knowledgebase-eigene-ki-aktionen-je-sammlung,
/resync 2026-08-18). Gehoben auf `dependency` — der Wert, der bei 32
Geschwistern nachweislich traegt.
Wirkung gemessen (foundation-batch --dry-run): 5 der 6 sind jetzt als
[core]/[field] IM Kollektor. Positiv-Kontrolle haelt: der echt geparkte
devopsalerts-entity-retire-candidate bleibt [awaiting-human] EXCLUDED, das
Tor ist also nicht pauschal geoeffnet.
Der sechste (rang2-restposten-zustandsfelder-fundament) bleibt draussen und
legt einen eigenen Befund frei: er beansprucht platform/interfaces+models,
traegt aber `foundation: false` — 11 Briefe liegen so, davon 7 mehrfach
zurueckgelegt. Nicht in diesem Commit behoben (Koordinations-Entscheid).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kaskade 65 stand als tote Next-in-line in der Fundament-Reihe
`foundation-batch-cascade-65-fields` trug seit dem CEO-Einfalten in Kaskade 66
(2026-08-21) ein `superseded_by`, aber weiter `status: blocked`. `foundation-advance`
liest den STATUS, nicht das Feld — der Brief meldete sich damit als
"Next-in-line (P1, 8-14 h)", obwohl sein Inhalt in 66 geliefert ist.
- status blocked -> superseded (Vorbild: Kaskade 67, die es korrekt traegt)
- echter Next-in-line jetzt: core-updateone-wickelt-404-in-500 (P1)
Gefunden durch CEO-Rueckfrage im /resync-Tick, nicht durch einen Waechter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(2026-08-21) ein `superseded_by`, aber weiter `status: blocked`. `foundation-advance`
liest den STATUS, nicht das Feld — der Brief meldete sich damit als
"Next-in-line (P1, 8-14 h)", obwohl sein Inhalt in 66 geliefert ist.
- status blocked -> superseded (Vorbild: Kaskade 67, die es korrekt traegt)
- echter Next-in-line jetzt: core-updateone-wickelt-404-in-500 (P1)
Gefunden durch CEO-Rueckfrage im /resync-Tick, nicht durch einen Waechter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
drei Briefe trugen `awaiting: pl-grant` — ein Wert ausserhalb des Kanons
`pl-grant` steht NICHT im kanonischen Vorrat (`ceo-decision | ceo-verification |
user-input | operator-action | hardware | dependency | deferred | dedicated-session |
none`). Der Pruefer sagt dazu woertlich: „ein Wert ausserhalb macht ihn fuer JEDE
Automatik unsichtbar" — die drei Briefe waren also weder claimbar noch befoerderbar.
🔴 ZWEI DAVON SIND MEINE, aus derselben Sitzung (Iteration 5, 2026-08-22): ich hatte
den Wert aus dem BESTAND abgeschrieben (`grep` zeigte ihn an einem vorhandenen Brief),
statt den Kanon zu pruefen. Genau die Fehlerklasse „vom Bestand abschreiben statt die
Regel lesen" — der vorhandene Brief trug denselben Fehler.
Korrigiert auf `awaiting: none`, und das ist gemessen, nicht geraten: der
Fundament-Grant laeuft ueber `foundation: true` plus den Grant-Mechanismus, NICHT ueber
`awaiting`. Die Verteilung der `foundation: true`-Briefe in `blocked/` bestaetigt es —
26x `dependency`, 11x `none`, 11x `deferred`, 1x `trigger`; kein einziger nutzt
`awaiting` als Grant-Tor.
Wirkung belegt: `ensure-worker-prompt` meldete fuer beide vorher
`awaiting-not-in-enum … nichts angefasst`, danach `already complete (no-op)`.
⚠ NICHT MITKORRIGIERT, bewusst: drei weitere Briefe tragen `awaiting: trigger`
(ebenfalls nicht im Kanon). Dort ist die richtige Ersetzung NICHT eindeutig —
`deferred` und `dependency` bedeuten Verschiedenes, und die Wahl aendert die
Einreihung. Das gehoert gelesen, nicht geraten:
`codingjobs-lebenszyklus-routen-und-cli-stilllegen`,
`codingjobs-strukturell-entfernen`, `deployment-health-severity-wirkung-nachmessen`.
user-input | operator-action | hardware | dependency | deferred | dedicated-session |
none`). Der Pruefer sagt dazu woertlich: „ein Wert ausserhalb macht ihn fuer JEDE
Automatik unsichtbar" — die drei Briefe waren also weder claimbar noch befoerderbar.
🔴 ZWEI DAVON SIND MEINE, aus derselben Sitzung (Iteration 5, 2026-08-22): ich hatte
den Wert aus dem BESTAND abgeschrieben (`grep` zeigte ihn an einem vorhandenen Brief),
statt den Kanon zu pruefen. Genau die Fehlerklasse „vom Bestand abschreiben statt die
Regel lesen" — der vorhandene Brief trug denselben Fehler.
Korrigiert auf `awaiting: none`, und das ist gemessen, nicht geraten: der
Fundament-Grant laeuft ueber `foundation: true` plus den Grant-Mechanismus, NICHT ueber
`awaiting`. Die Verteilung der `foundation: true`-Briefe in `blocked/` bestaetigt es —
26x `dependency`, 11x `none`, 11x `deferred`, 1x `trigger`; kein einziger nutzt
`awaiting` als Grant-Tor.
Wirkung belegt: `ensure-worker-prompt` meldete fuer beide vorher
`awaiting-not-in-enum … nichts angefasst`, danach `already complete (no-op)`.
⚠ NICHT MITKORRIGIERT, bewusst: drei weitere Briefe tragen `awaiting: trigger`
(ebenfalls nicht im Kanon). Dort ist die richtige Ersetzung NICHT eindeutig —
`deferred` und `dependency` bedeuten Verschiedenes, und die Wahl aendert die
Einreihung. Das gehoert gelesen, nicht geraten:
`codingjobs-lebenszyklus-routen-und-cli-stilllegen`,
`codingjobs-strukturell-entfernen`, `deployment-health-severity-wirkung-nachmessen`.
Walker prueft gegen queue/done + Aufraeumer meldet Fertig-Doppel
VORFALL 2026-08-22: `podcast-takt-zeit-je-objekt` fuhr 17:33:35Z ein sauberes
`coord done` (8596553cf2). 17:40:32Z claimte ein Walker denselben Brief erneut
aus toPost — auf dem AKTUELLEN Stand (merge-base --is-ancestor: ja). Ergebnis:
derselbe Slug in ZWEI Ordnern getrackt.
- Guard (a1) `already-done` vor dem O_EXCL-Lock, direkt nach `pending` — die
zurueckgekehrte Kopie traegt `status: pending`, der Vorgaenger-Guard faengt
sie also nicht. Benannter Grund `copy-in-queue/done`, nie stilles false.
- `coord reap` meldet FERTIG-DOPPEL (Slug in done UND toPost/blocked), nur
gemeldet, nie bewegt — die Ursache ist ungemessen, und eine getrackte Datei
wegen Namensgleichheit zu entfernen ist die riskantere Richtung.
GEMESSEN statt angenommen (der Brief verlangte es ausdruecklich): der bestehende
`done-zombie`-Zaehler stand zu Recht auf 0 — `classifyZombieBrief` laeuft
ausschliesslich ueber queue/active, der Doppel-Eintrag lag in toPost. Anderes
Quellverzeichnis, kein schwaecheres Signal.
`active` ist bei FERTIG-DOPPEL BEWUSST ausgenommen: waehrend eines laufenden
`coord done` liegt derselbe Slug kurz in active UND done.
Proben: 10 neu, ins test:coord-Fach VERDRAHTET (1066 -> 1076, Fehlschlaege
unveraendert 5 = Bestand, beidseitig gegengeprueft). Flip-Probe beidseitig.
Flottenweite Zaehlung 0 auf beiden Achsen, zweifach gemessen.
`coord done` (8596553cf2). 17:40:32Z claimte ein Walker denselben Brief erneut
aus toPost — auf dem AKTUELLEN Stand (merge-base --is-ancestor: ja). Ergebnis:
derselbe Slug in ZWEI Ordnern getrackt.
- Guard (a1) `already-done` vor dem O_EXCL-Lock, direkt nach `pending` — die
zurueckgekehrte Kopie traegt `status: pending`, der Vorgaenger-Guard faengt
sie also nicht. Benannter Grund `copy-in-queue/done`, nie stilles false.
- `coord reap` meldet FERTIG-DOPPEL (Slug in done UND toPost/blocked), nur
gemeldet, nie bewegt — die Ursache ist ungemessen, und eine getrackte Datei
wegen Namensgleichheit zu entfernen ist die riskantere Richtung.
GEMESSEN statt angenommen (der Brief verlangte es ausdruecklich): der bestehende
`done-zombie`-Zaehler stand zu Recht auf 0 — `classifyZombieBrief` laeuft
ausschliesslich ueber queue/active, der Doppel-Eintrag lag in toPost. Anderes
Quellverzeichnis, kein schwaecheres Signal.
`active` ist bei FERTIG-DOPPEL BEWUSST ausgenommen: waehrend eines laufenden
`coord done` liegt derselbe Slug kurz in active UND done.
Proben: 10 neu, ins test:coord-Fach VERDRAHTET (1066 -> 1076, Fehlschlaege
unveraendert 5 = Bestand, beidseitig gegengeprueft). Flip-Probe beidseitig.
Flottenweite Zaehlung 0 auf beiden Achsen, zweifach gemessen.
Einzelschreiber-Riegel unterscheidet Reservierung von Schreiber (CEO 2026-08-22)
Der Fundament-Riegel sperrte bis dahin gleich hart, egal ob ein Brief in toPost LIEGT
(Reservierung, niemand arbeitet) oder eine Sitzung AKTIV schreibt — und der ERSTE
gefundene Halter gewann, unabhaengig von Prioritaet und sogar davon, ob er ueberhaupt
dispatchbar war.
GEMESSENER SCHADEN (2026-08-22, DREI Faelle an EINEM Tag):
- Ein P3 hielt den models-Platz vor einer P1-Kaskade mit drei Gliedern.
- Ein P2 hielt den interfaces-Platz SECHS STUNDEN vor einem P1 — und war dabei selbst
nicht dispatchbar (NOT-READY:fe-coverage-missing). Ein Brief, den niemand claimen
KANN, blockierte einen, den jemand claimen soll.
- Ein weiterer P3 rueckte sofort nach, als der erste geraeumt war.
Alle drei mussten von Hand per demote --force weggeraeumt werden.
DIE REGEL:
- active / active-session sperren IMMER — dort schreibt jemand; Prioritaet darf einen
laufenden Schreiber nie verdraengen (Einzelschreiber-Garantie).
- toPost sperrt nur gegen gleich- oder hoeherrangige Anwaerter — eine Reservierung
weicht einem STRIKT dringlicheren Vorgang (gleicher Rang sperrt weiter, sonst
entstuende ein Wettlauf zweier claimbarer Briefe).
- FAIL-CLOSED: fehlt eine der beiden Prioritaeten oder ist sie unlesbar, haelt die
Sperre — ein Tippfehler darf nie zum Freifahrtschein werden.
- Rueckwaerts-vertraeglich: ohne uebergebene Prioritaet gilt das alte Verhalten.
VERIFIKATION:
- 17 neue Proben, im test:coord-Fach namentlich verdrahtet.
- Flip-Probe: Ausnahme neutralisiert → 4 von 17 rot, wiederhergestellt 17/17.
- Ende-zu-Ende am ECHTEN Fall: status-und-typ-kanon (P1) war vom P2-Halter REFUSED,
nach dem Fix "would promote".
- Bestands-Reihe coord-admin 257/259 — die 2 roten sind VORBESTEHEND, beidseitig
belegt per git stash (identisch rot am unveraenderten HEAD; byte-genaue
Wiederherstellung per Pruefsummen-Vergleich). Beide ohne Bezug zum Riegel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TzYJQKJ6eGLzeZXmLMMxX
(Reservierung, niemand arbeitet) oder eine Sitzung AKTIV schreibt — und der ERSTE
gefundene Halter gewann, unabhaengig von Prioritaet und sogar davon, ob er ueberhaupt
dispatchbar war.
GEMESSENER SCHADEN (2026-08-22, DREI Faelle an EINEM Tag):
- Ein P3 hielt den models-Platz vor einer P1-Kaskade mit drei Gliedern.
- Ein P2 hielt den interfaces-Platz SECHS STUNDEN vor einem P1 — und war dabei selbst
nicht dispatchbar (NOT-READY:fe-coverage-missing). Ein Brief, den niemand claimen
KANN, blockierte einen, den jemand claimen soll.
- Ein weiterer P3 rueckte sofort nach, als der erste geraeumt war.
Alle drei mussten von Hand per demote --force weggeraeumt werden.
DIE REGEL:
- active / active-session sperren IMMER — dort schreibt jemand; Prioritaet darf einen
laufenden Schreiber nie verdraengen (Einzelschreiber-Garantie).
- toPost sperrt nur gegen gleich- oder hoeherrangige Anwaerter — eine Reservierung
weicht einem STRIKT dringlicheren Vorgang (gleicher Rang sperrt weiter, sonst
entstuende ein Wettlauf zweier claimbarer Briefe).
- FAIL-CLOSED: fehlt eine der beiden Prioritaeten oder ist sie unlesbar, haelt die
Sperre — ein Tippfehler darf nie zum Freifahrtschein werden.
- Rueckwaerts-vertraeglich: ohne uebergebene Prioritaet gilt das alte Verhalten.
VERIFIKATION:
- 17 neue Proben, im test:coord-Fach namentlich verdrahtet.
- Flip-Probe: Ausnahme neutralisiert → 4 von 17 rot, wiederhergestellt 17/17.
- Ende-zu-Ende am ECHTEN Fall: status-und-typ-kanon (P1) war vom P2-Halter REFUSED,
nach dem Fix "would promote".
- Bestands-Reihe coord-admin 257/259 — die 2 roten sind VORBESTEHEND, beidseitig
belegt per git stash (identisch rot am unveraenderten HEAD; byte-genaue
Wiederherstellung per Pruefsummen-Vergleich). Beide ohne Bezug zum Riegel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TzYJQKJ6eGLzeZXmLMMxX
foundation-freshness hint no longer suggests --pin-exact for the 6 transitional shared libs
The freshness hint at coord claim treats any non-exact pin as "kein exakter Pin"
and recommends --pin-exact for it — correct for normal consumers, but wrong for
the six shared libraries (ayoune-theming, ayoune-device-shell, comm-sidebar,
notifications, permission-editor, communicator) that CLAUDE.md's transitional
override explicitly keeps on ranges until the deployment-plan bump_dependency
step carries them along. Following the hint there creates a second Foundation
resolution at their consumers (measured 2026-08-02, 11 affected pairs).
TRANSITIONAL_RANGE_LIBS excludes exactly those six from the hint; everything
else is unaffected (flip-probe-verified, gegenprobe for a 7th unlisted lib).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
and recommends --pin-exact for it — correct for normal consumers, but wrong for
the six shared libraries (ayoune-theming, ayoune-device-shell, comm-sidebar,
notifications, permission-editor, communicator) that CLAUDE.md's transitional
override explicitly keeps on ranges until the deployment-plan bump_dependency
step carries them along. Following the hint there creates a second Foundation
resolution at their consumers (measured 2026-08-02, 11 affected pairs).
TRANSITIONAL_RANGE_LIBS excludes exactly those six from the hint; everything
else is unaffected (flip-probe-verified, gegenprobe for a 7th unlisted lib).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
reuse_check.verdict auf gueltigen Wert (fix ist keiner)
Erlaubt sind laut @tolinax/ayoune-workitem-quality genau: reuse | extend |
genuinely-new | verify. Der Validator hatte die drei Briefe deshalb als
reuse-check-missing gefuehrt.
genuinely-new | verify. Der Validator hatte die drei Briefe deshalb als
reuse-check-missing gefuehrt.
Praemisse von alarm-umschlag-traegt-keinen-ursprungs-zeitpunkt korrigiert
An der Flaeche widerlegt: das ausgebrachte Bedienpanel (App-Laufzeit
360 s) zeigt 'seit 13.08. 18:30 · vor 8d'. Ein acht Tage alter Ursprung
kann nicht aus dem Arbeitsspeicher stammen — der START-Weg
(app.component.ts:1388-1392) liefert die Vorkommens-Daten sehr wohl.
Die Suche, die zur falschen Praemisse fuehrte, war ein FALSCHES NEGATIV:
eine Namens-Suche kann einen generisch gebauten Umschlag nicht sehen.
Die Positiv-Kontrolle fing es nicht — sie belegte nur, dass die Suche
ueberhaupt trifft, nicht dass der Erzeuger seine Felder woertlich
hinschreibt.
Offen ist damit nur noch, ob der LIVE-Weg (Socket) sie ebenfalls traegt.
360 s) zeigt 'seit 13.08. 18:30 · vor 8d'. Ein acht Tage alter Ursprung
kann nicht aus dem Arbeitsspeicher stammen — der START-Weg
(app.component.ts:1388-1392) liefert die Vorkommens-Daten sehr wohl.
Die Suche, die zur falschen Praemisse fuehrte, war ein FALSCHES NEGATIV:
eine Namens-Suche kann einen generisch gebauten Umschlag nicht sehen.
Die Positiv-Kontrolle fing es nicht — sie belegte nur, dass die Suche
ueberhaupt trifft, nicht dass der Erzeuger seine Felder woertlich
hinschreibt.
Offen ist damit nur noch, ob der LIVE-Weg (Socket) sie ebenfalls traegt.
awaiting auf dependency ziehen (sed traf den Kommentar-Suffix nicht)
Die Zeile lautete 'awaiting: none # CEO 2026-08-21 …' — mein Muster verlangte das Zeilenende
direkt nach 'none' und griff deshalb nicht. Ein blockierter Brief mit 'awaiting: none' waere
weiterhin claimbar gewesen (none steht in AWAITING_CLAIMABLE).
direkt nach 'none' und griff deshalb nicht. Ein blockierter Brief mit 'awaiting: none' waere
weiterhin claimbar gewesen (none steht in AWAITING_CLAIMABLE).