obtenerComentariosImportacion no tiene gate de host propio y confia en un chequeo de cliente

Sub-tickets

Activity

• coder03-mba-l-cc created · 1w ago
  parent=#4105
• coder04-mba-l-ca statusChanged · 1w ago
  Server action has RBAC but no host gate; direct authenticated pre-fix witness pending, client check is insufficient.
• coder04-mba-l-ca statusChanged · 1w ago
  Server-side isFaithfulHost guard added after auth/RBAC and before comentarios_importacion query; non-faithful host returns null. Pre-fix was source-confirmed absent gate; no direct runtime invocation made, per PM decision. Action SHA 9a7e3119. Audit pending.
• coder03-mba-l-cc note · 1w ago
  Decidido por coder03-mba-l-cc, 2026-10-08: NO se usa la sesion autenticada de Elazar para invocar el server action directo en ningun host, y no extiendo el alcance que el dio para MOVILBA-735 - esa extension es suya y no se infiere. Tampoco hace falta: un server action sin chequeo de host propio, gateado unicamente por isFaithfulClient del lado del cliente, es un gate ausente del lado del servidor en la cara del codigo. Agregar el gate no exige demostrar la explotacion primero. El item se arregla con la evidencia estatica y dice explicitamente que NO se ejecuto ninguna invocacion de runtime.
• audit-mba-l-cc audited · 1w ago
  audit fail: 743: actions/vehiculos.ts 9a7e3119, isFaithfulHost gate on obtenerComentariosImportacion. Gates run by audit under lock: eslint 0, typecheck 0, test:source 66/66, test:tools EXIT 1 / 21 failures. FAIL is on the red gate I ran, NOT on the missing runtime witness. The gate logic itself is right.
  payload

  {"scope":"743: actions/vehiculos.ts 9a7e3119, isFaithfulHost gate on obtenerComentariosImportacion. Gates run by audit under lock: eslint 0, typecheck 0, test:source 66/66, test:tools EXIT 1 / 21 failures. FAIL is on the red gate I ran, NOT on the missing runtime witness. The gate logic itself is right.","outcome":"fail","evidence":"audit-mba-l-cc 2026-10-08 20:18Z. FAIL. The change is semantically correct and consistent with the existing pattern (api/v1/exports/vehiculos/route.ts:59 already gates on isFaithfulHost; off-allowlist returns success:true comentarios:null, so no 500 and no leak). It BREAKS test:tools. 21 of 114 fail, all 21 in tools/tests/colectivo-expediente.test.cjs, which vm-loads @/actions/vehiculos from source through a strict allowlist at :76-79 containing only @/utils/dominio-validation, @/utils/expediente-validation, @/services/vehiculos, @/actions/vehiculos. The new module-level import { headers } from \"next/headers\" at vehiculos.ts:10 hits assert.ok(...) and every test in the file dies with AssertionError Unexpected dependency next/headers. CONTROL SEEN TO FAIL AND TO PASS, run by me under the lock: with 9a7e3119 in place that file is 22 tests / 1 pass / 21 fail; git stash push of ONLY src/actions/vehiculos.ts (tree back to 3d798d25) gives 22/22/0; stash popped and the file re-verified at 9a7e3119. So the cause is this hunk and nothing else. WHY THIS MATTERS BEYOND THE RED: neither ship path runs test:tools - mba-deploy-dev.sh is test:source + scoped lint + typecheck, mba-deploy-prod.sh is lockfiles + typecheck + test:source - so this would have shipped to PROD with the suite silently red, and the audit gate is the only place it was reachable. Fix is coder04 or coder03 to decide, not mine: mock next/headers in the harness, or resolve the host without a module-level next/headers import. Returns to coder04 per the FAIL routing rule. NOT EXERCISED: no live request against either host class, so the off-allowlist null path and the on-allowlist read path are both unobserved in runtime.","reportRef":null}

• coder04-mba-l-ca progress · 1w ago
  Audit FAIL 20:25Z was harness load failure on new next/headers import. Revised two-file scope: actions/vehiculos.ts unchanged 9a7e3119; tools/tests/colectivo-expediente.test.cjs 309e184a now mocks next/headers, loads the real isFaithfulHost, and asserts no DB read/comments on PROD/POD/unknown versus one read on staging/dev01. No coder gates run; audit re-review requested.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 20:38Z - SEVERITY CORRECTION to my own 743 FAIL evidence, raised by coder03 and verified by me against the scripts. WHAT I GOT WRONG: I wrote that neither deploy script runs test:tools and that 9a7e3119 would therefore have shipped PROD silently red. Both halves are wrong. Measured by grep on the scripts themselves: mba-deploy-dev.sh:178 runs pnpm run test:tools gated with exit 1 (stage label test:tools, step 1b/5), and mba-deploy-prod.sh:61 runs it the same way (step 2b/7). Both carry the comment MOVILBA-573: deploy runs both test suites explicitly. So the deploy would have ABORTED at that stage. The break was real, the FAIL stands on the control, but it was never silent and the audit gate was not the only place it was reachable. A SECOND STALE CLAIM I HAVE BEEN REPEATING, found while checking the first: mba-deploy-prod.sh:62 runs pnpm run build (step 2c/7). So a ship path DOES run next build. I have asserted "no ship path runs next build" in several earlier verdicts - including the logger/proxy reasoning on MOVILBA-735, where I used it to argue that a node:net import could not break the build. That conclusion survives on its own merits but the premise I cited for it is false, and the premise is what mattered. Every earlier verdict of mine carrying that sentence is corrected here. ROOT CAUSE OF BOTH: the repo CLAUDE.md section "What each ship path actually runs" lists dev as test:source + scoped lint + typecheck and prod as lockfiles + typecheck + test:source, omitting test:tools from both and build from prod, and adds "neither calls pre-commit, so lint:strict runs on no ship path at all". I took that table as the measurement instead of reading the scripts, which is exactly the instrument trap this project warns about - a written convention losing to the primitive. coder03 owns the CLAUDE.md fix. The lint:strict half of that sentence I have NOT re-verified and am not asserting either way.
• coder03-mba-l-cc note · 1w ago
  FAIL de audit sobre 9a7e3119, aceptado: el import module-level de next/headers en src/actions/vehiculos.ts:10 rompe 21 de 114 de test:tools contra el allowlist de dependencias del vm-load en tools/tests/colectivo-expediente.test.cjs:76-79. Control corrido por audit en los DOS sentidos bajo su lock: 22/1/21 con el cambio, 22/22/0 stasheando unicamente vehiculos.ts, restaurado y re-verificado en 9a7e3119. El gate logico del arreglo es correcto; lo que rompe es el arnes. coder04 ya tiene el fixture revisado 309e184a con audit. CORRECCION MEDIDA a la severidad que asigno el FAIL: 'ninguno de los dos scripts de deploy corre test:tools' es FALSO. Los dos lo corren, mba-deploy-dev.sh:178 y mba-deploy-prod.sh:61, cada uno con exit 1. Asi que 9a7e3119 no habria shipeado PROD rojo en silencio - el deploy habria abortado. Y no es una lectura de archivo: mi primer intento del deploy de 742 aborto exactamente en esa etapa, sobre carrocerias-duplicates.test.cjs contra src/services/carrocerias.ts:26, por el slice de 739 que entro al checkout compartido despues de mi park. El gate hizo su trabajo sobre codigo sin veredicto, observado. La tabla de ship paths del CLAUDE.md del repo omitia test:tools en los dos caminos y la corregi, nombrando que una afirmacion de ese archivo se habia propagado a un veredicto.
• audit-mba-l-cc audited · 1w ago
  audit pass: 743 re-review: actions/vehiculos.ts 9a7e3119 UNCHANGED + the revised harness tools/tests/colectivo-expediente.test.cjs 309e184a. SUPERSEDES my FAIL of 20:18Z. Gates run by audit under lock. NOT exercised: no live HTTP request on any host class; the on-allowlist read path against a real DB column.
  payload

  {"scope":"743 re-review: actions/vehiculos.ts 9a7e3119 UNCHANGED + the revised harness tools/tests/colectivo-expediente.test.cjs 309e184a. SUPERSEDES my FAIL of 20:18Z. Gates run by audit under lock. NOT exercised: no live HTTP request on any host class; the on-allowlist read path against a real DB column.","outcome":"pass","evidence":"audit-mba-l-cc 2026-10-08 21:08Z. PASS, superseding my 20:18Z FAIL on the same action SHA. The action is byte-identical (9a7e3119e6c9bb4b695ea2c4a56ec7a0ecc8800310dc3e8e39b720615864612d); what changed is the harness (309e184a723cfcb5e83362c3354db5e380a78ee8c2bfc992c9c879e38895f259). Both hashes identical before AND after the gate runs.\n\nTHE 21 MODULE-LOAD FAILURES ARE GONE AND THE FILE NOW HAS A REAL CONTROL. colectivo-expediente.test.cjs is 23 tests / 23 pass - up from 22, so the host behaviour is a NEW assertion and not a relaxed allowlist. CONTROL SEEN TO FAIL, run by me, not read: git stash push of ONLY src/actions/vehiculos.ts (tree back to the pre-743 3d798d25) leaves 23 tests / 22 pass / 1 fail, and the single failure is \"import comments require a faithful host at the server action\" - the exact assertion the change exists to satisfy, failing against the prior behaviour. Popped and the action re-verified at 9a7e3119. So the new test is a gate and not a green line, and the mock did not simply silence the loader: a next/headers mock that asserted nothing would have stayed green under that mutation.\n\nGATES, run by audit over the three modified .ts plus the two test files: eslint --max-warnings 0 exit 0; pnpm typecheck exit 0; test:source 66/66; test:tools 116/116 exit 0 - the 116 is 114 plus the two new tests, and the 21-failure mode is not reproducible; postman --check exit 0. No flake this time, 1 of 1 run green.\n\nNOT EXERCISED: no live HTTP request against either host class, so the off-allowlist null return and the on-allowlist read are both unobserved in runtime - the harness mocks next/headers and the DB, so this is coverage of the decision and not of the query. coder03 declined the Elazar session a login would need; that is a recorded decision, not a gap I am treating as a defect.","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 21:21Z - SHIPEADO en las tres superficies. dev 039fa245 patch 206, prod 89c99143 patch 206 verificado por curl en app.movilba.com, pod disparado y Tekton construyendo al cierre de esta nota - el pod venia de 205, o sea la pata del ship anterior de 742 SI cerro. src/actions/vehiculos.ts byte-identico en 9a7e3119 verificado por sha256 antes del commit; el arnes 309e184a es lo unico que cambio, 23 aserciones contra 22. SIN EJERCITAR: ninguna request HTTP viva contra este diff en prod.
• coder03-mba-l-cc completed · 1w ago
  completed