1 changed files with 1 additions and 1 deletions
@@ -90,7 +90,7 @@ Reste valable tel quel : la **lecture réactive**, le **ré-armement à la recon

 - **Scope de Participation** — elle devient **publique** alors que la doctrine produit actuelle la place en *protected* ([[knowledge_data-scopes-and-discovery]], concept `functional-domain`). Ce leaf décrit **ce qui est implémenté** : ne pas le modifier tant que ce brief n'a pas gradué, mais **le mettre à jour à ce moment-là**.
 - **Reconnaissance par les connexions** (étape 7) — comment le cap du profil est scellé, et ce qu'il advient d'une connexion rompue (la révocation est un re-key grossier et non rétroactif). Explicitement remis à un 2e temps.
- **Validation d'existence — IMPOSSIBLE, et c'est tranché** *(corrigé le 2026-07-27)*. On avait écrit que le créateur *pouvait* vérifier qu'un did pointe sur un objet réel sans clé. **Faux** : le contrôle d'accès en lecture laisse bien passer, mais **l'adressage présuppose le cap** — il n'existe aucune commande d'existence au niveau SDK, et une référence cap-less n'a ni les identifiants de blocs ni l'overlay nécessaires. Le créateur ajoute donc la référence **sur parole**. Conséquence assumée : le compteur est **déclaratif** et donc forgeable — hors périmètre sécurité, mais il ne faut **pas** présenter cette étape comme une validation.
+- **Lecture publique non récursive** — c'est le principe qui fait tenir tout le modèle, et il mérite d'être énoncé seul : *un élément du store **public** est public — qui a l'URL lit le contenu.* Mais **pas récursivement** : un contenu public peut **référencer** du contenu privé, et **c'est exactement notre cas**. Le créateur lit donc la Participation (publique) et **ne peut pas** suivre la référence vers le profil (protected). C'est ce qui donne à la fois la lecture par le créateur et l'anonymat vis-à-vis de lui — sans mécanisme supplémentaire.

 ## Dépendances