Une clause du Change policy enumerait quelles versions n-avaient pas de tag.
Poser un tag l-a rendue fausse dans l-heure. Elle est remplacee par la regle
qu-elle tenait lieu de dire - une version et son tag atterrissent ensemble -
plus la commande qui repond pour n-importe quelle version. Un engagement ne
doit pas porter un fait sur son propre depot qui se perime sans que personne
ne touche la feuille.
Patch: aucune signature ne change, aucun comportement ne bouge, seul ce que
le contrat DIT bouge - c-est le seul canal dont dispose une demande.
Surface
- une forme ShEx complete, celle de examples/notebook/app.ts, plus l-argument
de type qui type l-instantane (sans lui, T vaut BaseType - mesure au tsc)
- initNg jette son premier argument et passe le ng publie a sa place (mesure:
une sentinelle en position 0 n-arrive jamais, et ce qui arrive est === ng)
Guarantees
- une requete ancree refuse a voix haute le document qu-elle ne peut pas lire,
au lieu de l-avaler: vrai depuis 1.0.0-dev.8, dit seulement dans sa note
- quelles lectures atteignent un document de store public depuis sa seule
reference, et lesquelles non, enonce en un seul endroit
Non-guarantees
- ce qu-etait vraiment la panne orm_start_graph is not a function: l-enveloppe
ng de ce paquet, corrigee en 1.0.0-dev.7, et non le moteur refusant la forme
- l-avalement amont epingle sur l-artefact livre (@ng-org/orm 0.1.2-alpha.21,
dist/connector/RdfOrmSubscription.js) et non sur le checkout cite
- une liste << Asked for, not decided >>: useShape obligatoire, garde de type
NURI, echappement, ecriture de triplets au-dessus de sparqlUpdate, store
d-un document deja tenu, issue par depot
Change policy
- le tag polyfill/v<version> est le pin, et les tags retardent sur les
versions: le plus recent cut est polyfill/v1.0.0-dev.3
ShapeObservable portait l'annotation honnete kind=invention level=none ref=none
mais siegeait sous l'entete SDK-SHAPED qui promet un equivalent cible pour chaque
symbole. Il passe sous la barriere POLYFILL-ERA, toujours exporte (des
applications l'ecrivent : examples/notebook, e2e/polyfill-entry.ts). ShapeQuery
reste SDK-SHAPED, son enregistrement existe.
Ce n'est pas un adaptateur de framework : il porte le filtre de capacites et la
republication a l'arrivee d'une capacite, deux emulations du portefeuille
partage. Il disparait donc avec lui, migration couplee et non suppression
independante.
Le contrat enonce aussi que refetch() n'a aucun equivalent enregistre : les cinq
champs annonces ne le comptent pas. C'est un fait sur l'enregistrement, pas sur
TanStack ni sur les intentions de NextGraph.
PATCH, par le precedent du 2026-09-28 : aucune signature ne change. Version
1.0.0-dev.13 -> 1.0.0-dev.14, entree dans le contrat concept et dans
docs/api-contract.md section 14, dans le meme commit.
NgLike, UseShapeLike, OrmSubscriptionLike, GetObjectsLike et InsertObjectLike
n'existent que pour decrire ce que configure() recoit (les champs de
EventuallyConfig), et configure()/EventuallyConfig sont deja, sans ambiguite,
sur la liste de suppression - verifie en relisant index.ts : configure et
EventuallyConfig sont bien sous la barriere POLYFILL-ERA. Les cinq portaient
deja l'annotation honnete kind=invention level=none ref=none (aucun equivalent
cible), mais siegeaient sous l'entete qui promet un equivalent cible pour
chaque symbole liste.
Deplace les cinq exports sous la barriere, a cote de EventuallyConfig. Aucune
signature ne change - memes noms, memes formes, toujours exportes depuis cette
entree unique - seule la classification qui dit a un consommateur ce qu'il
supprimera a la migration est corrigee.
C'est un PATCH au sens de la politique de version du contrat concept : rien ne
bouge sous ## Surface ni ## Guarantees. Version 1.0.0-dev.12 -> 1.0.0-dev.13,
entree ajoutee au contrat concept et a docs/api-contract.md section 14, dans le
meme commit que le changement.
docChangeType est publie depuis index.ts mais absent du bloc ## Surface du contrat
concept (celui que tire la declaration usage_ d'un consommateur) - rien ne le liait
aux exports reels, contrairement au bloc "### Today" de docs/api-contract.md.
Ajoute la signature au bloc, et ajoute un test qui epingle desormais ce bloc contre
les exports reels de l'entree, sur le meme principe que le test existant pour
docs/api-contract.md : verifie a la fois (retire temporairement l'export de
docChangeType pour confirmer que le test tombe, puis restaure).
La regle qui avait deja retire ReadCap et InboxScope (un type n'est publie que si
une signature publiee l'utilise) rattrape une seconde recurrence : les reexports
`Schema` (@ng-org/shex-orm) et `DeepSignalSet` (@ng-org/alien-deepsignals) n'etaient
utilises par aucune signature publiee. DeepSignalSet n'apparaissait que dans la
prose decrivant l'enveloppe de useShape, jamais comme un type reel dans le paquet ;
Schema n'apparaissait nulle part ailleurs que dans ce reexport.
Contrairement a ReadCap/InboxScope, aucun des deux n'a d'usage interne ou ils
resteraient DEFINIS : ils disparaissent, sans etre deplaces.
Bump majeur vers 1.0.0-dev.12 (symbole publie retire), entree de version dans le
contrat concept et mise a jour de docs/api-contract.md (bloc de code, section 14,
annexe d'inventaire).
Cinq constats, aucun sur la frontiere des droits : le dossier et la garde.
LE MOTIF ENREGISTRE SUR `copyWithin` ETAIT FAUX, et c-etait raisonne, pas joue -
dans le meme lot que `rule_justify-a-return-value-by-running-it`, dont la
premiere application est a son propre voisin. Mesure : le vrai `readOnlyArray`
ne leve PAS, il execute et DETRUIT le premier element (["A","B","C"] devient
["B","C","C"]), tandis que `push`/`splice`/`sort`/`reverse`/`fill`/`shift`
levent a la lecture. `copyWithin` echappe a cette garde pour la raison exacte
qui le fait nommer ici : il est dans la meme liste mal etiquetee dont la garde
est faite. Le refuser est donc PLUS protecteur que la cible, pas equivalent :
une divergence deliberee, consignee comme telle, avec la mesure a cote.
LE FICHIER DOCUMENTAIT ENCORE LA REGLE QUE CE ROUND A SUPPRIMEE, et se
contredisait : deux en-tetes decrivaient le defaut par TYPE ("un compte, un
drapeau passent") et disaient que `isLoading` n-est pas nomme, alors que la
ligne 759 le nomme. Le contrat gardait les deux politiques a la fois. Une
doctrine qui survit a une reecriture est precisement ce qui egare le suivant.
LA GARDE NE VERIFIAIT PAS CE QU-ELLE ANNONCAIT. Prouve : une copie verbatim avec
{copyWithin, slice} en exceptions et `slice` retire de la liste servie passait
1 pass / 0 fail. Elle compare maintenant une PARTITION - l-ensemble effectif
amont egale l-union, les trois parts sont disjointes, l-exception vaut exactement
un membre nomme - et lit aussi les entrees SYMBOLE, invisibles a l-ancienne
expression. Verifie rouge dans les trois directions.
LA DEROGATION ECMASCRIPT ETAIT INFONDEE TELLE QUE RAISONNEE : la specification
ferme les CLES, pas les VALEURS. Un `Symbol.toStringTag` implemente en accesseur
rendant `Set(${size})` publiait le compte non filtre. Les deux cles sont
calculees a partir de la forme enveloppee. Et ce que la vue divulgue par
ailleurs - l-existence d-une cle sur la cible - est dit exactement, avec la
mesure qui montre qu-aucune presence de cle ne depend des objets.
`reduce` branchait sur `init === undefined` au lieu de l-arite.
LE PRINCIPE ETAIT FAUX, pas un nom manquant. "Un primitif ne peut atteindre
aucun objet, donc il passe" : or un COMPTE est un primitif qui DECRIT les
objets. Le fichier le savait deja, puisque `size` et `length` sont calcules - par
une liste de deux noms, c-est-a-dire la liste de noms interdite reapparue en
repli des que le principe a cede. Tout ce qui s-epelle autrement passait :
mesure, un porteur qui peut lire 1 objet sur 3 lisait `totalCount` a 3. Et LA
SUITE EPINGLAIT LA REPONSE QUI FUIT COMME CORRECTE, six lignes au-dessus d-un
test dont le commentaire appelle ce meme compte non filtre le defaut.
Aucun test de TYPE ne separe un primitif qui est une valeur d-un primitif derive
de la collection : un nombre est un nombre. Dit clairement, parce que la reponse
precedente pretendait le contraire. Le defaut s-inverse donc : ce que ce fichier
a DECIDE, il le sert ; tout le reste refuse, primitif ou non. C-est sur pour une
forme que personne n-a vue PAR CONSTRUCTION. Deux exceptions, aucune n-etant une
epellation du SDK : un membre que la cible ne porte pas rend `undefined`, et les
cles de protocole du LANGAGE, fermees par la specification.
LES DEUX VUES, PAS UNE. L-enveloppe avait deux pieges contre neuf : `delete
resultat.data`, `resultat.isLoading = x`, `setPrototypeOf` et
`preventExtensions` atteignaient l-objet du SDK - dont les deux derniers avaient
ete fermes sur la collection au round precedent. Les cinq pieges d-ecriture
vivent maintenant dans UN objet etale dans les deux.
`add` demandait `keep`, qui repond vrai pour un objet ne nommant AUCUN document :
juste pour une lecture, vide de sens pour une ecriture. L-objet atterrissait dans
la collection partagee, et seul l-amont l-arretait - la garantie empruntee que ce
fichier avait justement retiree un round plus tot.
Enfin `copyWithin`, que la liste amont classe non mutant a tort et que son propre
`readOnlyArray` refuse : il n-est plus servi.
Trouve en balayant le correctif de ce round plutot qu-en raisonnant dessus.
`Object.setPrototypeOf(vue, ...)` remplacait le prototype de la VRAIE
collection - apres quoi l-iterer leve pour toutes les identites, c-est le
probleme de `clear` dans une autre tonalite - et `Object.preventExtensions`,
par quoi `Object.freeze` commence, la rendait non extensible : une ecriture, et
de surcroit la projection d-index de `ownKeys` n-est licite que tant que la
cible est extensible.
L-ASYMETRIE, une fois de plus, et c-est elle le defaut. `delete` et `clear`
interrogeaient `keep`, `add` non - ce qui rendait la phrase publiee vraie par
coincidence : le `add` non garde FABRIQUAIT l-etat que les deux autres ne
traitaient qu-a moitie. Bob plante un objet dans le document d-ALICE, ne le
revoit jamais (la vue le refiltre), la liaison bidirectionnelle le commite
la-bas, puis `clear()` le laisse derriere. Les trois posent maintenant la meme
question ; ce qu-elles repondent differe parce que les membres different :
`delete` a `false`, qui est le mot du contrat Set pour "il n-y etait pas" et qui
est vrai de la vue ; `add` n-a aucune valeur de ce sens, donc il leve.
LA VUE PORTE SES PROPRES ECRITURES. Aucun piege `set`/`deleteProperty`/
`defineProperty` : contre un tableau ordonne, `view[0] = x`, `delete view[0]` et
`view.length = 0` passaient - le dernier defaisant `clear` entierement. Ce qui
est livre est un `readOnlyArray` qui les refuse, donc la production etait
protegee PAR LA CIBLE : la vue s-appuyait sur une garantie qu-elle ne donne pas,
sur une forme qu-elle ne controle pas. C-est l-hypothese empruntee qui est
derriere chaque defaut de cette famille.
LE PROPRIETAIRE EST SERVI. 18 membres declares d-un resultat ordonne levaient
pour celui dont ce sont les donnees, plus `includes` et les sept combinateurs
d-ensemble : une fuite echangee contre une panne. Tout ce que
`@ng-org/alien-deepsignals` declare non mutant est servi sur les objets
lisibles, et un test relit le fichier livre pour que la liste restee ici ne
derive pas.
Aussi : le descripteur d-un ACCESSEUR routait vers la cible ; le faux construit
maintenant les VRAIES collections (`deepSignal`, `readOnlyArray`) au lieu d-un
Set et d-un tableau nus, ce qui le rendait plus permissif que ce qui est livre
apres l-avoir rendu plus correct au round precedent.
Balayage execute sur les deux proxys apres le correctif precedent : aucun membre
de la vue de collection ne rend plus la cible, mais une commande de page de
l-enveloppe qui rendrait la collection la rendait BRUTE. `nextPage` est declare
`() => void` et ne rend rien aujourd-hui, donc ce n-est pas un defaut vivant -
c-est la meme justification jamais executee, sur l-autre proxy, et c-est
exactement le motif qu-il fallait casser. Elle s-execute toujours ; seul son
retour est tenu a la regle.
`Set.prototype.add` rend THIS pour permettre le chainage - EXECUTE, pas deduit,
sur le `Set` nu et sur le vrai `DeepSignalSet`, qui rendent tous deux la
collection. Les trois mutations etaient transmises liees a la cible sur le motif
ecrit juste au-dessus : "elles prennent un objet et rendent void ou un booleen,
donc elles ne laissent rien fuir". Faux pour `add`, et `add` est le PREMIER
membre que l-exemple de documentation du SDK emploie. Toutes les entrees etaient
filtrees et la sortie rendait la collection entiere.
Les deux autres rendaient bien ce que le motif disait, et AGISSAIENT au-dela de
la vue : `delete` retirait un objet dont `has` refuse meme de confirmer
l-existence - les deux se contredisaient - et `clear` vidait la collection que
toutes les identites partagent.
Une seule regle : une mutation atteint la collection dessous, mais ne rend ni
n-atteint ce que la vue cache. `add` rend la VUE, `delete` n-agit que sur ce que
la vue montre, `clear` vide la vue. L-ecriture atteint toujours le document.
Le motif commun aux cinq fuites de cette famille est une JUSTIFICATION ECRITE
SUR UNE VALEUR DE RETOUR JAMAIS EXECUTEE. Chacune etait raisonnable, aucune
n-avait ete jouee.
Aussi : la forme ordonnee rend des index la ou un Set rend des objets
(`keys`/`entries`/`forEach`), et le faux partage reproduit desormais le
`isLoading` LIVRE - inverse de sa propre declaration. L-inversion est amont ;
un faux plus correct que la cible recree l-aveuglement que cette tache enleve.
Trouve en rejouant l-adversaire sur le correctif precedent, et mesure :
`Object.getOwnPropertyDescriptor(resultat, "data")` rendait la collection BRUTE,
et `(..., "subscription")` le handle que `get` refuse. Cet appel ne passe pas
par le piege `get` - ni l-etalement, ni `Object.entries`, ni `JSON.stringify`,
ni une inspection console. Une deuxieme porte sur la meme piece, ouverte par un
piege que personne n-avait ecrit. Le meme trou existait sur la vue de collection
pour la trappe dunder.
La forme ordonnee dit combien d-objets elle porte a QUATRE endroits : `length`,
`Object.keys`, `in`, et le descripteur de chaque index. Un seul etait filtre,
donc le compte de ce que le porteur ne peut pas lire ressortait par les trois
autres, et le descripteur rendait les objets eux-memes.
Les quatre pieges appellent maintenant une seule fonction `read`, pas trois
copies de la regle : une frontiere faite de `switch` paralleles est une
frontiere qui derive. Et l-index nomme une position dans ce qui est LISIBLE,
donc la forme ordonnee sert son porteur au lieu de refuser.
Six endroits affirmaient au present que `useShape` rend un `DeepSignalSet` nu.
C-est vrai de la revision citee, faux de celle contre laquelle ce paquet est
construit - et deux de ces six PORTAIENT une decision de provenance :
- `ShapeQuery kind=invention` etait justifie par "aucun type amont ne porte
d-etat de chargement", alors que `isLoading` en porte un. Le kind tient, mais
pour l-autre raison : ce qui n-a de contrepartie nulle part est le troisieme
etat, la lecture ECHOUEE, parce qu-un `orm_start_graph` refuse n-est qu-un
`console.error` et laisse une attente eternelle a tous les niveaux.
- l-annotation `announced-not-written` de `useShapeQuery` posait la meme
premisse fausse. La direction annoncee ne bouge pas ; sa premisse si.
Ajoutee aussi l-instruction d-injection qui ne resolvait pas : l-export `.` de
`@ng-org/orm` pointe sur `core`, qui n-exporte aucun `useShape`. Il est sur
`/react` (export par defaut) ou `reactUseShape` sur `/all`.
Le `useShape` publie enveloppait le resultat du hook dans le filtre ecrit pour
une COLLECTION. Depuis que `@ng-org/orm` renvoie un `UseShapeResult` autour du
set, `[...resultat]` et `.size` levaient, et `data`, `promise` et `subscription`
revenaient BRUTS - chacun tous les objets de toutes les identites, sans que rien
ne casse. Aucun faux de ce depot ne renvoyait la forme livree, donc aucune garde
ne pouvait le voir.
Deux vues au lieu d-une : celle de la collection, et celle de l-enveloppe que
`surface/use-shape.ts` applique. `data` et `promise` sont filtres, `subscription`
est refuse (c-est le handle de l-ORM, que cette surface ne publie pas), les deux
commandes de page passent.
Le defaut par TYPE et non par une liste de noms : un primitif ne peut atteindre
aucun objet et passe, un objet ou une fonction refuse tant qu-il n-existe pas de
forme filtree ici. C-est pourquoi `isLoading` n-est nomme nulle part, et pourquoi
un membre qu-une version suivante ajoutera est deja tranche. `size` et `length`
comptent ce que le porteur peut lire.
`UseShapeLike` etait `(...args: any[]) => any`, ce qui est la raison pour
laquelle les deux typechecks restaient a 0 pendant que la fuite etait ouverte :
aucune declaration ne disait ce que le hook rend. Il rend `ShapeResult`, releve
sur le `.d.ts` installe, et le vrai `reactUseShape` y est assignable sans cast.
Le faux partage `test/use-shape-fake.ts` renvoie la forme livree et c-est celui
que les deux gardes injectent - unitaire et e2e. La garantie du contrat et le
test qui l-epingle arrivent ensemble ; `1.0.0-dev.11`, majeur.
Recherche menee sur les 94 citations vers engine/ et sdk/, en comparant
l'arbre cite aux artefacts publies. Onze citations de niveau 2
(doc_subscribe, sparql_update, sparql_query, doc_create) sont
identiques de part et d'autre, ainsi que ShapeType, Schema et
DeepSignalSet. Trois ne l'etaient pas.
- Scope : la revision citee declare `graphs?` OPTIONNEL,
@ng-org/orm@0.1.2-alpha.21 le rend requis - et c'est le paquet
installe qui est reexporte ici.
- BaseType : la revision citee garde "@graph" en commentaire derriere un
TODO, @ng-org/shex-orm@0.1.2-alpha.9 le declare.
- NG : le compte de membres disait 88 en neuf endroits, dont un marque
VERIFIED et un autre annoncant une mesure contre alpha.14. Le paquet
installe en declare 90 - 84 fonctions et 6 classes RDF - et deux des
quatre-vingt-dix, graph_orm_next_page et graph_orm_previous_page, sont
absents de l'arbre cite. Le compte vit desormais a un seul endroit,
avec la version a laquelle il appartient ; ailleurs il disparait, parce
que la phrase disait "tous les membres" et que le chiffre n'y ajoutait
qu'une occasion de perimer.
Les deux premieres reprennent la forme que RdfOrmConfig et
OrmSubscriptionHandle portaient deja : une clause finale nommant la
version publiee la ou elle diverge de la revision citee.
Deux feuilles affirmaient que la richesse de la config ORM est perdue au
niveau 1 - "no caller can reach any of it. The richness is real and
unreachable". La preuve invoquee etait le `json!({})` de
`Verifier::start_orm` a 213338f6, et elle ne porte pas cet enonce.
Ce qui est verifie a 213338f6 : `OrmConfig` declare where_, order_by,
select, page_size et max_active_pages ; `from_json` les analyse tous les
cinq et refuse un pageSize sans orderBy ; schema_shape_to_sparql et le
pagineur les consomment. La machinerie est implementee. Il manque un
seul saut, a l'ENTREE : start_orm ne prend aucun argument de config, et
son TODO voisin nomme le maillon absent, "use json in libwasm context".
Or ce maillon existe dans le build : @ng-org/web@0.1.2-alpha.14 publie
orm_start_graph avec SIX parametres, config en position 4, quand l'arbre
cite en declare CINQ, et @ng-org/orm@0.1.2-alpha.21 l'appelle avec six
en passant tout son objet d'options. Lus dans les artefacts publies.
Donc la config quitte le niveau 3 et est acceptee au niveau 2 aux
versions installees. Ce que le moteur derriere ce binding en fait n'est
etabli par rien d'atteignable, et c'est dit ainsi.
Une citation nomme un chemin et un symbole, jamais une version. Or le
checkout contre lequel toutes les citations `engine/` et `sdk/` se
resolvent declare des versions inferieures a celles que ce depot
installe, donc une citation prouve "c'etait vrai a ces versions-la" la
ou un lecteur lit "c'est vrai de ce qu'on construit".
La version est une propriete du CHECKOUT, pas d'une citation : aucune
des annotations n'est touchee. Elle est enregistree une seule fois, dans
l'`ANCHOR` de provenance.test.ts, a cote du resolveur qui s'en sert.
Ce que le mecanisme verifie maintenant, aux DEUX bouts de l'ecart, parce
qu'un enonce d'ecart peut perimer par l'un ou l'autre et a deja perime
par le bout eloigne : les versions que le checkout declare (a vide quand
le checkout est absent, comme la verification de resolution), celles que
les manifestes de l'espace de travail epinglent, et celle qui est
reellement installee sous packages/polyfill.
Pas un nouveau `kind` : les kinds classent la preuve d'UN symbole,
l'anciennete de toute la preuve appartient a l'arbre.
packages/polyfill/package.json declarait "*" sur les quatre @ng-org/*, ce
qui en semver n'admet aucune prerelease. Mesure sur le registre : "*"
n'admettait que le 0.1.2 bru (2025) pour web/shex-orm/alien-deepsignals et
ZERO version pour orm (qui n'a jamais publie de 0.1.2 stable). Les quatre
ranges deviennent ">=<pin actuel> <0.1.2>", le plancher etant la version
dont ce paquet est effectivement construit et teste (devDependencies) et
le plafond excluant le 0.1.2 perime, sur le modele mesure par T01.l pour
ng-e2e-helpers.
Le texte disait que les deux situations passaient de `isSuccess` a
`isPending`. Verifie : seul le second `configure()` publiait un succes
(vide ou perime). Sur un refus tardif du courtier la lecture etait deja
retenue - ce qui change est la sortie, la nouvelle tentative se
re-souscrit au lieu d'etre bloquee pour la session.
Trois reponses coexistaient et pouvaient se contredire : un ensemble de
souscriptions bootstrap et une carte d'etat de barriere dans `open-repo`, et les
auditeurs du fan-out dans `surface/subscribe`. Les deux premieres survivaient a
la disparition de la troisieme, parce que `resetDocSubscriptions()` - ce que fait
le `configure()` publie - largue ses auditeurs sans rien dire a personne.
Il n'en reste qu'une, l'etat de l'unique souscription reelle du document, exposee
par `docChannel(nuri)`. `open-repo` n'enregistre plus que l'auditeur qu'il a pose
- « est-ce que j'ecoute encore », rien de plus - et derive `getSyncState` a chaque
lecture, si bien qu'aucune reponse ne peut survivre au canal qu'elle decrit.
Disparaissent : `held`, `syncState`, `inFlight`, `settleInFlight` et le compteur
de generation, remplace par l'identite de l'enregistrement.
Les deux echecs prouves deviennent des tests qui echouent sans le changement :
un second `configure()` apres une synchro reussie (`"synced"` au lieu de
`"timed-out"`, zero re-souscription, et `isSuccess` cote application), et un
etablissement encore en cours quand la couche de souscription est demontee - cas
que le canal `onSetupFailed` ne peut pas rattraper, puisqu'il ne rapporte que la
tentative encore attendue.
La ligne qui ne casse pas : un document synchronise qui ne contient rien repond
toujours un succes a zero objet. `1.0.0-dev.10`, les deux non-garanties
nommees sont retirees et la garantie livree porte le test qui l'epingle.
Les deux textes expliquaient que `bun install` ne va pas chercher le pair
optionnel. Mesure : pnpm ne le va pas chercher non plus pour un consommateur
qui ne le nomme pas (un paquet qui ne declare que le polyfill recoit zero
@ng-org, sans avertissement) - mais ce depot-ci l-obtient quand meme, parce
que `packages/polyfill` le declare aussi en devDependency. Un `pnpm install`
depuis un `node_modules` vide suffit donc a faire construire le bundle du
runner, et le message qui demandait d-installer l-ORM a la main etait devenu
un faux conseil.
La sixieme revue a refute la reparation du tour 6 et a trouve la famille sur
laquelle nous nous etions engages a scinder. `held` n'est pas le registre unique :
il y en a trois, et celui que personne n'avait compte est `fanOuts` dans
`subscribe.ts`. `configure()`, qui est PUBLIE, vide les auditeurs sans le dire a
`open-repo` ; et `held.set()` s'execute avant meme que `establish` atteigne
`doc_subscribe`. `held` veut donc toujours dire « on a demande » - le sens plus
lache pour lequel j'avais supprime `opened`. J'ai remplace l'un des deux registres
qui se contredisaient ; il y en avait trois.
Aucun code touche ici. Le defaut de registre part dans T01.m, avec ses deux echecs
prouves comme tests d'acceptation.
Le contrat dit desormais ce que le code tient : la moitie « le document a-t-il
repondu » vaut DANS UNE SESSION ordinaire, et pas apres un second `configure(...)`
ni quand le courtier refuse un abonnement tardivement. Les deux situations sont
nommees en non-garanties avec leur cause et le renvoi vers T01.m. La moitie
« peut-on joindre le document » n'a pas cette reserve : elle est verifiee deux fois
contre un vrai courtier, et la retirer ramenerait un succes vide silencieux
partout, ce qui est pire qu'une garantie partielle honnetement enoncee.
Pas de changement de version : aucun comportement publie ne bouge, seule la
justesse de sa description.
Et une faute de compte-rendu consignee, parce que c'est un motif : trois fois j'ai
affirme qu'un changement avait reduit ou simplifie quelque chose, trois fois la
mesure disait le contraire. Regle desormais mecanique - toute affirmation
structurelle porte son `wc -l` ou son `--numstat` dans la meme phrase, sinon elle
ne s'ecrit pas.
Trois constats, un seul defaut sous trois visages : un etat enregistre comme vrai
qui ne l'est pas, sans moyen de se corriger. Deux des trois vivaient dans
`open-repo.ts`. Cinq tours sont alles dans l'appelant ; c'est le teneur de
registre qui mentait.
CE QUE LE REGISTRE VEUT DIRE, ecrit dans l'en-tete. `held` est le SEUL registre
d'ouverture : cette session detient un abonnement vivant a ce document. Il y avait
a cote un `opened` voulant dire « on a appele `doc_subscribe` une fois et on a
cesse d'attendre », et ce sens plus lache mentait de trois facons : il survivait a
un abonnement REFUSE par le courtier (donc la reprise que `subscribe.ts` offre
etait bloquee a jamais), il survivait a une reinitialisation (donc une nouvelle
session court-circuitait sur l'enregistrement de la precedente), et il laissait un
document annoncer une barriere jamais franchie. `opened` est supprime.
Les trois consequences, desormais vraies par construction :
- un abonnement qui a ECHOUE n'enregistre rien - `onSetupFailed`, le canal que
`subscribe.ts` offre exactement pour cela, est enfin branche - donc l'appelant
suivant s'abonne a nouveau ;
- une reinitialisation efface l'enregistrement ET DECLASSE l'etat de synchro :
une barriere franchie dans la session qui vient de disparaitre n'en est pas une
que celle-ci a franchie ;
- `"unknown"` ne veut plus dire qu'une chose : aucune barriere n'etait attendue ici
(jamais demande, ou un `ng` sans `doc_subscribe`). Jamais « on a oublie ».
Cote appelant, un seul changement, et c'est le troisieme constat : quand un
document nomme n'a pas repondu, `publish` PUBLIE « la question reste ouverte » au
lieu de sortir en laissant en place l'instantane precedent. Sortir laissait un
refus DEJA LEVE a l'affichage : l'application lisait « vous ne detenez pas la
capacite de ce document » a propos d'un document qu'elle detient desormais.
Deux tests portaient l'ancien sens et sont corriges avec leur raison : celui du
`ng` sans `doc_subscribe` (le compteur d'ids du faux courtier redemarrait a chaque
test, donc deux tests aliasaient leurs depots - la lecon de `wallet-fake` a
l'echelle du fichier), et celui de la lecture froide, ou « timed-out » est
desormais ce que dit « cette page ne l'a pas confirme ».
Deux defauts, aucun des deux sur la reprise - elle a passe cette revue intacte et
n'a pas ete rouverte.
1. La barriere verifiait qu'un document nomme peut etre JOINT, jamais qu'il a
REPONDU. Elle attendait `ensureRepoOpen` puis demandait `assertMayReach`, qui
est la question de la capacite, et ne consultait pas l'etat de synchro que
l'ouverture venait de produire. Un document dont l'abonnement a reussi mais dont
le premier `State` n'est jamais venu publiait donc `isSuccess` avec `data: []` :
le defaut d'origine, dans le cas precis pour lequel la barriere a ete ajoutee.
La verification rejoint le reste de la decision, dans `publish`, donc rejouee a
chaque publication au lieu d'etre memorisee. Les trois valeurs, enumerees avant
d'ecrire la condition : `"synced"` fait autorite - zero ligne VEUT DIRE zero
objet, la ligne tenue depuis cinq revues -, `"timed-out"` et `"syncing"` non, et
`"unknown"` PASSE deliberement, parce qu'il veut dire « pas de semantique de
`State` sur ce `ng` » et que le traiter autrement est exactement la regression
du cas inerte livree aux tours 1 et 3.
`isPending` plutot que `isError`, des deux que le contrat autorise : rien n'a
echoue, il manque l'autorite de dire que le document est vide.
Le test (t) EPINGLAIT le defaut - il attendait `isSuccess` apres trois
barrieres expirees. Corrige. Ce n'est pas un test affaibli : l'ancienne
assertion etait fausse.
Et un trou dans ma propre suite, trouve par mutation : inverser la condition
pour refuser `"unknown"` passait tous les tests, faute d'un `ng` SANS
`doc_subscribe` nulle part. (cc) le couvre.
2. Regression de mon correctif du tour 4. Terminer une ouverture abandonnee
faisait tourner sa continuation juste apres que la reinit avait vide les
tables, donc elle ecrivait une entree `opened` perimee dans le registre neuf -
et toute ouverture ulterieure de ce nuri court-circuitait dessus. Le depot
n'etait jamais abonne dans la nouvelle session. Une epoque de registre corrige
cela : une reinit l'incremente, une continuation dont l'epoque ne correspond
plus n'ecrit rien. Une reinit INVALIDE ce qu'elle abandonne, en plus de le
terminer.
`getSyncState` reste interne, et la doctrine cesse de l'offrir : elle pointait sur
un symbole qu'aucun appelant ne peut importer.
Quatrieme tour. Ce n'est pas un drapeau de plus : c'est la forme qui change.
Les tours 2 et 3 construisaient tous deux la reprise ainsi - noter qu'on a
refuse, puis reagir a un evenement ulterieur - et c'est la note qui etait
fautive les deux fois : une fois conditionnee a quelque chose qui ne pouvait pas
devenir vrai, une fois ecrite apres la fenetre ou arrive l'evenement decisif. Un
front manque n'est pas rattrapable par construction. Donc :
- LA DECISION EST UN NIVEAU. Les documents nommes sont reinterroges a chaque
publication, jamais reportes depuis la barriere. Une capacite qui arrive change
`isError` en document par le canal qui existait deja, et rien n'etant memorise,
il n'y a aucun evenement a manquer. C'est aussi ce qui rend sans objet la
question du porteur : une requete ouverte pendant qu'un autre etait connecte ne
peut pas revenir a cet abonne en succes auquel il n'a pas droit.
- UNE TENTATIVE QUI A COURU CONTRE UN CHANGEMENT S'EN APERCOIT au lieu
d'attendre. `open()` echantillonne `CapRegistry.version()` avant la barriere et
compare apres son echec ; un ecart signifie qu'elle a decide sur un terrain
perime, et elle retente d'elle-meme. Cela termine : une tentative ne se repete
que parce que le trousseau a bouge, les mouvements sont finis, et ceux qu'une
tentative provoque elle-meme sont les capacites qu'elle depose - au plus une par
document nomme.
La comparaison de porteur disparait : `holderKey()` vaut "" tant que personne
n'est connecte, donc un refus pris avant que l'identite se fixe - la ou les
composants se montent - ne correspondait plus jamais ensuite.
Un instantane d'echec inchange n'est plus republie : la surface documente sa
stabilite, et huit arrivees sans rapport produisaient huit objets porteurs de huit
`Error` distinctes pour un etat identique.
Enfin, un defaut a moi, trouve en mesurant : le changement rendait la suite
intermittente. `resetOpenedRepos()` abandonnait les ouvertures en vol sans les
terminer, donc un appelant attendait les 8s du repli sur un abonnement demonte,
puis repartait avec son etat de synchro efface - et « unknown » est la lecture
LAXE, celle qui accepte qu'une lecture a zero ligne soit une absence averee. Une
absence-qui-cache-un-echec latente, de la famille meme de cette tache. Une
reinitialisation termine desormais ce qu'elle abandonne, en « timed-out ».
Deux fixtures qui se couraient apres sont corrigees, raison ecrite a cote.
Troisieme tour de revue adversariale, trois constats, tous reproduits avant
correction.
1. La garde etait CIRCULAIRE, et c'etait structurel. `namedDocumentsReachable`
demandait si la capacite est DETENUE. Pour un document en store public, le seul
canal qui puisse jamais la deposer est `fetchReadCap` - l'appel meme que la
garde retenait. Elle attendait une reponse que seule l'action qu'elle bloquait
pouvait produire, et toute cette classe restait irrecuperable.
La bonne question n'est pas une meilleure garde, c'est de RETENTER. Les deux
facons d'etre refuse se reparent par des choses opposees, et le memo les
distingue deja : un echec n'est deliberement pas memoise, donc une nouvelle
tentative redemande vraiment au reseau - c'est la reparation de cette classe,
pas un cout a eviter ; une absence est memoise, donc une nouvelle tentative ne
demande a personne et coute un instantane, jusqu'au jour ou la capacite arrive
d'ailleurs, seule chose qui repare celle-la. La garde est supprimee : le module
est plus petit qu'au tour precedent.
2. La reouverture faisait un ACCES sous la mauvaise identite. Republier REFILTRE
une requete existante ; rouvrir EMET un abonnement et une requete au store
public pour un document que cet abonne a nomme. C'est un acte neuf, pas un
ancien qui ressort, et l'etat final etait `isSuccess` avec `data: []` pour un
document illisible - le mensonge que cette tache supprime, par la porte du
correctif. `refusedFor` retient QUI a ete refuse ; on ne retente que tant que
c'est encore lui le connecte.
Etabli plutot qu'affirme : une application ne peut pas changer d'identite en
cours de session. `ensureIdentity` est le seul appel publie qui en etablit une,
et `resolveIdentity` commence par `getCurrentUser()`. Corrige quand meme.
3. `Promise.all` court-circuite a la premiere rejection ARRIVEE, et un fetch qui
rejette n'attend pas la barriere de synchronisation : il double un refus portant
sur un document nomme avant lui. Le comportement est corrige plutot que le
commentaire - `allSettled` puis parcours dans l'ordre du scope.
Et le quatrieme controle e2e est retire, pas repare : il passait avec toute la
machinerie de reprise supprimee. Un controle qui ne peut echouer pour aucune
regression de ce qu'il garde se lit comme de la couverture et vaut moins que rien.
Revue adversariale : la barriere livree au tour precedent rendait le refus
TERMINAL. Le signal du trousseau s'ecrit `if (query !== null) publish(...)`, parce
qu'avant la barriere il n'y avait qu'une seule raison de n'avoir pas de requete -
rien n'avait encore ete tente - et qu'une cle qui arrive ne pouvait changer que ce
qu'une requete OUVERTE avait le droit de montrer. La barriere en a ajoute une
seconde : elle abandonne AVANT que la requete existe, donc le seul canal qui fait
converger une cle tardive passait a cote de l'etat qui en avait le plus besoin.
Une page qui s'abonne pendant que son trousseau se restaure, ou un document
partage sous les yeux de son destinataire, publiait `isError` et y restait. Ce
n'est pas une surface plus stricte, c'est une pire : echanger un vide mensonger
contre une erreur bloquee ne repare rien, et cela casse une garantie que ce paquet
publie.
Le signal rouvre donc un scope refuse, et seulement quand le refus est leve
(`namedDocumentsReachable`). Le garde-fou porte autant que la reouverture :
rouvrir a chaque changement de trousseau rejouerait la barriere pour chaque cle
qu'une connexion depose, redemanderait au reseau tout document dont le
telechargement avait ECHOUE - un echec n'est deliberement pas memoise - et
republierait la meme erreur a chaque abonne. La variante indiscriminee casse deux
tests, dont celui de demontage qui preexistait.
La barriere passe en parallele. Elle etait serie, donc N documents qui ne poussent
jamais de `State` coutaient N replis bornes, 8s chacun en production. Les refus
restent lus dans l'ordre du scope apres coup.
Et ce qui a laisse passer les deux : l'e2e ne parcourait pas ce chemin. Les deux
journeys `useShapeQuery` lisent `{graphs: "did:ng:i"}`, donc 43/43 n'a jamais rien
prouve sur la barriere. Quatre controles ajoutes sur un scope NOMME, contre le
vrai broker : la proprietaire lit son document, un porteur de rien recoit
`isError` et jamais un succes vide, un document PUBLIC s'ouvre pour lui depuis la
seule reference via la requete de la barriere, et une cle qui tombe pour un AUTRE
document laisse le scope refuse en place.
Majeur : trois appels existants se resserrent. `useShapeQuery` publie `isError`
pour un document NOMME qu'il ne peut pas lire, la ou il rendait `isSuccess` avec
`data: []` - la seule image que cette surface reserve a « ce scope ne contient
rien ». `inbox.postToDocument`, `readForDocument` et `readSyncedForDocument`
rejettent la ou elles annoncaient « pas d'inbox ». Rien de ce qui etait deja une
reponse ne bouge : un document vide, `graphs: []`, un document sans inbox, un
document public qui n'expose aucune cle.
Deux non-garanties corrigees parce que le changement les rend fausses : « aucune
des deux lectures par forme ne va chercher la cle d'un store public » ne vaut
plus que pour `useShape` et pour `did:ng:i`, et le pending eternel d'un demarrage
refuse se referme sur le cas nomme.
Nouveau `knowledge_what-a-failed-read-answers-upstream` : ce que la cible repond
pour un document injoignable, non synchronise ou vide, et les deux collisions que
l'appelant ne peut pas demeler - « n'existe pas » contre « pas connu de moi »
d'un cote, « non synchronise » contre « vraiment vide » de l'autre. C'est le fait
durable qui justifie la direction prise, et il vaut quel que soit le remede.
`docs/internal-contract.md`, section open-repo seulement : numeros de ligne,
`ensurePhysicalRepoOpen` qui n'a jamais ete un export de ce module,
`ensureReposOpen` supprime, `openRepoUnguarded` absent, et le second parametre de
`ensureRepoOpen`. Le reste du document porte une derive du meme age, laissee.
pnpm-workspace.yaml listed only packages/*, so pnpm never installed
examples/notebook's dependencies even though root package.json's
workspaces field named examples/* too; the example ran on a stray
node_modules a manual bun install had left behind (symlinks into
node_modules/.bun, including a dangling @ng-eventually/sdk link to a
package that no longer exists). Added examples/* to pnpm-workspace.yaml
and reinstalled; examples/notebook now resolves @ng-org/orm and
@ng-org/web to the exact same pnpm store instances packages/polyfill
uses (verified via the symlinks and node_modules/.pnpm listing) - no
package ended up duplicated.
That alone did not fix the example's TS2345: NoteShape's object
literal had its dataTypes[].valType widened from the "iri"/"string"
literals to plain string (no satisfies clause), which the existing
test suite already guards against elsewhere (satisfies
ShapeType<BaseType>). Applied the same pattern here, importing the
already re-exported ShapeType/BaseType from @ng-eventually/polyfill -
no new dependency needed, no compiler option touched.
Les quatre paquets @ng-org sont deja a leur derniere version publiee
(web alpha.14, orm alpha.21, shex-orm alpha.9, alien-deepsignals
alpha.13) : le refresh ne deplace rien. Ce qui restait faux, c'est la
doctrine, laissee en arriere par le refresh precedent.
Le point de fond : le checkout epingle de nextgraph-rs (213338f6)
declare orm alpha.18, donc la source citee est TROIS versions derriere
les paquets contre lesquels ce depot compile. La ou les deux divergent,
les leaves nomment desormais les deux.
Faits corriges, tous verifies dans node_modules :
- les versions installees annoncees en tete de leaf (alpha.19/13/11)
- OrmSubscription est renomme RdfOrmSubscription dans alpha.21, fichier
compris (connector/RdfOrmSubscription.ts)
- alpha.21 exporte removeObject(graphNuri, subjectIri), absent de la
source ; sa propre documentation se contredit sur sa portee
- getOrCreate prend un RdfOrmConfig, plus un Scope nu, et l'instance
gagne mode/isReady/addChangeListener/nextPage/previousPage
- Scope.graphs est REQUIS dans alpha.21, et les deux axes lisent [] en
sens INVERSE : graphs [] = ensemble vide, subjects [] = aucun filtre.
La table le dit explicitement, c'est le piege deja paye une fois
- la lecture ORM live DEMARRE contre le deploiement (5 passed, 0 failed,
pret en 13ms) ; le lien mort vers bug_useshape-live-read-needs-a-newer
-broker disparait, ainsi que le "exit non-zero attendu" de la suite
Ce qui n'est PAS affirme : que le where/orderBy/pageSize d'alpha.21
atteigne le moteur. A 213338f6 start_orm construit encore son config a
partir de json!({}) derriere un TODO, donc la richesse est exprimable au
niveau 3 et jetee au niveau 1. Non mesure, donc non ecrit.
Le contrat publie et l'api-contract etaient traites avec le retrait lui-meme ;
restaient les documents qui decrivaient readUnion comme la primitive de
lecture du paquet, ou qui nommaient le module disparu.
Ce que les lecteurs apprennent maintenant : lire un document, c'est
docs.sparqlQuery ancre dessus, et lire plusieurs documents, c'est cet appel
une fois par document -- avec la decision sur une lecture qui echoue ecrite
au point d'appel. Deux consequences sont dites plutot que decouvertes : une
lecture refusee leve au lieu de rendre une liste vide, et les sujets sous le
prefixe reserve urn:ng-eventually: reviennent dans le resultat, a l'appelant
de les ignorer -- sans aucun gain de droits, les deux registres qu'un
document ordinaire porte etant l'adresse de sa boite et, pour un document
public, la cle que son magasin sert deja a qui la demande.
Les briefs dates ne sont pas touches : ils decrivent un etat de juillet, et
le reecrire falsifierait ce qui avait ete decide alors.
readUnion etait N requetes ancrees plus une politique de lot : une lecture
qui echoue avalee en reponse vide, un document dont on ne detient pas la cle
ecarte au lieu d'etre refuse, un regroupement en sacs de proprietes, et le
filtrage du prefixe reserve. Rien en amont ne repond a cette composition, et
son annotation citait sparql_query -- une citation exacte attachee a une
affirmation fausse. Une composition ne s'aligne pas sur une fonction.
Ce qui reste est ce qu'il y avait dessous : docs.sparqlQuery ancre sur un
document, qui va deja chercher la cle servie par le magasin public -- donc
une reference nue suffit toujours pour lire un document public, sans rien
changer a useShapeQuery. Lire plusieurs documents, c'est cet appel une fois
par document, et la tolerance a une lecture qui echoue revient a l'appelant,
la ou l'amont la laisse : une requete ancree sur un depot que le verifier ne
detient pas rejette.
Cote src, l'unique lecture interne restante devient read-document.ts : un
document, une requete ancree, precedee de l'ouverture du depot -- barriere
que index-deposit consulte pour distinguer une absence d'un depot non
synchronise. Le harnais e2e et l'exemple composent la leur, avec leur catch
visible au point d'appel.
Version majeure : 1.0.0-dev.8.
Sylvain Duchesne