chore: porter les correctifs velesdb-memory sur main avant de taguer 0.11.2#1615
Merged
Conversation
cargo check -p velesdb-memory --no-default-features --features extract echouait sur 'cannot find function keep_alive', puis sur DEFAULT_KEEP_ALIVE : les deux etaient gates sur 'ollama', alors qu'extract.rs les appelle et que extract = [dep:ureq] ne tire pas ollama. Defaut pre-existant. Les deux passent en cfg(any(ollama, extract)) plutot que d'ajouter ollama aux dependances d'extract : un utilisateur qui ne veut que l'extraction n'a pas a embarquer l'embedder. La CI ne pouvait pas l'attraper. Son check --no-default-features porte sur le WORKSPACE, donc les features s'unifient entre crates et une feature qui ne compile que grace a une voisine passe quand meme. Chaque feature optionnelle de velesdb-memory est desormais verifiee isolement. Matrice verifiee en local : aucune, extract, ollama, ollama+extract, context, persistence, context+persistence.
Le correctif precedent n'avait traite que l'entree. wire_safe_output_schema n'appliquait que widen_id_properties, et cinq outils ne declaraient aucun output_schema du tout : rmcp en derivait un, qui conservait des $ref qu'un client aveugle aux $defs ne peut pas resoudre. Ce n'est pas cosmetique. Les SDK MCP officiels valident structuredContent contre le schema annonce : un $ref irresolvable est un resultat que le client peut rejeter, ce qui est plus dur que le cas de l'entree ou le serveur avait au moins pu repondre. L'inliner recursif est applique cote sortie, et recall, recall_fused, recall_where, why et list_working_contexts declarent desormais leur schema explicitement. Rouge prouve : 11 items non types sur 18 schemas de sortie avant, 0 apres. Le test generique couvre TOUS les outils, donc le prochain a rendre un tableau d'objets est couvert par construction.
Le nouveau gate par-feature l'a immediatement attrape : avec RUSTFLAGS=-Dwarnings comme en CI, --features ollama, extract ou persistence echouaient sur 'function stable_id_bytes is never used'. La fonction est pub, mais le module id est pub(crate) : hors du crate elle n'est joignable par personne, et son seul appelant est context/media.rs, qui adresse par contenu des octets bruts. Sans la feature context, elle est donc reellement morte. Gatee sur cfg(feature = context), ses deux tests aussi, plutot qu'un allow(dead_code) qui aurait masque le fait au lieu de le dire. Matrice verifiee sous -Dwarnings : aucune, ollama, extract, context, persistence, context+persistence, ollama+extract.
Il affirmait « Scope is deliberately the INPUT schemas [...] Output schemas keep their $ref-only items — a separate concern ». Le commit precedent de cette meme branche traite les schemas de sortie : le commentaire etait devenu faux, et un commentaire faux egare plus surement qu'une absence de commentaire.
…piles-alone fix(memory): --features extract compile désormais seule
…typed fix(memory): typer aussi les schémas de SORTIE des outils MCP
Mesure avant d'agir, sur les 18 outils reellement publies : avant inlining (0.11.1) 108 162 octets apres inlining, sans elagage 148 310 octets (+37 %) apres elagage 107 803 octets (-359 o vs l'origine) L'inlining copie chaque definition a tous les sites qui la referencent, ce qui rend son entree $defs inutile : 55 % des octets publies, soit 83 Ko. Un client aveugle aux $defs ne lit jamais ce pool, c'etait tout l'objet de l'inlining. Le schema redevient donc plus petit qu'avant tout en etant entierement auto-descriptif. Seules les entrees INATTEIGNABLES partent. 35 $ref survivent legitimement (une borne arretee par le garde de cycle, un bras d'anyOf) et leur cible est conservee. Le calcul est un point fixe : supprimer une entree peut en orpheliner une autre. Nouveau test : aucun $ref publie ne pointe vers une definition elaguee. Il resout chaque reference contre ce qui a reellement ete livre, entree ET sortie. Trois tests existants naviguaient via $defs["ContextFragment"]. Leur contrat est inchange et VERIFIE au site inline (type = ["integer","string","null"]) : ils pointent desormais sur le chemin publie. Ce n'est pas un affaiblissement, c'est l'inverse — ils verifient le contrat la ou le client le lit.
…-schema-defs perf(memory): élaguer les $defs que l'inlining a rendus inatteignables
…ter-4.1.0 chore(backmerge): main → develop après la release 4.1.0
Le commit de release 409c255 a ete fait avec `git add -A`, qui a ramasse deux chemins jamais suivis auparavant : .velesdb-hooks.json etat de session d'un poste : {"project": "velesdb", "session": "rolling"} .agents/skills/core-parity-audit/** repertoire de skills local Les deux sont donc partis dans le tag v4.1.0 d'un depot public, au detour d'un bump de version que personne n'a relu pour ca. Le depot prive n'a pas de .agents/, ce qui confirme qu'il s'agit d'etat de poste et non de contenu partage. Retires du suivi et ajoutes au .gitignore, avec la raison ecrite pour que le prochain `add -A` ne recommence pas. Les fichiers restent sur le disque : seul le suivi git s'arrete. Si .agents/ doit etre versionne, que ce soit une decision explicite, pas un effet de bord d'un commit de release.
…ifacts chore: retirer du suivi deux artefacts locaux embarqués par erreur
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 13 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prépare le tag
velesdb-memory-v0.11.2, qui ne peut pas être posé en l'état.Pourquoi cette PR est nécessaire
mainporte déjàvelesdb-memoryen 0.11.2, mais avec le seul #1608. Trois correctifs réels sont restés surdevelop:--features extractcompile enfin seule ;stable_id_bytesgaté sur son consommateur réelitemsnon typés$defsinatteignables — le schéma repasse sous sa taille d'origineTaguer
v0.11.2depuismainpublierait donc une version amputée de trois correctifs que le CHANGELOG 4.1.0 annonce déjà en chapeau.Comme 0.11.2 n'a jamais été publiée —
crates.ioest en 0.11.1 — son contenu n'est pas figé : aucun consommateur ne verrait un numéro changer de sens.Aussi dans ce lot
Le désuivi de
.velesdb-hooks.jsonet de.agents/, deux artefacts locaux qu'ungit add -Aavait embarqués dans le commit de release 4.1.0.Ensuite, et pas avant
Attendre que la CI soit verte sur le commit de merge, puis seulement taguer. Le gate
REL-06derelease-memory.ymlrefuse un tag posé sur un commit sans CI enregistrée — c'est exactement ce qui a fait échouer le premier run de la 4.1.0.