Eval farm has no HTTP surface: add register_eval_routes #39

New Issue

pbwraith · 2026-09-01T10:36:50+02:00

pbwraith commented

2026-09-01 10:36:50 +02:00

Outcome

The eval-farm product is reachable over the network. ARCHITECTURE.md describes
it as one of the two front-ends the billing core exists to serve, but
intake_eval.py exposes zero routes -- verified on main, while
intake_factory.py has five. Right now one of the two products cannot be used
by anything except a Python caller inside the process.

Scope

register_eval_routes(app, ...) mirroring the factory's shape, so the two
front-ends are symmetrical and a client integrates with one mental model:

POST /api/eval/batches -- submit a batch, returns batch id. Funding-gated
exactly like factory intake: unfunded work never becomes a Gitea issue, it
queues locally.
GET /api/eval/batches/<id> -- status + per-task state.
GET /api/eval/batches/<id>/results -- the results table.
POST /api/eval/batches/<id>/cancel -- stop draining; release held funds.
GET /api/eval/health.

Auth via auth.py only -- the X-API-Key consolidation from #24 is done, so
there is exactly one implementation. Do not add a sixth.

Files this issue owns

gitea_saas/intake_eval.py, tests/test_intake_eval.py.

Do not edit app.py -- registration is wired there by the assembly issue. Export
register_eval_routes and it will be picked up.

Acceptance

Each route has a test covering success, missing/blank key (401), and
unconfigured key (503).
Submitting an unfunded batch creates no Gitea issue and leaves a queued
row; funding then flushes it. Assert on both halves.
Cancel releases the hold -- balance returns to its pre-submit value exactly.
Full suite green.

## Outcome The eval-farm product is reachable over the network. ARCHITECTURE.md describes it as one of the **two front-ends** the billing core exists to serve, but `intake_eval.py` exposes **zero routes** -- verified on `main`, while `intake_factory.py` has five. Right now one of the two products cannot be used by anything except a Python caller inside the process. ## Scope `register_eval_routes(app, ...)` mirroring the factory's shape, so the two front-ends are symmetrical and a client integrates with one mental model: - `POST /api/eval/batches` -- submit a batch, returns batch id. Funding-gated exactly like factory intake: unfunded work never becomes a Gitea issue, it queues locally. - `GET /api/eval/batches/<id>` -- status + per-task state. - `GET /api/eval/batches/<id>/results` -- the results table. - `POST /api/eval/batches/<id>/cancel` -- stop draining; release held funds. - `GET /api/eval/health`. Auth via `auth.py` only -- the `X-API-Key` consolidation from #24 is done, so there is exactly one implementation. Do not add a sixth. ## Files this issue owns `gitea_saas/intake_eval.py`, `tests/test_intake_eval.py`. Do not edit `app.py` -- registration is wired there by the assembly issue. Export `register_eval_routes` and it will be picked up. ## Acceptance 1. Each route has a test covering success, missing/blank key (401), and unconfigured key (503). 2. Submitting an unfunded batch creates **no** Gitea issue and leaves a queued row; funding then flushes it. Assert on both halves. 3. Cancel releases the hold -- balance returns to its pre-submit value exactly. 4. Full suite green.

pbwraith added the

p1

label 2026-09-01 10:36:51 +02:00

pbwraith added the

in-progress

label 2026-09-01 10:48:46 +02:00

pbwraith referenced a pull request that will close this issue

2026-09-01 10:59:42 +02:00

gitea-saas-core#39: eval farm HTTP surface — register_eval_routes #44

pbwraith removed the

in-progress

label 2026-09-01 11:00:22 +02:00