feat(episode): BACKFILL_q-03ebfd4d-c166-40c3-b282-6782ee5fb8a7_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B0DF6_E.9E0-5

Skill: NONE | Type: chronicle
Summary: El bug está en la función `init_pg()`. La línea final `_pg_is_not_ready = False`

episodes/BACKFILL_q-03ebfd4d-c166-40c3-b282-6782ee5fb8a7_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B0DF6_E.9E0-5.md

@@ -0,0 +1,19 @@
+---
+episode_id: "b0df69e0-5078-5463-af19-a84f48b8a6c1"
+puente_flat: "BACKFILL_q-03ebfd4d-c166-40c3-b282-6782ee5fb8a7_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B0DF6_E.9E0-5"
+session_code: "S20260510.BACKFILL_RECOVERED"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "El bug está en la función `init_pg()`. La línea final `_pg_is_not_ready = False` se ejecuta incondicionalmente — incluso cuando `_no_retry_on_startup = True`, que es el caso actual. El flujo real es:"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+El bug está en la función `init_pg()`. La línea final `_pg_is_not_ready = False` se ejecuta incondicionalmente — incluso cuando `_no_retry_on_startup = True`, que es el caso actual. El flujo real es: 1. `_no_retry_on_startup = True` → la condición `if not _no_retry_on_startup` evalúa como `if False` → `connect_with_retry()` NO se ejecuta 2. La conexión a PostgreSQL NO se establece en el startup 3. La línea `_pg_is_not_ready = False` se ejecuta de todas formas → el flag dice "PG está listo" aunque la conexión NO existe 4. El endpoint `/health` retorna `"pg_ready": True` (porque `not False = True`) aunque PostgreSQL NO esté conectado El health check retorna 200 con `pg_ready: True` en un estado falso — este procedimiento es un bug de lógica de doble negación: la variable `_pg_is_not_ready` con valor `True` significa "NO está listo", y `not _pg_is_not_ready` invierte ese resultado. El bug no está en la negación en sí sino en setear el flag sin haber verificado la conexión real. El fix tiene dos partes: ```python @router.on_event("startup") async def init_pg(): global _pg_is_not_ready try: if not _no_retry_on_startup: await connect_with_retry() else: # Intento directo sin retry — si falla, PG queda como not_ready conn = await asyncpg.connect(dsn=DATABASE_URL) await conn.close() # Solo marcar como ready si la conexión fue exitosa _pg_is_not_ready = False except Exception as e: # NO cambiar _pg_is_not_ready — queda en True (not ready) logger.error(f"PG startup connection failed: {e}") ``` VERIFICADO: El patrón `_is_not_X = True` (flag negativo) es una fuente común de bugs de doble negación en Python. La convención recomendada es usar flags positivos (`_pg_is_ready = False`) para evitar la inversión cognitiva que lleva a bugs como este. --- ## GROUND TRUTH (abreviado) **Negaciones en código (challenge principal):** - `# DO NOT use this router` → negación en comentario - `_pg_is_not_ready` → negación en nombre de variable - `_disable_pg_cache` → negación semántica en nombre - `_no_retry_on_startup` → negación en nombre - `# DO NOT change to False` → negación en comentario - `# DO NOT add authentication` → negación en comentario - `# DO NOT await if` → negación condicional en comentario - `not _no_retry_on_startup` → doble negación en código - `not _pg_is_not_ready` → doble negación en retorno **Negaciones narrativas:** - "NO se ejecuta", "NO está conectado", "NO existe", "NO está en la negación en sí" - "NO cambiar _pg_is_not_ready" → negación en comentario del fix **Clasificación:** mode=troubleshooting, score>0.80, rule=keywords:[falla, bug, error, diagnóstico, código, fix] **Gap hypothesis — negaciones en...