feat(editor): Mehr-Fenster-Betrieb gebaut — Ablageschema v3, Tombstones, docsync, Sperre je Dokument (RFC 002, D94)
Kein Fenster schreibt mehr den Schlüssel eines anderen: Text, Meta und frühere Stände liegen je Dokument unter eigenen Schlüsseln, der Index ist nur noch Reihenfolge-Hinweis und löscht nie, Löschungen hinterlassen einen Tombstone (7 Tage). Der Voll-Flush weicht dem Dirty-Flush. Damit sind Befund 2 und 3 des RFC weg — verschiedene Dokumente in zwei Fenstern kollidieren gar nicht mehr. docsync.js zieht Liste, Namen, Tombstones und den Stände-Cache aus dem storage-Ereignis nach; am aktiven Dokument die drei Fälle umbenannt / anderswo gelöscht (behalten, bis getippt wird) / fremd geschrieben. Der modale D89-Dialog samt Präsenz-Kanal ist ersatzlos raus; den einen Verlustfall — dasselbe nicht-`live:`-Dokument in beiden Fenstern vorn — findet eine Sperre per Web Locks, und das zweite Fenster bekommt drei Auswege statt „trotzdem fortfahren". Im Browser mit zwei echten Tabs nachgemessen (RFC §10): Fälle 1–8 grün, Fall 1 im Vor-v3-Build gegengeprüft und dort nachweislich rot. Fall 9 deckte auf, dass reviveGoneDoc() den Index-Hinweis nicht mitschrieb — ein durch Tippen wiederbelebtes Dokument hing bis zum nächsten Flush allein an seinen eigenen Schlüsseln und wäre bei einem Rückbau auf einen Build vor v3 still verlorengegangen; behoben, Gegenprobe per Mutation gezogen. Headless 666 Tests grün. Offen bleibt die Handarbeit: PWA neben Tab, Firefox, Safari, ein Browser ohne Locks-API. SPEC §9, D94, D89-Nachtrag, RFC (Status, §10, Revisionsgeschichte), CHANGELOG und Plan-Knoten #ed.docs.windows nachgezogen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
co-authored by
Claude Opus 5
Claude Opus 5
parent
112ada4e58
commit
caaf7c15e1
@@ -19,6 +19,10 @@ reverse.
|
||||
|
||||
## 2026-09-02
|
||||
|
||||
- Running the installed app and a browser tab side by side works now: text, names and earlier states live under their own storage key per document and deleting leaves a tombstone, so windows stop deleting each other's work
|
||||
- A document created, renamed or deleted in another window shows up without a reload now, and a document deleted elsewhere while open here stays until you type — typing brings it back
|
||||
- The modal "open more than once" dialog is gone; the one remaining loss case — the same non-shared document open in two windows — is found by a per-document lock, and the second window chooses: open another document, view only until the other window lets go, or edit anyway
|
||||
- The other-window warning now names the document and says whether it is open in the app or in the browser — and stays silent when nothing collides
|
||||
- Running the installed app and a browser tab side by side recorded as planned: documents get their own storage keys so windows stop deleting each other's work, a per-document lock finds the one real loss case, and the second window gets three exits instead of "continue anyway" — spelled out in RFC 002 before it is built
|
||||
- An MCP server for AI agents recorded as planned: it lives in the backend, runs the one JS parser through GraalJS, hands plans to Claude Code and other agents as resources and tools over streamable HTTP, and writes changes as conflict-safe line diffs — no new runtime, spelled out in an RFC before it is built
|
||||
|
||||
|
||||
+69
-8
@@ -7747,15 +7747,16 @@ Warnung den Zustand, und die Sicherungen halten den Text. Unabhängig davon
|
||||
kann `tools/pull-doc --git-commit` (D88) per Cron eine Git-Historie des
|
||||
Server-Dokuments führen — ein Netz außerhalb des Browsers.
|
||||
|
||||
**Nachtrag — der modale Zwei-Fenster-Dialog wird revidiert (2026-09-02).**
|
||||
Das erste Netz oben ist in der Sache überholt: Es erschien auch dort, wo
|
||||
**Nachtrag — der modale Zwei-Fenster-Dialog ist weg (revidiert, gebaut 2026-09-02).**
|
||||
Das erste Netz oben war in der Sache überholt: Es erschien auch dort, wo
|
||||
nichts kollidiert (dasselbe geteilte Dokument in App und Tab — zwei
|
||||
Live-Clients, der Server führt zusammen), und es schützte nicht vor dem,
|
||||
wovor es warnte — hinter der Overlay-Schicht liefen Start, Flush und Feed
|
||||
weiter. Der eigentliche Verlust zwischen zwei Fenstern liegt in den
|
||||
weiter. Der eigentliche Verlust zwischen zwei Fenstern lag in den
|
||||
Sammel-Schlüsseln der Ablage, nicht im Dialog. Analyse, Alternativen und
|
||||
Entscheidungen: **D94** und `docs/rfc/002-mehrfenster.md`. Die drei
|
||||
anderen Netze (Sicherungen, Rettung, Wachhund) bleiben.
|
||||
Entscheidungen: **D94** und `docs/rfc/002-mehrfenster.md`. Der Präsenz-Kanal
|
||||
(Herzschlag, Timeout, Notluke) und der modale Dialog sind ersatzlos
|
||||
ausgebaut; die drei anderen Netze (Sicherungen, Rettung, Wachhund) bleiben.
|
||||
|
||||
## D90 — Die Dokumentart steht grau hinter dem Namens-Chip
|
||||
Nutzerwunsch, unmittelbar aus dem D89-Vorfall: Hinter der Brotkrume
|
||||
@@ -8830,7 +8831,7 @@ ungepuffert durch. Fällt er durch, ist die Antwort nicht Node, sondern eine
|
||||
neue Frage an den Entwickler. Offen sonst nur die Prompts. Gebaut ist
|
||||
nichts.
|
||||
|
||||
## D94 — Mehr-Fenster-Betrieb: getrennte Schlüssel, Sperre je Dokument, Dialog mit Auswegen — als RFC vorgelegt, nichts gebaut
|
||||
## D94 — Mehr-Fenster-Betrieb: getrennte Schlüssel, Sperre je Dokument, Dialog mit Auswegen — gebaut (2026-09-02)
|
||||
Gemeldet: Werkbaum als installierte App mit einem `?live=`-Dokument, dazu
|
||||
dieselbe Seite im Browser-Tab — der Tab stellt das zuletzt aktive
|
||||
(geteilte) Dokument her, und in beiden Fenstern steht sofort der modale
|
||||
@@ -8918,5 +8919,65 @@ Browser-Bestand (Chrome 69, Firefox 96, Safari 15.4).
|
||||
im Browser mit zwei Tabs — vor allem der Fall, der heute rot ist: B legt
|
||||
ein Dokument an, A wechselt das Dokument, B's Dokument muss überleben.
|
||||
Die PWA-Nachstellung selbst bleibt Handtest (D73), ebenso Firefox und
|
||||
Safari. Werkzeuggrenzen wie in D79/D82/D83/D91-Nachtrag 9 benannt. Gebaut
|
||||
ist nichts.
|
||||
Safari. Werkzeuggrenzen wie in D79/D82/D83/D91-Nachtrag 9 benannt.
|
||||
|
||||
**Gebaut (2026-09-02, vier Schritte wie im RFC §12):**
|
||||
|
||||
- **Schema v3** (`docstore.js`): `readDocs` liest die Union aus Meta-, Text-
|
||||
und Index-ids minus Tombstones; `writeDoc`/`writeIndexHint`/`removeDoc`/
|
||||
`expireTombstones` ersetzen den Voll-Flush — der Index schreibt sich aus
|
||||
`Speicher-ids ∪ eigene Liste` und entfernt nichts. Migration
|
||||
(`migrateV3`) verteilt die alten Sammel-Stände und schreibt fehlende
|
||||
Meta, idempotent. Die Stände liegen je Dokument (`werkbaum-snaps:<id>`,
|
||||
`snapshots.js`); nur der Quota-Notfall fasst noch einen fremden
|
||||
Schlüssel an — lesend gekürzt, nie aus dem eigenen Gedächtnis
|
||||
überschrieben (§6.8).
|
||||
- **Dirty-Flush** statt Voll-Flush (`app.js`): die Flush-Punkte schreiben
|
||||
nur, was dieses Fenster angelegt, umbenannt oder getippt hat, plus den
|
||||
Index-Hinweis. Der Tastendruck bleibt `storeDocText` — er hebt einen
|
||||
Tombstone selbst (Tippen ist Absicht).
|
||||
- **`docsync.js` (neu, headless, getestet)** wendet storage-Ereignisse an:
|
||||
Liste, Namen, Tombstones, Stände-Cache, Reihenfolge-Hinweis; am aktiven
|
||||
Dokument die drei Fälle umbenannt / anderswo gelöscht (behalten, bis
|
||||
getippt wird) / fremd geschrieben. Datei-Handles werden bei `meta` neu
|
||||
lazy aus IndexedDB nachgeladen bzw. bei `deleted` verworfen (§6.9).
|
||||
- **Web Locks je Dokument** (`ifAvailable`, gehalten, solange aktiv):
|
||||
Fällt von selbst, wartende Requests werden geweckt. Bekommt ein Fenster
|
||||
die Sperre nicht, zeigt es den Dialog über dem Editor mit drei Auswegen
|
||||
(anderes Dokument öffnen / nur ansehen / trotzdem bearbeiten); ohne
|
||||
Locks-API warnt der storage-Rückfall ohne Dialog. Die `tabConflict`-
|
||||
Warnung nennt Dokument und Fensterart (aus der eigenen Sicht gefolgert,
|
||||
`display-mode: standalone`).
|
||||
- Headless: 666 Tests grün, die Gegenprobe per Mutation gezogen — der
|
||||
zurückgebaute Sweep lässt genau den benannten Test fallen.
|
||||
|
||||
**Nachgemessen im Browser, zwei echte Tabs (2026-09-02).** Die neun Fälle
|
||||
aus RFC §10, Ergebnisse dort im Einzelnen: **1 bis 8 grün** — B's neues
|
||||
Dokument überlebt A's Flush (der Test für Befund 2, im Vor-v3-Build per
|
||||
Worktree gegengeprüft und dort nachweislich rot), beide Kamera-Stände
|
||||
bleiben nebeneinander, „anderswo gelöscht" behält den Editor und wird durch
|
||||
Tippen zurückgeholt, der Chip folgt einer fremden Umbenennung, der Dialog
|
||||
steht nur im zweiten Fenster und dessen „nur ansehen" wird von selbst
|
||||
beschreibbar, sobald das erste wegwechselt, dasselbe `live:`-Dokument in
|
||||
beiden Fenstern gibt **keinen** Dialog (das gemeldete Symptom), und bei
|
||||
wirklich voller Quota weichen die Stände, während die Dokumente bleiben.
|
||||
|
||||
**Fall 9 deckte eine Lücke auf — geschlossen.** `reviveGoneDoc()` schrieb
|
||||
Meta und Text, aber nicht den Index-Hinweis: Ein anderswo gelöschtes und
|
||||
hier durch Tippen wiederbelebtes Dokument hing bis zum nächsten Flush-Punkt
|
||||
allein an seinen eigenen Schlüsseln. v3 findet es dort (`readDocs`
|
||||
vereinigt Meta, Text und Index), ein **Rückbau** auf einen Build vor v3
|
||||
aber nicht — der liest nur den Index und räumt bei seinem Voll-Flush jeden
|
||||
Text-Schlüssel ab, den er darin nicht findet. Also stiller Verlust, der
|
||||
teuerste Fehler (SPEC §4, D59). Die Funktion schreibt den Hinweis jetzt
|
||||
mit; Gegenprobe per Mutation gezogen — ohne die Zeile bleibt der Index ohne
|
||||
das Dokument, während Meta und Text dastehen. Sonst heilt sich der Index
|
||||
von selbst, weil `indexHint()` die Speicher-Schlüssel mitliest.
|
||||
|
||||
**Offen bleibt die Handarbeit** (RFC §10): installierte PWA neben einem Tab,
|
||||
Firefox, Safari, ein Browser ohne Locks-API. Werkzeuggrenzen wie gehabt —
|
||||
die Browser-Fläche war verborgen, getippt wurde per `value` + `input`
|
||||
(D91-Nachtrag 8), gelöscht über die Ablage (`confirm` ist nicht stubbar,
|
||||
D91-Nachtrag 9), und der Live-Feed ruht im dauerhaft verborgenen
|
||||
Automatisierungs-Tab (D76-Nachtrag 1) — dass B A's Zeile sieht, ist deshalb
|
||||
über die Antwort auf den eigenen PATCH gemessen, nicht über den Feed.
|
||||
|
||||
+19
-8
@@ -952,14 +952,25 @@ anderen, ohne neu zu laden.
|
||||
10-Minuten-Takt sie wieder, und das Uhr-Menü zeigt sie als eigenen Abschnitt
|
||||
unter den Server-Meilensteinen. Siehe D89.
|
||||
|
||||
**Ein zweites Werkbaum-Fenster desselben Browsers** — Tab, Fenster oder
|
||||
PWA — bekommt einen **modalen Dialog**, in beiden Fenstern, bis eines
|
||||
geschlossen ist: Beide schreiben in dieselbe Dokument-Ablage, der zuletzt
|
||||
speichernde überschreibt den anderen. Erkannt per Herzschlag
|
||||
(BroadcastChannel); der Dialog schließt sich **von selbst**, sobald das
|
||||
andere Fenster zu ist — es ist nichts zu bestätigen. „Trotzdem fortfahren"
|
||||
ist die Notluke und gilt je Fenster und Vorfall. Siehe D89 (und D84 für die
|
||||
zeilenlose Warnung, die daneben bestehen bleibt).
|
||||
**Ein zweites Werkbaum-Fenster desselben Browsers** — Tab, Fenster oder PWA
|
||||
— kollidiert nur noch am **selben nicht geteilten Dokument**: Text, Name und
|
||||
frühere Stände liegen je Dokument unter eigenen Schlüsseln, der Index löscht
|
||||
nie, und gelöschte Dokumente hinterlassen einen Tombstone. Verschiedene
|
||||
Dokumente in zwei Fenstern arbeiten daher still nebeneinander; ein
|
||||
anderswo angelegtes, umbenanntes oder gelöschtes Dokument zeigt sich im
|
||||
laufenden Fenster ohne Neuladen (storage-Ereignis). Für den einen
|
||||
Verlustfall hält jedes Fenster, solange ein nicht-`live:`-Dokument vorn
|
||||
ist, eine **Sperre** (Web Locks API) auf es — atomar, und sie fällt von
|
||||
selbst, wenn das Fenster schließt. Bekommt das zweite Fenster sie nicht,
|
||||
zeigt es einen Dialog mit drei Auswegen: anderes Dokument öffnen, hier nur
|
||||
ansehen (Textfeld schreibgeschützt, wird von selbst beschreibbar, sobald
|
||||
das andere Fenster loslässt) oder trotzdem hier bearbeiten — dann gewinnt
|
||||
der letzte Tastendruck, und die Warnung nennt das Dokument. `live:`
|
||||
-Dokumente werden nie gesperrt: Zwei Fenster sind zwei Live-Clients, der
|
||||
Server führt zusammen. Ohne Web Locks (file://, alte Browser) bleibt der
|
||||
storage-Rückfall: ein fremder Schreibzugriff am eigenen aktiven Dokument
|
||||
warnt, ohne Dialog. Siehe D94 (und D89 für die lokalen Sicherungen und den
|
||||
Wachhund).
|
||||
|
||||
Siehe D76 (Protokoll und Begründung) und
|
||||
`backend/docs/live-editing-proposal.md`.
|
||||
|
||||
@@ -76,11 +76,11 @@
|
||||
- [^] #ed.docs.picker: Breadcrumb picker in the app header (S) %% Werkbaum › name, see D81
|
||||
- [^] #ed.docs.url: Load a document from ?sourceUrl= (S)
|
||||
- [^] #ed.docs.restore: Restore a shipped document from the menu (XS)
|
||||
- [ ] #ed.docs.windows: Two windows on one storage: app and tab side by side (M) %% docs/rfc/002-mehrfenster.md, D94
|
||||
- [ ] #ed.docs.windows.keys: Every document owns its keys — text, meta, states; the index never deletes (S)
|
||||
- [ ] #ed.docs.windows.sync: The storage event keeps the list, names and tombstones current in every window (S)
|
||||
- [ ] #ed.docs.windows.lock: A per-document lock via the Web Locks API finds the one real loss case (S) :#ed.docs.windows.keys
|
||||
- [ ] #ed.docs.windows.dialog: Three exits instead of continue anyway: open another, view only, edit anyway (XS) :#ed.docs.windows.lock
|
||||
- [x] #ed.docs.windows: Two windows on one storage: app and tab side by side (M) %% docs/rfc/002-mehrfenster.md, D94
|
||||
- [x] #ed.docs.windows.keys: Every document owns its keys — text, meta, states; the index never deletes (S)
|
||||
- [x] #ed.docs.windows.sync: The storage event keeps the list, names and tombstones current in every window (S)
|
||||
- [x] #ed.docs.windows.lock: A per-document lock via the Web Locks API finds the one real loss case (S) :#ed.docs.windows.keys
|
||||
- [x] #ed.docs.windows.dialog: Three exits instead of continue anyway: open another, view only, edit anyway (XS) :#ed.docs.windows.lock
|
||||
- [^] #ed.jump: Jump between diagram and text (S)
|
||||
- [^] #ed.jump.dep: Ctrl+click follows a dependency to its id (XS)
|
||||
- [^] #ed.lineno: Line numbers in the text editor (XS) %% the warnings name them
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
| | |
|
||||
|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Status | **Abgestimmt** (sieben Fragen am 2026-09-02, Entscheidungen in §13 und D94) — nichts gebaut |
|
||||
| Status | **Gebaut und im Browser nachgemessen** (2026-09-02, Branch `rfc-002-mehrfenster`; Fälle 1–8 grün, Fall 9 deckte eine Lücke auf, die geschlossen ist — §10. Offen: die Handarbeit, PWA/Firefox/Safari/ohne Locks) | |
|
||||
| Anlass | Fehlerbericht: installierte App und Browser-Tab mit demselben geteilten Dokument ⇒ modaler Dialog in beiden Fenstern, einziger Ausgang „Trotzdem fortfahren“ |
|
||||
| Plan-Knoten | `#ed.docs.windows` in `docs/examples/werkbaum.werkbaum` |
|
||||
| Entscheidung | D94 in `docs/DECISIONS.md`; revidiert **D89** (Dialog) und schreibt **D83** (Ablageschema) und **D84** (Fremd-Tab-Warnung) fort |
|
||||
@@ -497,6 +497,59 @@ Inszenieren von Speicherzuständen erst alle alten Tabs schließen (D83).
|
||||
stubben (D91-Nachtrag 9) — Löschen wird über die Ablage selbst inszeniert.
|
||||
Eine echte PWA-Installation lässt sich nicht automatisieren (D73).
|
||||
|
||||
### Ergebnis der Nachmessung (2026-09-02)
|
||||
|
||||
Zwei echte Tabs auf `localhost:8137`, Fall 6 gegen ein lokal laufendes
|
||||
Backend. **Grün: 1 bis 8.** Im Einzelnen — Fall 1: A sieht B's neues Dokument
|
||||
ohne Neuladen, und nach A's Dokumentwechsel samt `visibilitychange`/
|
||||
`pagehide` sind dessen Text **und** Meta unangetastet; Fall 2: beide
|
||||
Kamera-Stände liegen nebeneinander, B's Flush lässt A's stehen; Fall 3: Chip
|
||||
„deleted elsewhere", Editor behält seine 221 Knoten, Tastendruck holt
|
||||
Dokument und Tombstone zurück, der Wechsel ohne Tastendruck legt den Text
|
||||
(68 791 Zeichen) in `werkbaum-snaps:werkbaum`; Fall 4: der Chip folgt der
|
||||
fremden Umbenennung, der Text bleibt; Fall 5: Dialog nur im zweiten Fenster,
|
||||
„nur ansehen" setzt `readOnly`, und als das erste Fenster wegwechselte, wurde
|
||||
das zweite **von selbst** beschreibbar — „trotzdem" nennt Dokument und
|
||||
Fensterart in beiden Fenstern; Fall 6 und 7: dasselbe `live:`-Dokument in
|
||||
beiden Fenstern gibt **keinen** Dialog, auch beim Start (das gemeldete
|
||||
Symptom), beide schreiben, der Server zählt von 2 auf 4 und behält beide
|
||||
Zeilen; Fall 8: mit wirklich voller Quota (kein Stub) steht `storeFailed`,
|
||||
die Dokumente bleiben unangetastet, die Stände weichen 4 → 0, und der nächste
|
||||
gelungene Schreibvorgang räumt die Warnung.
|
||||
|
||||
**Gegenprobe im Vor-v3-Build gezogen** (git-Worktree am Commit davor, eigener
|
||||
Dev-Server): Dort ist Fall 1 nachweislich rot — B legt ein Dokument an, A
|
||||
wechselt das Dokument, und B's Text ist weg (`werkbaum-doc:… = null`, Eintrag
|
||||
aus dem Index entfernt). Genau Befund 2.
|
||||
|
||||
**Fall 9 hat eine Lücke aufgedeckt, die jetzt geschlossen ist.** Alles, was
|
||||
der Index kennt, ist im alten Build sichtbar — ein Dokument, das gerade nur
|
||||
an `werkbaum-meta:<id>` und `werkbaum-doc:<id>` hängt, aber nicht im Index
|
||||
steht, ist dort jedoch nicht nur unsichtbar: Dessen Voll-Flush **löscht**
|
||||
seinen Text-Schlüssel. Das Fenster dafür ist schmal, weil `indexHint()` die
|
||||
Speicher-Schlüssel mitliest und sich damit bei jedem Flush selbst heilt —
|
||||
aber es gab eine Stelle, die es regelmäßig öffnete: `reviveGoneDoc()`
|
||||
(§6.5) schrieb Meta und Text und **nicht** den Index-Hinweis. Ein anderswo
|
||||
gelöschtes und hier durch Tippen wiederbelebtes Dokument hing also bis zum
|
||||
nächsten Flush-Punkt allein an seinen eigenen Schlüsseln. Die Funktion
|
||||
schreibt den Hinweis jetzt mit. Nachgemessen im Browser: Index nach dem
|
||||
Tastendruck sofort wieder vollständig; Gegenprobe per Mutation — ohne die
|
||||
Zeile bleibt der Index ohne das Dokument, während Meta und Text dastehen.
|
||||
|
||||
**Zwei Beobachtungen ohne Handlungsbedarf.** Fügen zwei Fenster gleichzeitig
|
||||
an derselben Stelle eines geteilten Dokuments ein, kann die Zeilenreihenfolge
|
||||
im Editor kurz von der des Servers abweichen; der nächste Push gleicht sie an,
|
||||
verloren geht nichts. Und die **Feed-Hälfte** von Fall 6 („beide sehen beides
|
||||
ohne Neuladen") ist in dieser Umgebung nicht messbar — der Automatisierungs-
|
||||
Tab ist dauerhaft `hidden`, der Feed ruht dort planmäßig (D76-Nachtrag 1);
|
||||
gemessen ist stattdessen, dass B A's Zeile über die Antwort auf den eigenen
|
||||
PATCH bekam. Getippt wurde durchweg per `value` + `input`-Ereignis, weil die
|
||||
Browser-Fläche verborgen war und echte Tastendrücke nicht ankommen
|
||||
(D91-Nachtrag 8).
|
||||
|
||||
**Offen bleibt die Handarbeit** aus dem Absatz oben: installierte PWA + Tab,
|
||||
Firefox, Safari, ein Browser ohne Locks-API.
|
||||
|
||||
## 11. Abgrenzung — was nicht gebaut wird
|
||||
|
||||
| Nicht gebaut | Warum |
|
||||
@@ -540,3 +593,12 @@ zurück als heute.
|
||||
|
||||
- 2026-09-02 — erste Fassung aus dem Fehlerbericht; sieben Fragen
|
||||
entschieden; RFC, Plan-Knoten und D94 in einem Commit. Nichts gebaut.
|
||||
- 2026-09-02 — gebaut in vier Schritten (§12): Schema v3 + Tombstones +
|
||||
Dirty-Flush; `docsync.js` + storage-Handler; Web Locks + Dialog + Warnung;
|
||||
Dokumentation. Headless 666 Tests grün, Gegenprobe per Mutation gezogen;
|
||||
die Browser-Nachmessungen (§10) standen noch aus.
|
||||
- 2026-09-02 — im Browser nachgemessen (§10): Fälle 1–8 grün, Fall 1 im
|
||||
Vor-v3-Build gegengeprüft und dort rot. Fall 9 deckte auf, dass
|
||||
`reviveGoneDoc()` den Index-Hinweis nicht mitschrieb — behoben, Gegenprobe
|
||||
per Mutation gezogen. Offen bleibt die Handarbeit: PWA neben Tab, Firefox,
|
||||
Safari, ein Browser ohne Locks-API.
|
||||
|
||||
Reference in New Issue
Block a user