Add a raw API passthrough (gitea-axi api) as an escape hatch #40

New Issue

alexion · 2026-07-18T11:25:18-04:00

alexion commented

2026-07-18 11:25:18 -04:00

What I ran into

Twice in one review task I hit something gitea-axi doesn't expose (inline-comment line anchors when reading; inline comments when writing).
Each time, the fallback wasn't "drop to a supported raw call" — it was hand-rolling curl against the Gitea REST API and scraping the token out of ~/.config/tea/config.yml to authenticate.
That improvised auth + URL building is exactly the fragile, error-prone path the skill exists to prevent.

Real gap

Real gap: there is no api verb in the top-level dispatch or under pr (src/commands/pr.ts prCommand handles list/view/diff/checkout/checks/create/edit/merge/update-branch/close/reopen/review/comment — nothing generic).
So when a capability is missing, there is no sanctioned escape hatch, and the user notices agents reaching for curl + config-file parsing.

Recommendation

Add a thin raw passthrough, in the spirit of gh api:

gitea-axi api <METHOD> <path> [--field k=v ...] [--raw-field k=v ...] [--input <file>]

It should reuse the existing repo/login resolution and the tea login credentials (src/tea.ts / src/client.ts) so no token handling is improvised, resolve {owner}/{repo} placeholders in the path from context, and print the raw JSON response.

Value beyond convenience:

It's the honest fallback for anything the typed commands don't cover yet (e.g. resolving a review conversation, whose endpoint isn't in the pinned SDK), so agents stop hand-rolling curl + config.yml parsing.
It keeps auth and host resolution inside one code path instead of leaking the token into ad-hoc scripts.

This is the highest-leverage of the review-workflow gaps I hit, because it backstops all the others.

## What I ran into Twice in one review task I hit something gitea-axi doesn't expose (inline-comment line anchors when reading; inline comments when writing). Each time, the fallback wasn't "drop to a supported raw call" — it was hand-rolling `curl` against the Gitea REST API **and** scraping the token out of `~/.config/tea/config.yml` to authenticate. That improvised auth + URL building is exactly the fragile, error-prone path the skill exists to prevent. ## Real gap Real gap: there is no `api` verb in the top-level dispatch or under `pr` (`src/commands/pr.ts` `prCommand` handles list/view/diff/checkout/checks/create/edit/merge/update-branch/close/reopen/review/comment — nothing generic). So when a capability is missing, there is no sanctioned escape hatch, and the user notices agents reaching for `curl` + config-file parsing. ## Recommendation Add a thin raw passthrough, in the spirit of `gh api`: ``` gitea-axi api <METHOD> <path> [--field k=v ...] [--raw-field k=v ...] [--input <file>] ``` It should reuse the existing repo/login resolution and the `tea` login credentials (`src/tea.ts` / `src/client.ts`) so no token handling is improvised, resolve `{owner}`/`{repo}` placeholders in the path from context, and print the raw JSON response. Value beyond convenience: - It's the honest fallback for anything the typed commands don't cover yet (e.g. resolving a review conversation, whose endpoint isn't in the pinned SDK), so agents stop hand-rolling `curl` + `config.yml` parsing. - It keeps auth and host resolution inside one code path instead of leaking the token into ad-hoc scripts. This is the highest-leverage of the review-workflow gaps I hit, because it backstops all the others.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: alexion/gitea-axi#40