chore: scrub simulation vocabulary from app comments + settle doc-debt
Enforce the boundary in code-comments and doctrine (adversarial-review cleanup): - App comments in the data plane no longer narrate the SDK's internals: "emulated curator"→"the inbox read", "fan-out"→"discovered", removed store-placement reasoning and "polyfill/shim/mono-store" wording (FestipodDataContext, registration, storeRegistry, ngSession, AccountContext, isolation, sharedWallet, AccessGateScreen). Executable logic unchanged. - Removed dangling references to the dissolved `nextgraph-platform` concept and `brief_2026-06-15_shared-wallet-shim` from app code. - knowledge_nextgraph-stack: dropped "mécanique d'émulation" from the boundary note. - Settled and deleted all concept _debt.md (confirmatory; target leaves clean). (Test-infra under workshop/ + generated features.ts still carry some simulation vocabulary — parked as a separate below-SDK decision.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,14 +0,0 @@
|
||||
# Doc-debt — app-architecture
|
||||
|
||||
> 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).
|
||||
|
||||
## Block: T03.g — routage par scope (pas de changement d'archi)
|
||||
- **why**: FestipodDataContext route les entités par scope via le SDK et NextGraphContext ne surface plus les store-ids. La structure (provider stack, invariant d'imports module→shared, app shell) est inchangée — touches incidentes, pas d'évolution architecturale.
|
||||
- **files**: src/shared/context/NextGraphContext.tsx, src/shared/context/FestipodDataContext.tsx
|
||||
- **verify (leaves à relire)**: aucune — knowledge_app-shell.md / knowledge_module-structure.md inchangés. Bloc à supprimer après relecture confirmatoire.
|
||||
|
||||
## Block: T03.b — AccountContext déclare l'identité courante au SDK
|
||||
- **why**: `AccountProvider` appelle désormais `setCurrentUser(normalizeUsername(username))` au login / au changement de compte (effet sur `username`) — appel d'IDENTITÉ SDK, pas une règle d'accès applicative. Structure (provider stack, invariant d'imports) inchangée : touche incidente sur le glue React.
|
||||
- **files**: src/shared/context/AccountContext.tsx
|
||||
- **verify (leaves à relire)**: aucune — knowledge_app-shell.md inchangé. Bloc à supprimer après relecture confirmatoire.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Doc-debt — app-security
|
||||
|
||||
> 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).
|
||||
|
||||
## Block: T03.g — NextGraphContext ne surface plus les store-ids
|
||||
- **why**: `NextGraphContext` ne journalise/expose plus les trois store-ids dans le contexte app (routés uniquement au point d'injection SDK). Renforce la doctrine "isolation déléguée au SDK, l'app ne manipule pas de store physique" — ne l'invalide pas.
|
||||
- **files**: src/shared/context/NextGraphContext.tsx
|
||||
- **verify (leaves à relire)**: knowledge_trust-model.md (confirmer : confiance dans le SDK, aucune manipulation de store côté app). Aucun changement de contenu attendu — relecture confirmatoire.
|
||||
|
||||
## Block: T03.b — isolation ACTIVE (identité courante + acte de partage des connexions)
|
||||
- **why**: L'app déclare désormais au SDK (a) l'IDENTITÉ courante au login (`AccountContext` → `setCurrentUser`) et (b) son graphe de CONNEXIONS (`FestipodDataContext` → `declareConnections` sur les friendships) — les deux actes DOMAINE qui rendent le filtre du SDK discriminant (private→propriétaire, protected→propriétaire+connexions, public→tous). L'app ne porte toujours AUCUNE règle d'accès elle-même ; elle affiche ce que le SDK laisse passer. Renforce knowledge_trust-model — ne l'invalide pas (l'app fournit juste au SDK le « qui lit » + « qui est connecté à qui » qui manquaient pour que la délégation soit effective). Write-guard : best-effort (chemins d'écriture réels passent par le vrai `ng`, non gardés) — couverture documentée côté lib (docs/simulation.md), PAS dans Festipod.
|
||||
- **files**: src/shared/context/AccountContext.tsx, src/shared/context/FestipodDataContext.tsx
|
||||
- **verify (leaves à relire)**: knowledge_trust-model.md — confirmer « isolation déléguée au SDK, aucune logique d'autorisation côté écran/contexte ». Nuance à vérifier : le contexte fournit maintenant identité + connexions au SDK (ce n'est pas un filtre applicatif, c'est le câblage domaine→SDK). Relecture confirmatoire.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Doc-debt — bdd-testing
|
||||
|
||||
> 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).
|
||||
|
||||
## Block: T03.b — scénario @data « isolation protégée par connexions »
|
||||
- **why**: Nouveau scénario @data (workshop) prouvant l'isolation ACTIVE via le SDK contre le vrai broker : un compte non connecté ne lit pas l'entité PROTÉGÉE d'un autre, la lit après `declareConnections`, lit la PUBLIQUE toujours. Nouveaux hooks harness (`governProtected`, `connect`, `canReadPublicProbe`) réutilisant `<FilterProbe>` sur le vrai set ORM. Suivent le contrat @data (mutation/persistance broker) — pas de nouvelle couche, pas de vestige source-grep.
|
||||
- **files**: src/shared/test-harness/harness-ng.tsx, src/modules/workshop/features/protected-connections.feature, src/modules/workshop/steps/data/protected-connections.steps.ts
|
||||
- **verify (leaves à relire)**: aucune — rule_test-layer-contracts.md / knowledge_data-layer-broker.md inchangés (scénario conforme au contrat @data). Bloc à supprimer après relecture confirmatoire.
|
||||
|
||||
## Block: T03.c — scénario @data « découverte publique via l'index global »
|
||||
- **why**: Le scénario @data existant `decouverte-publique.feature` bascule du fan-out cross-comptes vers l'INDEX GLOBAL : un compte publie (submit → dépôt dans l'index) et un compte NON connecté découvre en LISANT l'index (materialize → read) puis s'abonne au doc référencé via un vrai `useShape({graphs})`. Aucune nouvelle couche ; contrat @data respecté (mutation/persistance broker réel). Hooks harness `publishPublicEventAs`/`discoverPublicEventsAs` réécrits pour passer par `submitEventToIndex`/`readDiscoveredEvents`.
|
||||
- **files**: src/shared/test-harness/harness-ng.tsx, src/modules/event/features/decouverte-publique.feature, src/modules/event/steps/data/decouverte.steps.ts
|
||||
- **verify (leaves à relire)**: aucune — rule_test-layer-contracts.md / knowledge_data-layer-broker.md inchangés (scénario conforme au contrat @data). Bloc à supprimer après relecture confirmatoire.
|
||||
@@ -1,9 +0,0 @@
|
||||
# Doc-debt — data-layer
|
||||
|
||||
> 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).
|
||||
|
||||
## Block: T03.g — l'app route par SCOPE via la lib, zéro store-id
|
||||
- **why**: Les fuites de store physique retirées de l'app applicative. Toute lecture/écriture d'entité passe par le SDK par scope (public/protected/private) ; l'app ne construit plus de `did:ng:${store_id}`. La lib expose `resolveScopeGraph(scope)` / `resolveInboxAnchor()` (placement interne). Le flag `FESTIPOD_MULTISTORE` et le chemin mono-store/multi-doc sont fusionnés en UN chemin par scope. Le point d'injection unique (`ngSession`/`storeRegistry.configureStoreRegistry`) passe la session (dont les store-ids) à la lib — wiring sanctionné.
|
||||
- **files**: src/shared/utils/ngGraph.ts, src/shared/hooks/useShapeWithDefaults.ts, src/shared/context/FestipodDataContext.tsx, src/shared/utils/ngSession.ts, src/shared/utils/storeRegistry.ts, src/shared/data/registration.ts
|
||||
- **verify (leaves à relire)**: _overview.md (le modèle "entité = document par scope" est déjà énoncé — vérifier qu'il ne reste aucune trace de mono-store/store physique dans l'app), knowledge_nextgraph-stack.md (frontière SDK : confirmer "l'app parle uniquement en scopes, jamais de store-id"), knowledge_context-internals.md (les scopes sont désormais résolus async via le SDK dans un effet — `scopeGraphs` state, gate `ready`). NB : le contenu doctrinal actuel décrit déjà la cible ; ces changements font *converger le code vers la doctrine*, ils ne l'invalident pas. Relecture confirmatoire (T03.e possède la passe doctrine).
|
||||
@@ -15,7 +15,7 @@ Festipod persiste via **`@ng-eventually/client`** — le SDK NextGraph que l'app
|
||||
|
||||
- L'app **ne dépend que de `@ng-eventually/client`** pour la donnée.
|
||||
- Le SDK est **initialisé/injecté une seule fois** via `ngSession.configure(...)` (`src/shared/utils/ngSession.ts`) — point d'injection unique. Le reste de l'app (data-plane, lifecycle, login, types) passe par la lib.
|
||||
- **Ne jamais documenter dans ce repo l'état courant de NextGraph** (contraintes du SDK sous-jacent, contournements, internes broker/verifier, mécanique d'émulation) : cela vit dans le repo `@ng-eventually/client`. Ici on décrit seulement **comment Festipod utilise ce SDK**.
|
||||
- **Ne jamais documenter dans ce repo l'état courant de NextGraph** (contraintes du SDK sous-jacent, contournements, internes broker/verifier) : cela vit dans le repo `@ng-eventually/client`. Ici on décrit seulement **comment Festipod utilise ce SDK**.
|
||||
|
||||
## ORM & shapes SHEX
|
||||
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
# Doc-debt — functional-domain
|
||||
|
||||
> 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).
|
||||
|
||||
## Block: T03.b — l'isolation par périmètre est désormais ACTIVE (confirmatoire)
|
||||
- **why**: Le modèle produit public/protected/private (knowledge_data-scopes-and-discovery) devient effectivement appliqué : protected = propriétaire + connexions, public = tous, private = propriétaire. Le fait DOMAINE (les connexions) est déclaré au SDK par l'app ; le contenu doctrinal du périmètre est inchangé (le code converge vers la doctrine, ne l'invalide pas). Le fichier .feature ne fait que valider ce modèle.
|
||||
- **files**: src/modules/workshop/features/protected-connections.feature
|
||||
- **verify (leaves à relire)**: knowledge_data-scopes-and-discovery.md — confirmer que le triptyque public/protected/private + "connexions bilatérales" reste exact (aucun changement attendu). Bloc à supprimer après relecture confirmatoire.
|
||||
|
||||
## Block: T03.c — découverte via index global (fan-out cross-comptes résorbé)
|
||||
- **why**: L'app passe du **fan-out cross-comptes** (lecture directe des docs publics de tous les comptes) à la lecture d'un **index global** possédé par le SDK : publier un événement public = soumettre sa référence à l'index ; découvrir = lire l'index. Le fait DOMAINE (intention « la découverte lit un index global d'événements ») est INCHANGÉ — le code converge vers la doctrine existante, ne l'invalide pas. Compte spécial / inbox / curateur portant l'index = simulation du SDK, invisibles à Festipod (frontière SDK) ; aucun store-id ni mécanique d'index dans le plan de données de l'app.
|
||||
- **files**: src/shared/data/discovery.ts (nouveau), src/shared/context/FestipodDataContext.tsx, src/shared/test-harness/harness-ng.tsx, src/modules/event/features/decouverte-publique.feature, src/modules/event/steps/data/decouverte.steps.ts
|
||||
- **verify (leaves à relire)**: knowledge_data-scopes-and-discovery.md — la section « Découverte des événements » dit déjà « un index global … le SDK lit cet index » : confirmer qu'aucun mot ne décrit encore un fan-out (aucun attendu). Bloc à supprimer après relecture confirmatoire.
|
||||
Reference in New Issue
Block a user