AGM_rewrite-4 · 2026-08-27 · Runde 7

Offene Entscheidungen

Vierter Anlauf des Audioguide-Rewrites. Phase 3 und 3b/3c sind abgeschlossen, Phase 3d steht bei einem Viertel; 373 Wachen sind grün. Die Punkte auf dieser Seite stammen aus achtzehn Naht-Reviews mit zwei unabhängigen Modellen und aus der Arbeit an den Verträgen.

Wachen: 373grün
Karten: 10Entscheidungen
Befunde: 17ohne Wahl, am Ende der Seite
Blockiert: 8vor P4-3 bzw. P5-1

Acht, die eine Kette aufhalten

R-56 vor P4-3 Fehlervertrag Reifegradrahmen

Braucht der Fehlervertrag eine fünfte Klasse „Zustand“?

rahmenFehler.CONFLICT und der neue REFERENCES_EXIST tragen heute die Klasse VALIDATION. Deren eigene Definition in packages/contract/src/fehler.ts lautet „die Anfrage ist ungültig; dieselbe Anfrage wird nie gültig“ — nach Wegfall der Verweise wird sie es doch. VALIDATION ist damit die am wenigsten falsche Klasse, nicht die richtige. Die vier Klassen stammen aus ~/.claude/docs/error-handling-standards.md und gelten projektübergreifend.

A — Bei vier Klassen bleiben, der Riss bleibt benannt CONFLICT und REFERENCES_EXIST behalten VALIDATION; der Widerspruch steht als Kommentar an beiden Stellen im Quelltext. retryable: false stimmt in jedem Fall, aber die Klassendefinition beschreibt zwei ihrer Fehler falsch — und in P4-3 entstehen Fehlerpfade in Menge. B — Fünfte Klasse „Zustand“ einführen Fehler, die von einem Zustand abhängen und nach dessen Änderung gültig werden, bekommen eine eigene Klasse. Das ändert den projektübergreifenden Reifegradrahmen, nicht nur diesen Vertrag — die Standards gelten für alle Projekte. Später entscheiden

Keine Empfehlung

Der Befundtext trägt keine. Er hält fest, dass eine fünfte Klasse den Reifegradrahmen ändern hiesse und das Marcs Entscheidung ist, keine innerhalb eines Vertrags umkehrbare. Gebaut ist heute Weg A.

Naht-Review zu W-04, 2026-08-27 — Alleinfund Grok. Dringlichkeit laut Text: vor P4-3 (Auftragsstrecke).

R-20 vor P5-1 Datenmodell Exponat-Kette

Bleibt es bei n:1 zwischen Exponat und Künstler?

R-20 hat am 2026-08-26 n:1 festgelegt: ein Exponat, ein Künstlerverweis. Ein Exponat mit zwei Künstlern oder der Zuschreibung „Werkstatt des X“ bekommt damit nur einen Eintrag; Beteiligung, Reihenfolge und Zuschreibungsart gehen verloren.

A — n:1 bleibt wie entschieden Empfehlung Das Exponat verweist auf genau einen Artist; der Mehrfachfall wird nicht abgebildet. Museen mit Mehrfachzuschreibung müssen sie in ein Freitextfeld schreiben; eine spätere Umstellung ist eine Datenwanderung. B — Geordnete Beteiligungsliste am Exponat Artist bleibt Personenprofil, das Exponat trägt eine geordnete Liste von Beteiligungen mit Rolle und Zuschreibungsart. Das ändert R-20 und damit das Datenmodell vor der Exponat-Kette — Vertrag, Schema, Route und Formular hängen daran. Später entscheiden

Warum A

Gebaut ist R-20 wie entschieden, weil eine Änderung der Kardinalität eine Datenmodellentscheidung ist und nicht im Ermessen des Agenten liegt. Der Befund ist belegt, aber nicht dringend: Die Erhebung hat im ganzen Altsystem kein Feld für Zuschreibung, Signatur oder Werkstatt gefunden und in den Feldinventuren keinen Marker; es gibt genau zwei Künstlerfelder, beide Freitext. Der Mehrfachfall ist fachlich real, im Bestand aber nicht belegt.

Naht-Review zu W-22, 2026-08-27 — Alleinfund Codex, Schweregrad hoch. Dringlichkeit laut Text: vor der Exponat-Kette (P5-1).

R-06 vor P5-1 Datenmodell Grundriss-Kette

Verweist das Exponat auf einen Raum — oder tut es die Position?

R-06 sagt zweierlei zugleich: Das Exponat verweist auf genau einen Raum, dauerhaft — und Geometrie und Position hängen je an einer Planversion. Wird eine neue Planversion freigegeben, in der ein Raum nicht mehr vorkommt, auf den noch Exponate zeigen, bricht eine der beiden Zusagen: Der Verweis zeigt ins Leere, oder er wird geleert (dann gibt es keinen „genau einen Raum“), oder der Raum bekommt je Version eine neue Kennung (dann zeigt das Exponat auf die Vorversion).

A — Raumverweis bleibt, die Freigabe wird gesperrt Empfehlung Die Raumkennung ist versionsübergreifend stabil, und eine Planversion, die einen belegten Raum weglässt, wird nicht freigegeben — mit demselben Fehler und derselben Aufstellung wie die Löschsperre aus W-04. Wer einen Raum aus dem Plan nehmen will, muss vorher alle Exponate umhängen; die Freigabe kann daran scheitern. B — Das Exponat verweist gar nicht auf einen Raum Die Position — die ohnehin an der Planversion hängt — nennt den Raum; Geminis Gegenvorschlag. Das ändert R-06, und die Frage „in welchem Raum liegt dieses Exponat?“ verliert ihre einfache Antwort, sobald es mehrere Planversionen gibt. Später entscheiden

Warum A

Gebaut ist die strengere Lesart nach R-45, weil sie beide Zusagen erhält und nichts zusagt, was nicht schon in R-06 und W-04 steht. Weg B wäre sauberer, ändert aber eine getroffene Entscheidung.

Naht-Review zu W-06, 2026-08-27 — beide Köpfe fanden den Fall, Gemini stufte ihn als fatal ein. Dringlichkeit laut Text: vor der Grundriss-Kette (P5-1), nicht vorher.

R-57 vor P5-1 Zuschnitt Besucher-PWA

Bleibt der QR-Code der einzige Weg zum Exponat?

Die Entwürfe sagen nicht, wie ein Besucher einem Museum zugeordnet wird: kein QR-kodierter Mandant, keine Scan-Route mit Mandantenauflösung, keine Zuordnungslogik. Die einzige museumsbezogene Zusage im Besucherbereich (Zeile 831 des Abgleichs) betrifft die Zugehörigkeit eines Exponats zu einer Sonderausstellung, nicht den Besucher. Alle sechs PWA-Entwürfe zeigen ausschliesslich die Abspiel- und Detailansicht eines bereits gewählten Exponats. Das Altsystem stimmt damit überein: Der einzige Weg zum Exponat ist ein QR-Code je Exponat (functions/src/routes/qrcode.routes.ts); eine öffentliche Liste, Suche oder Karte gibt es dort nicht.

A — QR bleibt der einzige Weg Der Besucher steht vor dem Objekt und scannt; die Mandantenbindung hängt am QR-Kennzeichen, wie R-51 es festgelegt hat. Es gibt keine Lücke — specs/visitor/ ist vollständig und W-38 steht auf der bereits getroffenen Entscheidung. B — Es gibt einen zweiten Einstieg Startseite, Haus-Übersicht, Liste, Suche oder Karte — ein Weg zum Exponat ohne Scan. Dann fehlt ein ganzer Bildschirm, den weder Entwurf noch Altsystem kennt, und P5-1 kann für die PWA bis dahin keine vollständige Kette schneiden. Später entscheiden

Keine Empfehlung

Der Befundtext trägt keine — er stellt die Frage und nennt beide Folgen. Festgehalten ist nur, dass W-38 auf R-51 und dem Altsystem aufbaut, nicht auf einer Zusage der Entwürfe, und dass das benannt ist, nicht stillschweigend.

P1-1/P1-2 (2026-08-26) und W-38 (2026-08-27); Belege in docs/sichtung/2026-08-27_besucher-zusagen.md. Alle 91 Besucher-Zusagen tragen „nur Entwurf“.

R-58 vor P5-1 Zuschnitt Entwürfe

Entstehen Entwürfe für Anmeldung, Abmeldung und Mandantenwechsel — oder schneidet die Kette sie selbst?

claude-design-handover/ enthält keine .dc.html für einen dieser drei Vorgänge; die Suche nach anmeld|login|sign-in und nach Mandantenwechsel|museum wechseln liefert nichts. Für Anmeldung und Abmeldung ist das schon länger bekannt — R-13 entstand genau daraus. Neu ist der Mandantenwechsel: R-50 verlangt, dass ein Mitglied mehrerer Museen „sichtbar“ wechselt; die Fläche dafür ist nirgends entworfen.

A — Für die drei Vorgänge entstehen Entwürfe Der Grundsatz „der Bildschirm liefert den Zuschnitt“ bleibt für alle Ketten gültig. Die Ketten W-15 und W-37 warten, bis die Entwürfe da sind. B — Die Kette schneidet die drei Bildschirme selbst Zuschnitt und Gestaltung entstehen im Lauf, festgehalten als ausdrückliche Abweichung vom Grundsatz. Drei Bildschirme ohne Entwurfsvorlage; die Abweichung muss protokolliert werden, sonst sieht sie später aus wie ein vergessener Entwurf. Später entscheiden

Keine Empfehlung

Der Befundtext trägt keine — er nennt die beiden Wege gleichrangig: „Entweder entsteht ein Entwurf, oder die Kette schneidet ihn selbst — dann aber als benannte Abweichung.“

Erhoben am 2026-08-27 für W-15/W-37. Dringlichkeit laut Text: vor P5-1, zusammen mit der QR-Frage.

R-59 vor P5-1 Vertrag Besucher-PWA

Wo wählt der Besucher Sprache und Zielgruppe?

Im Besucherbereich der Entwürfe: null Zusagen dazu. Es gibt nur drei Kurator-Zusagen zur Vorbelegung einer Standardsprache. W-19 und ADR-011 setzen aber voraus, dass die Wiedergabe Sprache und Zielgruppe als Wert trägt — gewählt werden sie bisher von niemandem.

A — Der Besucher wählt beides in der PWA Sprache und Zielgruppe werden vom Besucher gesetzt und wandern als Wert in jede Wiedergabe. Eine Auswahlfläche, die in keinem der sechs PWA-Entwürfe vorkommt — sie muss geschnitten werden. B — Vorbelegung aus Mandanteneinstellung und Gerätesprache, keine Wahl Die Standardsprache des Mandanten und die Zielgruppe „Erwachsene“ gelten, bis jemand etwas anderes baut. Kinder- und Einfache-Sprache-Varianten sind erzeugt, aber für keinen Besucher erreichbar. Später entscheiden

Keine Empfehlung

Der Befundtext trägt keine. Er stellt nur fest, dass die Verträge einen Wert voraussetzen, den niemand setzt.

Gefunden am 2026-08-27 in W-38; Beleg docs/sichtung/2026-08-27_besucher-zusagen.md, erhoben aus research/2026-08-26_bildschirm-abgleich.md.

R-60 vor P5-1 Fristen ADR-010

Gelten 30 Minuten Inaktivität und 12 Stunden Maximaldauer für die Besuchersitzung?

ADR-010 sagt seit dem 2026-08-27 zu, dass es eine Inaktivitätsfrist und eine harte Maximaldauer gibt — beide Review-Köpfe hatten die Lücke gefunden, Gemini mit Schweregrad fatal: „endet mit der Sitzung“ ist kein Zeitpunkt, und ohne Frist wird die Kennung im Local Storage zur Gerätekennung. Die Zahlen stehen im Vertrag als Vorschlag: SITZUNG_INAKTIVITAET_MINUTEN = 30, SITZUNG_MAXIMALDAUER_STUNDEN = 12. Belegt: Das Altsystem hat gar keine Frist — die visitorId liegt dauerhaft im localStorage, und GET /visitors wertet Wiederbesucher aus. Das ist der in ADR-010 verworfene Weg C.

A — Die vorgeschlagenen Zahlen bestätigen Empfehlung 30 Minuten Inaktivität, 12 Stunden Maximaldauer — beide werden aus dem Vorschlag zur Entscheidung. Beide Zahlen sind am Museumsbesuch geschätzt, nicht gemessen; eine spätere Änderung verschiebt die Verweildauerstatistik rückwirkend nicht, aber trennt Zeiträume unterschiedlich. B — Andere Werte setzen Marc nennt die beiden Zahlen selbst; die Konstanten im Vertrag werden entsprechend geändert. Zu kurz, und die Verweildauerschätzung über einen Museumsbesuch zerfällt in mehrere Sitzungen; zu lang, und zwei Besuche desselben Tages werden verknüpft. Später entscheiden

Warum A

Die Zahlen sind der Vorschlag des Laufs, behandelt wie die übrigen Fristen nach R-44: vorgeschlagen im Lauf, entschieden danach. Bezugsgrösse ist laut Text der Museumsbesuch — 12 Stunden decken ihn sicher ab, 30 Minuten Inaktivität trennen zwei Besuche desselben Tages.

Naht-Review 2026-08-27, beide Köpfe; Gemini Schweregrad fatal. Dringlichkeit laut Text: vor der Besucherkette (P5-1).

R-61 vor P5-1 Vertrag Dissens

Bleibt die Raumkennung in der Heatmap-Antwort?

Der erste echte Dissens nach R-45 seit Einführung der Regel — dieselbe Stelle, zwei Bewertungen. R-33 hat entschieden, dass Räume in der Heatmap nicht anklickbar sind; strittig ist, ob der fachliche Vertrag die Kennung trotzdem ausliefert.

Codex

Der fachliche Vertrag beschreibt die Heatmap-Daten korrekt; die Negativzusage gehört in den Gestaltungsvertrag — ein rein darstellender Baustein ohne Aktions-Prop.

Gemini

Die Kennung aus der Antwort weglassen. „Wo keine ID geliefert wird, kann auch nichts aufgerufen werden.“ Damit ist R-33 im fachlichen Vertrag erzwungen, nicht nur zugesagt.

A — Die Kennung bleibt in der Antwort Empfehlung Der fachliche Vertrag liefert je Raum Kennung, Farbe und Wert; die Nicht-Anklickbarkeit steht im Gestaltungsvertrag als Baustein ohne Aktions-Prop. R-33 ist zugesagt, aber nicht durch das Datenschema erzwungen — eine spätere Implementierung könnte die Kennung wieder verlinken. B — Die Kennung entfällt, Zuordnung über die Reihenfolge Räume werden ohne Kennung ausgeliefert; Farbe und Raum finden über die Position in der Liste zusammen. Restriktiver und zugleich brüchiger — und es hebt die belegte Zusage auf, dass Raumfarbe und Wert je Raum darstellbar sind (heatmapRoomOutline, heatmapRoomMetricValue). Später entscheiden

Warum A

Gebaut ist Codex' Lesart, weil Geminis eine belegte Zusage bricht: Der Entwurf sagt Raumfarbe und Wert je Raum ausdrücklich zu, und ohne Kennung ist kein Raum darstellbar. Eine Lesart, die eine belegte Zusage aufhebt, ist nicht die strengere, sondern eine andere Entscheidung.

Naht-Review zu W-20, 2026-08-27. Dringlichkeit laut Text: vor der Auswertungskette (P5-1).

Zwei mit späterem, aber benanntem Zeitpunkt

R-62 vor P5-4 Entscheidungsakte

Wie kommen die achtzehn Entscheidungen der Runde 4 in die Akte?

docs/offene-fragen.md führt für R-13 bis R-30 je einen Abschnitt mit „entschieden am 2026-08-26“ im Titel — der Text darunter nennt aber nur die Frage und endet mit „Zu entscheiden: …“. Die Entscheidung selbst steht nirgends in der Akte; sie steht als Zusage in tasks.md (W-22 bis W-36). Nachgezählt: 21 Abschnitte tragen „entschieden“ im Titel, 18 ohne Entscheidungstext. Die Runden 1, 2, 3 und 5 haben ihre Entscheidungen dagegen als Tabellenzeilen. Wer eine Weiche nachschlägt, findet die Frage und liest daraus, sie sei offen — oder er liest die Zusage in der Bauliste und hält sie für eine Ableitung des Agenten. Genau diese Klasse hat das Projekt schon zweimal getroffen (ADR-007 „aus dem Pfad“, ADR-010 „eines Geräts“).

A — Marc bestätigt die achtzehn Zusagen, sie werden als Text übernommen Empfehlung Der Wortlaut aus den W-Punkten wird Marc vorgelegt und nach Bestätigung als Entscheidungstext in die Akte geschrieben — als Text, nicht als Verweis. Achtzehn Zusagen sind einmal durchzusehen, bevor P5-4 mit clarify gegen die Akte arbeitet. B — Der Agent trägt sie ungeprüft aus tasks.md nach Die Bauzusagen werden wörtlich in die Akte kopiert, ohne Rückfrage. Eine Entscheidung, die niemand getroffen hat, lässt sich nicht aus ihrer Umsetzung rekonstruieren — die Akte trüge dann Agentenableitungen mit Marcs Datum. Später entscheiden

Warum A

Der Befundtext sagt es selbst: „Die achtzehn Entscheidungen aus tasks.md in die Akte übernehmen — als Text, nicht als Verweis. Der Wortlaut liegt in den W-Punkten vor.“ Und die Begründung dafür, es nicht selbst getan zu haben: „Was in tasks.md steht, ist die Bauzusage — ob sie Marcs Wortlaut wiedergibt, weiss nur er.“

Gefunden am 2026-08-27 beim Nachschlagen von R-20 für die Kette W-22. Dringlichkeit laut Text: vor P5-4, wo clarify gegen die Akte arbeitet.

R-63 vor der Produktivstellung Auswertung

Bleiben die drei geratenen Aufmerksamkeitsschwellen, bis gemessen werden kann?

R-32 sagt es selbst: „Die Schwellenwerte werden einmal festgeschrieben und sind zunächst geraten.“ Sie stehen in AUFMERKSAMKEITSREGELN mit origin: 'annahme', damit sie später nicht als gemessen durchgehen: Verweildauer unter 1,5 min bei über 500 Wiedergaben · unter 20 Wiedergaben · Abschlussquote unter 35 %. Die Karte „Aufmerksamkeit prüfen“ ist die einzige Stelle des Auswertungs-Screens, die eine Handlungsempfehlung gibt.

A — Geratene Werte behalten, nach dem ersten Museumsbetrieb messen Empfehlung Die drei Schwellen bleiben mit origin: 'annahme' stehen und werden korrigiert, sobald echte Besuchsdaten vorliegen. Bis dahin kann die Karte zu oft oder zu selten melden; beides macht sie in der Pilotphase wertlos. B — Marc setzt die drei Werte jetzt aus Museumserfahrung Die Schwellen werden vor der Messung festgelegt und verlieren die Kennzeichnung annahme. Ein gesetzter Wert ohne Messung sieht später aus wie ein gemessener — genau das verhindert die Kennzeichnung heute. Später entscheiden

Warum A

Der Befundtext hält fest: „Gemessen werden kann erst mit echten Besuchsdaten, also nach dem ersten Museumsbetrieb.“ Zu enge Schwellen erzeugen eine Karte, die immer etwas meldet; zu weite eine, die nie etwas meldet.

R-32, festgehalten in AUFMERKSAMKEITSREGELN. Dringlichkeit laut Text: nicht vor P5-1, aber vor der Produktivstellung.

Siebzehn Befunde ohne Wahl — sie brauchen Arbeit, keine Entscheidung

Befund	Wo er hingehört
Das Altsystem signiert seine QR-Codes und prüft die Signatur nie — `publicExhibitsHandler` liest `sig` gar nicht erst aus.	`W-38`: Das Kennzeichen ist der Zugang; es gibt keine Signatur daneben, die jemand vergessen könnte. Geschlossen.
Unveröffentlichte und archivierte Exponate sind über die öffentliche Route abrufbar — `findById` filtert weder `status` noch `archivedAt`.	`W-03` (Sichtbarkeit vom Statuskatalog trennen) — noch offen, vermerkt in `docs/gegenbeweise-w38.md`.
Die öffentliche Audio-Route liefert das komplette Dokument ungefiltert (`res.json({ data: audioGuide })`, ohne Projektion).	Der Adapter prüft jede Antwort zur Laufzeit gegen ihr Vertragsschema (`P3-1`/`W-38`). Geschlossen.
Rohe Fremdmeldungen von Firebase Auth, Pub/Sub, Secret Manager und dem TTS-Anbieter gehen an den Client; Stacktraces nicht — das ist geprüft.	Jede Fehlerantwort entsteht in `fehlerAntwortBauen` und trägt nur `code`, `class`, `message`, `retryable`, `correlationId`, optional `fields`. Geschlossen.
Dasselbe Ereignis bekommt verschiedene Codes — rund 70 Codes an rund 284 Fundstellen, teils in derselben Datei; der `jobs-service` antwortet zudem mit `{ error: "Zeichenkette" }`.	Ein Fehlervertrag, ein Basiskatalog, Fachfehler mit eigenem Status (`P3-1`). Geschlossen — und der Grund, warum der neue Vertrag eine Form erzwingt.
Das monatliche Zugangsdaten-Backup legt alle Geheimwerte im Klartext in einem GCS-Bucket ab, ohne Prüfspur.	`P4-3` (Auftragsstrecke) und `P4-5` (Alarmierung) berühren es; ein eigener Punkt für die Sicherung fehlt noch.
Die „vollständige DSGVO-Kaskade“ lässt zwei Datenarten stehen: Auftragsprotokolle (`jobs`) und Auswertungsdaten (`analyticsEvents`).	`P4-1` — Löschkonzept je Datenart mit Frist, Lauf und Nachweis. Offen.
Die Altsystem-Inventur behauptet 151 Routen; nachgezählt sind es 127, eine tolerantere Lesart kommt auf 146. Die 151 steht auch in `CLAUDE.md` und `SESSION-START.md`.	Eigene Aufgabe: Nachzählen gegen den Altsystemcode. Bis dahin misst `scripts/routendeckung.mjs` gegen 127 und meldet die Abweichung als Warnung, ohne `verify` rot zu machen.
Die lokale Review-Reserve `qwen3.8-27b` ist unbrauchbar — llama.cpp antwortet mit `400`, das ausgelieferte Modell heisst `qwen3.8-27b-heretic` und trägt ein anderes Chat-Template.	Werkzeugkette in `~/ADMIN`, nicht Teil dieses Projekts. Umgangen: Grok (`NAHT_REVIEW_MODELL=grok`) als zweiter Kopf — anderer Harnisch, kostet pro Token.
Der Heatmap-Pin folgt nicht der gewählten Kennzahl — die Punktgrösse basiert im Prototyp immer auf der Wiedergabenzahl, nur die Blob-Farbe wechselt.	Darstellungsfehler des Prototyps, nicht als Datenmodell-Eigenschaft übernehmen. Selbst entschieden, weil es weder Vertrag noch Datenmodell ändert.
`plattform-panel.dc.html` ist nicht lauffähig — referenziert `./support.js` und ein `_ds/`-Bündel, die im Ordner fehlen.	Betrifft die Vorschau, nicht die Zusagen — die stehen in den Inventuren. Der Curator-Ordner ist vollständig.
Das Plattform-Panel hat keinen Bausteinvertrag — seine 21 CSS-Klassen sind klassenbasiertes Styling ohne Komponentenregistrierung, ein Teil davon Utilities.	Vor der ersten Plattform-Bildschirmkette zu klären: eigener Vertrag, Abbildung auf die Kuratoren-Bausteine, oder bewusst ohne. Aus `P3-3`.
Die `.jsx`-Quellen des Designsystems fehlen im Handover; nur ein kompiliertes Bündel liegt bei.	Der Vertrag bindet nur Belegtes. Aus dem Markup nicht zu gewinnen: nie gesetzte Props, die Form hinter `{{ ausdruck }}`-Werten, ob ein Container über `actions` interaktiv wird. Die Lücke wächst mit jeder Komponente.
Null Zusagen zu Fehler- und Leerfällen im gesamten Besucherbereich — kein „Exponat nicht gefunden“, kein „kein Audio vorhanden“, kein „Museum gesperrt“. Das Wort „offline“ kommt in der Abgleichdatei kein einziges Mal vor.	Querschnittsspur `P4-4` (Fehlerklassen), vor der ersten Besucherkette.
Vertrag gegen Persistenz wird nirgends gemessen — `P3-2` misst Vertrag gegen Setzweg. Ein Schemafeld ohne Vertrag sieht niemand; ein Vertragsfeld ohne Schema kann niemand speichern.	Eigene Prüfung, sinnvoll sobald das Schema über die drei Durchstichtabellen hinauswächst. Aus dem `P3-2`-Review, beide Köpfe.
`mandantAufloesen` erteilt heute `durchstich.read` an jeden, der den Kurznamen eines aktiven Mandanten kennt — ohne Ausweis, ohne Mitgliedschaft.	Bekannter Umfang dieses Stands (es gibt keine Anmeldung). Verschwindet mit `W-15`; `services/api/test/uebergangskontext.test.ts` wird dann ersatzlos gelöscht.
`AGENTIC_REWRITE_WORKFLOW.md` trägt „nicht freigegeben“ und ist trotzdem das einzige Dokument, das den Einsatz von Spec Kit beschreibt.	Der übernommene Teil steht in `P5-3` und `P5-4`. Zu klären, ob das Dokument freigegeben, auf den übernommenen Teil eingedampft oder als Referenz belassen wird — solange der Status steht, ist unklar, was von den übrigen 470 Zeilen gilt.

0 von 0 beantwortet