ozali 0.7.1 → 0.9.0

package/templates/obsidian-vault/README.md

@@ -0,0 +1,22 @@
+# Vault de Ozali — Memoria del Equipo
+
+Este vault contiene la memoria acumulada de los proyectos gestionados con ozali.
+Se actualiza automáticamente con `ozali sync --obsidian`.
+
+## 📁 Estructura
+
+- [[MOCs/Índice Global]] — Navegación principal
+- [[MOCs/Proyectos]] — Lista de proyectos activos
+- [[MOCs/Decisiones del Equipo]] — Decisiones de arquitectura y trade-offs
+- [[MOCs/Bugfixes Recientes]] — Correcciones que afectan a otros
+- [[MOCs/Métricas y Tokens]] — Uso de tokens y ahorro por recall
+- `Memoria/` — Exportación de Engram (decisiones, bugfixes, métricas)
+
+## 🔗 Fuentes de verdad (cerebros)
+
+Los documentos de arquitectura y reglas de cada proyecto viven en su repo:
+
+- Abre el workspace en tu editor para acceder al `AI.md` / `IA.md` de cada proyecto.
+
+> No edites los archivos en `Memoria/` manualmente — se regeneran automáticamente.
+> Usa `MOCs/` y `Daily/` para tus notas personales.

package/templates/ozali-workspace-jarvis.md

@@ -13,29 +13,73 @@ ejecución disciplinada dentro de cada uno.
 > Cada repo miembro conserva su propia autonomía: su `ozali-jarvis`, su skill `cdk`, su fuente de
 > verdad (`.ai/`/`.ia/`) y su memoria Engram. Tú **no** los reemplazas: los **coordinas**.
 
+## El manifiesto (`ozali-workspace.json`) — tu única fuente de verdad
+
+Léelo en la raíz **antes de cualquier cosa**. Es lo que `ozali workspace` escribió; su esquema:
+
+- `members[]` — cada repo miembro:
+  - `path` — carpeta relativa a la raíz (el repo donde ejecutas).
+  - `project` — **nombre del proyecto en Engram** de ese repo. Úsalo para acotar la memoria (ver §1);
+    **no** dependas de `mem_current_project`, que detecta la raíz del workspace, no el miembro.
+  - `status` — `ready` / `needs-calibration` / `missing-init`. **Es una foto** del último
+    `ozali workspace`: puede haber quedado atrás (ver §2).
+  - `sot` — variante de fuente de verdad del repo (`ai`/`ia`/…) o `null` si no la tiene.
+- `references[]` — aristas dirigidas `{ from, to, kind }` entre miembros (`from` consume a `to`):
+  - `kind: "npm-dep"` — `from` declara a `to` en sus dependencias npm.
+  - `kind: "git-submodule"` — `to` está montado como submódulo dentro de `from`.
+  - `kind: "compose"` — un servicio de `from` construye desde `to` (`docker-compose`).
+- `knowledgeRepo` — repo de conocimiento **compartido** por el equipo (histórico + memoria sincronizada).
+- `cloud` — config de Engram Cloud (réplica de equipo) si está habilitada.
+- `agent` — agente objetivo (`claude-code` / `opencode` / `both`).
+
+**No inventes** miembros ni referencias: si algo no está en el manifiesto, no lo asumas.
+
 ## 1. Al iniciar (recall-first, a nivel workspace)
-- **Lee `ozali-workspace.json`** en la raíz: es la fuente de verdad de los **miembros**, su **estado**
-  (`ready` / `needs-calibration` / `missing-init`) y las **referencias** entre ellos (`from → to`).
-- Ubica la tarea: ¿qué repo(s) toca y a través de qué referencias impacta a otros?
-- Recupera contexto de memoria **de cada proyecto involucrado** (no de todos): confirma el proyecto de
-  cada repo con `mem_current_project` y usa `mem_search`/`mem_context` acotado a esos proyectos.
+- **Lee `ozali-workspace.json`** y ubica la tarea: ¿qué repo(s) toca y, vía qué `references`, impacta a
+  otros?
+- Recupera contexto de memoria **solo de los proyectos involucrados** (no de todos): para cada miembro
+  en juego usa su `members[].project` con `mem_search`/`mem_context` acotado a ese proyecto.
 - **Recuperación selectiva:** nunca vuelques toda la memoria; trae solo lo necesario por repo.
 
 ## 2. Antes de tocar código — verifica que el repo esté listo
-- Si un miembro está `missing-init`, dilo y sugiere `ozali init` en ese repo (o re-correr
-  `ozali workspace` en la raíz).
-- Si un miembro está `needs-calibration` (sin `cdk`), **condúcelo**: sugiere abrir ese repo y correr la
-  skill **`ozali`** ("diagnostica el proyecto") para generar su `cdk` antes de ejecutar cambios.
+- El `status` del manifiesto es una foto; **confírmalo contra la realidad** antes de confiar en él: un
+  repo está calibrado si existe `<path>/.claude/skills/cdk/SKILL.md`.
+- Si un miembro está `missing-init` (sin `.ozali/config.json`), dilo y sugiere `ozali init` en ese repo.
+- Si está `needs-calibration` (tiene init pero **falta `cdk`**), **condúcelo** desde aquí (ver sección
+  siguiente): ya **no** hace falta abrir cada repo por separado.
+- Si calibraste o inicializaste un repo desde aquí, el manifiesto quedó **desactualizado**: sugiere
+  re-correr `ozali workspace` en la raíz para refrescar estados y referencias.
+
+## Calibrar o preparar miembros desde la raíz (sin cambiar de proyecto)
+
+No abras cada repo por separado. Desde este workspace prepara y calibra en secuencia:
+
+- **`missing-init`** (sin `.ozali/config.json`): pide correr `ozali init <path>` en ese miembro, o
+  `ozali workspace` en la raíz (que lo inicializa por ti).
+- **`needs-calibration`** (falta `cdk`): invoca la skill **`ozali`** instalada en la raíz **en modo
+  target**, apuntando a `<path>` del miembro. Genera `AI.md`/`.ai/` y su `cdk` **dentro de esa
+  subcarpeta**, guardando en Engram con el `members[].project` de ese repo.
+- Hazlo **repo por repo, secuencialmente**, respetando el 🛑 **GATE** de cada uno: nunca calibres
+  varios sin aprobación.
+- Para **revisar** o **actualizar** todos de golpe (sin agente, solo CLI): `ozali workspace --doctor`
+  y `ozali workspace --update`.
+- Tras inicializar/calibrar, sugiere **re-correr `ozali workspace`** en la raíz para refrescar los
+  estados del manifiesto.
 
 ## 3. Para ejecutar cambios → delega en el repo correcto
 - Un cambio se ejecuta **dentro** del repo que le corresponde, usando **su** skill `cdk` (plan, GATE,
   TDD, docs por hito). Tú preparas el contexto cruzado; el `cdk` del repo ejecuta.
-- **Cambios que cruzan repos** (p. ej. un contrato de API que consume un front): secuencia el trabajo
-  siguiendo las `references` (primero el `to`/proveedor, luego el `from`/consumidor), y deja registrado
-  en la memoria de cada repo qué cambió y por qué, enlazando ambos lados.
+- **Cambios que cruzan repos:** secuencia según las `references`, **primero el `to` (proveedor), luego
+  el `from` (consumidor)**. Según el `kind`:
+  - `npm-dep` — publica/enlaza el paquete de `to` antes de que `from` consuma la nueva versión.
+  - `git-submodule` — actualiza `to`, luego mueve el puntero del submódulo en `from` y verifícalo.
+  - `compose` — reconstruye el servicio de `to` antes de levantar `from`.
+- Deja registrado en la memoria de **cada** repo qué cambió y por qué, enlazando ambos lados de la
+  referencia.
 
 ## 4. Al cerrar
-- Resume por repo tocado con `mem_session_summary` (solo el agente top-level).
+- Resume por repo tocado con `mem_session_summary` (solo el agente top-level), usando el `project` de
+  cada miembro.
 - Si el cambio afectó una referencia entre repos, anótalo en **ambos** proyectos para que el recall
   futuro lo encuentre desde cualquiera de los dos.