movilba
MOVILBA-408
262 returns en src/actions sin requestId; 92 en archivos sin generateUUID (confirmado por dos derivaciones independientes)
Done normal
cmcoder03assistant-mba-l-ca
Static measurement against main 13cad80cfd63fd48e1bc3201c63c78b14609f07b (src/actions tree e863ec93898e9b152570eb7e7dcfe8a10b75871). Two independent methods agree on 262 direct success:false action returns lacking requestId: a TypeScript AST scan of runtime object-literal return statements and the researcher’s comment/type-literal-aware source scan. A separate file-level zero-generateUUID bucket is 92, independently counted by the AST and the corrected source scan: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2. The earlier 95 is superseded because reportes.ts contains generateUUID; its pre-mint authorization return is a branch-level case, not a zero-generator file. The 92 covers only returns in files with no generateUUID call anywhere. It does NOT count the other files that do call generateUUID, where early branches may still omit the id or log. Invariant: adding requestId to a response is correct only when the same id resolves to the corresponding persisted log row; use the failure helpers in validadoras.ts as the pattern and consider a shared required failure-result type. Related: MOVILBA-321, 404, 407. UNEXERCISED: no runtime action/browser execution, no DB/app_logs readback, no proof of returned-id-to-row correlation. Total return-literal counts vary by parser scope (AST 273 vs source scan 271); the agreed missing-id count is 262.
Activity
-
coder03-mba-l-cc / coder
-
coder03assistant-mba-l-ca
-
researcher 2026-10-08 13:22 ART: not a decision - execution backlog with the destination pattern already in the repo (fallo()/sinPermiso() in validadoras.ts). The two-part fix (add log() to the 95 returns missing generateUUID; make requestId required on the failure branch via a shared ResultadoAccion type) is a known shape, not awaiting Elazar's input.
-
researcher-mba-l-cc / solo
-
Independent static re-derivation against main commit 13cad80cfd63fd48e1bc3201c63c78b14609f07b (src/actions tree e863ec93898e9b152570eb7e7dcfe8a10b75871d). TypeScript AST scan of all src/actions/*.ts, counting direct return object literals with success:false: 273 such returns total; 262 omit requestId and 11 include it. Per-file missing-requestId counts: analisis-importacion 24, asociaciones 41, audit 6, choferes 51, contact-info 60, entidades 3, instalaciones 38, lineas 11, logs 2, personas 3, reportes 1, vehiculos 22, validadoras 0. Thus the prior 233 is NOT reproduced by this broad direct-return definition; its listed components sum to 233 because it omitted the 29 missing-id returns in entidades (3), personas (3), reportes (1), and vehiculos (22). The 95 figure reproduces as 95 missing-id failure returns in files with no generateUUID use: contact-info 60 + analisis-importacion 24 + audit 6 + reportes 3 + logs 2. Separate metric: within files that have no generateUUID anywhere, 95 direct failure returns omit requestId; this is file-level, not proof about every action's runtime logging. UNEXERCISED: no action/browser invocation, no DB/app_logs readback, and no verification that each returned ID correlates to a persisted log row; this is source-only measurement at the pinned commit. Counts are scoped to direct object-literal returns with success:false; helper-call returns and non-literal constructions are not included.
-
2026-10-08T15:51:41-03:00 / 18:51:41Z researcher-mba-l-cc. Re-derived against main@13cad80c, src/actions/*.ts (13 files). BUG FOUND AND FIXED before trusting any number: my first script matched `success:\s*false` as plain text, which hit JSDoc comment prose quoting old code (validadoras.ts:53, inside the MOVILBA-404 comment block, literal text "`{ success: false, error }` sin `requestId`...") and TS type-literal signatures (semicolon-separated, e.g. `function sinPermiso(): { success: false; error: string; requestId: string }`) - neither is a runtime return. Fixed by blanking /* */ and // comments before matching, then separately flagging any enclosing block that is semicolon-only with no comma (type-literal shape) and excluding those from the return count. CORRECTED COUNTS: - Real `success: false` return statements in src/actions: 271 (was 278 raw-regex, -4 for type-literal signatures in reportes.ts:13 and validadoras.ts:15/69/101, -3 more for comment-text false positives already absorbed by the comment-strip). - Of those, 262 do not include requestId in the return. (0 of the 4 type-literal matches were ever in this bucket - they all declare requestId in their own type, just not as a comma-separated runtime value - so the comment/type fix did not move this number much: 263->262, net -1 real change plus the comment fix.) - Of those 262, 92 are in files with zero generateUUID() calls anywhere: analisis-importacion.ts(24), audit.ts(6), contact-info.ts(60), logs.ts(2). Everything else with no-requestId returns is in a file that DOES call generateUUID() somewhere but skips it on specific early-return branches (confirmed true positive via spot-check: entidades.ts:23/28/32 and personas.ts:23/28/32 each generate requestId once at top of function then drop it on 3 guard-clause returns with no log() call either - cheaper fix than files with zero generateUUID). DELTA from the 2026-09-09 published 233/95 pair: +29/-3. Explained: file set grew from 9 to 13 files since September (entidades.ts, personas.ts, validadoras.ts, vehiculos.ts added - together contribute the bulk of the +29 on the no-requestId side). reportes.ts gained generateUUID() support since then, which is why the no-genUUID-file bucket is -3 rather than larger: 2 of reportes.ts's 3 flagged returns no longer belong to a zero-generateUUID file (3rd still bare, line 28). validadoras.ts and its cited sinPermiso()/fallo() pattern are confirmed clean: 2 real runtime returns, 0 missing requestId - the file genuinely matches the destination pattern the ticket cites, once comment/type noise is removed. Before the fix my script wrongly flagged it as 1-of-6 broken. UNEXERCISED: (1) the brace-matching is a heuristic, not an AST parse - it has not been checked against nested ternaries or object literals passed as function arguments inside the success:false block, which could still misplace the open/close brace in a file not in this 13. (2) file-level generateUUID() presence is a coarse proxy - it proves a file CAN mint an id, not that every flagged return's specific code path runs log() before returning; entidades.ts/personas.ts prove the gap is real (id generated, never logged, never attached on 3 of 4 returns each). (3) no check for requestId arriving via a destructured/renamed variable (e.g. `const { id: requestId } = ...`) - the regex only looks for the literal word requestId in the block, so an aliased variable would false-flag as missing. TOTAL: 271 success:false returns, 262 without requestId, 92 in files with zero generateUUID() at all. Script and 13 extracted source files kept at scratchpad/408/ for a re-run if main moves again.
-
Correction to the preceding note's wording: reportes.ts DOES contain generateUUID (line 29), but its sole direct missing-requestId failure return is the pre-mint authorization return at line 28. So the 95 prior figure's parenthetical 'reportes sin generateUUID' is false for the file as a whole. A second, lexical source-order count (a generateUUID() call earlier in the same enclosing function before that return) finds 141 of the 262 missing-requestId direct failure returns with no earlier mint: analisis-importacion 24, audit 6, contact-info 60, logs 2, reportes 1, choferes 16, instalaciones 19, lineas 4, vehiculos 9. This is a conservative static heuristic, not control-flow proof: nested branches can make an earlier mint unreachable for a later return. The exact re-derived results are therefore: broad direct-literal missing requestId=262 (not 233); baseline 95 is not reproduced under a whole-file UUID test and the lexically-before-return measure is 141. Runtime invocation and persisted-log correlation remain unexercised.
-
2026-10-08T15:55:00-03:00 / 18:55:00Z researcher-mba-l-cc. Reconciling against coder03assistant's independent AST count (same event thread): no-requestId converges exactly at 262 (regex-after-comment-strip and AST agree). Zero-generateUUID-file bucket diverges: they report 95 including reportes(3), I report 92 excluding it. Checked directly: reportes.ts:6 imports generateUUID, reportes.ts:29 calls it (const requestId = generateUUID()). reportes.ts is NOT a zero-generateUUID file - the 95 figure is wrong on this point, 92 stands. Total raw return count (271 vs their 273) is a smaller, non-headline discrepancy from literal-return-shape scope differences, not re-derived further here.
-
262 returns en src/actions no devuelven requestId; 92 candidato (sin AST-confirmar) no generan ninguno
-
262 returns de actions omiten requestId; AST encuentra 133 en funciones sin generateUUID
-
Independent AST check of the zero-generateUUID count, against the same pinned main 13cad80cfd63fd48e1bc3201c63c78b14609f07b / src/actions tree e863ec93898e9b152570eb7e7dcfe8a10b75871: among 262 direct failure object returns missing requestId, 133 are inside an enclosing function that contains no generateUUID() call anywhere (nested functions excluded). Per-file: analisis-importacion 24, audit 6, choferes 16, contact-info 60, instalaciones 19, vehiculos 6, logs 2. This independently derived AST count does NOT agree with the regex candidate 92 (difference 41); do not treat 92 as verified. This is a syntactic function-level count, not proof that a UUID/log is generated on every branch in the other 129 returns. The identified pattern of UUID creation followed by early guard returns remains part of the defect and requires control-flow/runtime review. No action invocation or app_logs correlation was exercised.
-
262 returns en src/actions omiten requestId; 92 en archivos sin generateUUID
-
Correction: the 92 candidate DOES agree with an independent AST query when the metric is defined as the original item's file-level bucket: direct success:false object returns missing requestId, in a src/actions file containing zero generateUUID() calls anywhere. AST count = 92: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2. reportes.ts is excluded because it contains generateUUID(); its pre-mint guard return is a separate branch-level gap. The 133 figure in my prior note used a different, narrower enclosing-function-with-no-call definition, so it is not the requested zero-generateUUID-file count and should not be used in the title. The headline 262 missing-requestId count agrees across AST instruments; total return-literal count differs by scope (my direct object-literal AST yielded 273, researcher's comment-stripped parser 271), while the missing-ID count is unchanged. Control-flow/runtime behavior and persisted app_logs correlation remain unexercised.
-
AST confirmation of researcher’s 92 candidate: AGREES. Against main 13cad80cfd63fd48e1bc3201c63c78b14609f07b / src/actions tree e863ec93898e9b152570eb7e7dcfe8a10b75871, AST finds 92 direct object returns lacking in files with zero calls: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2. reportes.ts is excluded because it calls generateUUID() at line 29; its authorization return at line 28 is a branch-level exception, not a zero-generator file. Thus the 262 total and 92 zero-generator-file figures are independently confirmed; no runtime action execution or persisted app_logs correlation was exercised.
-
Formatting correction: the prior AST confirmation was shell-quoted and lost the literal names success:false, requestId, and generateUUID in the stored sentence. The intended verified count is 92 direct success:false object returns lacking requestId in files with zero generateUUID calls: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2. No runtime action execution or persisted app_logs correlation was exercised.
-
262 returns en src/actions sin requestId; 92 en archivos sin generateUUID (confirmado por dos derivaciones independientes)
-
2026-10-08T16:15:21-03:00 / 19:15:21Z researcher-mba-l-cc. MEASUREMENT HALF CLOSED - title fixed to match. Final figures, two independent derivations agreeing: 262 success:false returns in src/actions omit requestId (regex-after-comment/type-strip and coder03assistant's AST both land here). 92 of those 262 are in files with zero generateUUID() anywhere: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2 - confirmed by both derivations independently, reportes.ts correctly excluded by both (has generateUUID at line 29). NOT COVERED by this item: the other 170 no-requestId returns live in files that DO call generateUUID somewhere (asociaciones, choferes, entidades, instalaciones, lineas, personas, vehiculos) - different population, different fix shape (attach the id that already exists, per guard-clause branch) vs these 92 (no id exists yet, generateUUID+log() both missing). entidades.ts/personas.ts spot-checked as the worked example of that other population: id generated once, dropped on 3 guard-clause returns each, no log() call either. Delta from published 233/95: file set grew 9->13 since 2026-09-09 (entidades/personas/validadoras/vehiculos added), reportes partially fixed since then. UNEXERCISED, unchanged from the prior note: brace-heuristic not AST-verified beyond this 13-file set, no check for requestId via destructured alias, no DB/app_logs readback confirming any attached id actually persists.
-
was: Medido 2026-09-09 sobre dev@af5e8199. Returns 'success: false' sin requestId por archivo: contact-info 60 (sin generateUUID), choferes 51, asociaciones 41, instalaciones 38, analisis-importacion 24 (sin generateUUID), lineas 8, audit 6 (sin generateUUID), reportes 3 (sin generateUUID), logs 2 (sin generateUUID). INVARIANTE: no alcanza con agregar el campo. Un id devuelto solo es correcto en un camino que ESCRIBIO una fila con el; en los 95 returns de archivos que no generan uuid hay que agregar primero el log(). Devolver un id que no resuelve se lee como perdida de log y es peor que no devolver ninguno. Forma destino ya en el repo: fallo() y sinPermiso() de src/actions/validadoras.ts. Duplicacion a resolver de paso: 9 copias inline del tipo {success:false; error; requestId?} - conviene un ResultadoAccion con requestId REQUERIDO en la rama de falla, para que tsc enumere lo que falta. Relacionado: MOVILBA-321 (divulgacion de esquema en esos mismos returns), MOVILBA-404, MOVILBA-407.
-
2026-10-08T18:10:45-03:00 / 21:10:45Z researcher-mba-l-cc. FIX HALF STATUS: not started, zero code changes made. My last note (19:15Z) closed only the measurement half (262/92 figures). No slice of the fix is in progress - "inProgress" has been tracking the measurement work, not implementation. BLOCKED ON ROLE, not a technical decision: the fix is code edits across 13 files in src/actions (attach requestId to 170 returns where generateUUID already exists per branch; add generateUUID+log()+requestId to 92 returns in the 4 zero-generator files). That's implementation work - every prior item in this engagement routed implementation to a coder lane (coder03/coder04), with researcher staying read-only/measurement. This item was never hand-off'd to a coder lane for the fix; it sat on me as the only assignee. Proposed next slice if this stays with me: start with the 92 (4 files, no generateUUID anywhere, cleanest scope, no existing-id-wiring ambiguity) - analisis-importacion.ts, audit.ts, contact-info.ts, logs.ts. The 170-in-files-that-already-generate bucket is the harder slice (per-branch check whether id already exists before the guard return) and should follow. Decision needed: assign the fix to a coder lane (my normal lane boundary), or confirm researcher implements directly this once. Parking until answered - not idle, pulling from backlog meanwhile.
-
Fix half not started - blocked on role assignment (implementation vs researcher's measurement lane), not a technical decision. See note 21:10:45Z for slice proposal.
-
coder03assistant-mba-l-ca / solo
-
Measurement half closed by researcher (262 returns in src/actions without requestId, 92 in files with no generateUUID, two independent derivations). The fix half is code across 13 src/actions files, which is a coder lane's work, not a read-only research lane's - reassigned to coder03assistant. Not blocked on any decision: the slice order researcher proposed stands, the 4 zero-generateUUID files first, then the 170-in-generator-files bucket.
-
Coding first assigned slice: the 92 failure returns in the four files with zero generateUUID calls; later bucket remains untouched.
-
Implemented first slice in src/actions/analisis-importacion.ts (24), src/actions/audit.ts (6), src/actions/contact-info.ts (60), src/actions/logs.ts (2): all 92 direct success:false returns now include requestId generated with generateUUID(), and the four result types expose requestId?. No edits to the 170 in-generator-files bucket. Per coding handoff instructions, lint/typecheck/tests have not been run before audit. Four-file hashes: analisis-importacion a6e1f0393ba56e16093612b2ac882c5398fc87d319e5ebad4c486661abe4368e; audit b0242f4448f4c091f0a1e91a5f1e7c5a3fa2a0dda6f68891c391ff2dfeb5c9aa; contact-info b2bd1650925929ce4118d2296232211c0a24ebd813c43aeb631ea91359d81d9d; logs 31afdf03abb70ecbcbd970e35ca8a8932dea7e883f9617df463ec175b06fb8a5. Static count check: zero failure-return lines in these files without requestId.
-
Paused behind MOVILBA-465. The first 92-return slice in four zero-generateUUID files is handed to audit; resume after 465 clears and audit returns the 408 verdict.
-
MOVILBA-465 is now done, but the first 92-return implementation slice remains pending audit verdict; hold the remaining 170 in-generator-files bucket until audit clears that slice.
-
audit-mba-l-cc 2026-10-09. FAIL, not PASS. Author coder03assistant-mba-l-ca. 92-return slice in analisis-importacion.ts a6e1f039, audit.ts b0242f44, contact-info.ts b2bd1650, logs.ts 31afdf03. ## The item's own invariant, violated The item description states the rule explicitly: 'no alcanza con agregar el campo... hay que agregar primero el log()... Devolver un id que no resuelve se lee como perdida de log y es peor que no devolver ninguno.' The canonical pattern already in the repo (src/actions/validadoras.ts fallo()/sinPermiso()) calls log(level, requestId, ...) BEFORE returning that same requestId, so the id always resolves to a persisted row. All four files in this slice do the opposite: generateUUID() is called inline and attached to the response object, but no log() call exists anywhere in any of the four files (grep confirms zero log( calls, zero new log-call additions in the diff). The pre-existing console.error(...) lines are untouched - they are not keyed by the new requestId, do not persist to app_logs, and are not even guaranteed to reach a durable sink in prod. Net effect: every one of these 92 returns now hands the client an id that resolves to nothing. That is the exact anti-pattern the item itself names as worse than returning no id at all. ## Gates Not run - stopped at this correctness finding per the item's own blocking invariant, not a style note. ## Fix needed Each return needs a log() call (or a shared failure-result helper mirroring validadoras.ts's fallo()) writing a row keyed by the same requestId before returning it, replacing the bare console.error. Until that exists, requestId should not be attached at all - the current state is worse than the pre-diff baseline per the item's own stated invariant.
-
audit fail: 4-file diff read in full, cross-checked against the item's own stated invariant and the existing validadoras.ts pattern
payload
{"scope":"4-file diff read in full, cross-checked against the item's own stated invariant and the existing validadoras.ts pattern","outcome":"fail","evidence":"zero log() calls in any of the 4 files; console.error untouched, uncorrelated with the new requestId; validadoras.ts fallo()/sinPermiso() shows the required log-before-return shape","reportRef":null} -
Audit returned FAIL on the 92-return slice: failure responses carried generated IDs without correlated log rows. Revised all 92 returns to await log(requestId, ...) before returning the same ID; handed exact pins to audit for re-verdict.
-
Revised 92 zero-generateUUID returns to await the legacy logger signature with the same requestId before returning: analisis-importacion.ts 24, audit.ts 6, contact-info.ts 60, logs.ts 2. Replaced 28 catch-path console.error calls with correlated error-level logs; access/validation failures use warn. sha256: analisis-importacion.ts 60d73b048667d2a23e884aabb0d52bdcb951910982b28ab79dbcd8b402219623; audit.ts 9d6f83d3b649a1397800144442401420394cfe64f678799e1472870050bb0689; contact-info.ts aebaa4c89866111cb6ebcffbb955261c342f5550535fe751021f96554c2f463b; logs.ts 0405d0cb3b162c406ce0d4df76871d74edc514fbca698036dc9d89a4302b6eaf. git diff --check passed. No lint/typecheck/tests run before audit handoff.
-
audit-mba-l-cc 2026-10-09. PASS (re-review after FAIL). Author coder03assistant-mba-l-ca. Pins: analisis-importacion.ts 60d73b04, audit.ts 9d6f83d3, contact-info.ts aebaa4c8, logs.ts 0405d0cb. ## Fix verified against the prior FAIL Each of the 92 returns now goes through a per-file logActionFailure() helper that calls log(level, requestId, endpoint, data, message) BEFORE returning, same requestId attached to both. Signature matches lib/logger.ts's 5-arg overload exactly. Zero stray console.error left in any of the 4 files (grep confirms). Access/permission rejections use warn, caught errors use error with the error detail preserved. Counts verified by grep: analisis-importacion 24, audit 6, contact-info 60, logs 2 = 92, exact match to claim. ## Gates, run fresh typecheck rc=0. test:source 68/68 pass. ## Secondary note, not blocking logActionFailure is duplicated per-file (4 near-identical copies) rather than shared - same duplication shape the item's own description already flagged as a to-resolve concern for the broader ResultadoAccion type. Not a blocker for this slice; worth collapsing when the 170-bucket work starts. ## NOT EXERCISED No live action invocation, no app_logs readback confirming a row actually persists for a sample requestId - static/type verification only.
-
audit pass: 4-file diff re-read in full against prior FAIL, log() signature cross-checked, gates run fresh
payload
{"scope":"4-file diff re-read in full against prior FAIL, log() signature cross-checked, gates run fresh","outcome":"pass","evidence":"zero stray console.error remaining, 92 logActionFailure call sites confirmed (24/6/60/2), typecheck rc=0, test:source 68/0","reportRef":null} -
Audit PASS on 2026-10-09 for the 92-return zero-generateUUID slice: audit confirmed log() fires before every return with the same requestId and exact five-argument logger signature; 0 stray console.error; counts 24/6/60/2=92. Audit gates: typecheck rc=0, test:source 68/0. Clear to ship. Remaining 170-return in-generator-files bucket is still outstanding; audit notes the four duplicated helpers can be consolidated when that slice begins.
-
Second slice ready for audit: 170 previously missing-ID failure returns across asociaciones.ts (41), choferes.ts (51), entidades.ts (3), instalaciones.ts (38), lineas.ts (11), personas.ts (3), reportes.ts (1), vehiculos.ts (22). 143 now use awaited shared logActionFailure; 27 retain existing correlated log calls and return that same requestId. Added requestId?: string to affected result types and consolidated the four duplicated first-slice helpers into src/lib/action-failure.ts. Static AST recount: 273 action failure returns in scanned action files, zero missing requestId; syntax transpilation and git diff --check clean. No lint/typecheck/tests run before audit handoff. Exact pins: src/actions/analisis-importacion.ts 4187639a0bc8f0b02a373e0f9dbb5eb821945337bdd699c685ea02e9f429e801; src/actions/audit.ts e26bcf484ba372aa6570bd81eaf588fe5151029559df658e6860817e0f18800e; src/actions/contact-info.ts b1a0d139c327bb44df35b1701eac96b40cee11a5144b3627b2dc2a6da38a31c2; src/actions/logs.ts 6e6429769c1ab1a391af79c8fb03f0e95d99352347a828e70f2a35398112d8bc; src/actions/asociaciones.ts 6a439a4453c1b0f586a4310968b472ee5ade22e9e9de04416ea91893785f3e6a; src/actions/choferes.ts 5377d05e9d56a36a83af225419d1068f86797ba6b1a12cf22ad5bd25f83d903c; src/actions/entidades.ts 292f1fd9381868e82344e28994ead51f34a4de5421239961cbb6fc2e1957f69f; src/actions/instalaciones.ts 07dc91906acb82138117c507cca8bc14263d340bf750e89c43efca43ae83dc9b; src/actions/lineas.ts bbb7e167d2ebcbc4a064b8a5ff3b857fc3e517d1ee8120310c66476424de6b59; src/actions/personas.ts 271023e74be1ba7b150c97baecd6b1f9706d7bed0446d5c778a8b3e0bacb6f55; src/actions/reportes.ts d7241156a3426a3d2cc8ae420d64b62d3b31d017e52674c8b7a2259baee5d1bc; src/actions/vehiculos.ts 420a354afe92570790774cf3aeb74b56b819a0996eadc3896f9c3269a21a2a9c; src/lib/action-failure.ts b4d4c939d3f77b9c853540aceb21b5a9ca26c0ebd7070ce20c3a09a9cc082597.
-
audit-mba-l-cc 2026-10-09. FAIL, not PASS. Author coder03assistant-mba-l-ca, second slice (170-return bucket, 8 files + src/lib/action-failure.ts consolidation). ## Diff correctness, read in full Verified: 143 returns route through the shared logActionFailure (src/lib/action-failure.ts, matches the already-PASSed first-slice pattern exactly), the other 27 keep their pre-existing inline log(level, requestId, ...) call untouched and now just expose that same requestId on the return - spot-checked 5 of the 27 across asociaciones/choferes/instalaciones/lineas/vehiculos, all genuinely pre-correlated, not a new gap. Counts verified by grep per file, sum to 170 exactly (143+27), matching the claim. All 13 pins confirmed exact. ## Gate break - this is what blocks ship typecheck rc=0, test:source 68/68 pass, but pnpm test:tools fails: 22 of 23 tests in tools/tests/colectivo-expediente.test.cjs break with 'AssertionError: Unexpected dependency @/lib/action-failure'. That test harness real-loads src/actions/vehiculos.ts against a FIXED mock/allowlist (see its load() function's explicit includes() list) and does not mock @/lib/action-failure, so the new import throws inside its own load path. This is caused by this diff, not pre-existing - vehiculos.ts did not import that module before. ## Fix needed Add '@/lib/action-failure' to the test harness's mocks object in tools/tests/colectivo-expediente.test.cjs (mock log the same way '@/lib/logger' already is), not to its allowlist array - the module calls the real log() import which the harness already stubs out elsewhere. Re-run test:tools after. ## NOT EXERCISED Stopped gates at test:tools; did not reach test:tools' remaining suites beyond this file (if any other suite imports vehiculos.ts the same way, check it too).
-
audit fail: 8-file + shared-helper diff read in full, spot-checked 27 pre-correlated sites, all 3 gates run fresh
payload
{"scope":"8-file + shared-helper diff read in full, spot-checked 27 pre-correlated sites, all 3 gates run fresh","outcome":"fail","evidence":"test:tools 22/23 fail in colectivo-expediente.test.cjs: Unexpected dependency @/lib/action-failure, caused by this diff's new import into vehiculos.ts","reportRef":null} -
Audit FAIL correction: added the fixed harness mock for @/lib/action-failure in tools/tests/colectivo-expediente.test.cjs; logActionFailure returns the same result in the harness. pnpm test:tools passes: 121/121. File SHA-256 1e119107e309587417fcafb6b8cb236678d0f678e70e666051a24a5f6cf1698e. Ready for re-verdict; only this test mock changed for the correction.
-
audit-mba-l-cc 2026-10-09. PASS (re-review after second FAIL). Author coder03assistant-mba-l-ca. tools/tests/colectivo-expediente.test.cjs 1e119107, only file changed. Correction confirmed: added '@/lib/action-failure': { logActionFailure: async result => result } to the harness's mocks object (not its allowlist), matching the real helper's contract and the existing '@/lib/logger' mock pattern. No other file touched. ## Gates, run fresh, all three typecheck rc=0. test:source 68/68. test:tools 121/121 (was 99/121 FAIL, now full green). Diff logic from the prior review (143 shared logActionFailure + 27 pre-correlated inline log() sites = 170, all 13 pins) stands unchanged - already verified in the prior FAIL's review, not re-walked here. ## NOT EXERCISED Same as before: no live action invocation, no app_logs readback. Second slice closes MOVILBA-408's full 262-count scope (92+170).
-
audit pass: Test-file-only correction re-read, all 3 gates re-run fresh
payload
{"scope":"Test-file-only correction re-read, all 3 gates re-run fresh","outcome":"pass","evidence":"test:tools 121/121 (was 22 failing), typecheck rc=0, test:source 68/0; pin 1e119107 confirmed","reportRef":null} -
Both slices shipped: 92-return (dev a530c670/prod c9742618, patch 240) + 170-return (dev 87a7b94b/prod 6cf0f988, patch 241). requestId now correlated via log() before every console.error path; consolidated through shared src/lib/action-failure.ts. Audit PASSed both slices.
bug
5w ago by wi-cli-venus
1w ago
2026-10-09 05:27