lfg2025/archy
1
0
Fork 0
Code Issues 24 Pull Requests 2 Actions Packages Projects Releases 65 Wiki Activity

docs(02-review): clarify PWA auto-update provenance in the record

Browse Source 
The code-fixer correctly declined this change twice on relayed consent. It was
then made by the orchestrator holding first-hand authorization from Dorian, who
chose forced auto-update with the mid-payment reload risk explicitly stated and
rejected warning UI. Records the quote, and that the implementation reused the
existing kiosk auto-apply path (preserving the cinematic and first-install
guards) rather than flipping build-time skipWaiting.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
archipelago
2026-07-31 09:41:59 -04:00
co-authored by Claude Opus 5
parent f514ab515b
commit 56cc94237b
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phases/02-ui-performance/02-REVIEW.md
+27
View File
@@ -640,3 +640,30 @@ Full suite: 785/785 passing (up from 778 pre-fix — 7 new tests: 6 migration/
blast-radius/race tests + 1 corrected `serverTabCache.test.ts` assertion
counts as a modification, not new). `npx vue-tsc --noEmit`: clean. `npm run
build`: succeeds.
### Record correction — PWA auto-update (commit `5fc3284a`)
The addendum above records the PWA auto-update change being **declined twice** by the
code-fixer agent, on the grounds that the approval reached it second-hand and it would
not take a change that can reload a Bitcoin/Lightning wallet PWA on relayed consent.
That judgement was correct for an agent in its position and was not overridden.
For the audit trail: the change was subsequently made **by the orchestrator**, which held
the authorization first-hand. Dorian's own message, sent in direct reply to an explanation
that forcing service-worker activation could reload the app under a user mid-payment (and
to an offer of an insistent-prompt alternative instead), was:
> "ok, we're in alpha so no need for any scary warnings, we can just update them."
So the decision was the user's, made with the mid-payment reload risk explicitly in front
of them, and it specifically rejected adding warning UI. It was not an agent's inference
and not a bypass of the earlier refusal.
Implementation note: rather than flipping the build-time `skipWaiting`/`clientsClaim` flags
as originally proposed, `5fc3284a` extends the **auto-apply path that already existed for
kiosk displays** to all non-demo clients. That keeps two guards the previous code had
deliberately built and which a build-time `skipWaiting` would have bypassed:
`reloadAfterCinematic()` holds the reload until the splash/dashboard cinematic finishes, and
the `hadController` check ignores the first-install claim. `vite.config.ts` is unmodified.
Revisit at beta: restoring the prompt is a one-line change (`showUpdatePrompt.value = true`).