Reconnexion/festipod
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(concept): la validation d'existence est IMPOSSIBLE, pas optionnelle

Browse Source 
Le brief inscriptions disait que le créateur pouvait vérifier qu'un did pointe
sur un objet réel sans détenir la clé, et rangeait ça en durcissement optionnel.
Faux : le contrôle d'accès en lecture laisse bien passer, mais l'ADRESSAGE
présuppose le cap — 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.

Conséquence assumée, écrite noir sur blanc : le créateur ajoute la référence SUR
PAROLE, donc le compteur est déclaratif et forgeable. Hors périmètre sécurité,
mais cette étape ne doit pas être présentée comme une validation.

Le modèle lui-même n'en dépendait pas — il était déjà noté comme non requis.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg
This commit is contained in:
Sylvain Duchesne
2026-07-27 16:08:15 +02:00
parent 96e28a702f
commit e2adfacb0b
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.project/concepts/data-layer/brief_2026-07-20_attendance-set-model.md
+1 -1
View File
@@ -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** — le créateur *peut* vérifier qu'un did pointe sur un objet réel sans clé (protocole `Ext`). **Pas requis** ; durcissement optionnel, et à ne pas rendre load-bearing : la garde correspondante n'est pas branchée côté NextGraph et pourrait l'être un jour.
- **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.
## Dépendances