Rendiciones API: extender api-external o crear API nueva

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus statusChanged · 7w ago
  Decision: build Rendiciones as a dedicated API surface in this repo (not extending api-external, which is out-of-repo/call-only). Reuse MovilBA repositories/services, add separately authenticated versioned endpoints. coder-mba-l-ca owns it, starting after MOVILBA-59 DoD (dev01 live import) is met.
• wi-cli-venus note · 7w ago
  Unanimous 3/3 (coder-mba-l-ca, coder02-mba-l-ca, db-mba-l-ca): dedicated Rendiciones API in this repo, versioned route namespace, own auth (x-api-key scoped, not NextAuth/external_api_keys). Gate: no implementation until MOVILBA-143 contract gaps resolved by requester (relay owned by Elazar, off-hub).
• wi-cli-venus assigned · 7w ago
  coder02-mba-l-cc / coder
• wi-cli-venus note · 7w ago
  Documento de respuesta al solicitante actualizado: /resource-lezama/docs/2026-08-27-rendiciones-endpoints.docx (original preservado como -ORIGINAL-solicitante.docx). Contiene 7 preguntas bloqueantes + que puede servir MovilBA campo por campo, medido en dev 2026-08-28. HUECOS DUROS encontrados contra el modelo real: (1) apoderados NO existe en MovilBA - solo asociaciones persona-entidad tipo Propietario/Empleado/Contratista, 2 cargadas en total; (2) correo/telefono no son campos de entidad sino tablas 1:N, y estan vacios en 23/26 y 25/26 entidades respectivamente; (3) lineas no tiene nombre, solo numero_linea int 0-999; (4) el campo 'id' del endpoint 5 (4975) distinto de vehiculo_id (5964) no se sabe que es; (5) fecha_ultima_actualizacion existe y esta 100% poblada pero es fecha de sistema (max=hoy, la escribe el importador), no de negocio; (6) alcance de /lineas/N/colectivos: 1753 vehiculos con linea vigente vs 642 de baja sin linea, de 2393 vivos. RESUELTO sin preguntar: el formato de CUIT del spec (NN-NNNNNNNN-N) es exactamente el que exige el CHECK de entidades.cuit.
• wi-cli-venus note · 7w ago
  CORRECCION DE UN ERROR MIO EN EL DOCUMENTO AL SOLICITANTE (coder02-mba-l-cc, 2026-08-28 11:07). Yo habia escrito que 'apoderados NO existe en MovilBA'. ES FALSO y ya esta corregido en /resource-lezama/docs/2026-08-27-rendiciones-endpoints.{md,docx}. Apoderado ES uno de los 12 tipos de persona del catalogo (opciones id 113, campo_nombre='tipo_persona', valor_opcion='APODERADO'), y asociaciones_entidad_persona vincula persona<->entidad CON VIGENCIA (fecha_inicio/fecha_fin), asi que el modelo soporta 'quien es apoderado de esta empresa' y 'desde cuando'. Medido: PROD 1 persona tipo apoderado y CERO asociaciones vivas; DEV 2 personas y 2 asociaciones vivas, ambas de tipo Apoderado (ej. Pablo perrelo -> Empresa Soldati desde 2026-06-11). O sea que el endpoint SE PUEDE SERVIR y hoy devolveria [] por falta de carga, no por falta de modelo - misma situacion que correo/telefono. COMO ME EQUIVOQUE, para que no se repita: mire el eje equivocado. Consulte los tipos de asociacion filtrando opciones por campo_nombre ILIKE '%asociacion%' y me dieron Propietario/Empleado/Contratista con uso 0, y conclui ausencia. Pero asociaciones_entidad_persona.tipo_asociacion_id NO apunta a un catalogo 'tipo_asociacion': apunta a campo_nombre='tipo_persona'. Un filtro por el nombre del campo que parecia obvio no toca el catalogo que la columna realmente usa. HALLAZGO COLATERAL PARA EL CARRIL DB, misma clase que la trampa de estandar_emisiones_id: la columna se llama tipo_asociacion_id pero se puebla desde el catalogo tipo_persona; los ids 18/19/20 (Propietario/Empleado/Contratista) existen en otro grupo y estan sin uso. Vale revisar si es intencional o drift.
• wi-cli-venus progress · 6w ago
  ENTREGADO EN DEV (coder02-mba-l-cc, 2026-08-31). Elazar 2026-08-28 'build it inside here': la API se construyo DENTRO de movilba-web, lo que REVIERTE la decision unanime 3/3 de este mismo item (servicio dedicado aparte). Motivo practico: un servicio separado necesita repo, host y proyecto Vercel, y Elazar es el unico que puede crear un proyecto Vercel. Queda namespaceada para poder levantarla despues. Deployado commit 798e395a v5.4.75. Cinco endpoints read-only bajo /api/rendiciones/v1/: empresas (paginado, ?cuit= repetible), empresas/{cuit} (?tipo_persona=, marcado personalData), lineas/{numero}, lineas/{numero}/colectivos (?estado=), colectivos/{dominio}. Tres capas segun la regla del repo (repositories/services/routes). Auth reusa el patron MOBAAPI-678 (x-api-key, tabla api_keys, sha256) con scope propio 'rendiciones' para poder revocarlo sin tocar vehiculos-export ni parque-movil. Claves de recurso CUIT/numero_linea/dominio, nunca ids: los tres tienen indice unico parcial entre filas vivas en DEV y PROD. Errores en application/problem+json (RFC 9457), divergencia deliberada con parque-api.ts porque el contrato v2.6 se lo prometio por escrito al consumidor; no se toco el formato de Parque Movil, que ya corre en prod con otro consumidor. Fuente de 'estado' = la FICHA (vdc.estado_id), no el historial: el historial deja 950 colectivos en null. Contrato: /resource-lezama/docs/2026-08-27-rendiciones-endpoints.md v2.6.
• wi-cli-venus blocked · 6w ago
  No existe fila en api_keys con scope 'rendiciones', asi que los cinco endpoints devuelven 401 en toda llamada. El codigo esta deployado en dev (798e395a, v5.4.75) y no se puede ejercitar hasta que la fila exista. Es una escritura a la base: necesita GO y una decision de Elazar sobre quien tiene la llave. Desbloquea con: mintear la api_key (carril db) + una llamada real que devuelva 200.
• wi-cli-venus unblocked · 6w ago
  Credencial minteada en DEV (api_keys id=8, owner RENDICIONES, scopes {rendiciones}, expira 2027-08-31). Los cinco endpoints responden 200 contra dev01. SQL de la credencial: docs/migrations/2026-08-31-rendiciones-api-key-DEV.sql - solo el hash, el valor en claro se entrega por DM y no queda versionado. PROD sigue sin credencial y necesita una key DISTINTA mas GO explicito. Sigue inProgress, no done: falta la decision de Elazar sobre quien tiene la llave y el publish a prod/POD.
• wi-cli-venus progress · 6w ago
  DEFECTO ENCONTRADO Y CORREGIDO EN LO YA SHIPEADO (coder02-mba-l-cc, 2026-08-31). La API estaba rota desde v5.4.75 en todo camino CON FILTRO y nadie lo habia visto porque no habia registro. sql`= ANY(${arrayDeJS})` en drizzle liga el array como UN parametro escalar: postgres recibia ANY(($2)) con $2='BAJA' en vez de text[] y la consulta tiraba 500. Afectaba ?cuit= en /empresas y el default estado=ALTA en /lineas/N/colectivos - o sea la llamada MAS comun. El unico camino que respondia 200 era ?estado=todos, que es el que no filtra, asi que un smoke test de 'el endpoint responde' pasaba. Arreglado con IN ($2,$3,...) via sql.join, v5.4.79. POR QUE SE ESCAPO: la consulta se habia probado a mano en psql, donde = ANY('{BAJA}') es SQL valido; lo que fallaba no era el SQL sino como el ORM liga el parametro, que es justo lo que psql no ejercita. Verificacion nueva: llamar la funcion del repositorio contra la base real y despues curl contra dev01. SEGUNDA TRAMPA en el mismo turno: dev01 tenia el fuente corregido en disco y el build nuevo, y seguia sirviendo el build viejo - el servicio habia arrancado antes de que el build terminara. Un 500 despues de un deploy no prueba que el fix este mal; hay que separar 'no sirve' de 'no esta corriendo' antes de volver a tocar el codigo.
• wi-cli-venus parentChanged · 6w ago
  parent=MOVILBA-185
• wi-cli-venus completed · 6w ago
  db03 independent review: the dedicated API architecture and DEV implementation are complete; remaining production credential, deploy, and five-route acceptance are explicitly owned by MOVILBA-187. Blackboard delivery failed only because the per-cwd hub overlay arrived after timeout.