overflow

Overflow is presented as an already-running service at overflow.nitjsefni.eu. Users sign in with GitHub; no deployment is required to use the hosted instance. The repository's setup instructions are for running a development environment, not for using the service. A registered public GitHub repository has an opening catalog and an actual catalog. Registration creates catalog labels on the repository and installs a webhook. Sponsors apply an opening label to an issue; after the closing pull request's final commit and before merging, they apply an actual-catalog label and post a comment naming that label. Settled credit transfers are recorded with auditable proof; changes to catalogs are versioned and do not re-price already settled work. Signed-in members can read Ledger, Issues, Settlements, Register a repository, Calibration, and Rules pages. The ledger also supports programmatic repository registration with an Overflow-issued API token. Accounts still register manually via browser GitHub sign-in. A token is generated on the Register a repository page, shown only once, stored hashed, and can be regenerated, invalidating the previous token. POST /api/tokens mints tokens using a same-origin session cookie; it requires an Origin header matching APP_URL and either no body or Content-Type application/json. POST /api/repositories accepts a bearer token and JSON with repositoryUrl, openingName, actualName, openingLabels and actualLabels; the actual catalog must have exactly ten entries covering points 1 through 10. Errors use a JSON error envelope with code and message. PATCH /api/repositories appends a new catalog version; the version governs from the change moment, so earlier evidence windows keep their recorded figures. Read endpoints return the same JSON the pages render: GET /api/dashboard, GET /api/issues with optional repository, openingLabel and claimState filters, GET /api/settlements, GET /api/settlements/id, and GET /api/calibration. They use bearer ovf_ tokens or browser cookies; reads have no origin check and take no request body. Responses are scoped to the authenticated account; settlement proof is available only to a party to that settlement. Some fields degrade to null when a read fails, and list reads are capped at the most recent 200 rows. The API is also exposed as MCP tools over POST /api/mcp for agent harnesses. Authentication uses the same ovf_ tokens. The transport is stateless streamable HTTP: one JSON-RPC request per POST, no session state between calls, initialize answers protocol version 2025-06-18, and notifications receive an empty HTTP 202. Cookie-authenticated writes through MCP are refused because synthesized internal calls lack an Origin header for the same-origin guard.