Réécriture de « Apps & services » : la version précédente déduisait la forme
cible de l'absence d'implémentation dans le moteur — exactement ce que le
principe de conception du README interdit — et concluait l'inverse de ce que le
développeur NextGraph énonce.
Deux couches désormais séparées et étiquetées comme telles :
- ce que le moteur CONTIENT (vérifié) : `AppManifestV0` avec `singleton: bool`,
`access_requests`, `installs`, `dependencies` ; `init(callback, singleton,
access_requests)` côté JS. Et personne ne le consomme — le module
`permissions` n'est importé par aucune crate, `AppManifest` n'est construit
nulle part. Du vocabulaire, pas du comportement.
- ce que le modèle SERA (énoncé par le développeur, non implémenté) : une app
singleton peut aussi gérer les documents par utilisateur ; les données
communes prennent la forme d'un document ou d'un store partagé par tous les
utilisateurs et codé en dur dans l'app ; le développeur détient les droits
d'écriture et peut les déléguer, jamais à tous — les contributions arrivent
par une inbox.
Le commentaire du champ dit `/// cannot create Documents?`, avec le point
d'interrogation. Une seconde glose publiée le contredit et rejoint ce que dit
le développeur : `sdk/js/web/README.md:90,108` annote l'argument « will your app
create many docs in the system, or should it be launched as a unique instance »
— `singleton` porte sur la multiplicité d'instance, pas sur une interdiction de
créer des documents. C'est cette lecture qu'il faut retenir.
Conséquence sur l'ADR discovery : sa moitié « la voie app singleton est
incertaine » est caduque et doit être re-posée, sans que cela rétablisse la
découverte, qui tient sur son propre appui.
Sylvain Duchesne
e24a20cc46