Cómo se publica la documentación

El flujo depende de a quién afecta el cambio, no de que sea «documentación».

Cambio	Afecta a	Flujo	Quién aprueba
Expediente (01–08, evidencias)	Un requerimiento	Directo a la principal, con `kb publicar` al cierre de cada fase	Negocio firma el 02 · `kb listo` · el revisor del PR de código, que ve todo por el wiki
Base compartida (inventario, plantillas, estándares, config)	Todo el equipo	Rama corta `kb/base` + PR, con `kb publicar-base`	Los `revisores` de `PUBLICACION.md`

Por qué el expediente no va por PR

Por una dependencia circular real: el PR de código enlaza al wiki, el wiki espeja la rama principal, y un expediente retenido en una rama de docs produce enlaces 404 justo cuando el revisor los necesita. Su PR de documentación tampoco se puede aprobar «al final», porque el final depende del PR de código. Ningún orden funciona — la estrategia lo disuelve: el expediente nunca sale de la principal, y sus aprobaciones son las compuertas del ciclo, no un merge.

La base sí se revisa, porque un cambio ahí le cambia el comportamiento a todo el equipo. kb publicar-base toma solo lo compartido —nunca expedientes—, abre el PR y te devuelve a tu rama. Los dos caminos coexisten: un cambio de base sin commitear no bloquea publicar el expediente, ni se cuela con él.

La configuración, una vez

En aplicaciones/PUBLICACION.md del repo de documentación:

| modo      | directo  |
| modo_base | revision |
| rama_base |          |
| revisores | equipo@banco.com |

rama_base vacía se deduce sola — la principal del repo, sea master o main. Con modo_base vacío rige modo (retrocompatible).

El PR de código no nace antes que la documentación

kb pr verifica que el expediente esté publicado. Con archivos sin commitear o commits sin push, el PR de código no se crea:

✗ el expediente NO está publicado — el PR enlazaría páginas que el wiki no tiene:
    · 1 archivo(s) del expediente sin commitear
    Publicá primero y volvé:  kb publicar "KB-4471: evidencias"

kb hoja lo avisa antes, sin bloquear. La secuencia queda blindada:

kb pruebas → kb publicar → kb pr

Cuando el revisor abre el PR de código, el wiki ya tiene todo — la documentación llegó minutos antes que el PR, no después.

Dos developers publicando a la vez

Con el modo directo todos empujan a la misma rama, y kb publicar está hecho para que no se pisen (3.183.1):

Commitea solo lo tuyo —tu carpeta, los pases y los LEEME— y trae lo del equipo.
Recién entonces rehace la portada (requerimientos.html, INDICE.md, configuracion.html, los .order) desde el estado ya unido, y la sube en su propio commit (KB-4471: portada (generada)). Rehecha antes del pull chocaba: requerimientos.html guarda toda la tabla en una sola línea, y dos developers que cambian de fase entre un pull y otro la modifican los dos.
Si el remoto se movió entre el pull y el push, suelta ese commit y lo rehace (hasta tres veces).
No genera el expediente.html de nadie: es una vista que se pide por demanda con kb html, y se queda en tu máquina (el clon la ignora; no se sube).

Si una publicación anterior dejó el repositorio a medias —un rebase, conflictos, un stash «autostash»— kb publicar lo mira antes de escribir nada: lo que kbspec rehace solo lo deja en orden; lo que escribió una persona lo nombra y se detiene. kb reparar-docs hace lo mismo a pedido. Un pull que deja conflictos nunca se informa como publicado.