refacil-sdd-ai 4.1.0 → 4.1.2

package/README.md

@@ -43,7 +43,7 @@ npm update -g refacil-sdd-ai
 refacil-sdd-ai update          # en cada repo donde se use
 ```
 
-En Claude Code el hook `check-update` hace esto automaticamente al iniciar sesion. Si la nueva version incluye migraciones de estructura (ej. nuevo patron de documentacion), el hook informa al LLM y propone ejecutar `/refacil:update` — la skill detecta que aplica y omite lo que ya esta al dia.
+En Claude Code / Cursor el hook `check-update` (cada sesion) sincroniza skills y `compact-guidance`; solo si la **deteccion automatica** (`lib/methodology-migration-pending.js`) encuentra migracion de metodologia pendiente se escribe el flag y `notify-update` puede pedir `/refacil:update`. Si no hay migracion, no se molesta al usuario. La skill `/refacil:update` usa `refacil-sdd-ai migration-pending` como mismo criterio.
 
 ### Desinstalar
 
@@ -64,7 +64,7 @@ npm uninstall -g refacil-sdd-ai
 |---|---|
 | `refacil-sdd-ai init` | Instala skills y hooks en el repo actual |
 | `refacil-sdd-ai update` | Re-copia skills y hooks a la ultima version |
-| `refacil-sdd-ai migration-pending [--json]` | Misma deteccion que hooks/`notify-update`; exit 1 si hay migracion de metodologia pendiente (uso en `/refacil:update`) |
+| `refacil-sdd-ai migration-pending [--json]` | Misma deteccion que hooks/`notify-update`; exit 1 si hay migracion pendiente; con exit 0 tambien borra `.refacil-pending-update` obsoleto (igual que al inicio de `check-update`) |
 | `refacil-sdd-ai clean` | Elimina skills y hooks SDD-AI del repo |
 | `refacil-sdd-ai help` | Ver ayuda |
 
@@ -72,7 +72,7 @@ npm uninstall -g refacil-sdd-ai
 
 | Comando | Descripcion |
 |---|---|
-| `refacil-sdd-ai check-update` | (`SessionStart`) Verifica nueva version, sincroniza skills y `compact-guidance` en AGENTS.md |
+| `refacil-sdd-ai check-update` | (`SessionStart`) Limpia flag de update obsoleto si no hay migracion; npm opcional; sincroniza skills y `compact-guidance` en AGENTS.md |
 | `refacil-sdd-ai notify-update` | (`UserPromptSubmit` / `beforeSubmitPrompt`) Solo actua si hay migracion de metodologia pendiente (misma logica que `/refacil:update`); si no, no interrumpe |
 | `refacil-sdd-ai check-review` | (`PreToolUse`) Bloquea `git push` si falta `.review-passed` en algun cambio activo |
 | `refacil-sdd-ai compact-bash` | (`PreToolUse`) Reescribe comandos Bash bare via `updatedInput` |
@@ -106,6 +106,8 @@ npm uninstall -g refacil-sdd-ai
 | `refacil-sdd-ai bus inbox [--session <s>]` | Ver mensajes nuevos |
 
 > Los subcomandos `join/leave/say/ask/reply/attend/inbox` tambien existen como **skills** dentro del IDE (`/refacil:join`, etc.). En la mayoria de los casos conviene usar las skills; los comandos del CLI son para scripting o debugging.
+>
+> **Coordinacion entre repos** (solicitudes por `ask`, acuerdos en sala, `/refacil:propose`, cierre al solicitante): tras `init` queda en `.claude/skills/refacil-prereqs/` y `.cursor/skills/refacil-prereqs/` el archivo **`BUS-CROSS-REPO.md`** (no duplicar aqui el contrato completo).
 
 ---
 
@@ -359,10 +361,11 @@ Bus local (WebSocket sobre `127.0.0.1`) para que los agentes de distintos repos
 
 **Patron optimo**: antes de arrancar una tarea que puede requerir consultar otro repo, ir a la ventana del otro repo y decir *"atiende el bus"*. Eso lo pone en `/refacil:attend` y la conversacion entre agentes ocurre en background sin que el dev cambie de ventana.
 
+**Convenciones SDD-AI en el bus**: quien esta en la sala entro con `/refacil:join` (metodologia ya activa en el repo). Las **solicitudes de cambio** a otra sesion van con **alcance claro** en el `ask` (sin pegar la guia en cada mensaje); el repo destino canaliza con **`/refacil:propose`** y quien implementa **cierra por bus** con quien pidio el trabajo. Detalle y casos limite: `refacil-prereqs/BUS-CROSS-REPO.md` en las skills instaladas.
+
 **Observador puro** (0 tokens): `refacil-sdd-ai bus watch <session>` o `refacil-sdd-ai bus view` para la UI web.
 
 > **Diagramas, escenarios y pitch**: ver `refacil-bus-diagrams.md` (incluido en el paquete) — incluye arquitectura, flujo con attend, flujo sin attend, tabla comparativa de impacto y guia de decision visual (Mermaid).
->
 
 ### Limitaciones conocidas
 
@@ -375,7 +378,7 @@ Bus local (WebSocket sobre `127.0.0.1`) para que los agentes de distintos repos
 ## Que se instala en tu repo
 
 ```
-.claude/skills/refacil-*/    # Skills Claude Code (incluye refacil-prereqs con OPENSPEC-DELTAS.md)
+.claude/skills/refacil-*/    # Skills Claude Code (incluye refacil-prereqs: OPENSPEC-DELTAS.md, BUS-CROSS-REPO.md, …)
 .claude/agents/refacil-*.md  # Sub-agentes (auditor, investigator, validator)
 .claude/settings.json        # Hooks: check-update + check-review + compact-bash
 .cursor/skills/refacil-*/    # Skills Cursor (equivalente)

package/agents/auditor.md

@@ -11,6 +11,8 @@ Eres un lider tecnico auditor, exigente pero constructivo, que evalua el codigo
 
 **Prerequisitos**: perfil `agents` de `refacil-prereqs/SKILL.md` + modo de salida de `METHODOLOGY-CONTRACT.md`.
 
+Si inspeccionas `openspec/changes/<cambio>/` para prereqs o contexto, los marcadores **`.review-passed`** son dotfiles: **`METHODOLOGY-CONTRACT.md` §8** (no concluyas ausencia con `ls` sin `-a`).
+
 ## Guardrail: deteccion de invocacion directa
 
 Estas disenado para ser **delegado por el skill `/refacil:review`**, que resuelve el scope y escribe el marcador `.review-passed` con el JSON que emites. Si detectas que fuiste invocado **directamente** (ej. el prompt del usuario no trae un scope explicito tipo nombre de cambio activo, lista de rutas o "git-diff"), tu PRIMERA respuesta debe ser:

package/agents/validator.md

@@ -29,6 +29,10 @@ Si prefieres solo el reporte (sin aplicar fixes), respondeme con el scope explic
 
 **No procedas con lecturas ni corras tests hasta que el usuario confirme scope.**
 
+## Archivos ocultos en `openspec/changes/<cambio>/`
+
+Antes de afirmar ausencia de **`.review-passed`** u otros dotfiles, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**.
+
 ## Reglas criticas del sub-agente
 
 - **NO modificas ningun archivo**. No tienes `Edit` ni `Write`. Solo lectura + ejecucion de tests via `Bash`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "4.1.0",
+  "version": "4.1.2",
   "description": "SDD-AI: Specification-Driven Development with AI — metodologia de desarrollo con IA usando OpenSpec, Claude Code y Cursor",
   "bin": {
     "refacil-sdd-ai": "./bin/cli.js"

package/skills/archive/SKILL.md

@@ -22,7 +22,7 @@ Antes de archivar, verifica que el cambio esta realmente completo:
 
 3. **Sin archivos pendientes**: Ejecuta `git status` y verifica si hay cambios sin commitear relacionados al feature. Si los hay, sugiere hacer commit antes de archivar.
 
-4. **Review aprobado (bloqueante)**: Verifica que existe el archivo `.review-passed` en la carpeta del cambio (`openspec/changes/[nombre-cambio]/.review-passed`). Si NO existe, **detener el archivado** e informar al usuario:
+4. **Review aprobado (bloqueante)**: Verifica que existe el archivo `.review-passed` en la carpeta del cambio (`openspec/changes/[nombre-cambio]/.review-passed`) siguiendo **`METHODOLOGY-CONTRACT.md` §8** (dotfile; no concluyas por listados sin dotfiles). Si NO existe, **detener el archivado** e informar al usuario:
    ```
    No se puede archivar: el cambio no tiene review aprobado.
    Ejecuta /refacil:review primero.

package/skills/ask/SKILL.md

@@ -25,6 +25,19 @@ Si el destino no es claro, usa `/refacil:rooms` (vía `refacil-sdd-ai bus rooms`
 
 **Broadcast dirigido (`@all`)**: el broker emite un `ask` por cada miembro (excepto quien pregunta), mismo `correlationId`. Cada receptor puede `/refacil:reply` por su lado. Con `--wait`, el CLI sigue devolviendo **la primera** respuesta que llegue (no espera a todos).
 
+### Paso 1.5: Pregunta informativa vs. solicitud de cambio (en el repo destino)
+
+Quien está en la sala llegó con **`/refacil:join`** (y el repo con metodologia Refacil): **ya conoce SDD-AI**; **no** hace falta pegar en el `ask` la guía ni explicar de nuevo qué es `/refacil:propose`. Basta con que el mensaje sea **claro en alcance y criterios** para que el otro agente ejecute **su** flujo (`propose`, `apply`, etc.) sin improvisar parches.
+
+Antes de redactar el `--text`, clasifica lo que vas a pedir a `@<destino>`:
+
+| Tipo | Ejemplos | Cómo redactar el `ask` |
+|------|----------|-------------------------|
+| **Solo información** | "¿Qué payload envía Z?", "¿Dónde está el handler de X?" | Pregunta concreta. |
+| **Solicitud de cambio** en el **repo del destino** | "Agregá campo W al contrato", "Corregí el bug en el servicio que vive en tu repo", "Alineá el consumer con la spec" | Describe **qué** hay que lograr, **dónde** aplica, criterios de aceptación o enlaces a spec/conversación. El destinatario canaliza eso con **`/refacil:propose`** (y lo que siga) en **su** repo; no pidas "solo un cambio rápido" opaco cuando el impacto es código versionable, salvo orden **explícita** del usuario humano en contrario. |
+
+Si mezclas consulta + cambio, separa en dos mensajes o deja claro qué parte es solo lectura y qué parte es trabajo versionable en el otro repo.
+
 ### Paso 2: Decidir si usar `--wait`
 
 Dos modos:
@@ -61,3 +74,5 @@ Usa `Bash` con el comando elegido.
 - Si el texto tiene comillas, escápalas con `\`.
 - Nunca envíes secretos, tokens ni datos sensibles — el bus persiste los mensajes 7 días en disco local.
 - Si el destino no existe en la sala, el mensaje queda en el `inbox.jsonl` y se entregará cuando se una.
+- Si **acordaste** con otra sesion que ellos cambien su repo, ellos deben usar **`/refacil:propose`** alli y **avisarte por el bus** al terminar; si te piden cambios a ti, tu haces lo mismo aqui. Convencion completa: `refacil-prereqs/BUS-CROSS-REPO.md`.
+- Los **`ask` que son solicitudes de cambio** deben ser **sustantivos en alcance** (Paso 1.5): el receptor ya usa la metodologia; no repitas la guía en el texto. No uses el bus para pedir quick fixes opacos cuando el impacto exige SDD-AI.

package/skills/attend/SKILL.md

@@ -29,17 +29,18 @@ El comando:
 
 **Si el output contiene "Pregunta recibida del bus"**:
 1. Lee `de:`, `correlationId:` y `texto:` del output.
-2. Investiga el repo para encontrar la respuesta. Usa `Read`, `Grep`, `Glob` según necesites.
-3. Responde al bus con:
+2. Si el `texto` es una **solicitud de cambio** en **este** repo (no solo una pregunta informativa), canaliza con **`/refacil:propose`** y el flujo SDD-AI; en el `reply` resume estado o siguiente paso sin re-explicar la metodologia (quien pregunta ya esta en la sala por `join`). Ver `refacil-prereqs/BUS-CROSS-REPO.md` y `/refacil:ask` Paso 1.5.
+3. Investiga el repo para encontrar la respuesta. Usa `Read`, `Grep`, `Glob` según necesites.
+4. Responde al bus con:
    ```bash
    refacil-sdd-ai bus reply --text "<tu respuesta>"
    ```
    El broker autocompleta el `correlationId` con la última pregunta dirigida a ti (la que acabas de procesar).
-4. Si la pregunta está fuera de tu scope, igualmente responde:
+5. Si la pregunta está fuera de tu scope, igualmente responde:
    ```bash
    refacil-sdd-ai bus reply --text "fuera de mi alcance, consulta al repo X"
    ```
-5. **Vuelve a ejecutar `refacil-sdd-ai bus attend`** (paso 1) para seguir escuchando.
+6. **Vuelve a ejecutar `refacil-sdd-ai bus attend`** (paso 1) para seguir escuchando.
 
 **Si el output contiene "Sin preguntas en"**:
 - No hubo preguntas en el intervalo.
@@ -61,6 +62,7 @@ El loop continúa mientras el usuario (dev) no te dé otra instrucción o aborte
 
 ## Reglas
 
+- Si el `ask` implica **que implementes un cambio en este repo** acordado por la sala, despues de ejecutarlo usa **`/refacil:propose`** (y el flujo SDD-AI) y **cierra al solicitante** por bus (`reply` u otro canal segun `refacil-prereqs/BUS-CROSS-REPO.md`); no cierres en silencio.
 - **Siempre re-invocar attend después de responder** — un solo `attend` atiende una sola pregunta; el loop lo mantienes tú.
 - **No respondas desde conocimiento general**: usa archivos del repo como fuente. Si no sabes, dilo.
 - **No envíes secretos ni tokens** en las respuestas — los mensajes quedan 7 días en disco local.

package/skills/guide/SKILL.md

@@ -48,6 +48,10 @@ Para cuando el dev tiene varias ventanas de Claude Code / Cursor abiertas (una p
 
 **Patron tipico**: antes de una tarea que puede necesitar contexto de otros repos, el dev va a las otras ventanas y dice *"atiende el bus"*. Luego en su repo de trabajo, `/refacil:ask @<otro-repo> "..." --wait 180` trae la respuesta automatica sin saltar entre ventanas.
 
+**Acuerdos en sala**: si en el bus se pactan cambios que tocan **este** repo, el agente los encarrila con **`/refacil:propose`** (metodologia SDD-AI), no con parches sueltos salvo orden explicita del usuario. Quien implementa **cierra por el bus** con quien pidio el cambio (`reply` al mismo hilo `ask`, o `ask`/`say` segun `refacil-prereqs/BUS-CROSS-REPO.md`).
+
+**`ask` como solicitud**: si pides trabajo en **otro** repo, **alcance y criterios** claros; alli aplican **`/refacil:propose`** sin repetir la guía (ya estan en metodologia por `join`). Ver `/refacil:ask` Paso 1.5.
+
 Para supervision: `refacil-sdd-ai bus view` (UI web) o `refacil-sdd-ai bus watch <session>` (terminal). No consumen tokens.
 
 Detalle completo en el README de refacil-sdd-ai (seccion `refacil-bus`).

package/skills/inbox/SKILL.md

@@ -25,6 +25,7 @@ El CLI imprime los mensajes nuevos (si los hay) con `from`, `kind`, texto y time
 - Si hay mensajes `kind=reply` dirigidos a esta sesión, úsalos como contexto para continuar el flujo que originó la pregunta (el usuario puede haberte pedido "revisa si llegó respuesta y sigue").
 - Si hay mensajes `kind=ask` dirigidos a esta sesión sin responder, considera si corresponde responderlos con `/refacil:reply`.
 - Si hay broadcasts relevantes, resúmelos al usuario.
+- Si el hilo implica **acuerdos de cambio en este repo**, al actuar usa **`/refacil:propose`** y al cerrar avisa por bus al solicitante (`refacil-prereqs/BUS-CROSS-REPO.md`).
 
 ### Paso 3: Reportar al usuario
 

package/skills/join/SKILL.md

@@ -78,4 +78,5 @@ Reporta:
 
 - NUNCA modifiques otras secciones de `AGENTS.md` — solo agrega o actualiza el bloque entre los marcadores.
 - El LLM NO debe mantener estado del bus entre turnos; cada skill del bus es independiente.
+- Coordinacion multi-repo y acuerdos en sala (propose + aviso al solicitante): `refacil-prereqs/BUS-CROSS-REPO.md`. Al estar en la sala se asume que las sesiones **ya conocen SDD-AI**; los `ask` de solicitud no deben re-enviar la guía, solo ser claros en alcance.
 - Si el CLI retorna error (dependencia `ws` faltante, puertos ocupados), informa al usuario el mensaje literal.

package/skills/prereqs/BUS-CROSS-REPO.md

@@ -14,7 +14,8 @@ Cuando el trigger de la skill se cumpla:
 
 1. **Verificar salas activas**: ejecuta `refacil-sdd-ai bus rooms` para ver las salas y sus miembros.
 2. **Evaluar precondiciones**:
-   - **Si hay una sala activa Y el repo que necesitas consultar ya esta en ella**: puedes ejecutar `/refacil:ask @<nombre-repo> "pregunta concreta" --wait 180` directamente. **Informa al usuario antes de enviar** ("voy a preguntar a @X en la sala Y: ..."). Si el otro repo esta en `/refacil:attend` responde automatico; si no, el dev va a esa ventana y pide `/refacil:inbox`.
+   - **Si hay una sala activa Y el repo que necesitas consultar ya esta en ella**: puedes ejecutar `/refacil:ask @<nombre-repo> "..." --wait 180` directamente. **Informa al usuario antes de enviar** ("voy a preguntar a @X en la sala Y: ..."). Si el otro repo esta en `/refacil:attend` responde automatico; si no, el dev va a esa ventana y pide `/refacil:inbox`.
+   - **Si el `ask` es una solicitud de cambio** en el repo del destino (no solo una pregunta informativa), redacta **alcance y criterios** concretos; la sesion destino ya opera bajo SDD-AI (unio con `/refacil:join`) y debe canalizar el trabajo con **`/refacil:propose`** alli sin que repitas la guía en el mensaje. Ver `/refacil:ask` Paso 1.5 y la seccion "Acuerdos en la sala" mas abajo.
    - **Si no hay sala, o el repo que necesitas no esta en ninguna**: **no crees la sala por tu cuenta**. Pide al usuario que ejecute `/refacil:join <nombre-sala>` en **esta** sesion y tambien en la sesion del otro repo (otra ventana de IDE). Ambos repos deben estar en la misma sala. Una vez confirmado, vuelve al paso 2.
 
 Si el usuario no conoce el bus o no sabe como configurarlo, remitelo a `/refacil:guide` (seccion "Bus entre agentes") antes de intentar la consulta.
@@ -30,9 +31,25 @@ Cada skill decide que hacer con la respuesta:
 - `verify`: incorporarla al reporte combinado como SUGGESTION; si revela un bug real, escalar a WARNING/CRITICAL.
 - `bug`: usarla para confirmar si el fix va en este repo, en el otro, o en ambos (en cuyo caso el otro tendra su propio `/refacil:bug`).
 
+## Acuerdos en la sala y cambios en este repo
+
+Un **`ask` cuya intencion es pedir trabajo** (implementacion, correccion, refactor sustantivo) en el repo de la sesion destino cuenta como **solicitud de cambio**: el texto debe ser **claro en alcance** para que el destino ejecute **`/refacil:propose`** (y el flujo habitual) en **su** repo. **No** hace falta incrustar la guía metodológica en el mensaje: quien está en la sala ya entro por **`/refacil:join`** y el repo sigue SDD-AI. Igual criterio si la conversacion mezcla `say` y `ask`. Excepcion: si el **usuario humano** pide otro procedimiento.
+
+Si en la sala (mensajes `say`, hilos `ask` / `reply`, o una mezcla) **se llega a acuerdos** que implican **modificar este repositorio** (codigo, contratos, docs bajo metodologia), ese trabajo debe seguir SDD-AI en **esta** sesion: como minimo **`/refacil:propose`** y el flujo normal (revision humana, `/refacil:apply`, etc.). No lo sustituyas por ediciones o commits ad-hoc **salvo** que el usuario te ordene explicitamente otro camino (hotfix de emergencia, spike desechable, etc.).
+
+**Cierre con quien pidio el cambio**: quien **implementa** aqui, al terminar el ajuste acordado (o al dejar un estado claro: listo, PR, bloqueo, delegacion), **debe avisar por el bus** a quien origino el pedido o a la sala segun corresponda:
+
+- Si el trabajo nacio de un **`ask`** a esta sesion y el contexto sigue siendo el mismo hilo: **`/refacil:reply`** con el resumen (el broker enlaza `correlationId`).
+- Si el acuerdo fue por **`say`**, hay varios interlocutores, o ya no aplica el mismo `ask`: **`/refacil:ask @<sesion-solicitante> "..."`** con el cierre, o **`/refacil:say`** si el cierre debe ser visible para **toda** la sala.
+
+Por defecto: **no cierres en silencio** cuando otra sesion esperaba el resultado del acuerdo.
+
 ## Que NO hacer
 
 - No asumas el comportamiento del otro repo sin consultar.
 - No ejecutes `/refacil:join` por tu cuenta — crear o unirse a una sala es decision del dev (implica que el otro repo tambien debe unirse desde su ventana).
 - No ejecutes `/refacil:ask` sin antes verificar que la sala existe y el repo destino esta en ella. Si alguna precondicion falla, pide al dev que la resuelva.
+- No envies **solicitudes de cambio** vagas (sin alcance ni criterios) esperando que el otro adivine el trabajo; el destinatario ya usa SDD-AI (ver `/refacil:ask` Paso 1.5). Tampoco repitas la guía en cada `ask`.
 - No insistas si el dev prefiere resolverlo por otra via (lectura directa, docs, pregunta verbal a un compañero).
+- No omitas `/refacil:propose` (u orden equivalente del usuario) para cambios acordados en sala que afecten este repo sin una instruccion explicita en contrario.
+- No dejes de **responder por el bus** al solicitante o a la sala cuando termines un ajuste que pedian otros (ver seccion anterior).

package/skills/prereqs/METHODOLOGY-CONTRACT.md

@@ -98,7 +98,13 @@ Si el usuario no pide detalle, usa modo conciso.
 
 ## 7) Persistencia de evidencia de review
 
-- `archive` requiere `.review-passed` como precondicion bloqueante.
+- `archive` requiere `.review-passed` como precondicion bloqueante (comprobar existencia segun **§8**).
 - Al archivar cambios regulares (via OpenSpec), la metadata de `.review-passed` debe persistirse en `openspec/specs/`.
 - El formato recomendado es `review.yaml` dentro de cada carpeta de spec afectada.
 - Si no se puede mapear de forma confiable a specs concretos, registrar la evidencia en `openspec/specs/review-metadata.yaml`.
+
+## 8) Archivos ocultos bajo `openspec/changes/<cambio>/`
+
+- **`.review-passed`** y cualquier archivo cuyo nombre empiece por **`.`** son **ocultos** en muchos entornos: en shell, **`ls` sin `-a` / `-la` no los lista** — no concluyas que no existen por eso (evita falsos negativos en prereqs, review, verify, `up-code` y archive).
+- **Preferido**: herramienta **`Glob`** (patron bajo `openspec/changes/<nombre>/`), **`Read`** sobre la ruta exacta `openspec/changes/<nombre>/.review-passed`, o Bash **`test -f`** / **`[ -f ... ]`** sobre esa ruta.
+- Si el usuario dice que el archivo existe y tu comprobacion lo nego, **re-verifica** con uno de los metodos anteriores antes de insistir.

package/skills/prereqs/SKILL.md

@@ -32,6 +32,6 @@ Convenciones Refacil al delegar a skills `openspec-*`: ver `OPENSPEC-DELTAS.md`
 
 ## BUS-CROSS-REPO.md
 
-Protocolo compartido para consultar a otros repositorios via `refacil-bus`. Aplica en `explore`, `propose`, `verify` y `bug` cuando la skill detecta una dependencia cross-repo. Ver `BUS-CROSS-REPO.md` (misma carpeta).
+Protocolo compartido para consultar a otros repositorios via `refacil-bus` y para **acuerdos en sala** (propose + cierre al solicitante). Aplica en `explore`, `propose`, `verify` y `bug` cuando la skill detecta dependencia cross-repo o coordinacion multi-repo. Ver `BUS-CROSS-REPO.md` (misma carpeta).
 
 Si faltan estos archivos, ejecuta `refacil-sdd-ai update` (o `init`).

package/skills/propose/SKILL.md

@@ -33,6 +33,10 @@ Si el cambio propuesto involucra un contrato con otro sistema (un endpoint que o
 
 Usa la respuesta para ajustar `specs.md` / `design.md` antes de pasar a revision humana.
 
+### Paso 2.6: Origen acordado en la sala del bus (si aplica)
+
+Si el cambio surge de un **acuerdo en `refacil-bus`** (say / ask / reply) que compromete **este** repo, igualmente es un propose aqui: no acortes el flujo metodologico salvo orden explicita del usuario. No hace falta que el `ask` en sala traiga la guía: quien pregunta asume que esta sesion ya opera SDD-AI. Al **implementar** despues (apply, etc.), quien ejecuta debe **cerrar por el bus** con quien pidio el trabajo; ver `refacil-prereqs/BUS-CROSS-REPO.md` (seccion acuerdos en la sala).
+
 ### Paso 3: Revision del desarrollador (Human-in-the-Loop)
 
 **IMPORTANTE**: Este paso es OBLIGATORIO. El desarrollador debe revisar y aprobar los artefactos antes de implementar.
@@ -80,4 +84,5 @@ Quieres que continue con /refacil:apply?
 - Siempre explorar el codebase ANTES de generar artefactos (para que el design sea realista)
 - Los criterios de aceptacion deben ser especificos y testeables
 - El Paso 2.5 (bus cross-repo) es **opcional** — solo invocarlo si el cambio toca un contrato con otro sistema. Ver `refacil-prereqs/BUS-CROSS-REPO.md`.
+- El Paso 2.6 aplica cuando el input viene de **acuerdos en sala**; no implica saltarse artefactos ni escribir codigo en esta skill.
 - **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 4, invocar inmediatamente el **Skill tool** con `skill: "refacil:apply"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:apply`. (Ver `METHODOLOGY-CONTRACT.md §5`.)

package/skills/reply/SKILL.md

@@ -34,6 +34,7 @@ Reporta al usuario que la respuesta se envió.
 
 ## Reglas
 
+- Si acabas de **implementar** un cambio pedido por otro agente y este `reply` es el **cierre** (hecho / PR / bloqueo), incluye ese resumen en el texto; es el canal por defecto para contestar a quien hizo el `ask` original (mismo hilo).
 - Entrecomilla correctamente el texto.
 - Responde solo desde tu conocimiento de ESTE repo. Si la pregunta cae fuera de tu scope, dilo explícitamente: `"fuera de mi alcance, esto lo sabe el repo X"`.
 - Si no hay pregunta pendiente dirigida a ti y no quieres engancharla, usa `/refacil:say` en su lugar.

package/skills/review/SKILL.md

@@ -20,7 +20,7 @@ Este skill es un **wrapper delgado** que delega el review pesado al sub-agente `
   3) Cambios no commiteados (`git diff`)
 - Si hay multiples cambios activos en `openspec/changes/` y no hay `$ARGUMENTS`, **detente** y pide al usuario seleccionar explicitamente cual cambio revisar. **No invoques al sub-agente con scope ambiguo.**
 
-**Review ya aprobado**: Si el cambio objetivo ya tiene `.review-passed`, verifica si hay cambios posteriores al review:
+**Review ya aprobado**: Si el cambio objetivo ya tiene `.review-passed`, verifica si hay cambios posteriores al review (existencia del marcador: **`METHODOLOGY-CONTRACT.md` §8**):
 1. Lee la `date` del `.review-passed`.
 2. Compara con `git log --since="[date]" --oneline` y `git status --porcelain`.
 3. **Si hay cambios nuevos**: elimina el `.review-passed` anterior y continua (invoca al sub-agente para re-evaluar).

package/skills/review/checklist-back.md

@@ -48,7 +48,8 @@
 - Las consultas usan indices apropiados
 - No hay queries N+1
 - No hay inyeccion SQL/NoSQL posible (queries parametrizadas con el ORM/driver del proyecto)
-- Las migraciones (si hay) son reversibles y no rompen datos existentes
+- **Esquema (DDL)**: por defecto, no usar el sistema de migraciones de TypeORM ni `synchronize` para aplicar o versionar cambios de BD (ni `MigrationInterface`, ni depender de `migration:run` / `migration:generate` en el flujo de despliegue de la app). Los cambios de esquema se entregan como **scripts explícitos** (p. ej. `.sql` versionados bajo convención del repo) para que **quien opera el motor** los ejecute **manualmente y aparte** en cada entorno (Postgres, MySQL, etc.). **Excepción**: si `AGENTS.md` define **explicitamente** como regla de **ese** repositorio otro mecanismo (p. ej. migraciones TypeORM u otro pipeline acordado), marca esta viñeta como **N/A** y revisa solo que el cambio cumple lo documentado allí (sin exigir scripts manuales).
+- Si aplica la politica por defecto (scripts manuales): los scripts de esquema entregados documentan orden de ejecución, son reversibles o describen rollback, y no destruyen datos existentes sin plan explícito. Si aplica la excepción por `AGENTS.md`, marca **N/A** o evalua segun lo que ese archivo exija para migraciones.
 
 ## B7. Caching
 - Consultas repetitivas a BD usan cache **distribuido** (no cache local en memoria del proceso — evitar reinicios por falta de RAM)

package/skills/say/SKILL.md

@@ -35,3 +35,4 @@ Reporta al usuario que el mensaje se envió con su id.
 - La sesión debe estar unida a una sala; si no, el CLI retornará error.
 - Mensaje corto y útil — evita spam en el bus.
 - Si el usuario pide "avisa al equipo ...", usa `say`. Si pide "pregúntale a X ...", usa `ask`.
+- Si un hilo en sala **acuerda cambios en este repo**, sigue `refacil-prereqs/BUS-CROSS-REPO.md`: **`/refacil:propose`** y cierre por bus con quien pidio el trabajo al terminar.

package/skills/up-code/SKILL.md

@@ -30,7 +30,7 @@ Ejecuta `git branch --show-current` para obtener el nombre de la rama.
 Antes de continuar, verifica si hay cambios activos en `openspec/changes/` (excluir carpeta `archive/`).
 
 Si hay cambios activos:
-1. Para cada carpeta activa, verifica si existe el archivo `.review-passed`.
+1. Para cada carpeta activa, verifica si existe el archivo `.review-passed` (marcador oculto: **`METHODOLOGY-CONTRACT.md` §8** — no concluyas por `ls` sin `-a`).
 2. Si **todas** tienen `.review-passed` → continua al paso 3.
 3. Si hay **una sola** carpeta sin `.review-passed`:
    - Informa al usuario cual es.

package/skills/verify/SKILL.md

@@ -21,6 +21,10 @@ Determina el scope antes de invocar al sub-agente. Prioriza este orden:
 
 No invoques al sub-agente con scope ambiguo.
 
+### Paso 0.5: Archivos ocultos bajo `openspec/changes/` (evitar falsos negativos)
+
+Si **esta sesion** inspecciona el directorio del cambio (listar archivos, confirmar precondiciones) **antes o despues** de delegar, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**. El sub-agente `refacil-validator` sigue la misma regla.
+
 ### Paso 1: Delegar al sub-agente refacil-validator
 
 Invoca a `refacil-validator` pasandole:
@@ -86,6 +90,7 @@ Lista los issues para que el usuario los corrija manualmente. Sugiere `/refacil:
 ## Reglas
 
 - **Siempre delega al sub-agente** para el analisis (pasos 1-3). No repliques aqui la logica de lectura de specs ni de ejecucion de tests.
+- **Dotfiles en `openspec/changes/`**: nunca afirmes ausencia de `.review-passed` (u otros `.…`) basandote solo en `ls` sin `-a`; ver `METHODOLOGY-CONTRACT.md` §8 y Paso 0.5.
 - **Las correcciones SOLO las aplica este wrapper** (Paso 4), despues de aprobacion explicita del usuario. El sub-agente es read-only.
 - **No muestres el bloque JSON al usuario**. Es solo metadata para parsear el resultado.
 - **Las correcciones deben ser quirurgicas**: solo lo necesario para resolver los issues reportados.

package/templates/methodology-guide.md

@@ -36,6 +36,8 @@ Canal local de texto plano entre sesiones de Claude Code / Cursor corriendo en d
 
 Uso tipico: antes de arrancar una tarea que puede requerir contexto de otros repos, el dev pone al agente de cada otro repo en `/refacil:attend`. Despues, en su repo de trabajo, el LLM puede pedir contexto con `/refacil:ask @<repo> "..." --wait` y recibir la respuesta automaticamente sin que el dev salte entre ventanas.
 
+Si en la sala se acuerdan cambios que afectan un repo, en ese repo se sigue el flujo SDD-AI (`/refacil:propose`, etc.) y quien implementa **avisa por el bus** al que pidio el cambio al terminar (detalle en `refacil-prereqs/BUS-CROSS-REPO.md` en el paquete). Los **`ask` que piden trabajo** en otro repo deben ir con **alcance claro**; el destino usa **`/refacil:propose`** por convención (no hace falta pegar la guía en el mensaje). Skill `/refacil:ask`.
+
 CLI util para el dev: `refacil-sdd-ai bus view` (abre UI web en el navegador), `bus watch <session>` (panel en terminal), `bus status`, `bus rooms`. No consumen tokens.
 
 ## Estructura de documentacion del proyecto