ValidadoraEntitySection renderiza SUBE en las pantallas de linea, fuera del redirect de /validadoras
El redirect de proxy.ts:136 cubre /validadoras y lo que esta debajo, pero ValidadoraEntitySection se renderiza SIN CONDICION desde src/app/lineas/[id]/page.tsx:332 y src/app/lineas/[id]/editar/page.tsx:176, que estan FUERA del prefijo redirigido. Medido por researcher: los registros SUBE se muestran en todos los hosts, prod incluido, sin importar useValidatorFull; solo los sub-campos de OPENPASS quedan gateados por host. Contradice la regla dura de CLAUDE.md (literal: hide validadoras for now, we are not going to show them, export them, etc). Es un HIDE, no una remocion: el arreglo es dejar de renderizar la seccion en esas dos paginas, SIN DDL y sin tocar public.validadoras, validadoras_historial ni las cuatro columnas de vehiculos_datos_colectivos. SIN EJERCITAR: nadie abrio la pantalla viva para verlo renderizado - la evidencia es el call site, no una observacion de runtime, y ese control se debe antes de llamarlo arreglado. Censo de superficies: MOVILBA-462.
Activity
-
parent=#4105
-
Two unconditional line-page render sites confirmed in source; live failing-before witness requested before the hide patch.
-
Static failing-before: both Linea pages imported and rendered ValidadoraEntitySection unconditionally outside /validadoras redirect (detail :332, edit :176), against CLAUDE.md hard hide rule. Diff removes only those two imports/renders; live PROD screen not exercised because no authenticated session. Page SHAs 6bfe1335/67d30d8f. Audit pending.
-
Correccion del alcance por coder03-mba-l-cc, 2026-10-08: el testigo de runtime NO bloquea el arreglo. El render es incondicional en los dos call sites y eso es un hecho estatico ya medido, no una hipotesis; la regla de CLAUDE.md es dura y hoy esta violada en prod, y un arreglo de prod de algo ROTO no pide GO. El arreglo sale primero y la pantalla viva queda como control POSTERIOR. El motivo por el que el testigo previo no estaba disponible: el proxy en whey reporta todas las pestanas de PROD en /user/login y el login de AD lo tipea Elazar, nunca un agente - es un limite de herramienta, no un bloqueo del item.
-
audit pass: 742: app/lineas/[id]/page.tsx 6bfe1335 + app/lineas/[id]/editar/page.tsx 67d30d8f, removal of two unconditional ValidadoraEntitySection renders + their imports. Static evidence only, by design. NOT exercised: no live render of either page on any host.
payload
{"scope":"742: app/lineas/[id]/page.tsx 6bfe1335 + app/lineas/[id]/editar/page.tsx 67d30d8f, removal of two unconditional ValidadoraEntitySection renders + their imports. Static evidence only, by design. NOT exercised: no live render of either page on any host.","outcome":"pass","evidence":"audit-mba-l-cc 2026-10-08 20:20Z. PASS. FAILING-BEFORE VERIFIED BY ME AGAINST main, not against dev and not from the claim: git show main:src/app/lineas/[id]/page.tsx has the import at :15 and the render at :332, and main:src/app/lineas/[id]/editar/page.tsx has them at :12 and :176. Both renders are guarded only by `id &&`, i.e. unconditional for every host and every user who can open a linea - and /lineas is NOT under the proxy redirect at src/proxy.ts:136, which only covers /validadoras, so these two were the live leak of validadora data on a reachable route under the hide rule. The diff removes exactly the two JSX blocks and the two imports, touches nothing else, and leaves 0 residual occurrences of validadora in either file (grep -i). CENSUS IN BOTH DIRECTIONS over src: after this diff the only remaining ValidadoraEntitySection consumer is src/app/validadoras/[id]/page.tsx, which the proxy 307s to / on every host, and useValidatorFull / VALIDATOR_FULL_HOSTS are reached only from that same redirected tree plus lib/stagingSwitch.ts itself. So the component-render surface of the hide is closed for every route that is actually reachable. This is a HIDE not a removal and the diff respects that: no DDL, no change to public.validadoras, and src/components/ValidadoraEntitySection remains in the tree. Gates: eslint --max-warnings 0 exit 0 on both files, typecheck exit 0, test:source 66/66. test:tools is red in this checkout but with a control proving the cause is MOVILBA-743, not these two files. NOT EXERCISED: neither page was rendered live, so the absence of a visual gap or a broken layout in detail-grid is unobserved; PM declined the Elazar session needed for a login.","reportRef":null} -
SHIPPED. dev 1e907130, main (merge de dev), PROD y DEV sirviendo patch 205 medido por curl -fsS con (serviceId-911)/137; el pod quedo con el push aceptado (HTTP 202) y Tekton construyendo, se verifica aparte. Los dos pins verificados contra el arbol como ultimo paso antes del commit: src/app/lineas/[id]/page.tsx 6bfe1335, src/app/lineas/[id]/editar/page.tsx 67d30d8f. Audit PASS con el failing-before verificado contra main en :332 y :176. SIN EJERCITAR, y es una decision mia explicita: nadie abrio la pantalla viva en ningun host. El proxy en whey reporta todas las pestanas de PROD en /user/login y el login de AD lo tipea Elazar, nunca un agente. El render era incondicional en los dos call sites, que es un hecho estatico ya medido, asi que el arreglo salio primero y la pantalla viva queda como control POSTERIOR - esperar el login habria dejado una violacion de regla dura viviendo en prod. El item se cierra como shipeado, NO como verificado de punta a punta. Shipeado SOLO - con src/actions/vehiculos.ts, el fixture revisado y el slice de servicios de 739 parkeados y devueltos byte-identicos despues, verificados por sha256 uno por uno.