Repository navigation
P0: Dev Swarm sin ticks ~25h y 0 workers; reconciliar binding AG-53/54 post-merge #193
Description
Incidente observado (18 Oct 2026, 17:10-17:12 UTC)
Este es un informe de regresión post-merge y verificación en runtime, no una solicitud de crear otro control plane. Prioridad alta: reparar el circuito InnerOS existente, local-first y sin gasto de agentes externos salvo bloqueo justificado.
Evidencia reproducida vía MCP Small
dev_swarm_scheduler_status->ok:true,state.enabled:true,state.max_concurrent:4,state.last_tick_at:2026-10-17T16:20:39.295541+00:00,state.last_executor_tick_at:2026-10-17T14:24:40.359696+00:00. La telemetría actual es de2026-10-18T17:10:50.625127Z, es decir ~25 horas sin tick registrado.- La misma consulta devuelve
active_worker_count:0,active_ops_count:80,proposed_count:8. Capacity governor:admittable_now:8, CPU y RAM bajo umbrales de throttling,throttled:false; la VRAM al 95% se clasifica como consumo BASELINE de Qwen, sin workers. No dar por hecho un problema de recursos. reconcile.launch_dispatch_reconcile:requeued:0, failed:0, a pesar de trabajos bloqueados. Determinar si el timer/tick está detenido, si no persiste estado o si la selección/admisión no recorre estas tareas; inspeccionar los logs y ejecución real en AMD e Intel, no inferir desde el booleanoenabled.ops_9c06568886ec(Joshua local Dev Swarm): worktree creado, worker despuésfailed_retryable/stale_worker_reclaimed_for_retry.ops_9f19f5ae62d6(repo plataforma): modelo intentó sustituir archivos críticos por muy pocas líneas; gate correctamente rechazóautonomous_diff_deletes_too_many_lines. No relajar ese guardrail: reparar model-output/patch contract para producir cambios pequeños y válidos.ops_12de9cf5dc58:compileallencontró SyntaxError en código generado de AG-09;unittestdetectó 0 tests. No marcar éxito si no hay cambios reales/validación.
Canal correo/oportunidades también roto
ops_283703a1f602: clasebusiness_ops, laneemail_intelligence,dispatch_mode:business_handoff,do_not_auto_dispatch:true, proveedorralfia; la evidencia guardada devuelveerror:do_not_auto_dispatch,runner:blocked, estadowaiting_for_binding. Sin embargo,mainenplatform/inneros_core_runtime/execution_binding.pytiene_is_business_ops_email_envelopey devuelveEMAIL_INTELLIGENCE_RUNNERread-only/ready sin requerir repo Git. Comprobar si el binding almacenado es histórico, si el código live está desfasado, o si el orquestador evalúa por una ruta distinta. Recalcular binding con la MISMA tarea real y ver logs.ops_ec7e2ed7c5ff: oportunidad enviada a AG-54 el 18 Oct,pending_human_reviewporcircuit_breaker_reason: Activity task failed, workflowops_task:ops_ec7e2ed7c5ff, run01a14da9-ad33-7ba8-a4c3-a2924e1deda2. Inspeccionar fallo Temporal concreto, no declararlo revisión humana normal.- AG-21/22/23/24 y AG-53/54/55 ya aparecen registrados en 61 Agent Cards; no inventar nuevos agentes ni un segundo scheduler.
Cambios en GitHub y hueco de certificación
- PR fix(dev-swarm): silent stall when launch succeeds without worker #187 (Dev Swarm silent stall watchdog) fusionado 17 Oct; su checklist dejó sin validar el despliegue/ejecución real en AMD.
- PR P0: repair IDE ops lifecycle end to end #183 (IDE lifecycle), Restore MCP runtime and IDE profile contracts #189/Make MCP launcher self-contained #190 (MCP launcher/profile) y Fix Cursor worker survival after oneshot dispatch #192 (Cursor transient worker survival; fusionado 18 Oct) están en main, pero Fix Cursor worker survival after oneshot dispatch #192 es de Cursor, no una prueba de scheduler Dev Swarm.
- PR fix(ops): canonical worktree materializer and claim stability (ops_8691cdde5c05) #191 (worktree materializer / claim preflight) sigue abierto, igual fix(ops): worktree materializer + claim preflight (ops_8691cdde5c05) #188 (solapado, diff mucho más amplio). Revisar conflictos/alcance y elegir una única ruta antes de fusionar. No hacer auto-merge.
docs/INNEROS_RELEASE_ATTESTATION.jsondemainaún dicehosts.amd.verified:falseyhosts.intel.verified:false, sin SHA de runtime; no presumir despliegue por commit GitHub.
Reparación solicitada sobre la infraestructura YA EXISTENTE
- Diagnóstico read-only de timer/servicio/invocación de
scheduler_tick, worker processes, journals, Temporal, Mongo, imports y hashes de código realmente cargados en AMD e Intel. Comparar con main actual; documentar root cause y último tick. Sin resets/rsync amplios. - Aplicar solo el parche o promoción mínima y reversible con snapshot + rollback; conservar PRs ya fusionados y no cruzar carriles de hackathon. Mantener ejecutor local AMD Qwen y fallback Intel Ollama, sin gastos externos.
- Canary Dev Swarm real: nueva tarea interna desde creación → selección → lease/worker real → worktree → cambio pequeño en código → tests relevantes no vacíos → commit SHA → verificador independiente → estado terminal y notificación al owner. No falsos
runningni éxito por launch/ACK. Verificar al menos dos ticks consecutivos, capacidad 1→N, recuperación tras error y no duplicados. - Canary AG-53/54 con mensaje sintético: clasificar correo, enlazar origen y deadline, preparar borrador por ejecutor
email_intelligence_localsin worktree de código; no pedir aprobación de gasto para internos ni crear OPS no ejecutables. Validar Temporal, idempotencia y una única notificación útil. No enviar formularios automáticamente. - Solo después probar AG-55 Browser Ops con un formulario de prueba, cumplimentar como borrador, preservar consentimiento y aprobación humana antes de enviar postulaciones reales.
- Cierre únicamente con estado BUILD / TESTED / DEPLOYED, timestamp, main SHA y hashes de procesos AMD/Intel, pruebas MCP externas, run/task IDs, resultado PASS o blocker con evidencia y rollback. Actualizar attestations cuando exista prueba, no antes.
Referencias: PRs #187, #183, #189, #190, #192, #191 y #188 en este repositorio. Mantener separación del carril Alexa/AMD ACT III y no duplicar trabajo ya asignado.
Activity
Rafa-Innerchispa commentedon Oct 19, 2026
Auditoría 19-Oct, Joshua ops_9c06568886ec, sin duplicación: PR #200 existente contiene la reparación propuesta de root
.. Revisé y reforcé su rama con commits70f13189y2c2327d5: reconocesrc/...y./src/...cuandopackage_root='.', conserva exclusión de tests/diagnósticos y rechaza rutas de otro paquete cuando el root es anidado. CI iniciado, pendiente de resultado. No es un E2E PASS ni deployment. Worker Joshua sigue FAIL, intenta sustituirsrc/service_operations.jsde 22.5K caracteres por 979/1319 bytes; exigir fail-closed de diffs destructivos y no activar requeue ciego. Pendiente validar suite CI, rollback, runtime AMD/Intel, mismo task_id con diff seguro y pruebas de negocio Joshua (memoria+correo autorizado+flujo aprobado/auditado). Seguimiento a Cursor por mensaje relacionado conmsg_91de4faa91edf5f7.Rafa-Innerchispa commentedon Oct 19, 2026
Seguimiento live 2026-10-19: La tarea original Joshua
ops_9c06568886ecsiguequeued+dev_swarm_retry_requested=true, binding localinternal_bounded_local/ready; el scheduler estáenabledcon ticks recientes y 0 workers, pero no incluyequeueden el selector de reintentos, aunque el reconciliador la coloca justamente en ese estado. Se implementó el parche PR #206 (ramafix/dev-swarm-queued-retry-pickup-20261019, SHA7847a0c6) que permite solo queued + retry explícito con gates por lane/repo/no-autodispatch, con test de Joshua y tests negativos de externas. Aún no considerar deployed. Inspección MCPlocal_exec.inspect_repo.v1reporta checkout local plataforma en branchfix/coordination-systemic-recoveryHEADfd37005f, distinto delmainactual: desplegar solo desde SHA aprobado, con fuente aislada,sync_platform_runtime_from_git.sh --dry-run, backup/rollback y verificación de SHA realmente importado por procesos. Cursor recibió seguimiento en la cadena previa para promoción/verification sin tareas nuevas ni gasto IDE sin permiso.Rafa-Innerchispa commentedon Oct 19, 2026
Cierre BUILD/TESTED 19-Oct-2026: PR #206 fusionado a
main(5f8ad7225bd10121a6d95255509bc2ac1f285bfb). GitHub Actions run39339478003:189 passed, 9 subtests passed. Correcciones: (1) scheduler recoge exclusivamentequeuedcondev_swarm_retry_requested=truey mantiene gates de repo/lane/no-autodispatch; (2) Integration Guardian resuelve SHA abreviado inequívocamente contra Git y lo compara con SHA completo, sin permitir hash ambiguo o distinto. DEPLOYED / Joshua E2E = NO: inspección MCP posterior al merge aún muestra checkout local enfix/coordination-systemic-recoveryHEADfd37005f; Joshuaops_9c06568886ecsiguequeued, scheduler 0 workers. Cursor notificado en el mismo hilo (msg_5d1dcc7efb7cdcd8) para promoción SHA-pinned con backup/dry-run/import-hash y canario de la misma OPS, sin activar consumo de agentes externos ni crear nueva OPS. No cerrar #193 hasta hashes de runtime AMD/Intel, estado Mongo/Temporal coherente y E2E verificable.Rafa-Innerchispa commentedon Oct 19, 2026
Auditoría de regresión y ramas (19-Oct): Ya existían avances parciales, pero también falsos positivos históricos.
ops_744b5a2c85f6(8-Oct) estácompletedcon 8 tests PASS, mientrasevidence.agent_result.ok=false,files_count=0,objective_files_count=0,reason=coding_task_requires_non_bridge_objective_diff; no debe restaurarse ese gate laxo.ops_096993ac0911sí registra un commit Cursor y seis objective paths. PR #174 documenta canario local Intel Qwen commitfc2e4ad..., pero sin certificación posterior de AMD/Intel;docs/INNEROS_RELEASE_ATTESTATION.jsonaún marca ambosverified:false. PR #187 dejó despliegue AMD unchecked. PR #194 añadió un sync rsync inicialmente no protegido, sustituido por el de SHA-pinned/backup en PR #205: determinar por logs reales si se aplicó antes y produjo drift, sin asumirlo. Branchfix/coordination-systemic-recoveryfd37005fdiverge de main debido al squash de PR #200; eso no prueba pérdida de esos commits. LEPinspect_repopasó defd37005fen rama a detached1dd76253(main actual), pero es solo checkout, no código importado por procesos. Los PR #188/#191 continúan abiertos y solapados, introducenops_task_materializer.pyque no existe en main; revisar valor/solapamiento sin fusionar ambos. PR #206 ya merged pero Joshua sigue queued/0 workers. Pendiente hashes de módulos importados por PID AMD+Intel, systemd timers/journals, deploy log y comparación con último canario real. Handoff forense enviado a Cursor en mensajemsg_f7a4045c38e1d899, mismo hilo, sin crear OPS ni gasto externo.Rafa-Innerchispa commentedon Oct 20, 2026
Actualización de verificación read-only | 2026-10-20 02:20 UTC (19 oct, Ecuador)
La incidencia P0 de scheduler continúa sin canary de ejecución acreditado.
dev_swarm_scheduler_statusdevuelveenabled=true,last_tick_at=2026-10-19T23:56:12.892904Z,last_executor_executed=0yactive_worker_count=0durante la consulta ~02:20 UTC. Eso representa ~2h24 desde el último tick registrado; no equivale por sí solo a que el proceso esté detenido. Se requiere distinguir timer, persistencia de estado, admisión/claim y ejecución de worker usando logs y tareas reales, sin reconfigurar servicios por conjetura.La tarea AG-60 existente
ops_0784065f1fb1sigue enawaiting_antigravity_claim/assignee Antigravity, pese a existir código probado localmente (PR #197). El commit local adicionale53ac7fepara verificar dos muestras Mongo quedó sin publicar. El repositorio tiene candado activo de otra tareanebius-physical-ai-runtime-20261019con expiración reportada2026-10-20T02:44:16Z; no robar el lock ni crear otro scheduler.La lectura MCP
bellini_guardian_statusa2026-10-20T02:19:14Zsigue sin camposdiagnostics/mongo_sample_evidence, por lo que el nuevo código del PR no está acreditado como respuesta activa. Criterios de aceptación pendientes: >=2 ticks seguidos con IDs y logs, claim local sin Antigravity de pago, worker y commit verificables, SHA activo y recargas, dos muestras Mongo distintas y canary terminal. Mantener políticas local-first, lectura sin reinicio, no modificar red.Este comentario actualiza la issue canónica #193 sin abrir incidencia duplicada ni declarar reparación.
Rafa-Innerchispa commentedon Oct 20, 2026
Novedad material | 2026-10-20 04:42 UTC (19 oct, 23:42 Ecuador)
Se repitió la comprobación read-only de
dev_swarm_scheduler_status:enabled=true,last_tick_at=2026-10-19T23:56:12.892904Z,last_executor_executed=0,active_worker_count=0. Han transcurrido aprox. 4 h 46 min desde el último tick persistido, sin evidencia de ejecución de workers. No se deben confundirenabledy actividad real. Sigue requiriendo comprobación independiente de systemd timer, logs, Temporal y contratos de admisión/claim, manteniendo todos los guardrails.La tarea AG-60
ops_0784065f1fb1todavía esperaantigravity_claimaunque el trabajo local ya tiene PR #197 y CI verde en HEADe53ac7fe. Esta disociación coordinación↔código es parte del problema existente, no justifica crear otro scheduler. No hubo cambios de servicios/red ni gasto externo.Esta es actualización incremental de issue P0 #193; no se abre tarea duplicada.
Rafa-Innerchispa commentedon Oct 21, 2026
Diagnóstico 21 oct 2026, 11:26 Ecuador. Scheduler sigue sin canary, aun con arreglos de Cursor
Consulta MCP Small:
enabled=true,executor_version=autonomous_impl_v11_strict_output_recovery,last_tick_at=2026-10-20T17:59:26.369985Z,last_executor_executed=0,active_worker_count=0en medición 2026-10-21 16:13Z. Casi 22h sin otro tick acreditado. Un worker local de Joshua sí produjo commit y tests el 20 oct (df201a7492...), pero no prueba recuperación periódica ni ejecución deops_0784065f1fb1(sigueawaiting_antigravity_claim, aunque el usuario solicita local-first). AMD: disco 94% ocupado, swap 8/8 GiB; no hay evidencia de causa única ni se autorizan reinicios experimentales.Se reprodujeron sobre
maincinco fallos concretos en autorizaciones WhatsApp + un aislamiento de Temporal; PR #210 los corrige en rama aislada (00fe937c, 66+56 focused tests PASS, ambos CI PASS, preflight Evolution Intel conectado). No desplegado. Un test heredadotest_temporal_ops_engine.pysigue fallando al importar el símboloAgentStateretirado; actualizar al contrato actual tras evaluar vigencia.Se necesita diagnosticar en runtime, read-only: ticks reales
systemd/journals, worker lease/admisión, Temporal workflow IDs/event history,mainactivo en MCP, estado de servicio, prueba inocua orden→claim local→ejecución→evidencia→cierre. No crear scheduler nuevo ni confundirenabled/mensajes con ejecución. No usar modelos IDE de pago.Rafa-Innerchispa commentedon Oct 23, 2026
Actualización de capacidad y coordinación | 22 oct 2026, 20:40 Guayaquil
Consulta MCP Small actual:
dev_swarm_scheduler_statustieneenabled=true,last_tick_at=2026-10-23T01:37:14.272048Z,active_worker_count=1,last_executor_executed=0. Esto corrige el problema anterior de más de 20 horas sin tick, PERO no constituye un canary terminal ni confirma que AG-60 tenga un worker (tarea canónicaops_0784065f1fb1sigueawaiting_antigravity_claim).Riesgo de host P0: AMD
/94%, 417/466 GiB, solo 30 GiB libres; swap ~8/8 GiB usada, RAM disponible ~5.1 GiB. Intel/86%, 721/877 GiB, swap ~7.7/8 GiB. AMD creció aprox. 95 GiB desde 13 oct. La tarea existente de almacenamientoops_f9983b081febsigueblocked/cursor_claim_required; no crear una nueva. Cursor recibió actualización precisamsg_af1b260bc28b8e5d; RalfIA/AG-25 recibemsg_d486c9b11dc713cepara alerta al propietario con recibo real y dedupe.Se intentó
df -h,df -i,du -x -h -d 1vía local_exec.allowlisted: los tres denegados porcommand_not_allowlisted. No se evadió el control y no se ejecutaron limpiezas, migraciones, prunes ni reinicios. Para resolver en host: permitir/ejecutar diagnóstico de directorios bajo agente de host aprobado, comprobar montajes y Docker/cache/worktrees, guardar manifest y demostrar liberación segura before/after (solo temporales verdaderamente huérfanos), sin tocar MC3/modelos/Mongo/volúmenes.Recomendación operacional: contener temporalmente builds/descargas de alto consumo hasta recuperar margen de root y no atribuir swap a una causa sin PID/evidencia. Se requiere recuperar ejecución autónoma real de una OPS local con 2 ticks y cierre probado, no marcar PASS por
enabled.Rafa-Innerchispa commentedon Oct 23, 2026
Actualización verificada 22-Oct-2026 21:56 GYT (SIN nueva OPS): Joshua
ops_9c06568886eccompleted 20-Oct 06:00Z. Su worker AMDworker_f4f9b0ad17ebregistróexecutor.PASS, test PASS, commitdf201a7492dec437d16d820355300c56af9d293c, e Integration Guardianverification.ok=true,integration.ok=true,canonical_target_fast_forwarded. GitHubinnerops-service-ops/mainapunta exactamente al SHA y Actions run 39377921491 PASS connpm testreal. Alcance limitado:src/joshua/second_brain_p0.jses canario sintético (1 cliente demo / 3 eventos); no afirmar correo autorizado o Second Brain real.Bug reproducido MCP Local Execution Plane (execution_id
exec_9fabe4f15ce5):run_command_allowlistedcon la misma task y rama de Joshua devuelveworktree_missingen ruta aislada canónica, aunqueinspect_repomuestra el checkout FUENTE en esa rama HEADdf201a7. En launchcreate_worktreerecibió Gitalready used by worktree at .../workspaces/innerops-service-opsy marcó OK viareused_external_worktree; posteriormenterun_command_allowlisted/write_file/commit_branchsolo calculan la ruta aislada. Reconciliar en PR #191/#188 ya existentes, sin duplicar otra reparación, singit reset --hard, ni usar el checkout de origen como sandbox de escrituras. Exigir prueba de regresión real create→npm test→commit bajo worktree gobernado.Estado scheduler actual: enabled/ticks; 1 worker activo
ops_e679506768faphase=inference sin progreso desde2026-10-23T02:37:15Za la inspección ~02:56Z;last_executor_executed=0. Se requiere liveness/lease comprobado, no falso running. Riesgo host AMD raíz 94% + swap 100% según última medición P0, tarea existenteops_f9983b081febsigue blocked/cursor_claim_required.docs/INNEROS_RELEASE_ATTESTATION.jsonpermanece AMD/Intelverified:false; plataforma Git checkout main ≠ módulo Python importado por procesos. Seguimiento puntual enviado a Cursor en el mismo hilomsg_810197114fcd5d9b, sin ordenar modelos externos pagos ni nueva OPS.Rafa-Innerchispa commentedon Oct 24, 2026
Auditoría live 24-Oct-2026 10:17 GYT, continuación del MISMO incidente #193 (sin OPS nueva): MCP scheduler
enabled=true, tick2026-10-24T15:17:11Z,last_tick_started=1,last_executor_executed=0,active_worker_count=1/4; workerops_e679506768fasiguerunning/inferencecon último progreso2026-10-24T14:56:14Z, sin cierre E2E. Joshuaops_9c06568886eccontinúacompletedpor canario sintético con commitdf201a7492...y Guardian PASS, pero faltan memoria/correo/flujos E2E reales. Hallazgo de código más preciso:platform/inneros_core_runtime/local_execution_plane.pyMAIN blob250d9ef2permitecreate_worktreedevolver OK reutilizando el checkout fuente cuando la rama ya está en uso (reused_external_worktree);run_command_allowlistedcalcula exclusivamente_worktree_path()aislado y devuelveworktree_missing, como se reprodujo enexec_9fabe4f15ce5. PR #191 sigue OPEN/no mergeable y su diff no cambiarun_command_allowlisted; PR #188 se solapa. No fusionar PR191 como solución suficiente ni hacer reset/destrucción del checkout. Primero reparar incoherencia de aislamiento y probar create→npm test→commit en un worktree exclusivo, sin alterar controls. AG-41 observabilidad read-only de hoy: AMD / 90% (401G/466G, 46G libres), RAM available ~3.9GiB, swap 8GiB ocupada; Intel / 87% (728G/877G, 113G libres), RAM available ~3.7GiB, swap ~8GiB ocupada. Mantener HOLD a builds pesados/descargas; liberar solo tras análisis aprobado de host, sin prunes/borrados ciegos. La task de storageops_f9983b081febpermaneceblocked/cursor_claim_required; Host Attestation AMD/Intel todavíaverified:false. Checkout plataformamainHEAD3a091e11, Joshua checkout fuente aún rama local-agent HEADdf201a7; no confundir con hash de módulos importados por PID. No crear segunda OPS, no gastar agentes externos.