docs: se connecter restaure ce qu'on possède, et un dépôt fautif ne verrouille personne

Deux affirmations à corriger, toutes deux écrites par moi et démenties par le bug d'aujourd'hui. La feuille disait que se connecter « restaure ce qui vous a été partagé ». C'est la moitié : le portefeuille garde vos propres clés ailleurs, et ne rejouer que le registre des partages refusait à une application son PROPRE document après un rechargement. La règle qui reste : rejouer TOUS les registres durables, pas celui qui se trouve sur le chemin qu'on teste. Et la règle « tout échec remonte » était trop grossière. Elle était juste pour la restauration ; appliquée à chaque étape, elle verrouillait. Un dépôt inapplicable n'est pas consommé par son échec, donc il refusait la session à chaque tentative — une personne qui ne peut plus entrer, là où il n'y avait qu'un partage manquant. La distinction consignée : ATTEINDRE les files et restaurer sont de l'infrastructure, et refuser la session y est juste ; APPLIQUER un élément est de la donnée, et ça se signale sans priver personne de sa session. Plus la forme générale, parce qu'elle se reproduira : devant un « tout échec remonte », demander lesquels se rattrapent en réessayant plus tard et lesquels sont définitifs pour l'acteur. Les définitifs ne doivent jamais garder une porte qu'il n'a pas d'autre moyen de franchir.
2026-08-16 17:58:25 +02:00
parent f6d1734679
commit a33fb8a214
4 changed files with 13 additions and 25 deletions
@@ -1,7 +0,0 @@
-# Doc-debt — app-contract
-
-> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
-> One block = one "big change": `why` + `files` + `verify` (leaves to review).
-
-## Raw markers (consolidate into blocks, then delete)
- TOUCHED packages/polyfill/src/surface/inbox.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
@@ -1,8 +0,0 @@
-# Doc-debt — e2e-harness
-
-> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
-> One block = one "big change": `why` + `files` + `verify` (leaves to review).
-
-## Raw markers (consolidate into blocks, then delete)
- TOUCHED packages/polyfill/e2e/harness-page.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/e2e/notebook.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
@@ -1,9 +0,0 @@
-# Doc-debt — sign-in
-
-> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
-> One block = one "big change": `why` + `files` + `verify` (leaves to review).
-
-## Raw markers (consolidate into blocks, then delete)
- TOUCHED packages/polyfill/src/shared-wallet/account-registry.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/src/shared-wallet/bootstrap.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/src/emulated-verifier/connect.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
@@ -8,7 +8,9 @@ summary: Deciding which identity acts needs no session; connecting does — conf
 Two acts of different nature hide behind "sign in":

 - **`settle`** — decide which identity is acting, from the URL, from storage, or by asking at the `barrier`, then persist it. Pure DOM and storage. **No session required.**
- **connect** — restore what was shared with that identity and drain its inbox. **Requires a live session.**
+- **connect** — put back in that identity's hands everything it can already open: what it OWNS as well as what was shared with it, then drain its queues. **Requires a live session.**
+
+The wallet keeps those two in different places, and connecting once replayed only the second — so an application that reloaded and went straight to a document it had made itself was refused its own document. Whatever else changes here, connecting must replay **every** durable register, not the one that happens to be read on the path being tested.

 They must stay apart, and the reason is not tidiness.

@@ -37,3 +39,13 @@ Hence the shape of the fix — recording who acts and starting to connect are se
 ## The lesson worth keeping

 A "session-free" half that calls something which fires a session lookup is not session-free. When splitting on a dependency, check what the *side effects* of each remaining call reach, not only what the call itself does.
+
+## Failing to reach a queue is not failing to apply one item in it
+
+Making connection failures surface was right — a restore that did not happen makes shared documents silently invisible, and resolving as though it had is the defect family this project keeps finding. But applied to *every* step alike, that rule locked people out.
+
+A deposit that cannot be applied is not consumed by failing. So a single unusable item denied the session, and denied it again at every future connection: not a missing share, a person who can never sign in. Strictly worse than the silence it replaced.
+
+The distinction to keep: **reaching** the queues, and the restore itself, are infrastructure — if they fail, the session genuinely cannot proceed, and rejecting is right. **Applying one item** is data — it must be reported loudly, the remaining queues must still be drained, and the session must still be granted.
+
+The general shape, worth carrying to any similar rule: when a blanket "every failure surfaces" is imposed, ask which failures are *retried by simply trying again later* and which are *permanent for the actor*. The permanent ones must never gate something the actor cannot otherwise obtain.