movilba
MOVILBA-667
Simplificar MovilBA: censo de tablas, columnas, vistas, rutas y pantallas que nada usa, para quitarlas
Done high
rmresearcher-mba-l-cc
Elazar 2026-10-02: MovilBA se construyo grande y complejo y hay que simplificarlo; lo que no se necesita se quita. Censo con evidencia por objeto (lectores en codigo, filas, ultima escritura, superficie que lo muestra), en PROD y DEV. Por cada candidato abrir un item hijo de bwi de remocion. NO borrar nada desde este item; validadoras quedan OCULTAS, no removidas (regla vigente). Primer caso ya abierto: motor_modelo de la API.
Sub-tickets — 29/29 done
MOVILBA-674 Done
rmresearcher-mba-l-cc
MOVILBA-686 Done
rmresearcher-mba-l-cc
MOVILBA-689 Done
rmresearcher-mba-l-cc
MOVILBA-696 Done
cmcoder03assistant-mba-l-ca
MOVILBA-697 Done
cmcoder03assistant-mba-l-ca
MOVILBA-700 Done
rmresearcher-mba-l-cc
Activity
-
coder03assistant-mba-l-ca | 2026-10-02 14:07 ART. Initial read-only census: Prod/Dev catalogs exported for public/rutap (relation/column lists, view dependency edges, routine bodies). Scanned runtime src references using generated Drizzle symbols and relation SQL names; no repo runtime readers found for several populated/empty tables. Protect validadoras from removal and rutap.projection_quarantine_rows because active MOVILBA-89/125 depends on it. Candidate objects and limits will be recorded individually; no schema or data writes.
-
coder03assistant-mba-l-ca | 2026-10-02 14:07 ART. Exact SELECT counts PROD/DEV: public.lineas_transporte 0/0; public.parque_rutap_2025_12_16 2487/2487; public.parque_rutap_20260821_0624_raw 5088/5088; public.parque_rutap_import_manifest 1/2; public.verification_tokens 0/0; puestos_a_tierra and puestos_a_tierra_direcciones 0/0 (excluded from candidate list due validadoras preserve rule). Runtime source search excludes generated drizzle schema; DB view edges and routine bodies exported for both bases. db04 role svc_nextjs lacks SELECT on rutap.projection_quarantine_rows in PROD; DEV movable_user returns 0; active MOVILBA-89/125 also makes this a keep. Candidate follow-ups will verify constraints/retention and external consumers before any deletion.
-
coder03assistant-mba-l-ca | 2026-10-02 14:18 ART. Opened children MOVILBA-668..672 for five table candidates: empty legacy lineas_transporte; dated 2025 snapshot; 2026 raw reconciliation table; import manifest; empty verification_tokens. Counts and reader/dependency evidence live on each child; no DDL/data writes. Public/rutap schema scan found 73 page.tsx and 71 route.ts files. Validadoras UI/API surface remains protected by the explicit hide-not-remove ruling. I am not marking any page/API route unused from static scans alone: no request-usage evidence is available here, and external API contracts can have callers outside this repository. Columns and view candidates remain under census.
-
coder03assistant-mba-l-ca | 2026-10-02 14:17 ART. Census update: children MOVILBA-668..672 cover five table candidates with per-object counts, src reader search, pg_depend view graph, routine-body scan and last-write limits; 668 additionally records its FK/trigger topology. View inventory: documented operational/API/admin/audit views retained; active RUTAP/import/quarantine views retained; existing MOVILBA-472 covers v_vehiculos_export_periodo_actual and MOVILBA-473 covers rutap.v_export_estado_actual (fresh SELECT: present in both bases, 2419 PROD / 2455 DEV). Column candidates motor_modelo and VDC fecha_vigencia_desde/hasta already have MOVILBA-666 and -242; no duplicate children. Route/screen census found 73 page.tsx and 71 route.ts files; no route is labelled unused from static absence alone because runtime/external callers were not measured. Validadoras stay hidden; no delete/DDL/data write.
-
coder03assistant-mba-l-ca | 2026-10-02 14:26 ART. Extended read-only census: 10 column candidates MOVILBA-691..700, each has PROD/DEV row+nonnull counts and no src/tools token, dependent view-column edge or installed routine-body reference; protected validadora columns and active quarantine_id excluded. 17 view candidates MOVILBA-674..690. Test: installed in both bases; zero dependent views per pg_depend, no relation/generated Drizzle symbol reader in src/tools, no routine-body reference. Existing cases excluded from duplicates: 472, 473, 601, 89; v_vehiculos_vivos_estado is left with existing 479 caution; active quarantine/validadora views excluded. View-column edge CSVs: /data-lezama/movilba/evidencia/MOVILBA-667/{prod,dev}-column-view-edges.csv. Candidate descriptions state manual/external readers are unmeasured and authorize no DDL. Route/screen candidates remain unsubstantiated absent usage telemetry. No deletion or DB write.
-
db04 read-only count control 2026-10-02 for children 691-700: accounts 0 rows both bases, five token columns 0 non-NULL; asociaciones_entidad_persona_archive 0 rows both, fecha_desde 0; external_api_keys 7 rows both and allowed_endpoints/key_name/service_url each 7 non-NULL (697-699 already closed KEEP); vehiculos_archive.numero_serie_carroceria PROD 0/1841, DEV 20/33640, so 700 must not drop without Elazar. Exact predicate count(column) per table with default_transaction_read_only=on; individual child notes posted. No DDL.
-
2026-10-02 accounts whole-table DROP preflight: PROD and DEV accounts each 0 rows, owner postgres/movilba_user, inbound FK 0, outbound FK 1, user triggers 0, routine-body hits 0. BUT pg_depend shows 5 direct view-column edges into THREE live views in both bases: v_auth_methods_stats (user_id/type/provider), v_db_users_footprint_detalle (user_id), v_db_users_sin_login (user_id). A no-CASCADE guarded DROP aborts, so NO DDL performed. 676/679 cover two view candidates; footprint_detalle is not in the candidate list and docs/reference/view-catalog.md lists it as a user-footprint diagnostic. Need disposition of all three views or rewrite of their accounts arm before table drop. Source reader grep in src/tools/scripts/api-external found none for the three, but DB dependency is decisive.
-
2026-10-02 14:41 ART | Widened scan posted per child. Views 674-681,683-690: no repo consumers in scripts/, api-external/, docs/reference/parque-movil-api/ or systemd; external/manual readers remain unmeasured. 682 moved under 313 per PM and assigned coder04; view-catalog still documents the dropdown role. Table stats (stats_reset NULL): three retained populated RUTAP tables have PROD/DEV seq_scan/index-scan counts 1196/196 & 35/3; 1020/205 & 3/1; 512/170 & 2/0. 668/672 already dropped by db04 under audited migration. Columns 691-696 all empty in both; auth flow reads users/Keycloak, not accounts table, but 5 dependent live views still block whole-table DROP. 697-699 populated 7/7 in both; API-key flow reads separate api_keys. 700 has DEV 20 non-NULL and is retained; docs legacy mentions. No DDL by this lane.
-
2026-10-05 refreshed source-reader census: exact-name search across src/, tools/, scripts/, api-external/, docs/reference/parque-movil-api/ found no consumer of views 674-690; only substring false positive v_users_groups in an old todo file. No repo systemd/ directory exists. Prior SELECT/pg_depend and pg_stat evidence remains on the item/children. No DDL or view drop by this lane; DB lane owns guarded drop batch. Manual/external consumers remain unmeasured.
-
2026-10-06 refresh: child candidates 674-690 (views) and 696-700 (columns) plus table children 668-672/702 cover the DB objects identified; source-reader scans found no in-repo consumers for view candidates in src/, tools/, scripts/, api-external/, docs/reference/parque-movil-api/, or repo systemd. Existing DB evidence is recorded per child. No route/screen deletion candidates asserted: a 73-page.tsx/71-route.ts inventory and static scans cannot prove external/runtime use or non-use. Remaining blocker for completing route/screen portion is request-usage telemetry (and external/manual consumer inventory); no such evidence source is currently available. No deletion performed.
-
DB-object census and in-repo reader scan are recorded across children 668-672, 674-690, 696-700, and 702. The remaining routes/screens portion cannot identify genuinely unused surfaces from static absence: the 73 page.tsx and 71 route.ts inventory needs request-usage telemetry and external/manual-consumer evidence, neither currently available. No deletions made.
-
researcher-mba-l-cc / solo
-
2026-10-08T12:34:26-03:00 researcher-mba-l-cc Census instrument per layer, from the existing children's own evidence, plus the blind spot of each: TABLES (668-672,702,696-700 scope): instrument = row count + pg_stat_user_tables (seq_scan/idx_scan, stats_reset) + pg_depend (inbound/outbound FK) + routine-body grep. Blind spot: stats_reset can be NULL or reset, hiding true last-access recency (db04 2026-10-02 flagged this explicitly for the three retained RUTAP tables); a 0-row/0-scan table only proves no access since last reset, not "never used". COLUMNS (696-700): instrument = count(column) non-NULL across PROD+DEV under default_transaction_read_only. Blind spot: 0 non-NULL proves no data written to date, not that code never reads it (a column read conditionally, or write-only going forward, needs the separate source-grep db04 already ran, not the count alone) - MOVILBA-700 is the live example, kept because DEV has 20 non-NULL despite PROD 0. VIEWS (674-690,701,703): instrument = pg_depend (view->table edges, decisive over source grep per db04's 2026-10-02 accounts note) + exact-name source grep across src/, tools/, scripts/, api-external/, docs/reference/parque-movil-api/, repo systemd (absent). This grep already covers the specific risk flagged - a view backing the published /api/v1 contract - because docs/reference/parque-movil-api/ and api-external/ are both in the scanned set; no candidate view appears there. Remaining blind spot is structural, not a scan gap: ordinary (non-materialized) views have no access counter of their own in pg_stat - only the underlying base tables accumulate seq_scan/idx_scan, so a view query is invisible as "this view was used" even where pg_stat shows table activity. Also unmeasured: an external consumer connecting directly to Postgres outside this repo (a GCABA-side report tool, a manual psql script never checked in) - no telemetry source for that exists today, same gap as routes/screens below. ROUTES (71 route.ts) / SCREENS (73 page.tsx): no instrument exists. Static absence (no internal Link/fetch to a route, no nav entry to a screen) cannot distinguish "unused" from "reached via direct URL, a bookmark, an external system calling the API, or a not-yet-wired nav path" - this is the actual open blocker on the item, confirmed unresolved as of 2026-10-06. Closing it needs one of: Next.js/proxy access-log analysis over a representative window, or an explicit external/manual-consumer inventory from Elazar. Neither is available to this lane; it's the same capability gap as the "external DB consumer" blind spot above, one layer up the stack. No deletions, no DDL, no code changes made - read-only synthesis of already-recorded evidence per children 668-690/696-703.
-
2026-10-08T13:10:21-03:00 researcher-mba-l-cc follow-up. No letter-answer shape fits this ticket - it is a census-instrument/methodology synthesis, not an A-vs-B decision on a field with four surfaces. The actual per-candidate removal decisions (keep/drop each table/column/view/route/screen) live on the individual children (668-703), each with its own evidence; 667 only states which instrument to trust and where its blind spot is. Nothing to append here in the requested format - flagging instead of forcing a fit.
-
coder03 2026-10-08 13:14 ART: accepted that this is not a letter-answer item. It is a census instrument, and the per-candidate decisions live on children MOVILBA-668 through MOVILBA-703, so it stays off the question list and the children carry the asks.
-
coder03-mba-l-cc 2026-10-08 18:05Z / 15:05 ART - El bloqueo decia que la parte de rutas y pantallas no se puede resolver porque hace falta telemetria de uso por request y no existe ninguna. Desde v5.6.199 EXISTE y es la razon del unblock, no una suposicion: MOVILBA-732 puso un unico request_id por request en app_logs (observado por audit en PROD, tres grupos de 3 filas, cero breadcrumbs de transportRequestId) y MOVILBA-735 arreglo user_id e ip_address (9 de 9 filas post-deploy con ip poblado contra 0 de 71 antes). Y lo que importa para este item: proxy.ts:143 setea source = metodo + pathname en cada request, asi que app_logs.source es un registro de que ruta se ejecuto. LIMITE QUE DECIDE COMO SE USA, y hay que leerlo antes de medir: la app NO ESTA EN USO en GCABA. El trafico de app_logs es de los agentes y de Elazar, no de usuarios. Entonces la telemetria sirve para una sola direccion - prueba que una superficie SI se usa, y eso es definitivo: una ruta con hits no se borra. CERO hits NO prueba que no se use, porque nadie la ejercito todavia, y confundir las dos direcciones es exactamente la forma 'ausencia de ejercicio no es verificacion'. Alcance que queda entonces: de las 73 page.tsx y 71 route.ts, sacar del candidato a borrado todas las que tengan hits en app_logs.source, y reportar el resto como NO DECIDIDO - no como no usado. Ese resto sigue necesitando evidencia de consumidor externo o manual, que es lo que el bloqueo original describia bien. El item pasa de 'no se puede empezar' a 'se puede podar la lista', que es menos de lo que pide el titulo y mas que cero. Ninguna otra parte cambia: el censo de objetos de base y el scan de lectores en repo siguen registrados en los hijos 668-672, 674-690, 696-700 y 702. Sin borrados.
-
2026-10-08T15:03:41-03:00 / 18:03:44Z researcher-mba-l-cc. Built the exact 73 page.tsx + 71 route.ts candidate list myself (find src/app -name page.tsx|route.ts, route-group segments stripped since they are not in the URL). 144 pathnames total, matches the count exactly. Instrument confirmed: proxy.ts:143 sets source = method + ' ' + pathname, where pathname is the REQUEST path (concrete values, e.g. /vehiculos/AB123CD), not the route pattern (/vehiculos/[dominio]). So matching candidate->hits needs per-route regex (static segments literal, [param] -> one non-slash segment, [...catchall] -> one-or-more segments), not a literal string match against app_logs.source. I am SELECT-only / no direct DB access in this role. Requesting a db lane run one aggregate, zero-PII query: SELECT split_part(source,' ',2) AS pathname, count(*) FROM app_logs WHERE source IS NOT NULL GROUP BY pathname ORDER BY pathname; (distinct concrete paths + counts, read-only, no row content). I match the 144 route patterns against that output myself. Scope answer to coder03's question: unchanged from my 2026-10-08T12:34 note's framing - telemetry only proves the positive direction. What changes is that the method is now executable instead of blocked. No surface pruned yet pending the db query. No deletions, no code changes.
-
2026-10-08T15:30:00-03:00 / 18:30:00Z researcher-mba-l-cc. db03's premise corrections (docs/reference/movilba-667-route-usage-census.md, untracked, sha256 37b942a4) stand and change the method: app_logs stores route PATTERNS literally (/api/vehiculos/[id]), not concrete paths, via data->>'source', so matching is a literal join, not a regex - the static-sibling trap does not apply here, there is no parameter value to confuse with a literal sibling. Matched the 71 route.ts candidates (exact find src/app -name route.ts listing) against the union of PROD+DEV hit pathnames from db03's census, literal string match: USED (61 of 71, pruned from the removal candidate list - hits prove used, definitively): /api/admin/audit-log, /api/admin/carrocerias(+[id]), /api/admin/chasis(+[id]), /api/admin/fabricantes(+[id]), /api/admin/opciones(+grupos-campos,+[id]), /api/admin/users(+[id],+last-login), /api/auth/change-password, /api/auth/password-status, /api/auth/reset-password, /api/auth/verify-email, /api/dropdowns, /api/entidades(+[id]), /api/export, /api/health, /api/lineas(+[id]), /api/navigation, /api/paradas(+[id]), /api/personas(+[id],+edit), /api/ramales(+[id]), /api/recorridos(+[id]), /api/rendiciones/v1/colectivos(+[dominio]), /api/rendiciones/v1/empresas(+[cuit]), /api/rendiciones/v1/lineas/[numero](+colectivos), /api/reportes/liquidacion, /api/reportes/vehiculos-historico, /api/user/profile, /api/v1/exports/vehiculos, /api/v1/parque/choferes/[id](+search), /api/v1/parque/entidades, /api/v1/parque/estados-colectivo, /api/v1/parque/instalaciones/search, /api/v1/parque/lineas, /api/v1/parque/vehiculos/[id](+search), /api/vehiculos, /api/vehiculos/detail-dropdowns, /api/vehiculos/[id](+entidad,+entidad/history,+historia,+linea,+linea/current,+linea/history). NOT DECIDED - no app_logs evidence either way (10 of 71): /api/auth/federated-logout, /api/auth/[...nextauth], /api/diagnostics/fiscalizacion-connectivity, /api/docs, /api/log-error, /api/v1 (index), /api/v1/openapi.json, /api/vpn-probe, /health/liveness, /health/readiness. Zero hits proves nothing per the standing rule - not reclassified as unused. Unmeasured confound db03 flagged: 44573 PROD / 83437 DEV rows are service/repo labels (auth-jwt, vehiculos-service, ...), route-unattributable - a route could be live and under-logged through one of those call sites rather than genuinely cold, and db03 did not mine service/message for route evidence. Also unmeasured: 14699 PROD rows with no source key at all. SCREENS (73 page.tsx): NOT INSTRUMENTED, not NOT DECIDED-by-zero-hits - a structural gap, not a measurement result. db03's positive control confirmed the probe works (/api/ prefix returns 27404 rows) and zero page routes appear in either shape in either base, because pages never call log(). No page/screen candidate is prunable or decidable from this data at all; closing that half still needs the same external/manual-consumer evidence the original 2026-10-06 blocker named. Candidate list shrinks from 73+71=144 to 73+10=83 still open, all NOT DECIDED, none reclassified as unused. No deletions, no code changes.
-
2026-10-08T15:22:00-03:00 / 18:22:00Z researcher-mba-l-cc. AMENDS the prior note - the 61/10 split in it is WRONG, do not read it as settled. db03's second correction: the census window (2026-01-28..2026-10-08) spans earlier deletions. 7 of the 56 PROD logged patterns have no route.ts on disk at all (deleted by MOBAAPI-671/661/591) - already confirmed these 7 never leaked into my candidate match (grep -Fx against routes71.txt, all 7 clean), so the original 61/10 split did not resurrect a dead route. But the deeper point survives past that check: an all-time hit on a route that DOES still exist can predate a refactor, so "has an all-time hit" is not the same claim as "is used today." coder03's instruction: re-derive on the 30-day window, which db03 showed as a working positive control (the 7 deleted patterns sit at exactly 0 in 30 days, 24 of 56 PROD patterns have any recent hit). Re-derived against PROD's last-30-day column (only PROD table supplied so far; DEV's equivalent requested from db03, pending): CONFIRMED USED (24, PROD hit within last 30 days - strongest class): /api/vehiculos, /api/rendiciones/v1/empresas, /api/navigation, /api/rendiciones/v1/lineas/[numero]/colectivos, /api/vehiculos/[id], /api/rendiciones/v1/colectivos, /api/rendiciones/v1/empresas/[cuit], /api/vehiculos/detail-dropdowns, /api/export, /api/auth/reset-password, /api/admin/users/[id], /api/dropdowns, /api/entidades, /api/admin/users/last-login, /api/user/profile, /api/lineas, /api/reportes/vehiculos-historico, /api/entidades/[id], /api/admin/users, /api/v1/exports/vehiculos, /api/v1/parque/entidades, /api/health, /api/rendiciones/v1/lineas/[numero], /api/reportes/liquidacion. MOVED BACK TO NOT DECIDED (was wrongly called USED on all-time-only evidence; these have an all-time PROD hit but ZERO in the last 30 days, so the window cannot rule out a stale/pre-refactor hit): /api/personas, /api/lineas/[id], /api/personas/[id], /api/personas/[id]/edit, /api/ramales, /api/admin/carrocerias, /api/admin/fabricantes, /api/admin/chasis, /api/admin/carrocerias/[id], /api/auth/change-password, /api/admin/fabricantes/[id], /api/admin/chasis/[id], /api/auth/verify-email, /api/ramales/[id], /api/v1/parque/vehiculos/search, /api/admin/opciones, /api/rendiciones/v1/colectivos/[dominio], /api/v1/parque/lineas, /api/v1/parque/estados-colectivo, /api/admin/audit-log, /api/v1/parque/instalaciones/search, /api/v1/parque/vehiculos/[id], /api/v1/parque/choferes/search, /api/v1/parque/choferes/[id], /api/vehiculos/[id]/historia. (25 by PROD table; one of these, auth/verify-email, also appears DEV all-time only - still provisional pending DEV's 30-day column.) STILL PENDING (DEV-only all-time hits, no PROD row, no DEV 30-day data yet): /api/admin/opciones/grupos-campos, /api/admin/opciones/[id], /api/auth/password-status, /api/paradas, /api/paradas/[id], /api/recorridos, /api/recorridos/[id], /api/vehiculos/[id]/entidad, /api/vehiculos/[id]/entidad/history, /api/vehiculos/[id]/linea, /api/vehiculos/[id]/linea/current, /api/vehiculos/[id]/linea/history. Requested db03's DEV equivalent of the all-time/last30/route.ts table; not yet received. Unchanged from before: already-NOT-DECIDED 10 routes stand (/api/auth/federated-logout, /api/auth/[...nextauth], /api/diagnostics/fiscalizacion-connectivity, /api/docs, /api/log-error, /api/v1 index, /api/v1/openapi.json, /api/vpn-probe, /health/liveness, /health/readiness). Screens (73 page.tsx): still NOT INSTRUMENTED, not decidable from app_logs at all, db03's positive control confirmed the probe works. Running count, PROD-only evidence so far: 24 CONFIRMED USED, 59 NOT DECIDED (25 moved back + 10 original + 12 DEV-only-pending, with 12 subject to revision once DEV's 30-day table lands), 73 screens NOT INSTRUMENTED. No deletions, no code changes. Will amend again once DEV's 30-day data arrives.
-
2026-10-08T15:25:00-03:00 / 18:25:00Z researcher-mba-l-cc. Clarification per coder03: NOT DECIDED is not one reason, it is two, and a reader must not prune from either without knowing which: (a) NO INSTRUMENT - the 10 originally-flagged routes (federated-logout, [...nextauth], fiscalizacion-connectivity, docs, log-error, v1 index, v1/openapi.json, vpn-probe, health/liveness, health/readiness) plus all 73 screens: app_logs has never seen these at all, zero evidence either direction. (b) INSTRUMENT MAY BE TOO SHORT - the 25 PROD routes with an all-time hit but zero in the last 30 days: the 7/7 control only proves the 30-day window correctly excludes routes that no longer exist, it does NOT prove 30 days is long enough to catch a route that is live but called rarely (a monthly report endpoint, a quarterly admin task). These are NOT DECIDED because the window may be shorter than the route's real calling period, not because no evidence exists. Same (b) caveat will apply to whichever of the 12 DEV-only-hit patterns end up with an all-time-only hit once DEV's 30-day table arrives. No change to the counts: 24 CONFIRMED USED, 59 NOT DECIDED (reason a or b, named per route above), 73 screens NOT INSTRUMENTED (reason a), 0 unused.
-
2026-10-08T15:35:00-03:00 / 18:35:00Z researcher-mba-l-cc. FINAL - supersedes the 15:30 draft, which undercounted by not using db03's merged/union table (doc sha256 078e2800, 598 lines, Final tally section) and missed the label-half rescue. Merged instrument: all_time = PROD+DEV summed, last30 = 1 if either base hit in 30 days, route.ts = present in tree today. Two independent dead-route controls agree: PROD 7/7 and DEV 8/8 patterns with no route.ts (deleted by MOBAAPI-671/661/591, MOVILBA-314) sit at last30=0. Final counts, 71 route.ts candidates: USED - 43. 42 logged with file present and a hit in the last 30 days. Plus 1 rescued by the label half alone: /api/auth/federated-logout has zero path-shaped rows but the label federated-logout carries 86 PROD hits - without mining labels this route would have been misclassified as NOT DECIDED/no-instrument. NOT DECIDED - 28, three different reasons, never pruned from any: (a) present, logged, but zero hits in the last 30 days (19): /api/admin/carrocerias/[id], /api/admin/chasis/[id], /api/admin/fabricantes/[id], /api/auth/verify-email, /api/admin/opciones, /api/auth/change-password, /api/admin/opciones/[id], /api/recorridos, /api/paradas, /api/recorridos/[id], /api/paradas/[id], /api/admin/opciones/grupos-campos, /api/vehiculos/[id]/historia, /api/auth/password-status, /api/admin/audit-log, /api/vehiculos/[id]/linea, /api/vehiculos/[id]/entidad, /api/vehiculos/[id]/entidad/history, /api/vehiculos/[id]/linea/history. The dead-route controls only prove 30 days correctly excludes a DELETED route, never that 30 days is long enough to catch a route that is live but rare (monthly report, quarterly task). (b) in the tree, never logged in any shape, no label either (7): /api/auth/[...nextauth], /api/diagnostics/fiscalizacion-connectivity, /api/docs, /api/log-error, /api/v1 (index), /api/v1/openapi.json, /api/vpn-probe. (c) outside db03's measured scope entirely - not under /api, app_logs source values never cover them (2): /health/liveness, /health/readiness. NOT INSTRUMENTED - 73 screens (page.tsx). Pages never call log() (db03's positive control: same probe with /api/ prefix returns 27404 rows, confirming the page-route zero is a measured absence, not a broken probe). Not decidable from app_logs at all. UNUSED - 0. Nothing in this census establishes non-use for any route or screen. 43+28+73=144, matches the candidate list exactly. No deletions, no code changes. Per-candidate keep/drop calls remain with children 668-703 as before; this closes only the methodology/evidence half coder03 asked for.
-
2026-10-08T15:38:00-03:00 researcher-mba-l-cc. Routes/screens census closed per coder03's instruction: 43 USED, 28 NOT DECIDED, 73 NOT INSTRUMENTED, 0 UNUSED (see final bwi note for breakdown and both controls). DB-object census (tables/columns/views) already recorded across children 668-690/696-703. No deletion authorized by this item; per-candidate keep/drop stays with the children.
chore
2w ago by coder03-mba-l-cc
1w ago
2026-10-08 18:22