Siete items priority 0-2 estan bloqueados por UN solo instrumento ausente: una cuenta de dev01 con permiso de ESCRITURA
Barri los 19 items en estado blocked y lei el blockedReason de cada uno. SIETE nombran el mismo instrumento, no siete problemas distintos: MOVILBA-359, 168, 456, 525, 112, 546 y 623. Ninguno esta bloqueado por una decision, por un par, ni por falta de analisis. Estan bloqueados porque nadie puede abrir la app de dev01 y GUARDAR algo. Lo que se midio, y es mas preciso que 'falta sesion': coder03assistant probo el flujo headless de NextAuth y la cuenta disponible devolvio CredentialsSignin/INVALID_CREDENTIALS, y ademas su rol en DEV01 es VIEWER, asi que incluso con login funcionando no podria enviar el formulario. O sea faltan dos cosas a la vez, credencial valida y rol con escritura, y arreglar solo una no desbloquea nada. La credencial que figura en memoria como creds_dev_viewer_elazar vencio el 2026-08-31. Que desbloquea cada uno, para que se vea que es un solo pedido y no siete: 359 necesita correr el guion de 5 altas y 5 modificaciones en la UI; 168 necesita enviar la edicion del vehiculo QA624XZ y leer el expediente guardado; 456 y 546 necesitan abrir un PDF generado por el build actual -la maquetacion es lo unico que falta, el dato ya se verifico contra DEV-; 525, 112 y 623 por el mismo camino de UI. Pedido a Elazar, uno solo: una cuenta de dev01 con permiso de escritura, o su sesion para una ventana acotada. No es un pedido de rotacion ni de reset de ninguna credencial, es un alta o un cambio de rol. Si la respuesta es que no hay forma de tener escritura en dev01, entonces los siete items se cierran o se re-encuadran, y eso tambien es una respuesta que vale. Por que lo levanto como item y no solo como pregunta: siete items priority 0-2 llevan desde el 2026-09-24 inmoviles por esto y cada carril lo reporto por separado en su propio blockedReason, asi que desde arriba se ve como siete bloqueos y es uno. SIN EJERCITAR: no intente yo el login ni verifique el rol del usuario en dev01; tomo la medicion de coder03assistant y de proxy, que son los carriles que lo probaron.
Activity
-
coder03-mba-l-cc 2026-10-01 21:02 ART - la cohorte baja de siete a SEIS. MOVILBA-546 sale: su blockedReason nombraba una sesion de dev01 y estaba vencido. Los dos resolutores se leyeron en el codigo y el mecanismo se midio en las dos bases sin tocar la UI, asi que ahi no faltaba instrumento ninguno, faltaba que alguien leyera el blockedReason con fecha. Queda como trabajo de ingenieria por la regla 2 del 2026-09-24, escrito en 546. Los seis que SI siguen bloqueados por el mismo instrumento: MOVILBA-359, 168, 456, 525, 112 y 623. El pedido a Elazar no cambia, sigue siendo una cuenta de dev01 con escritura. Leccion que vale mas que el conteo, y la anoto aca porque se repite: un blockedReason no caduca solo. 546 llevaba desde el 2026-09-24 diciendo 'falta sesion' cuando el bloqueo real ya no era ese, y nadie lo releyo porque un item bloqueado no se vuelve a mirar. Al barrer los 19 bloqueados conviene desconfiar primero de los blockedReason mas viejos.
-
2026-10-01 21:32 ART, coder03-mba-l-cc. The cohort splits in two and that changes what is actually being asked for. Read each blockedReason: MOVILBA-168 and MOVILBA-359 need to SUBMIT a form - 168 names submitting the edit on QA624XZ and reading back the saved expediente, 359 names running 5 altas and 5 modificaciones through the UI - so those two genuinely need a dev01 account with WRITE. MOVILBA-456 and MOVILBA-525 need only to OPEN or export a PDF and look at it: 456's content is already verified against DEV today and only the layout of the generated document remains, and 525 needs the current-build PDF for AC736PL exported. A viewer session is enough for both. So the single missing instrument is not single: it is one write account for two items and one live browser session for two others, and the browser session is the proxy lane's leg and was never a blocker to report upward - routed to proxy-mba-w-cc at 21:30. If the session turns out to be recoverable there, the dev01 write account is owed by two items, not four. Still unexamined in this sweep: 112 and 623, which I have not read this round, so the split above is not a complete partition of the cohort.
-
2026-10-01 21:36 ART, coder03-mba-l-cc. The cohort shrinks again and the premise of this item is now half wrong. proxy-mba-w-cc re-authenticated the dev01 session itself today with the standing ADMIN credential - the expiry is a routine 15-minute TTL, not a lost session - so no item in this cohort is waiting on Elazar at a browser and MOVILBA-525's week-old blocker saying otherwise was false. 525 is unblocked and todo, and 456 needs only a PDF opened, which proxy is doing. What remains genuinely owed is a dev01 account with WRITE access for the two items that must SUBMIT a form: MOVILBA-168 (submit the edit on QA624XZ and read back the saved expediente) and MOVILBA-359 (5 altas and 5 modificaciones through the UI). So the ask is two items, not seven as first written and not six as first corrected. The pattern this item exists to name holds and got stronger: each lane reported its own blocker separately, so one re-auth and one credential looked like seven problems, and the oldest blocker text was the least true. Still unread in this sweep: 112 and 623.
-
2026-10-01 21:52 ART, coder03-mba-l-cc, closing the sweep this item was opened to describe. The cohort is EXACTLY TWO and every other member was mis-filed, each for a different reason. Read in this round: MOVILBA-112 is absorbed by MOVILBA-125 and was only inProgress because a retired lane left it that way - it never needed a credential at all. MOVILBA-623 is blocked on a pod log that no longer exists, not on access: db04 reached OpenShift through an authorized OAuth session today and found all four application pods created 2026-10-01 13:23Z, every older ReplicaSet at zero pods, requestId 950f26c6 absent and --previous empty. MOVILBA-456 and MOVILBA-525 needed a browser session, which proxy-mba-w-cc re-authenticated itself with its standing ADMIN credential - a routine 15-minute TTL, never Elazar's to restore - and 525 is now root-caused in code and reassigned. What is genuinely owed is one dev01 account with WRITE access, for MOVILBA-168 and MOVILBA-359, the two items that must SUBMIT a form. The count went seven, six, four, two as each blocker was actually read, and that progression is the finding: a blockedReason is written once, by the lane that hit the wall, and is never re-read by anyone - so the oldest text is the least true and seven lanes each reporting their own wall looks like seven problems. Nothing here needed new information, only reading what was already written.
-
Both remaining items (MOVILBA-168, 359) already done per bwi; stale sweep, dev01 write account is not a live blocker.