log() interno pasa una etiqueta literal como requestId y app_logs.request_id queda NULL por descarte de UUID_RE

Sub-tickets

Activity

• coder03-mba-l-cc created · 1w ago
• researcher-mba-l-cc note · 1w ago
  2026-10-08T13:06:35-03:00 researcher-mba-l-cc measurement. Three distinct patterns found via grep across src/repositories/, src/services/, src/lib/, src/utils/ - only two are actually broken: PATTERN A - direct literal second-arg, unconditional (log('level', 'LITERAL', 'source', data, message) - always NULLs request_id). 198 call sites across 19 files: src/repositories/asociaciones.ts, src/services/asociaciones.ts (literal 'repository'/'service'), src/repositories/page-configs.ts, src/services/page-configs.ts, src/repositories/user.ts, src/services/user.ts, src/services/lineas.ts, src/repositories/lineas.ts, src/services/opciones.ts, src/repositories/chasis.ts, src/services/chasis.ts, src/repositories/userGroups.ts, src/services/paradas.ts, src/services/recorridos.ts, src/repositories/vehiculos.ts (4 sites, repo side only), src/lib/password-expiration.ts (literal 'password-expiration'), src/lib/rbac.ts (literal 'SYSTEM', 5 sites), src/services/numeros-telefonicos.ts (literal 'SYSTEM', 2 sites). PATTERN B - requestId-or-literal fallback (requestId || 'LITERAL' - NULLs only when no caller actually threaded a real id through). 22 more sites: src/services/vehiculos.ts (14x, fallback 'service'), src/repositories/entidades.ts (6x, fallback 'unknown'), src/repositories/carrocerias.ts (8x, fallback 'unknown' - note: this is the REPOSITORY file; the companion src/services/carrocerias.ts uses a DIFFERENT fallback, requestId || randomUUID(), which is NOT broken, confirmed at carrocerias.ts:48). NOT broken, spot-checked because they looked similar: src/services/carrocerias.ts (serviceRequestId = requestId || randomUUID() - real UUID), src/utils/connectionHandler.ts (correlationId = generateUUID() - real UUID), src/services/personas.ts, src/services/ramales.ts, src/repositories/personas.ts, src/repositories/notes.ts, src/repositories/paradas.ts, src/repositories/recorridos.ts, src/repositories/fabricantes.ts, src/services/fabricantes.ts, src/repositories/ramales.ts, src/services/entidades.ts, src/services/notes.ts, src/services/userProfile.ts, src/repositories/rutap-historial.ts - all thread a real requestId variable with no literal fallback. Total: ~220 broken call sites across 21 files (repositories/services layer only - rbac.ts and password-expiration.ts are the only lib-level ones). Which option costs less: dropping the literal label (switching to log()'s NEW signature) is cheaper. The OLD signature's broken calls all hardcode a source label in the requestId slot with no threading of a real id anywhere above them - fixing via propagation means adding a requestId parameter to every one of these ~220 call sites AND to every repository/service function signature that doesn't already accept one AND to every caller of those functions, a cascading signature change through the repository+service+action layers for 21 files. Switching to the NEW signature (log(level, message, data)) needs no plumbing at all: logger.ts's NEW branch already auto-captures the real request id from AsyncLocalStorage via getLogContext() (wired from proxy.ts), with 'source' moving into data.source. It is a pure local rewrite at each of the ~220 call sites, zero signature changes elsewhere, and it gets every one of these rows a real, correlatable request_id instead of NULL. No fix applied - measurement only, per coder03's ask. Recommending NEW-signature migration as the next step.
• coder03-mba-l-cc assigned · 1w ago
  coder04-mba-l-ca / coder
• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:10 ART: fix is log()'s NEW signature, which auto-captures the real request id via AsyncLocalStorage - zero signature threading, versus a cascading parameter change through repository, service and caller layers. 220 call sites across 21 files, two patterns (198 unconditional literal, 22 requestId-or-literal fallback); the file list is in researcher's note. Mechanical, do it in one pass.
• coder04-mba-l-ca progress · 1w ago
  AST census corrected the 220 estimate: 198 unconditional literal calls, 12 inline requestId||service calls, and 47 repoRequestId calls across entidades/carrocerias = 257 target calls in 21 files. Converted 236 in 20 clean files; entidades.ts has an unrelated pre-existing 520-line formatting diff from another lane, ownership check pending before touching it. Untargeted auth/action/client literal calls observed separately; not folded into this 21-file scope.
• coder04-mba-l-ca progress · 1w ago
  All 257 affected calls in the specified 21 files converted via AST-targeted edits: 198 literal, 12 inline fallback, 47 repoRequestId. New signature keeps source in data and uses ALS requestId; 0 target 5-arg calls remain by AST census. Removed only now-unused local fallback bindings/renamed unused params. src/repositories/entidades.ts had a pre-existing unrelated formatting diff in shared tree, preserved; audit must scope its log hunks separately. Other auth/action/client literal calls remain outside this assigned 21-file scope and need separate triage.
• coder04-mba-l-ca progress · 1w ago
  PM ownership split at 2026-10-08 15:08 ART: audit scope 1 is 236 conversions in 20 clean files (198 literal + 12 inline requestId||service + 26 carrocerias repoRequestId). Tail scope 2 is 21 entidades repoRequestId conversions after MOVILBA-646 commits. These 21 had already been edited on top of assistant WIP before PM instruction arrived; disclosed to PM+assistant, excluded from scope 1 and must not ride 646 ship. Denominator 257 across 21 files.
• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:24 ART: resolving the entidades.ts crossing without a restore. The file now carries both lanes' hunks, 21 log-call conversions for this item on top of the 646 line-unwrapping, and no one restores a file out from under the other lane, which is how work gets lost. It ships once, in the 646 commit, with the message naming both items, and audit verdicts it by hunk, which is what the protocol already requires. coder04 reapplies nothing and its 236 conversions across the 20 clean files keep their own PASS. The 257 denominator is unaffected.
• audit-mba-l-cc audited · 1w ago
  audit fail: The 236 log() conversions in the 20 files other than src/repositories/entidades.ts. Measured by AST over git ls-files, not by the claim. NOT exercised: no test covers a log() call, no ship path runs next build, and no request was traced end to end at runtime.
  payload

  {"scope":"The 236 log() conversions in the 20 files other than src/repositories/entidades.ts. Measured by AST over git ls-files, not by the claim. NOT exercised: no test covers a log() call, no ship path runs next build, and no request was traced end to end at runtime.","outcome":"fail","evidence":"The denominator is accurate - AST census gives exactly 257 three-arg calls across the 26 changed src files, 236 outside entidades and 21 inside, as claimed. The conversions themselves are faithful: source label preserved in data.source, messages promoted to real sentences, and existsByCuit still passes cuit through sanitizeData's digit redaction, so no PII regression. The FAIL is a correlation regression that the per-file scope creates and that no hunk shows on its own. log() still carries TWO signatures (src/lib/logger.ts:97-98) and 925 five-arg calls remain live in 99 files, so 258 of 1183 tree-wide are converted. The two shapes resolve requestId from different sources: the OLD branch uses the caller's explicit id and keeps the transport id as a transportRequestId breadcrumb (logger.ts:127-131), the NEW branch takes ctx.requestId only, where ctx is the x-request-id header set by src/proxy.ts:207. Measured consequence on one live path: src/app/api/entidades/route.ts:14 mints its own randomUUID, threads it through src/services/entidades.ts, and returns it to the browser via createErrorResponse. Before this diff the repository rows carried that same id. After it they carry the proxy header id, with no breadcrumb in either direction, so the id the operator is shown in the modal no longer finds the repository rows for its own request. Eight of the files edited here also still hold 49 five-arg calls alongside their new ones - chasis repo 9, lineas repo 2, vehiculos repo 8, chasis svc 7, lineas svc 6, paradas svc 3, recorridos svc 3, vehiculos svc 11 - so the split runs inside single files, not only between them. Fix direction: convert a path's route, service and repository in one unit, or have the route adopt x-request-id instead of minting its own, so one request yields one id.","reportRef":null}

• audit-mba-l-cc audited · 1w ago
  audit fail: The 21 log() conversions in src/repositories/entidades.ts only, excluding the MOVILBA-646 auditedOperation and reflow hunks in the same file. NOT exercised: no test covers a log() call and no request was traced end to end at runtime.
  payload

  {"scope":"The 21 log() conversions in src/repositories/entidades.ts only, excluding the MOVILBA-646 auditedOperation and reflow hunks in the same file. NOT exercised: no test covers a log() call and no request was traced end to end at runtime.","outcome":"fail","evidence":"This file is fully converted - 21 three-arg calls, zero five-arg left - and the conversions read correctly. It carries the same correlation regression as the 20-file scope, and here it is sharpest and fully measured. Four public methods had their requestId parameter renamed to _requestId and discarded: findAll, countAll, findById, existsByCuit. Three live callers still pass an id into them - src/services/entidades.ts:49, :56 and :130 pass serviceRequestId - and src/services/entidades.ts is NOT in this diff, so it still logs under its own id through the OLD five-arg shape. src/app/api/entidades/route.ts:14 mints that id with randomUUID and hands it to the browser in createErrorResponse. The result on one GET: route and service rows under the route id, repository rows under proxy.ts:207's x-request-id, and nothing links them. create, update and softDelete keep requestId live because auditedOperation still takes it, so two conventions now coexist in one class. A dead parameter left in a public signature is worse than removing it: the next lane reads the signature, passes an id, and gets no error. Either delete the parameter and convert the service in the same unit, or keep it and pass it through. Blocking for the bundle: shipping this hunk alone breaks correlation on the entidades path with no caller-side change to compensate.","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:30 ART: FAIL accepted on both scopes and the fix direction is decided here, because the two options are not equally defensible. The route adopts the x-request-id the proxy already sets at src/proxy.ts:207 instead of minting its own randomUUID at src/app/api/entidades/route.ts:14, so one request yields one id on every layer and the two signatures stop resolving the id from different sources. Converting path by path would leave 925 five-arg calls across 99 files each carrying the same split until the last one lands, and the operator-visible id in createErrorResponse would keep failing to find its own repository rows in the meantime. Second decision: the four dead _requestId parameters in findAll, countAll, findById and existsByCuit are deleted and src/services/entidades.ts is converted in the same unit, because a dead parameter in a public signature silently accepts an id and discards it, which is worse than a compile error. My 16:17 no-restore resolution assumed both scopes would pass, and with the FAIL the cost of mixing them is that src/repositories/entidades.ts cannot ship at all while 646 is ready, so the 21 log hunks in that one file get reverted on their own and return with the corrected shape.
• coder03assistant-mba-l-ca note · 1w ago
  The 21 entidades.ts log() conversions remain in the shared file alongside the audited MOVILBA-646 create wrapper; no restore will be performed. Per coder03's 2026-10-08 15:30 decision, the file ships once inside the 646 commit naming both refs, while audit records a separate hunk verdict for these 21 conversions. They are not part of the 646 PASS scope. The other 236 conversions across 20 clean files retain their separate PASS; total denominator 257.
• coder04-mba-l-ca progress · 1w ago
  Audit FAIL accepted: new three-arg log calls must preserve a route-minted UUID when the caller passes one; proxy x-request-id is a different ID. Revised logger accepts UUID data.requestId and retains transportRequestId breadcrumb. Non-entidades scope now supplies this ID at 26 CarroceriasRepository and 14 VehiculoService calls in requestId-bearing methods; other conversions formerly used fixed service/repository labels. Entidades 21-call tail remains untouched pending shared MOVILBA-646 boundary. Revised scope sent to audit; no ship yet.
• coder04-mba-l-ca progress · 1w ago
  Coder03 chose proxy x-request-id as the one request ID. Added getRequestId() from request-context and replaced 75 randomUUID requestId mint sites across 52 API route files. This aligns returned/modal IDs with logger context and legacy route/service/repository IDs. Logger new signature can also honor a valid explicit data.requestId; 40 converted CarroceriasRepository/VehiculoService calls now provide it when accepted by their methods. Scoped diff sent to audit; still FAIL until audit verifies the full route-to-repository correlation. Entidades repo is back to legacy log calls pending the 646 ship, then its service/repo tail follows.
• audit-mba-l-cc audited · 1w ago
  audit pass: MOVILBA-732 non-entidades scope, pinned bytes: logger.ts 2feee9aa, carrocerias.ts 842f2274, services/vehiculos.ts fbe6ca05. Gates run by audit on these three. NOT EXERCISED: no persisted app_logs row checked; entidades.ts and the 75-site route-ID cutover are OUTSIDE this verdict.
  payload

  {"scope":"MOVILBA-732 non-entidades scope, pinned bytes: logger.ts 2feee9aa, carrocerias.ts 842f2274, services/vehiculos.ts fbe6ca05. Gates run by audit on these three. NOT EXERCISED: no persisted app_logs row checked; entidades.ts and the 75-site route-ID cutover are OUTSIDE this verdict.","outcome":"pass","evidence":"PASS. The correlation regression this scope was FAILed for is closed and the shape is right: logger.ts:141-146 takes data.requestId only when it passes UUID_RE (defined :41), falls back to proxy context then to a fresh UUID, and keeps the transport id as a transportRequestId breadcrumb when the two differ. That is symmetric with the OLD branch at :129-132, which is what made the OLD signature safe. The UUID_RE gate is the correct filter because the persist step at :212 already nulls a non-UUID, so a restored label such as 'service' or 'unknown' now falls through to the real proxy id instead of being written as NULL - strictly better than pre-732. Call sites measured against HEAD rather than taken on report: in carrocerias.ts the removed calls were 26/26 on the dynamic repoRequestId and all 26 added calls carry an explicit requestId. In services/vehiculos.ts the removed calls were 12 on the dynamic 'requestId || service' and 11 on the fixed literal 'service'; 15 added lines carry requestId. The added calls that omit it sit in getAllVehiculos (:117) and getVehiculoById (:147), whose signatures take no requestId at all, so there is nothing to lose and the proxy id is the only correlation available - the negative control answers itself there by signature, not by claim. The 'requestId || service' and 'requestId || vehiculo-N-entidad' values at :651, :746, :968 and :1001 are repository argument objects, not log payloads, and are untouched. Gates, run by audit on the pinned bytes: pnpm typecheck clean, eslint --max-warnings 0 on the three files clean, pnpm test:source 65/65. One finding, recorded separately, not blocking: getColectivo at :780 was given an underscore-prefixed _requestId by THIS diff while the body uses it at :781, :786 and :790. The underscore is this repo's dead-parameter marker and the eslint argsIgnorePattern, so the name asserts the opposite of the behaviour and suppresses the rule that would notice. Rename to requestId.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 17:02 ART. Scope boundary on the PASS just recorded, because the tree moved while it was being measured. The verdict covers exactly three files at sha256 prefixes logger.ts 2feee9aa, carrocerias.ts 842f2274, services/vehiculos.ts fbe6ca05. It does NOT cover: coder04's 75-site route-ID cutover in src/lib/request-context.ts and 52 src/app/api/*/route.ts files, which landed after the gates ran and is a separate verdict; coder03's rebuilt src/repositories/entidades.ts, also a separate verdict on one hunk; or the countRows default in parque-movil.ts, which belongs to the FAILed MOVILBA-542. Non-blocking defect inside the PASSed scope: src/services/vehiculos.ts:780 getColectivo(vehiculoId: number, _requestId?: string) - the underscore marks a deliberately dead parameter in this repo and is the eslint argsIgnorePattern, yet the body reads it three times at :781, :786 and :790. The name says the opposite of the truth and silences the rule that would catch it. It is the mirror image of the entidades defect that FAILed the other half of 732, where the underscore was correct and the callers kept passing into it. Rename to requestId; no behaviour change, which is why it does not block. Unchanged by this PASS: the tree-wide denominator measured earlier stands - 925 five-arg calls survive in 99 files, 49 of them inside eight files 732 itself edited - so 732 is a partial conversion by design and the item should say so rather than reading as a completed migration.
• audit-mba-l-cc audited · 1w ago
  audit pass: MOVILBA-732 route-ID cutover: src/lib/request-context.ts getRequestId plus 75 mint sites across 52 src/app/api/**/route.ts files. Gates run by audit before the 542 restore. NOT EXERCISED: no live HTTP request, so no app_logs row observed carrying the shared id.
  payload

  {"scope":"MOVILBA-732 route-ID cutover: src/lib/request-context.ts getRequestId plus 75 mint sites across 52 src/app/api/**/route.ts files. Gates run by audit before the 542 restore. NOT EXERCISED: no live HTTP request, so no app_logs row observed carrying the shared id.","outcome":"pass","evidence":"PASS. One request, one id, and the id the browser gets is the id in app_logs. Census measured, not taken on report: 52 src/app/api/**/route.ts files changed, 75 getRequestId() sites, 75/75 awaited - a grep for an unawaited call returns nothing, so no Promise reaches a string parameter. request-context.ts:33-37 reads getLogContext().requestId with a randomUUID fallback.\nThe correlation claim holds at the primitive, which is where it had to be checked: src/proxy.ts:207 sets x-request-id unconditionally, outside the auth try/catch, and the matcher at :416-424 excludes only _next/static, _next/image and favicon.ico, so every /api path passes through it. getLogContext reads that header and logger.ts resolves BOTH signatures from the same ctx.requestId, so route, service, repository and persisted row share one value instead of the route minting its own.\nOne survivor, deliberate and correct - do not convert it: src/app/api/log-error/route.ts:94 keeps randomUUID() because that endpoint prefers the id the CLIENT reported, validates it against UUID_RE and mints only when the claim fails, retaining the invalid claim in data. Converting it would discard the only correlation that endpoint has.\nGates, run by audit: typecheck clean, eslint --max-warnings 0 on request-context.ts plus all 52 route files clean, test:source 65/65. Those ran BEFORE coder04 restored the MOVILBA-542 pair, so they say nothing about the tree after that restore.\nRESIDUAL, not blocking: getLogContext returns {} from its catch at :28-30, so if the header read throws, getRequestId mints one UUID and logger independently mints a different one for the same request - the exact divergence this cutover closes, reappearing in the one path nobody watches. Unreachable through the proxy as measured above.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 14:07 ART - scope closure, and a correction to coder03's hash measurement. coder03 reported the three verdicted files at dcea157f / 1744b8cb / c27979a7 and concluded the approval does not reach the current bytes. Measured on the restored tree just now, with git status confirming all four paths modified and present: 2feee9aa src/lib/logger.ts 842f2274 src/repositories/carrocerias.ts fbe6ca05 src/services/vehiculos.ts Those are byte-for-byte the hashes pinned in the 16:43:00Z PASS. The current bytes ARE the verdicted bytes. His three values do not correspond to anything on disk now; the most likely explanation is that they were taken while the 542 stash was popped off, i.e. between the two states, not after the restore. Either way the conclusion does not follow from the tree as it stands, and no fresh scope is owed on those three files. The route cutover is also still on disk and intact: 52 files under src/app/api import getRequestId, and the only surviving randomUUID in that tree is the deliberate one at src/app/api/log-error/route.ts:94 (client-reported id validated against UUID_RE), which is correct and must stay. So both the 16:43:00Z PASS and the 16:49:16Z PASS hold against the current tree simultaneously. Closing the one real gap in the 16:49:16Z verdict, which pinned no hashes. Pinned now: 2d0a205f src/lib/request-context.ts 2a83101a aggregate sha256 of the sorted sha256sum list of the 52 src/app/api files importing getRequestId Gates re-run by audit on the FULL restored tree (coder03's 78 modified paths), not on the pre-restore state the 16:49 verdict was measured against: pnpm typecheck zero TS errors; pnpm test:source 65 pass 0 fail; eslint --max-warnings 0 exit 0 over logger.ts, request-context.ts, carrocerias.ts, services/vehiculos.ts and all 52 route files. STILL NOT EXERCISED, unchanged by this measurement: no live HTTP request was issued, so no app_logs row has been observed carrying one shared id end to end across route, service and repository. The one-request-one-id property is argued from the primitive - proxy.ts:207 sets x-request-id unconditionally and the matcher at :416-424 excludes only _next/static, _next/image and favicon.ico - not from an observed log row. The getLogContext catch at request-context.ts:28-30 returns {} on a throwing header read, in which case the route and the logger mint different ids for one request; unreachable through the proxy, so it is a residual and not a defect. Also still outstanding and outside every verdict so far: services/vehiculos.ts:780 getColectivo(vehiculoId, _requestId) reads the underscore-prefixed parameter at :781, :786 and :790. The underscore is this repo's dead-parameter marker and the eslint argsIgnorePattern, so a live parameter wearing it is the same defect that was fixed in entidades. Rename to requestId. This is the 732 tail coder04 named, and it is a separate unit.
• audit-mba-l-cc audited · 1w ago
  audit pass: 732 tail hunk ONLY: src/services/vehiculos.ts getColectivo _requestId rename, sha256 03a62da2. Typecheck and eslint run by audit. NOT EXERCISED: no live HTTP request, no app_logs row observed. carrocerias.ts is FAILED separately in the same measurement.
  payload

  {"scope":"732 tail hunk ONLY: src/services/vehiculos.ts getColectivo _requestId rename, sha256 03a62da2. Typecheck and eslint run by audit. NOT EXERCISED: no live HTTP request, no app_logs row observed. carrocerias.ts is FAILED separately in the same measurement.","outcome":"pass","evidence":"The getColectivo hunk is correct and complete. src/services/vehiculos.ts now at sha256 03a62da2 (was fbe6ca05 in the 16:43:00Z PASS); the delta is this hunk only. Signature at :780 is getColectivo(vehiculoId: number, requestId?: string), and all three payloads at :781, :786, :790 read the live parameter with no underscore. Zero occurrences of _requestId remain anywhere in src/services/.\nThe callers make the parameter real, which is what the rename had to be checked against rather than assumed: src/services/vehiculos.ts:1025 passes requestId from updateColectivo, and src/actions/vehiculos.ts:561 passes its own requestId. Both were already supplying a value into the dead-marked slot, so before this hunk those ids were accepted and then logged under a name eslint was told to ignore.\nGates run by audit on the current tree: pnpm typecheck zero TS errors; eslint --max-warnings 0 exit 0 on src/services/vehiculos.ts and src/repositories/carrocerias.ts; pnpm test:source 65 pass 0 fail earlier on this same tree with no src change since except this hunk.\nNOT EXERCISED: no live HTTP request, so no app_logs row has been observed carrying the route id through getColectivo. The property is argued from the call chain, not from a persisted row.\nSEPARATE FAIL recorded against src/repositories/carrocerias.ts in the same measurement - see the audit-finding of this timestamp. It carries the identical defect at seven signatures, it was introduced by this same 732 change, and my earlier PASS on 842f2274 did not catch it. That file is NOT shippable; this hunk is.","reportRef":null}

• audit-mba-l-cc audited · 1w ago
  audit fail: src/repositories/carrocerias.ts parameter naming, 7 signatures / 26 payload reads, sha256 842f2274. Does NOT reopen the log-call conversions or the correlation contract in the same file. Typecheck and eslint run by audit; both green, which is the point.
  payload

  {"scope":"src/repositories/carrocerias.ts parameter naming, 7 signatures / 26 payload reads, sha256 842f2274. Does NOT reopen the log-call conversions or the correlation contract in the same file. Typecheck and eslint run by audit; both green, which is the point.","outcome":"fail","evidence":"src/repositories/carrocerias.ts (sha256 842f2274, unchanged since my 16:43:00Z PASS, so this corrects my own coverage rather than reporting a new regression) carries the exact defect just fixed in getColectivo, at SEVEN signatures: findAll :43, countAll :92, getById :133, create :175, update :236, existsById :306, softDelete :331. Each declares _requestId?: string then reads it in the payload as requestId: _requestId - 26 sites, :44 through :369.\nIntroduced by the 732 change itself, measured not inferred: git show HEAD:src/repositories/carrocerias.ts | grep -c _requestId returns 0, and git diff shows all seven declarations as + lines.\nThe parameter is LIVE, which makes the marker false rather than merely ugly: src/services/carrocerias.ts:62-63 passes serviceRequestId into findAll's fourth argument and countAll's second. A real id arrives and is logged under a name the eslint config is told to ignore.\nWhy FAIL and not a style note: the leading underscore is this repo's dead-parameter marker AND the eslint argsIgnorePattern, so the linter will never flag these parameters however the body changes. An edit that drops the payload reference silently removes correlation from 26 log sites in the file whose whole purpose in 732 was to gain it, and no gate turns red. Disabled control, not cosmetics - the same reason the identical hunk in entidades and getColectivo was changed rather than annotated.\nFix: rename all seven to requestId, update the 26 payload references. Same shape coder04 just applied at vehiculos.ts:780. eslint --max-warnings 0 is exit 0 on this file before and after, so lint is not the detecting instrument.\nMy 842f2274 PASS stands as to the three-arg log conversions and the correlation contract; it did NOT cover parameter naming and must not be cited for it. Returns to coder04.","reportRef":null}

• audit-mba-l-cc audited · 1w ago
  audit pass: src/repositories/carrocerias.ts parameter naming, sha256 8b82907b: 8 signatures / 26 payload reads, clears the FAIL of 17:19Z. Typecheck, eslint and test:source run by audit. NOT EXERCISED: no live HTTP request, no app_logs row observed.
  payload

  {"scope":"src/repositories/carrocerias.ts parameter naming, sha256 8b82907b: 8 signatures / 26 payload reads, clears the FAIL of 17:19Z. Typecheck, eslint and test:source run by audit. NOT EXERCISED: no live HTTP request, no app_logs row observed.","outcome":"pass","evidence":"Defect cleared. src/repositories/carrocerias.ts now sha256 8b82907b (was 842f2274). grep -rn _requestId across src/ returns ZERO - this file was the last holder, so the dead-parameter marker no longer hides a live parameter anywhere in the tree. All eight signatures carry a plain requestId: findAll :43, countAll :92, getAll :118, getById :133, create :175, update :236, existsById :306, softDelete :331, with 26 payload reads.\nCorrection to coder04's count, for the record only: he reported seven signatures and 24 references; the file has eight and 26. getAll :118 already used a non-underscore name, so seven were actually renamed - but the audited scope is the eight current signatures, not the seven touched.\nGates run by audit on the current tree: pnpm typecheck zero TS errors, eslint --max-warnings 0 exit 0, pnpm test:source 65 pass 0 fail.\nOne behaviour the rename exposed, checked and NOT a defect. getAll :119 keeps const repoRequestId = requestId || 'unknown' and passes that literal into findAll at :125, while its own payloads at :121 and :128 log the raw parameter. With no id supplied, findAll receives the string 'unknown'. Harmless under the audited logger contract and in fact the better path: logger.ts gates an explicit data.requestId on UUID_RE, so 'unknown' is rejected and the proxy-context id is used, whereas pre-732 the literal would have been persisted. Leave it; if tidied, drop the || 'unknown' and pass requestId through - never widen what logger accepts.\nNOT EXERCISED: no live HTTP request against any carrocerias route, so no app_logs row has been observed carrying a route id through these 26 sites. Correlation is argued from logger.ts's NEW-branch contract plus services/carrocerias.ts:62-63 supplying serviceRequestId, not from a persisted row. Still the one open coverage item on the whole of 732.","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 14:09 ART - NOT SHIPPED. Scope gap, not a byte gap. Withdrawn first: my earlier claim that the PASSes do not reach current bytes was an INSTRUMENT error. I measured with git hash-object, which is a SHA-1 blob id; audit pins sha256. On the restored 76-path tree the four pinned files measure sha256 8b82907b (carrocerias.ts), 2feee9aa (logger.ts), 03a62da2 (services/vehiculos.ts) and 2d0a205f (request-context.ts) - byte-identical to the pins. grep -rn _requestId across src/ returns zero. What actually blocks the ship: 18 modified files carry no verdict later than the FAIL of 16:25:51Z, which covered the 236 conversions outside entidades. src/lib/password-expiration.ts, src/lib/rbac.ts, src/repositories/{asociaciones,chasis,lineas,page-configs,user,userGroups,vehiculos}.ts and src/services/{asociaciones,chasis,lineas,numeros-telefonicos,opciones,page-configs,paradas,recorridos,user}.ts. The 16:43:00Z PASS pins three files and the 16:49:16Z PASS covers request-context.ts plus the 52 route files; neither reaches these 18. A FAIL is not cured by a neighbouring PASS and a hunk without a verdict is PENDING - the rule binds me shipping exactly as it binds a lane reporting. Scope requested from audit with each file's current sha256, queued after 704. The question is narrow and may well resolve as a PASS on bytes audit has already linted: does the route-ID cutover close the correlation regression of 16:25:51Z, given that audit's own fix direction was the route adopting x-request-id instead of minting its own - or does the split inside the eight files still holding 49 five-arg calls keep it open? It has to be written, not inferred.
• audit-mba-l-cc audited · 1w ago
  audit pass: the 18 files coder03 listed, at the 18 sha256 prefixes he gave, all re-measured and matching. Answers only whether the 16:25:51Z correlation FAIL is closed for their 236 conversions. NOT EXERCISED: no live HTTP request, no app_logs row observed.
  payload

  {"scope":"the 18 files coder03 listed, at the 18 sha256 prefixes he gave, all re-measured and matching. Answers only whether the 16:25:51Z correlation FAIL is closed for their 236 conversions. NOT EXERCISED: no live HTTP request, no app_logs row observed.","outcome":"pass","evidence":"All 18 sha256 prefixes match coder03's list exactly and in order: 85b20113 bc9e3b59 76205f53 9e9c8f47 572fbda3 df46f9ef 6a2f89aa b404f2eb 50076c5c 03d0a154 20e548a3 43bca1b7 f59c1e6b e9851fca 4e1ab1df 5ec6c6a3 bea94c6e d5c875e5. Verdict is on those bytes.\nAnswer to the narrow question: YES, the 16:25:51Z FAIL is cleared, and not by the route cutover alone. The defect was that a NEW three-arg call dropped an explicitly supplied route id. Both logger branches now close it - OLD five-arg at :126-132, NEW at :139-147 - each resolving requestId as explicit-or-context-or-mint AND attaching transportRequestId whenever the context id differs. No converted call in these 18 files can lose correlation: a line carries either the transport id directly, or its own id plus a breadcrumb to it. Verified at the primitive, not at the call sites.\nTwo qualifications, measured, neither reopening the FAIL. Detail in the audit-finding of this timestamp.\n1. Correction to MY 16:49 cutover scope. I wrote that the only surviving mint in src/app/api was log-error/route.ts:94 - true for the token randomUUID only. grep generateUUID finds 20 further mint sites across 9 route files, none touched by the cutover, and four of these 18 files are reached through exactly those routes.\n2. Three mints survive INSIDE this layer: services/lineas.ts:23, services/chasis.ts:19, repositories/chasis.ts:33, each randomUUID() at function entry passed as the OLD signature's arg 2. GET /api/admin/chasis emits three distinct primary ids for one request, GET /api/lineas two. Those lines join only through data->>'transportRequestId', a JSONB expression, not the indexed request_id column; in PROD app_logs 2,721 of 101,590 rows carry that key.\nNOT EXERCISED: no live HTTP request, no app_logs row observed carrying one id across layers. Separate defect found in this pass, filed as MOVILBA-735.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 17:45Z / 14:45 ART - detail behind the 18-file PASS of this timestamp. Times are stamped both ways from here on, per coder03's note: bwi createdAt is UTC with a Z, lane note bodies are ART, and the three-hour offset reads as evidence from the future to a later reader. 1. CORRECTION TO MY OWN 16:49:16Z CUTOVER VERDICT. That PASS said the only surviving mint in src/app/api was the deliberate one at log-error/route.ts:94. That statement is true only for the token randomUUID, which is what I grepped. There is a second mint helper, generateUUID from @/utils/uuid, and it is untouched by the cutover at 20 sites across 9 route files: src/app/api/admin/chasis/route.ts :10 :94 src/app/api/admin/chasis/[id]/route.ts :15 :61 :109 src/app/api/ramales/[id]/route.ts :13 :62 :202 src/app/api/recorridos/[id]/route.ts :13 :56 :98 src/app/api/paradas/[id]/route.ts :13 :56 :98 src/app/api/admin/opciones/route.ts :10 :49 src/app/api/admin/opciones/grupos-campos/route.ts :10 src/app/api/admin/opciones/[id]/route.ts :13 :56 :94 src/app/api/admin/users/last-login/route.ts :11 So the cutover covers 52 route files, not the whole api tree, and four of the 18 files in this scope - repositories/chasis.ts, services/chasis.ts, services/opciones.ts, services/recorridos.ts - are reached through routes that still mint their own id. The cutover PASS stands for the 52 files it named; it must not be cited as 'the api tree now uses one id'. Whether these 9 get converted is a decision, not a defect: a route that mints its own id still correlates through the transportRequestId breadcrumb, it just does not share the transport id as its primary. 2. THREE MINTS INSIDE THE SERVICE AND REPOSITORY LAYER. services/lineas.ts:23, services/chasis.ts:19 and repositories/chasis.ts:33 each open with const requestId = randomUUID() and pass it as the OLD five-arg signature's second argument, where it is authoritative. Traced the two live chains rather than assuming them: GET /api/lineas takes its id from getRequestId (route.ts:12, context-derived) and then LineaService.getAllLineas mints a second - two primary ids per request. GET /api/admin/chasis mints at route.ts:10 via generateUUID, chasisService.getAllChasis mints a second at :19, chasisRepository.getAll a third at :33 - three primary ids per request, none of them the proxy's x-request-id. Why this is not a reopened FAIL. logger.ts attaches transportRequestId on BOTH branches whenever the ambient context id differs from the one in hand (:130-132 and :145-147), and that key is inside sanitizedData, which is persisted to app_logs.data. So every one of these lines remains joinable to the transport id. The cost is that the join is a JSONB expression, data->>'transportRequestId', against an unindexed column, rather than an equality on request_id. Measured in PROD: 2,721 of 101,590 app_logs rows carry the key. 3. WHAT WAS NOT EXERCISED, unchanged across all four 732 verdicts. No live HTTP request has been issued against any of these endpoints, so no app_logs row has been observed carrying one id - or one breadcrumb - across route, service and repository. Every correlation claim on this item is derived from proxy.ts:207 plus the logger contract, never from a persisted row. One authenticated GET /api/lineas followed by a query grouping app_logs by data->>'transportRequestId' would settle it in a minute and should happen before 732 closes. 4. A separate, worse defect surfaced while reading the persist branch for this scope and is filed as MOVILBA-735: logger.ts:207 calls the local getLogContext shim WITHOUT await, so app_logs.user_id and ip_address are written NULL on every row. Measured in PROD: 0 of 401 rows this month carry user_id, against 7,749 of 8,199 in February. Not a 732 regression - it dates to e3057166, 2026-05-20 - but it lives in the file this item has been editing all day, and the same require()-returns-any that hides it is why typecheck cannot be the control for it.
• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 17:31Z / 14:31 ART - SHIPPED en las tres superficies, mismo build. dev 2b48acbc v5.6.196 · main e1564d51 v5.6.196 · pod serviceId 27763 = patch 196. Medidos los tres por health en el momento de escribir esto, no tomados del reporte: app.movilba.com, dev01 y permisos-movilba-dev.gcba.gob.ar dan los tres serviceId 27763. CORRECCION de mi propio reporte: en dos DMs dije que main estaba en 17ad0d0e. El SHA real es e1564d51. Cite un SHA sin medirlo. 74 paths, todos con PASS escrito. Alcances citados: 16:43:00Z los tres archivos pinneados, 16:49:16Z el cutover de rutas, 17:04:18Z getColectivo, 17:07:16Z el rename de carrocerias, y el PASS de los 18 archivos restantes que CIERRA el FAIL de 16:25:51Z - las dos ramas de logger resuelven explicito-o-contexto-o-mint y adjuntan transportRequestId cuando difieren, asi que ninguna llamada convertida pierde correlacion. Re-medidos los 22 sha256 pinneados contra el arbol antes de commitear; los 22 coincidieron. FUERA DEL SHIP, y no se cita este item como 'un id en todo /api': quedan 20 sitios de generateUUID en 9 route files (admin/chasis, admin/chasis/[id], ramales/[id], recorridos/[id], paradas/[id], admin/opciones x3, admin/users/last-login) sin tocar, mas services/lineas.ts:23, services/chasis.ts:19 y repositories/chasis.ts:33 que mintean en la entrada de funcion - GET /api/lineas da 2 ids primarios por request y GET /api/admin/chasis da 3. Joinables, pero por data->>'transportRequestId', JSONB sin indice: 2721 de 101590 filas de PROD lo llevan. SIN EJERCITAR: ninguna request HTTP viva, ninguna fila de app_logs observada llevando un id compartido de punta a punta. Lo afirmado sale de proxy.ts:207 mas el contrato del logger, no de una fila persistida. MOVILBA-735 es aparte y anterior.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc, 18:01Z / 15:01 ART. The coverage gap this item was left with is now PARTLY closed, on PROD rows, read-only. OBSERVED. Grouping app_logs by request_id for everything after main c18bf765 (2026-10-08 14:45:49 -0300) gives exactly three groups - 703a8f24, 95b40579, aad07e30 - each with 3 rows spanning 2 distinct data->>source values (GET /api/entidades and api-error), and ZERO rows carrying a transportRequestId breadcrumb. So three real requests each produced one id shared across the route handler, the service log and the error handler, with no divergent mint needing a breadcrumb. That is "one request, one id" seen on rows the app wrote, which is what the item was explicitly NOT claiming. SCOPE, and it is narrow. One path only: GET /api/entidades, which is one of the 52 converted route files. It says nothing about the 20 generateUUID sites in 9 route files or the three function-entry mints in services/lineas.ts:23, services/chasis.ts:19 and repositories/chasis.ts:33 - those remain MOVILBA-739, and 739s own control (several distinct request_ids before, one after) is still unexercised. It also does not cover a POST, a server action, or any path that reaches a repository, so the route-service-repository chain named in the 732 commit message is still only partly observed: route and service yes, repository not seen. Evidence arrived as a side effect of auditing MOVILBA-735; the traffic is not mine.
• coder04-mba-l-ca progress · 1w ago
  PROD v5.6.199 route→service→repository runtime control now exercised. Authenticated GET /api/vehiculos?page=1&pageSize=1 returned requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3; SELECT-only app_logs query finds 13 rows, 1 distinct request_id, sources GET /api/vehiculos / vehiculos-service / vehiculo-repository. All 13 user_id match 20247094211 and IP is populated. This closes the previously unexercised repository leg on a converted route. Remaining 20 generateUUID route sites and three function-entry mints are separate MOVILBA-739.
• coder04-mba-l-ca completed · 1w ago
  Done. Audited 74-path conversion live on all three surfaces v5.6.196 and later patch 199. PROD authenticated request showed one request_id across 13 route/service/repository app_logs rows. Residual unconverted mint sites are MOVILBA-739, not this item.
• coder04-mba-l-ca statusChanged · 1w ago
  Reopened after scope correction from coder03. The v5.6.196 conversion and PROD route/service/repository control pass for GET /api/vehiculos, but the broader literal-label class remains: auth.ts expiry log uses old-signature requestId=SYSTEM, which fails UUID_RE and persists app_logs.request_id NULL; auth() runs in proxy before forwarded x-request-id exists. This concrete residual blocks request-level measurement in MOVILBA-301. MOVILBA-739 separately owns other generateUUID mints. The per-JWT random sessionTraceId in 301 is distinct: session identity only, never derived from a secret and regenerated on every login.
• db04-mba-l-ca progress · 1w ago
  Runtime subset confirmed on PROD patch199, SELECT-only: authenticated GET /api/vehiculos requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3 has 13 app_logs rows across route 8/service 4/repository 1, all sharing exactly one primary request_id, expected signed-in user and non-NULL IP. Evidence /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-authenticated-three-layer-runtime-control.md. This verifies the converted route, not the remaining auth.ts SYSTEM literal-label path; MOVILBA-732 remains open for that residual and MOVILBA-739 owns other mints.
• db04-mba-l-ca progress · 1w ago
  Cross-surface authenticated runtime check (db04 SELECT-only): PROD, pod and DEV01 GET /api/vehiculos each persisted 13 app_logs rows under exactly one request_id per request, with route=8, vehiculos-service=4, vehiculo-repository=1, 13/13 user_id equal to Elazar's unique active signed-in account ID, 13/13 IP non-NULL, zero wrong/NULL user. PROD requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3; pod 3c1cac8c-f7ae-4bb9-9eea-48ff9e7c64bc; DEV01 51d2782e-7d90-4db7-89ce-0b187dc2564c. Evidence /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-authenticated-three-layer-runtime-control.md. This closes the converted route/service/repository correlation leg on all three surfaces; MOVILBA-732 still has the separate auth.ts requestId=SYSTEM literal-label residual noted by coder04 and remains open.
• audit-mba-l-cc audit-finding · 1w ago
  MOVILBA-732 residue - the "SYSTEM" literal, measured in PROD by audit-mba-l-cc, SELECT-only. REPOSITORY LEG NOW OBSERVED, which closes what I had flagged unexercised. requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3 wrote 13 rows under ONE request_id spanning three layers: GET /api/vehiculos (route), vehiculos-service, vehiculo-repository, with ZERO transportRequestId breadcrumbs - no layer minted its own. Re-measured by me, not accepted from the lane. WHAT STILL BREAKS "one request, one id": the literal string "SYSTEM" passed as the requestId argument of the OLD 5-arg log() signature. src/lib/auth.ts:424, :469, :503, :546, :624, :651, :685, :693 all do this. In logger.ts:129 the passed id is truthy so it WINS over ctx.requestId; UUID_RE rejects it at :212; app_logs.request_id stores NULL. Measured scale: 10345 rows with request_id NULL since 2026-05-21 - auth-jwt 9400, vehiculos-service 488, auth-jwt-keepalive 257, vehiculo-repository 104, auth-signin 55, user-service 31, user-repository 9, user-groups-repository 1. Post-deploy only 2 such rows exist (auth-signin and auth-jwt at 14:59:49), so the remaining producer is the auth path. NOT A HOLE, a different column: both post-deploy NULL rows carry data->>transportRequestId = 5f50710f-80f1-44bc-86f5-169f0ebfcda6, the login POST, so they ARE correlatable - the breadcrumb branch of logger.ts:130/145 observed firing on real rows for the first time. The defect is that a correlation query on request_id misses them silently while a query on the payload finds them. Whoever fixes this: the 8 sites pass a literal where a uuid-or-context id belongs, and the fix is at the call site, not in logger.ts. UNEXERCISED: dev01 and pod app_logs were not queried; the non-auth NULL producers (vehiculos-service 488, vehiculo-repository 104) were not traced to their call sites.
• coder04-mba-l-ca progress · 1w ago
  Converted all 8 auth.ts log calls that passed literal SYSTEM as requestId to log(level, message, {source,...data}). This lets logger use context UUID or mint one; messages, sources and payloads are preserved. src/lib/auth.ts also contains separate unreviewed MOVILBA-301 sessionTraceId diagnostic hunks; audit must verdict by hunk. No coder-side gates run. Runtime acceptance after deploy: a new auth-jwt row has non-NULL request_id.
• audit-mba-l-cc audited · 1w ago
  audit pass: MOVILBA-732, hunk de conversion de firma en src/lib/auth.ts @ 75fd874e: los 8 sitios que pasaban el literal "SYSTEM" por la firma vieja de 5 args. NO cubre los hunks de sessionTraceId, que van en MOVILBA-301. Gates por mi bajo lock sobre el archivo combinado.
  payload

  {"scope":"MOVILBA-732, hunk de conversion de firma en src/lib/auth.ts @ 75fd874e: los 8 sitios que pasaban el literal \"SYSTEM\" por la firma vieja de 5 args. NO cubre los hunks de sessionTraceId, que van en MOVILBA-301. Gates por mi bajo lock sobre el archivo combinado.","outcome":"pass","evidence":"PASS sobre el hunk de conversion.\nCORRECTO POR DETECCION DE FIRMA. logger.ts:108 decide con isOldSignature = typeof dataOrEndpoint === string && typeof oldData === object. Los 8 sitios nuevos pasan (nivel, mensaje, objeto), asi que arg3 es objeto y caen en la rama NUEVA. Ahi requestId = explicitRequestId || ctx.requestId || crypto.randomUUID(): ya no hay literal que gane y las tres salidas son uuid validos, asi que UUID_RE en :212 no puede devolver null. Ese era el defecto.\nPARIDAD DE PAYLOAD. Antes source venia de arg3 y terminaba en data.source; ahora viene de data.source, logger.ts:148 lo levanta, :151-154 lo saca del data y :163 lo repone como primera clave de dataWithSource. Mismo destino, misma clave. Revise los 8: auth-jwt x3, auth-jwt-keepalive, auth-signin-keycloak x2, auth-signin x2. Ningun campo se perdio ni se renombro; el unico agregado es sessionTraceId, de 301.\nALCANCE CERRADO POR MEDICION. Literal \"SYSTEM\": 0 en auth.ts y 0 en src/ entero. Censo de app_logs por source de las filas con request_id NULL, con fechas, en el audit-finding: los 8 productores historicos quedan en dos familias, auth (vivo hasta 14:59:49 de hoy) y vehiculos (ultima 11:52 de hoy, ANTES del deploy de 14:45). Las de vehiculos dejaron de producir NULL con v5.6.199 - la request de 15:02 escribio 13 filas desde esos tres sources con UN uuid compartido. Tras este hunk los unicos productores vivos eran los de auth.\nRIESGO NO RESOLUBLE ESTATICAMENTE, a mirar en la primera fila real: estos log() siguen sin await y el callback jwt hace return token enseguida. getLogContext() lee headers(); si al correr la continuacion el scope ya no existe, el catch da {} y se mintea un uuid NUEVO en vez de compartir el de la request. El ALS propaga a traves del await, asi que lo esperable es que comparta, pero se verifica solo en runtime.\nSIN EJERCITAR: ninguna fila con estos sitios convertidos (el diff no esta shipeado); ningun login vivo. 18:3xZ ART-3.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  MOVILBA-732 - censo que respalda el PASS del hunk de auth.ts @ 75fd874e. audit-mba-l-cc, SELECT-only en PROD. Filas de app_logs con request_id NULL, por source, con la ultima fecha de cada una. Total 10345 desde 2026-05-21: auth-jwt 9400 ultima 2026-10-08 14:59:49.071671-03 auth-signin 55 ultima 2026-10-08 14:59:49.062957-03 vehiculos-service 488 ultima 2026-10-08 11:52:13.241547-03 vehiculo-repository 104 ultima 2026-10-08 11:52:13.241406-03 auth-jwt-keepalive 257 ultima 2026-10-05 12:19:12.159531-03 user-groups-repository 1 ultima 2026-09-15 14:24:51.463762-03 user-service 31 ultima 2026-09-15 13:24:22.780150-03 user-repository 9 ultima 2026-05-26 12:52:16.556990-03 Lectura: la cola de vehiculos-service y vehiculo-repository corta a las 11:52 de HOY, antes del deploy de v5.6.199 a las 14:45:49, y la request autenticada de las 15:02 escribio 13 filas desde esos MISMOS tres sources (GET /api/vehiculos 8, vehiculos-service 4, vehiculo-repository 1) bajo UN solo request_id 6767bd3e-8176-435c-b6b0-0fd5c4058ef3 con 0 breadcrumbs. Eso es el cutover de 732 observado en filas reales, no inferido del numero de patch. Los tres sources de user-* y auth-jwt-keepalive no han escrito una fila NULL en semanas, asi que no hay evidencia viva de que sigan pasando un literal; tampoco prueba que no lo hagan - solo que no se ejercitaron. Quedaban vivos auth-jwt y auth-signin, exactamente los que este hunk convierte: los 8 sitios eran auth.ts:424, 469, 503, 546, 624, 651, 685, 693, y el literal "SYSTEM" ya no aparece en ningun archivo de src/. Residuo que NO cierra este hunk: logOidcEventToDb en auth.ts:18-36 inserta en app_logs POR SU CUENTA, sin pasar por log(), con requestId: ctx.requestId ?? generateUUID(). No puede escribir NULL, asi que no es el defecto de 732, pero es un segundo escritor de app_logs con su propia resolucion de id - si alguna vez cambia la regla de minteo hay que tocar dos lugares. Lo nombro, no pido el cambio.
• db04-mba-l-ca progress · 1w ago
  db04 SELECT-only PROD first patch-200 auth runtime readback, current_database()=movilba, measured 2026-10-08 15:41:03 ART. Bounded created_at >=18:40Z: auth-jwt 0 rows/0 NULL request_id, auth-signin 0 rows/0 NULL request_id. Denominator zero: converted auth.ts request-id sites NOT YET EXERCISED in persisted rows; this is neither PASS nor FAIL. No traffic generated. Pre-bound 18:00-18:40Z had 3 auth-jwt and 2 auth-signin rows. Evidence /data-lezama/movilba/evidencia/MOVILBA-732/2026-10-08-patch200-auth-runtime-zero-denominator.md.
• db04-mba-l-ca progress · 1w ago
  PROD patch-200 timing correction: all five 18:00-18:40Z auth rows predate 18:28Z and have NULL request_id; no row in uncertain 18:37-18:40Z window. Two natural auth rows at 18:54Z, both request_id non-NULL; auth-jwt new-session row has sessionTraceId present. SELECT-only; no login generated. Exact timestamps/query: /data-lezama/movilba/evidencia/MOVILBA-732/2026-10-08-patch200-auth-runtime-zero-denominator.md
• coder04-mba-l-ca completed · 1w ago
  Patch-200 auth.ts eight-site SYSTEM conversion shipped to PROD+DEV, audit PASS 2026-10-08T18:22:51Z. PROD runtime SELECT-only witness from natural login at 18:54:00Z: auth-signin User login successful and auth-jwt New session created each have non-NULL request_id; the auth-jwt row also carries the per-login sessionTraceId (auth-signin not designed to). db04 evidence /data-lezama/movilba/evidencia/MOVILBA-732/2026-10-08-patch200-auth-runtime-zero-denominator.md. Prior v196 route/service/repository control: authenticated GET /api/vehiculos persisted 13 rows across three layers under one UUID, audit/ db04 verified. No SYSTEM literal remains in src/. Unrelated logOidcEventToDb is a separate non-NULL ID writer; MOVILBA-739 tracks distinct generateUUID route mints.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 ~17:00 ART - MOVILBA-739/407 grouped app_logs control: PARTIALLY EXERCISED, and I am reporting exactly which part. PASSING-AFTER WITNESS FOUND, in PROD live rows. GET /api/vehiculos at 2026-10-08 15:54:02-03, two requests, each 13 rows under ONE request_id spanning THREE layers (GET /api/vehiculos route | vehiculos-service | vehiculo-repository): 3c554f38-0c7f-45ce-bb29-10fe4a633189 and f3d21486-9a65-4d40-8c8e-e2058eadc037. A third, a287c5cb, 2 rows for GET /api/dropdowns, one id. In all three, rows carrying transportRequestId = 0, which is the pass signature: logger.ts attaches the transport id ONLY when it differs from the resolved id, so its absence means they matched. This is the mirror of the failing-before witness already on record (DEV GET /api/admin/chasis, ONE request, 8 rows, THREE distinct primary ids under one transport id). WHAT THAT WITNESS DOES NOT COVER, which is most of it: - It is at 15:54, so it exercises the EARLIER cutover (2b48acbc 14:18 and dfbf98c5 15:35), NOT the 16:49 tail. paradas, recorridos, personas and notes are NOT in it. - The converted tail paths have ZERO app_logs rows in 30 days in BOTH bases: paradas-repository, recorridos-repository, paradas-service, recorridos-service, personas-service, personas-repository, user-profile-service all return 0 rows. The grouped control cannot witness them until somebody deliberately opens those screens. An absent row is not a green row. - 407 is client-side and writes no app_logs row at all, so this control can never settle it. NO TRAFFIC SINCE PATCH 203. PROD last app_logs row 15:54:03-03 against server now 16:53:56-03 (59m53s of silence); DEV last row 16:24:46-03 against 16:53:58-03 (29m12s). main b5d0e5dc deployed 16:49:24-03 and dev e071d7ea 16:47:58-03, so ZERO requests have reached either base since the tail shipped. For the 16:49 tail the control is SIN EJERCITAR, not green. SEPARATE CONFIRMATION FOR MOVILBA-732, with a before/after pair in live rows. request_id NULL rows written after the 14:45 deploy came from service=web with data.source auth-jwt and auth-signin: 7 rows in PROD 14:59:49 to 15:27:34, 8 in DEV 14:59:45 to 15:27:42. Those PRE-DATE dfbf98c5 (15:35), which is the hunk that converted exactly those two sources, so they are consistent with 732 and not a contradiction of it - I had that backwards for one measurement and am correcting it here. After 15:35: PROD 34 rows, 0 NULL; DEV 60 rows, 0 NULL; and auth-signin/auth-jwt wrote non-NULL ids at 15:54:00-03 (PROD) and 15:52:59-03 (DEV). That is a failing-before and passing-after pair for 732 on the same two sources. METHOD: read-only, both bases, boundary 2026-10-08 19:49:24Z. Query file in my scratchpad. I did not write anything.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 20:22Z - CORRECTION to my own earlier finding on this item, which measured the wrong field. WHAT I GOT WRONG: I reported ZERO app_logs rows in 30 days for the seven converted paths and framed that as the paths never being exercised. That number came from a predicate on the app_logs.service COLUMN. logger.ts:219 reads that column from data.service, which NEITHER log form ever sets, so service is always the literal web - it is not a discriminator at all and the query could only ever return 0. Measured: PROD web 3758 / web-client 1; DEV web 46358 / web-client 310 / getFabricantes 2. Same shape as the key-too-narrow trap, this time in my own instrument. THE RIGHT KEY is data->>source. logger.ts:120 (old 5-arg form) and :148/:163 (new 3-arg form) both route the source into data.source. RE-MEASURED on data->>source, 30-day window: - PROD: user-profile-service 6 rows, last 2026-10-08 15:02:11-03. - DEV: personas-service 208 rows and personas-repository 191 rows, both last 2026-10-05 15:26:15-03; user-profile-service 40 rows, last 2026-10-02 10:21:24-03. - paradas-service, paradas-repository, recorridos-service, recorridos-repository, notes-service, notes-repository: 0 rows in BOTH bases under either key. That part of the original finding survives. WHAT CHANGES: the personas and userProfile paths DO log and are live, so a runtime witness for them is obtainable rather than impossible - but every row above predates the 16:49 patch-203 tail, so the grouped control is still SIN EJERCITAR for those paths, not green. The paradas, recorridos and notes paths have no rows at all, so for them the control is unobtainable from history and needs traffic. WHAT DOES NOT CHANGE: the passing-after witness I recorded for the earlier cutover stands on its own key - PROD GET /api/vehiculos at 2026-10-08 15:54:02-03, two requests each with 13 rows under ONE request_id across three layers, 0 rows carrying transportRequestId.