From ceb0653415c28be4514dafa221b694470e4f1b6d Mon Sep 17 00:00:00 2001 From: 4gray Date: Sun, 27 Sep 2026 15:36:57 +0200 Subject: [PATCH] docs(parental-lock): record the accepted restart case of a failed rollback write Co-Authored-By: Claude Opus 5.5 --- docs/architecture/parental-lock.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/architecture/parental-lock.md b/docs/architecture/parental-lock.md index df651bae2..1b8e33209 100644 --- a/docs/architecture/parental-lock.md +++ b/docs/architecture/parental-lock.md @@ -425,7 +425,11 @@ by the index alone: marked stale and re-stamped on the next store access. A failed rollback WRITE still puts memory back to the previous locks and leaves a pending rewrite: the next store access persists them before it re-stamps, so the - failed edit cannot take effect through that re-stamp. For the whole + failed edit cannot take effect through that re-stamp. The pending rewrite + lives in memory: if the app exits before it lands, the next launch loads + the persisted copy, i.e. the edit the parent submitted with the PIN. That + is accepted — it is not a bypass, and a durable rollback journal would + hit the same storage failure. For the whole re-stamp window — store changed, stamps not yet landed — the playlist counts as stale, so `readable` is false and a relock inside the window reloads fail-closed instead of through the old stamps. Such in-flight