Organic RDD recovery — pre-release para probar

Refresh 4. Binarios reconstruidos desde c2b91ac9. Los checksums cambiaron: vuelvan a bajar y verifiquen contra el SHA256SUMS.txt nuevo.

Si probaron antes, hay flujos nuevos. Esta ronda arregla 18 defectos que ustedes encontraron, y la guía suma los Flujos 9 a 13 para probarlos. Los flujos 1 a 8 siguen valiendo como regresión.

👉 Guía de testing paso a paso

Lo que arreglamos con el feedback de esta ronda

El pre-push después de haber pusheado (el que más costó)

Reportado por @Wladimirfn, @Denver2828, @MarsSall y @Freedom2828. Parecía un bug de Windows y no lo era: aparecía cuando el commit revisado ya estaba publicado. Ahí el boundary de publicación avanzaba más allá de la base congelada del receipt, y el error sin tipar caía en el cajón de "autoridad corrupta" sobre autoridad perfectamente sana.

@Denver2828 llegó al mismo diagnóstico por su cuenta, compilando la rama con prints, y su control lo cerró: mismo escenario sin pushear antes → funcionaba. Ahora el caso lleva un sentinel tipado y se reporta como cambio de alcance: con revisiones apagadas sale disabled/unmanaged y exit 0; con revisiones prendidas, un rechazo tipado con razón legible. Flujo 9.

Primer commit en un repo sin historia

Reportado por @lu149e, con la causa raíz confirmada por @Denver2828 — y su parche era idéntico al nuestro, línea por línea. El fallback para repos sin commits existía pero sólo se alcanzaba desde la proyección staged, y review start usa workspace por default. Ahora corre para cualquier proyección; los guardias contra fallas reales de Git quedaron intactos. Flujo 10.

El gate apagado sin upstream

Reportado por @dnlrsls (#1832), probando el fixture literal de la guía. Sin remote configurado el gate derivaba el target remoto antes de mirar el kill switch, y fallaba cerrado. Un repo sin upstream no tiene boundary que derivar, y eso no es daño de autoridad: con revisiones apagadas ahora reporta disabled/unmanaged. Con revisiones prendidas el rechazo tipado queda igual, y autoridad corrupta sigue fallando cerrada en los dos modos. De paso corregimos la guía, que no configuraba el remote que el Flujo 6 necesita.

Evidencia de riesgo medio que no decía nada

Reportado por @orlo-dragomir (#1827). El tier medio emitía una frase genérica aplicable a cualquier cambio. Ahora nombra el archivo y la señal causal.

El routing de OpenCode que no llegaba

Reportado por @orlo-dragomir (#1825). En instalación de workspace, la guía de routing se escribía en una ruta que OpenCode nunca lee. Ahora se entrega donde el agente realmente carga.

Findings sin id rechazados por no tener el id que nunca les dimos

Reportado por @ftorga. La verificación de findings candidato-causales corría contra el resultado crudo, mientras que la asignación automática de IDs pasaba después. Un finding sin id quedaba con ID vacío de un lado y R4-001 del otro: rechazo permanente. Ahora ambos lados comparan lo mismo, y las formas que deben fallar (IDs malformados, cross-lens, duplicados) siguen fallando.

Lo que arreglamos de la auditoría propia

Reprodujimos los 41 issues abiertos de la familia de revisiones contra el binario del día, con el criterio de que un callejón cuya única salida es apagar las revisiones es un bloqueante. Nueve resultaron ya resueltos. Estos son los que arreglamos ahora:

• Un artefacto histórico inválido envenenaba el store entero (#1813, #1589): una lineage terminal malformada hacía fallar status, start, abandon y reclaim para todas las demás. Ahora se pone en cuarentena con diagnóstico estructurado y las lineages sanas siguen operando. Lo no-terminal, otras clases de error, y una lineage nombrada explícitamente siguen fallando cerrado.
• START con deadline propio (#1778): 25 segundos fijos cortaban candidatos válidos grandes sin ninguna continuación posible.
• Transiciones ejecutables literales (#1745): el producto imprimía --captured-results true y el parser lo rechazaba. Un agente que obedece al pie de la letra se trababa en cada revisión. Flujo 11.
• Finalize sin evidencia dice qué hacer (#1663, #1788): antes devolvía "continuá el estado actual" para siempre. Ahora nombra los dos comandos. Flujo 12.
• Rechazos que nombran el escape (#1812, #1641): combinaciones de flags no soportadas ahora dicen el comando exacto para salir — y cuando hay dos intenciones posibles, nombran las dos. Flujo 13.
• Grafo de recovery (#1744, #1816, #1782): sucesores que eligibility, start y el store aceptaban quedaban bloqueados por un gate del CLI; recovery de release-scope ahora acepta un commit de un solo padre; y una cadena lineal de receipts dejó de reportarse como convergencia.
• Schema de evidencia publicado (#1775) y la causa real en el envelope de error (#1666, #1807).
• Dos fallbacks de plataforma (#1781 macOS con perfiles administrados, #1804 ExFAT). Estos no los podemos verificar en Linux — si alguien tiene una Mac con perfil administrado o un volumen ExFAT, ese reporte nos sirve muchísimo.

Qué necesitamos de esta ronda

1. Los Flujos 9 a 13, que son los nuevos.
2. Los Flujos 1 a 8 de nuevo, como regresión — sobre todo el 6, que ahora arranca configurando el remote.
3. Si están en macOS, cualquier señal sobre los dos fallbacks de plataforma.

Reporten en el PR #1801 como vienen haciendo. Este feedback es literalmente lo que decide el merge — de las últimas dos rondas salieron 18 arreglos.