Todo .ts bajo tools/ gatea dev y prod por typecheck pero esta fuera de eslint, asi que un artefacto de verificacion que no compila bloquea a todos los carriles

Sub-tickets

Activity

• audit-mba-l-cc created · 1w ago
• researcher-mba-l-cc note · 1w ago
  2026-10-08T20:34:07-03:00 / 2026-10-08T23:34:07Z researcher-mba-l-cc Evidencia sin fix, docs/reference/movilba-768-tools-tsconfig-scope.md, sha256 c68bbe9f81fe0e47ed8c58e232e7a1d40c06525363a72da60f4ef0b4c70cf532. Next.js oficial (nextjs.org/docs/.../typescript): solo muestra include creciendo, nunca documenta excluir una carpeta de scripts propia - decision del proyecto, no hay regla citable. TypeScript handbook (typescriptlang.org/tsconfig#exclude): exclude solo recorta lo que include encuentra; un archivo afuera del alcance no lo typechequea ESE tsc, pero el handbook no habla de tsx/ts-node ejecutando ese archivo aparte - es propiedad de esas herramientas, no de TS. next typegen reescribe solo include, no exclude: hecho YA establecido en CLAUDE.md del repo, corroborado estructuralmente (exclude ya tiene node_modules/temp-disabled/api-external custom que sobreviven). La busqueda externa (GitHub vercel/next.js#39942) son reportes de usuario, no garantia documentada - lo afirmo como hecho medido de este repo, no de Next.js en general. Que se rompe si tools/ sale de tsc: NADA en test:tools. El glob de package.json:17 (tools/tests/*.test.*js) nunca matchea .ts (termina en "js"); confirmado 11 .cjs + 2 .mjs + 1 .py en tools/tests/, cero .ts. Esos archivos corren via tsx directo sin paso tsc previo, y ninguno lee/importa un .ts de tools/ (grep, cero coincidencias) - lo que leen via esbuild.transformSync (no tsc) es codigo de src/. Lo unico que deja de typechequearse son los .ts sueltos de tools/ mismo (verification/, import/*.ts incluidos los *.test.ts que tampoco corre ningun gate), exactamente los artefactos que audit ya califica de ejecucion manual - quedarian sin NINGUN gate, no solo sin el de tsc.
• coder04-mba-l-ca assigned · 1w ago
  coder04-mba-l-ca / coder
• coder04-mba-l-ca statusChanged · 1w ago
  Measuring TypeScript inclusion, ESLint ignore, deploy gates, and scope before choosing an implementation; no checkout edit yet.
• coder04-mba-l-ca progress · 1w ago
  Read-only source measurement: tsconfig.json includes **/*.ts and excludes no tools path; eslint.config.mjs ignores tools/**/*, so 16 tools .ts files are typechecked but never linted. DEV deploy lints selected TS before whole-tree typecheck; PROD deploy performs whole-tree typecheck first and has no lint stage, so simply removing the ESLint ignore cannot guarantee an earlier warning in PROD and generic ESLint would not necessarily detect semantic TS2698. Correction to the existing research note: tools/run-source-tests.mjs:18 recursively executes *.test.ts under tools/import via tsx; test:source gates both deploys. test:tools alone does not match them. No edit yet; app/tool gate separation is the design question.
• coder04-mba-l-ca progress · 1w ago
  Implementation chosen after read-only measurement: exclude tools/** from the APP tsconfig's initial include so unrelated untracked manual artifacts cannot block every app deploy; add a separate tsconfig.tools.json and typecheck:tools command; invoke it in mba-deploy-dev.sh only when selected staged paths contain tools/*.ts(x). The PROD script merges dev after that selected-path gate; leave test:source recursion over tools/import intact. Existing ESLint ignore remains, so do not claim lint catches TS2698. Checkout edit waits for gates-checkout-movilba-web held by audit.
• coder04-mba-l-ca progress · 1w ago
  Candidate implementation in shared checkout under gates-checkout-movilba-web: tsconfig.json SHA256 7dff8dae excludes tools from app tsc without editing Next-owned include; tools/typecheck-tracked-tools.mjs SHA256 88d0b705 compiles explicit Git-index tool TS roots via TypeScript API. mba-deploy-dev.sh SHA256 657f0527 calls that gate with selected tool TS paths; mba-deploy-prod.sh SHA256 ce83083d calls it for all tracked tool TS on the clean PROD merge; package.json SHA256 cda4b15b adds typecheck:tools. Both ship paths have explicit exit 1. UNGATED by design: unrelated untracked/unselected manual .ts drafts and non-TS tools; tools/import *.test.ts still execute via test:source in both paths. Dev selected tool TS and PROD tracked tool TS remain typechecked. ESLint still ignores tools and cannot be cited as a semantic TS2698 guard. Coder ran no lint/typecheck/tests; audit must verify selected/full runner, next typegen preserving exclude, and the fail controls before PASS.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-768 — audit verdict: PASS, with a named coverage TRADE. Author coder04-mba-l-ca. audit-mba-l-cc, 2026-10-08 tsconfig.json 7dff8dae43b80fac666dcb47cf95ab76c8a1a77173a61e0aa7c85f5c7fd65fce package.json cda4b15b46e217d8d48acdb9e08cd733544b0cd8dc62e01ca7527f48b321fa76 mba-deploy-dev.sh 657f0527040e812228bf90494b5411cf5b0b032487d698353c636e063e0d55d0 mba-deploy-prod.sh ce83083d0ad4efedf6a0eb27bd2f8a9eb06da834197b040611b9c7c6a9e9bd25 tools/typecheck-tracked-tools.mjs 88d0b7056e30caef09cd3cc4f23ea4bc04370e58f93e66f7aa369c4b1c1fe771 All five pins exact in the shared checkout. All five are LIVE in the working tree, not parked, which is why this item blocked the 753 ship and confounded every gate run until now. Every mutant below ran in an ISOLATED git repo (`scratchpad/v768`) built for this verdict — `node_modules` symlinked, the runner and `tsconfig.json` copied, two synthetic `tools/*.ts` and one `src/*.ts`, its own index. Nothing was mutated in the checkout and no `git` write touched it. **First harness was broken and its results are discarded.** The scratch repo initially had no `src/` file, so `include` matched nothing and `ts.parseJsonConfigFileContent` returned TS18003; the runner exits 1 at `:15-18` before any check. All eight runs came back rc=1 — every one of them the harness, not a control. I report none of them. After adding `src/app-file.ts` and `src/types/globals.d.ts` the pinned baseline is rc=0, "Typechecked 2 tracked tools TypeScript files", and the controls below are measured against that. ## 1. What the diff actually does, isolated and seen both ways `tsconfig.json` adds ONE entry, `"tools"`, to `exclude`; `include` is untouched, which is correct — `next typegen` owns `include` and rewrites it, so a hand edit there vanishes with no diff. Measured on the same scratch tree, one tools file carrying `TS2322`: tsconfig with "tools" excluded (768) tsc -p rc=0, error NOT seen same tree, "tools" removed from exclude tsc -p rc=1, TS2322 reported So the main `typecheck` genuinely stops covering `tools/**`, and the new runner is what has to replace that coverage. **`next typegen` preserves the `exclude` entry** — independently confirmed in the checkout: my 753 gate run invoked `pnpm typecheck` (which runs typegen first) and `tsconfig.json` still hashes to `7dff8dae` after it. `package.json` adds `"typecheck:tools": "node tools/typecheck-tracked-tools.mjs"` and changes NOTHING else — the definitions of `typecheck`, `test:source`, `test:tools` and `pre-commit` are byte-identical to HEAD. `mba-deploy-dev.sh` adds a `2b/5` stage passing only the `tools/*` members of its `--only` selection; `mba-deploy-prod.sh` adds the bare full-tree form at `:54`. Both with `exit 1`, so it is on BOTH ship paths. ## 2. Nine controls, each forced alone, each seen 1 full mode, clean tree rc=0 "Typechecked 2 ..." 2 TS2322 in a TRACKED tools file, FULL mode (PROD) rc=1 TS2322 reported 3 same error, --selected naming that file (DEV) rc=1 4 same error present, --selected naming the OTHER file rc=0 "Typechecked 1 ..." 5 --selected with NO paths rc=0 "tools gate has no candidate" 6 --selected path absent from the git index rc=1 index guard 7 UNTRACKED tools file carrying TS2322, FULL mode rc=0 error not seen 8 zero tracked tools .ts, FULL mode rc=1 "refusing an empty tools gate" 9 unrecognised argument rc=1 usage Lines 2, 3, 6, 8 and 9 are real controls: they were seen to FAIL, so they are not green lines. Line 8 matters most — the refuse-empty branch is what stops the PROD gate from passing vacuously if the glob or the index ever comes back empty, and it is reachable. **`args[0] === '--'` at `:33` is load-bearing, measured:** `pnpm run x -- --selected tools/a.ts` delivers `["--","--selected","tools/a.ts"]`. Without the shift the runner would see `--` as `args[0]`, miss `selectedMode`, hit `args.length > 0` and exit 1 as a usage error on every DEV deploy. **The empty-array expansion is safe here:** `pnpm run typecheck:tools -- --selected "${TOOL_TS_FILES[@]}"` with an empty array under `set -euo pipefail` is not an error on bash 5.2.15 (both deploy scripts are `#!/bin/bash` with `set -euo pipefail`). Forced: `f "${A[@]}"` with `A=()` delivers 0 args and survives rc=0. It WOULD abort on bash before 4.4, where the script already uses the `${X[@]+"${X[@]}"}` idiom at `mba-deploy-dev.sh:52` — inconsistent, not broken on this host. ## 3. The coverage trade, which is the substance of this verdict Before 768, `include: ["**/*.ts", ...]` with no `tools` exclusion meant **every** `.ts` under `tools/`, tracked or not, was typechecked by `pnpm typecheck` on BOTH ship paths. After 768: - **PROD: equal today, latent hole by design.** The full-mode gate covers TRACKED tools files only. Counted in the checkout: 16 `tools/**/*.ts(x)` in the tree, 16 tracked, 0 untracked — so parity is exact right now. But control 7 shows an untracked tools file with a type error passes. The moment a lane leaves a `tools/verification/*.ts` draft untracked, which is this project's normal working pattern, it falls out of a gate that used to catch it. - **DEV: strictly weaker.** Controls 4 and 5 are the measurement. A type error in a tools file that is not in the `--only` selection ships (rc=0), and a selection with no tools file at all makes the stage a no-op (rc=0). `pnpm typecheck` no longer backstops it, because of the exclude. Every src-only DEV deploy now typechecks zero tools files where it previously typechecked all 16. Both behaviours are DECLARED in the comment at `typecheck-tracked-tools.mjs:55-57` — "Untracked verification drafts are deliberately outside both deployment typechecks. DEV checks only its selected paths; PROD checks every tracked tool on a clean tree." A declared design with its controls seen to fail is a PASS, not a FAIL. What I am not willing to leave implicit is that the headline reading "tools are now typechecked on both paths" is true only of PROD and only of tracked files. ## 3b. Gates in the checkout, under the lock The hold was GRANTED to me directly inside coder04's `unlock()`, so no race. All five pins re-hashed EXACT before and after; released after. pnpm run typecheck:tools rc=0 "Typechecked 16 tracked tools TypeScript files." pnpm run typecheck:tools -- --selected <one> rc=0 "Typechecked 1 ..." pnpm run typecheck:tools -- --selected rc=0 "tools gate has no candidate" pnpm typecheck rc=0 pnpm test:source 68 pass / 0 fail pnpm test:tools 119 pass / 0 fail The first line is the one that matters: the real 16 tracked tools files pass the new gate, so it does not land red. `shellcheck` is not installed on this host, so the two shell hunks got no static check from me at all — they were read, not linted. ## 4. NOT EXERCISED - **No deploy ran.** Neither `mba-deploy-dev.sh` nor `mba-deploy-prod.sh` was executed, so the `2b/5` and `:54` stages have never been seen to run IN SITU — only the runner they call, invoked directly, plus the argv and empty-array shapes separately. The wiring itself is read, not measured. - No push, no merge, no bump, no health gate, no OpenShift pod. - The 16 real `tools/**/*.ts` files were never put through the runner in the checkout; my controls used two synthetic files. The full-mode run on the real 16 is part of the gate run below and is the only place that is covered. - No HTTP, no browser, no SQL, neither base touched. No DDL and no data. - Bash < 4.4 behaviour is reasoned from documentation, not measured: this host is 5.2.15 and I ran nothing else. - `lint:strict` and `next build` still run on no ship path, and 768 does not change that.
• audit-mba-l-cc audited · 1w ago
  audit pass: All FIVE files, live in the checkout, pins exact: tsconfig 7dff8dae, package.json cda4b15b, dev 657f0527, prod ce83083d, runner 88d0b705. 9 controls in an ISOLATED git repo plus gates in the checkout under lock. NO deploy ran, so the two wired stages are READ, not measured.
  payload

  {"scope":"All FIVE files, live in the checkout, pins exact: tsconfig 7dff8dae, package.json cda4b15b, dev 657f0527, prod ce83083d, runner 88d0b705. 9 controls in an ISOLATED git repo plus gates in the checkout under lock. NO deploy ran, so the two wired stages are READ, not measured.","outcome":"pass","evidence":"FIRST HARNESS BROKEN, EIGHT RESULTS DISCARDED: my scratch repo had no src/ file, include matched nothing, TS18003 came back, and the runner exits 1 at :15-18 before checking anything. All eight runs rc=1 - the harness, not a control. With src/ added the baseline is rc=0.\nNine controls, one at a time in an isolated git repo: clean full rc=0; (2) TS2322 in a TRACKED tools file, FULL mode rc=1; (3) same, --selected naming it rc=1; (4) same error present, --selected naming the OTHER file rc=0; (5) --selected with NO paths rc=0 \"no candidate\"; (6) selected path not in the index rc=1; (7) UNTRACKED tools file with TS2322, FULL mode rc=0, error NOT seen; (8) zero tracked tools .ts rc=1 \"refusing an empty tools gate\"; (9) bad arg rc=1. 2,3,6,8,9 were SEEN TO FAIL, so they are controls, not green lines.\ntsconfig hunk isolated: with \"tools\" excluded tsc -p rc=0 and MISSES the error, without it rc=1 and catches it. next typegen PRESERVES the exclude - tsconfig still hashes 7dff8dae after typecheck ran typegen. :33's `--` shift is LOAD-BEARING: pnpm delivers [\"--\",\"--selected\",...], so without it every DEV deploy exits 1 on usage.\nTHE TRADE: before 768, include **/*.ts typechecked EVERY tools .ts on both paths. PROD now covers TRACKED only - equal today at 16 of 16 - but control 7 shows an untracked draft with a type error PASSES, and untracked tools/verification/*.ts is this project's normal pattern. DEV is strictly WEAKER: by 4 and 5 a tools error outside the --only selection ships, and a src-only ship checks ZERO tools files where it used to check 16, with no backstop after the exclude. Both DECLARED at runner :55-57, hence PASS - but \"typechecked on both paths\" holds only for PROD and only for tracked files.\nGates under lock, pins exact both sides: typecheck:tools rc=0 on the real 16, typecheck rc=0, source 68/68, tools 119/119. NOT EXERCISED: no deploy ran, so the 2b/5 and prod :54 stages were never seen in situ; no push, bump or pod; no HTTP, no SQL, neither base.","reportRef":null}

• coder04-mba-l-ca progress · 1w ago
  Audit PASS 2026-10-09T02:00:45.472Z on all five pinned files. Scope limit from audit: PROD tool typecheck covers 16/16 tracked tools TS today, but a normal untracked tools/verification/*.ts with a type error passes; DEV selected mode can ship an error outside --only and a src-only ship checks zero tools files after the app tsconfig exclude. Typegen preserved exclude; pnpm's -- argument shift is load-bearing. No deploy stage executed in the audit; shellcheck unavailable. These limits are part of the PASS, not implied coverage.
• coder03-mba-l-cc completed · 1w ago
• coder03-mba-l-cc verified · 1w ago
  Shipped and LIVE on both surfaces. dev ec6a1b94/patch 222, prod main merged and app.movilba.com/api/health answers serviceId 31325 = patch 222, probed 2026-10-08 23:33 ART. Root cause of the earlier 221 reading: the post-receive hook on /srv/movilba-web.git runs synchronously inside the push and my push was killed by a 2-minute timeout at 23:15:55, exactly when pnpm build finished writing BUILD_ID - so the hook never reached its restart stage (deploy.json has install and build entries and NO restart entry) and next-server kept serving the 221 build from 22:28. Fixed by completing the hook step the kill skipped: systemctl restart movilba-web.service. SIN EJERCITAR: only the health route was probed; no screen, PDF, XLSX or pod. POD leg still owed.
• coder03-mba-l-cc note · 1w ago
  CORRECCION que supersede mi evento de 02:21:46Z: el SHA de dev esta mal escrito ahi. dev = ec4b68642158f9bba09edbeb5562c34a8ecbd790 (ec4b6864), NO ec6a1b94, que no es un objeto de este repo. prod main = 3dd4b3ec971026c2c5dbb6ebb298aa734938bc05. Todo lo demas de ese evento se sostiene sin cambios: prod responde serviceId 31325 = patch 222 y la causa del 221 fue la etapa restart del hook que el kill de los 2 minutos salteo.
• coder03-mba-l-cc verified · 1w ago
  FLEET PARITY alcanzada: las TRES superficies sirven patch 222. prod app.movilba.com serviceId 31325 (23:33 ART), dev01 ya estaba en 222 por el deploy, y el pod permisos-movilba-dev.gcba.gob.ar devolvio 31325 a las 23:31 ART despues de que Tekton terminara - mba-deploy-pod.sh espejo el arbol de dev ec4b6864 a repositorio-asi, force-push fe6d299 -> b5feafd en develop y EventListener HTTP 202. Las dos primeras sondas al pod a las 23:27 y 23:28 devolvieron 31188 (patch 221) y eso era el pipeline todavia corriendo, no una falla: no hay sesion de oc para mirar los builds (oc whoami da Unauthorized, el token sale de la consola OCP y eso es Elazar en el navegador), asi que el pipeline no se observo, solo su resultado. SIN EJERCITAR en las tres superficies: ninguna pantalla, PDF, XLSX ni consulta - la unica ruta probada es /api/health.