Guardianship: ward ziet z'n guardians, PWA-assets no-cache, handle-fix
De handshake commit werkte al aan beide kanten (geverifieerd live: sound-fabrics
ziet beta als ward, beta weet dat sound-fabrics guardian is), maar het TONEN
ontbrak op drie plekken. Dit lost de Klonkt-kant op.
- Ward-kant: in Berichten ziet een ward nu wie z'n guardians zijn (committed
relaties, FEP-633c §2). Die view bestond nog niet.
- other_handle bewaarde per ongeluk de FEP-escalatiehandle (candidate/inbox)
i.p.v. de @handle, dus overal waar we het toonden kwam een inbox-URL uit. Nu
de echte @handle uit de offer; display self-healt oude rijen door @user@host
uit de actor-URI af te leiden als de opgeslagen handle geen @ is.
- Guardian PWA-assets via /guardian/app.js|css met Cache-Control: no-cache, dus
een update wordt nooit meer gemaskeerd door de 1-jaar /assets-cache of een
vastgelopen install (dat was de "niks werkt na deploy"-bug). Client zit nu in
try/catch met een zichtbare foutbanner i.p.v. stil te hangen.
Changed files:
src/services/guardianship/handshake.js
- applyCommitLocally schrijft de @handle (offer.ward/candidate_handle) naar other_handle
src/routes/posts.js
- messages-route levert myGuardians (committed guardians met afgeleide @handle)
src/views/pages/messages.ejs
- "Jouw guardians"-sectie voor de ward
src/services/i18n.js
- msg.guardians_label (nl/en/de)
src/routes/guardian.js
- /guardian/app.js|css no-cache; ASSET_V-mtime-machinerie weg
src/assets/js/guardian.js
- hele client in try/catch met zichtbare foutbanner; handleOf vertrouwt alleen echte @handles
src/views/pages/guardian.ejs
- assets via no-cache routes i.p.v. /assets?v=
test/guardianship.test.js
- assert dat other_handle de @handle is na commit
remarks: getest met npm test (6/6). sound-fabrics (stable-lane, handmatig) bewust
niet aangeraakt; wacht op akkoord.
-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>