overflow

Overflow se presenta como un servicio ya operativo en overflow.nitjsefni.eu. Los usuarios inician sesión con GitHub; no se requiere despliegue para usar la instancia alojada. Las instrucciones de configuración del repositorio son para ejecutar un entorno de desarrollo, no para usar el servicio. Un repositorio público de GitHub registrado tiene un catálogo de apertura y un catálogo real. El registro crea etiquetas de catálogo en el repositorio e instala un webhook. Los patrocinadores aplican una etiqueta de apertura a un issue; después del commit final del pull request de cierre y antes de la fusión, aplican una etiqueta de catálogo real y publican un comentario nombrando dicha etiqueta. Las transferencias de crédito liquidadas se registran con pruebas auditables; los cambios en los catálogos están versionados y no vuelven a tasar el trabajo ya liquidado. Los miembros conectados pueden leer las páginas de Ledger, Issues, Settlements, Register a repository, Calibration y Rules. El libro mayor también admite el registro programático de repositorios con un token de API emitido por Overflow. Las cuentas aún se registran manualmente mediante el inicio de sesión de GitHub en el navegador. Se genera un token en la página Register a repository, que se muestra una sola vez, se almacena mediante hash y puede regenerarse, invalidando el token anterior. POST /api/tokens acuña tokens utilizando una cookie de sesión de mismo origen; requiere un encabezado Origin que coincida con APP_URL y, o bien, ningún cuerpo o Content-Type application/json. POST /api/repositories acepta un token bearer y un JSON con repositoryUrl, openingName, actualName, openingLabels y actualLabels; el catálogo real debe tener exactamente diez entradas que cubran los puntos del 1 al 10. Los errores utilizan un sobre de error JSON con código y mensaje. PATCH /api/repositories añade una nueva versión del catálogo; la versión rige a partir del momento del cambio, por lo que las ventanas de evidencia anteriores mantienen sus cifras registradas. Los endpoints de lectura devuelven el mismo JSON que renderizan las páginas: GET /api/dashboard, GET /api/issues con filtros opcionales de repository, openingLabel y claimState, GET /api/settlements, GET /api/settlements/id y GET /api/calibration. Utilizan tokens ovf_ bearer o cookies del navegador; las lecturas no tienen comprobación de origen y no aceptan cuerpo de solicitud. Las respuestas están limitadas a la cuenta autenticada; la prueba de liquidación solo está disponible para una parte de dicha liquidación. Algunos campos pasan a ser null cuando falla una lectura, y las lecturas de listas están limitadas a las 200 filas más recientes. La API también está expuesta como herramientas MCP a través de POST /api/mcp para arneses de agentes. La autenticación utiliza los mismos tokens ovf_. El transporte es HTTP transmitible sin estado: una solicitud JSON-RPC por POST, sin estado de sesión entre llamadas, la respuesta de inicialización indica la versión del protocolo 2025-06-18 y las notificaciones reciben un HTTP 202 vacío. Las escrituras autenticadas por cookie a través de MCP son rechazadas porque las llamadas internas sintetizadas carecen de un encabezado Origin para la protección de mismo origen.