v2.0.0 — primer estable de la linea v2
Salio el estable: 462 commits desde v1.20.0. La identidad de proyecto ahora se resuelve consistente desde config explicita, ENGRAM_PROJECT, metadata de Git y el directorio actual, y la atribucion de sesion queda atada al runtime asi no te escribe en el proyecto, worktree o agente equivocado.
Suma mem_current_project, merge y pruning de proyectos, rescate de ownership legacy, captura curada de prompts, upserts por topic-key, ciclos de review, pinning local y truncado seguro en UTF-8. La busqueda FTS5 se expande con filtros de proyecto y scope, match modes y soporte CJK/trigram. Ojo con lo copado: mem_save ahora te tira memorias que probablemente entren en conflicto, y mem_judge / mem_compare persisten veredictos supersedes, conflicts_with, compatible y not_conflict.
Tambien llega la replicacion Cloud opcional con engram cloud serve sobre Postgres, autosync opt-in con lease, retries acotados y backoff exponencial. El SQLite local sigue siendo la fuente de verdad. Antes de subir: backup de ~/.engram/engram.db, corres engram doctor, y reinicias los MCP servers de larga vida para que carguen el binario v2. Si tenes proyectos enrolados en Cloud, segui la secuencia doctor → repair → bootstrap; no hay migracion remota implicita.
Nota de seguridad: los deployments autenticados exigen un ENGRAM_JWT_SECRET no default, los servidores Cloud requieren ENGRAM_CLOUD_ALLOWED_PROJECTS, y ENGRAM_CLOUD_TOKEN_PEPPER tiene que ser distinto del JWT secret.
v3.1.0 — work-unit commits y review por commit o por PR slice en ODD
Cambia como Organic Driven Development entrega el trabajo. El paso 6 del protocolo ODD ahora cierra cada tarea con al menos un work-unit commit en la feature branch (si estas en la default, branch primero), con tests y docs al lado del comportamiento, mensaje Conventional Commit, y la identidad del commit registrada en el feature document como evidencia. Traduccion: un feature de 24 tareas ya no le llega al reviewer como un unico candidato acumulado.
Despues de cada work-unit commit, con RDD habilitado, el orquestador corre gentle-ai review assess --base-ref <ultimo boundary revisado> --committed-only. Passive o low queda silencioso y el boundary avanza. High — o un assessment que falla o no esta disponible — hace que el commit mismo sea el candidato y arranca el review nativo ya. Medium defiere al PR slice: los commits acumulados desde el ultimo boundary, acotados por el presupuesto de entrega de ~400 lineas autoradas. Ojo con esto: la clasificacion de riesgo es evidence-only, asi que decide el tier el clasificador, nunca el modelo.
La estrategia de entrega y los chained PRs ahora aplican tambien al trabajo organico, no solo a SDD: al crear el feature document se forecastean las lineas autoradas y se lleva el conteo corriendo. Una estrategia por feature del vocabulario SDD (ask-on-risk, auto-chain, single-pr, exception-ok), y cuando el forecast o el conteo pasa las ~400 lineas, ask-on-risk pregunta una vez por la chain strategy. RDD sigue siendo el mismo switch del usuario; lo que cambio es el candidato que ve.
v2.0.0 — first stable release of the v2 line
The stable line is here: 462 commits since v1.20.0. Project identity now resolves consistently from explicit configuration, ENGRAM_PROJECT, Git metadata and the current directory, and session attribution is runtime-bound so writes stop landing on the wrong project, worktree or agent process.
New surface includes mem_current_project, project merging and pruning, legacy ownership rescue, curated prompt capture, topic-key upserts, review cycles, local pinning and UTF-8-safe truncation. FTS5 search gains project and scope filters, match modes and CJK/trigram support. The headline capability: mem_save can now surface likely conflicting memories, and mem_judge / mem_compare persist supersedes, conflicts_with, compatible and not_conflict verdicts that also participate in local, Git and Cloud sync.
Optional Cloud replication arrives via engram cloud serve on Postgres, with opt-in autosync carrying lease protection, bounded retries and exponential backoff. Local SQLite stays authoritative. Upgrade path: back up ~/.engram/engram.db, run engram doctor, then restart long-running MCP servers and agent sessions so they load the v2 binary. Enrolled Cloud projects must follow doctor → repair → bootstrap — there is no implicit remote migration.
Security notes: authenticated deployments require a non-default ENGRAM_JWT_SECRET, Cloud servers require ENGRAM_CLOUD_ALLOWED_PROJECTS, and ENGRAM_CLOUD_TOKEN_PEPPER must be distinct from the JWT secret.
v3.1.0 — work-unit commits and per-commit or per-slice review in ODD
This release changes how Organic Driven Development delivers work. Step 6 of the ODD protocol now closes each task with at least one work-unit commit on the feature branch (branch first when on the default branch), with tests and docs alongside the behavior, a Conventional Commit message, and the commit identity recorded in the feature document as evidence. The practical effect: a 24-task feature no longer reaches the reviewer as one accumulated candidate.
After each work-unit commit, when RDD is enabled, the orchestrator runs gentle-ai review assess --base-ref <last reviewed boundary> --committed-only on that commit. Passive or low stays silent and the boundary advances. High — or an unavailable or failed assessment — makes the commit itself the candidate and starts the native review immediately. Medium defers to the PR slice: the commits accumulated since the last reviewed boundary, bounded by the delivery budget of about 400 authored changed lines. Risk classification stays evidence-only, so the classifier decides the tier, never the model.
Delivery strategy and chained PRs now apply to organic work too, not only SDD: at feature-document creation the orchestrator forecasts authored changed lines and keeps a running count. One strategy per feature from the SDD vocabulary (ask-on-risk, auto-chain, single-pr, exception-ok), and once the forecast or running count exceeds ~400 authored changed lines, ask-on-risk asks once for the chain strategy. RDD remains the same user-owned switch — what changed is the candidate it sees.
v2.0.0 — premiere version stable de la ligne v2
La ligne stable est la : 462 commits depuis v1.20.0. L'identite de projet se resout desormais de maniere coherente a partir de la configuration explicite, de ENGRAM_PROJECT, des metadonnees Git et du repertoire courant, et l'attribution de session est liee au runtime, ce qui evite les ecritures sur le mauvais projet, worktree ou processus d'agent.
Nouveautes : mem_current_project, fusion et purge de projets, recuperation d'ownership legacy, capture de prompts curee, upserts par topic-key, cycles de revue, epinglage local et troncature compatible UTF-8. La recherche FTS5 gagne des filtres de projet et de portee, des modes de correspondance et le support CJK/trigram. Point fort : mem_save peut faire remonter les memoires potentiellement en conflit, et mem_judge / mem_compare persistent les verdicts supersedes, conflicts_with, compatible et not_conflict.
La replication Cloud optionnelle arrive avec engram cloud serve sur Postgres, plus un autosync opt-in avec protection par bail, retries bornes et backoff exponentiel. SQLite local reste la source de verite. Mise a niveau : sauvegardez ~/.engram/engram.db, lancez engram doctor, puis redemarrez les serveurs MCP de longue duree. Pour les projets Cloud enroles, suivez doctor → repair → bootstrap.
Securite : les deploiements authentifies exigent un ENGRAM_JWT_SECRET non par defaut, les serveurs Cloud exigent ENGRAM_CLOUD_ALLOWED_PROJECTS, et ENGRAM_CLOUD_TOKEN_PEPPER doit etre distinct du secret JWT.
v3.1.0 — work-unit commits et revue par commit ou par tranche dans ODD
Cette version change la maniere dont Organic Driven Development livre le travail. L'etape 6 du protocole ODD termine desormais chaque tache par au moins un work-unit commit sur la branche de feature (branchez d'abord si vous etes sur la branche par defaut), avec tests et docs aux cotes du comportement, un message Conventional Commit, et l'identite du commit enregistree dans le feature document comme preuve. Consequence : une feature de 24 taches n'arrive plus au relecteur comme un seul candidat accumule.
Apres chaque work-unit commit, si RDD est active, l'orchestrateur lance gentle-ai review assess --base-ref <dernier boundary revu> --committed-only. Passive ou low reste silencieux et le boundary avance. High — ou un assessment indisponible ou en echec — fait du commit lui-meme le candidat et declenche la revue native immediatement. Medium differe a la tranche de PR : les commits accumules depuis le dernier boundary revu, bornes par le budget de livraison d'environ 400 lignes modifiees.
La strategie de livraison et les PR chainees s'appliquent maintenant aussi au travail organique : a la creation du feature document, l'orchestrateur prevoit les lignes modifiees et tient un compte courant. Une strategie par feature issue du vocabulaire SDD (ask-on-risk, auto-chain, single-pr, exception-ok), et des que la prevision depasse ~400 lignes, ask-on-risk demande une fois la strategie de chainage. RDD reste le meme interrupteur controle par l'utilisateur.