docs: map Gitea web UI vs REST API parity gaps #43

Merged
alexion merged 1 commits from docs/gitea-web-vs-api into main 2026-07-18 16:07:55 -04:00
Owner

Adds .claude/gitea-web-vs-api.md, a map of the capabilities Gitea's web UI exposes that its REST API does not, scoped to the issue / PR / review / comment / label / milestone domain.

Analysed against go-gitea/gitea at commit e8befe026853a90a9efca559ca9f9cac8b41fc88.

Method

Every web route registered under the issue/PR paths in routers/web/web.go was paired against routers/api/v1/api.go; each unpaired route was then traced to the services/ or models/ function its handler calls, and that function checked for reachability from any API handler. Each surviving finding was cross-checked against the generated OpenAPI spec, and searched for upstream prior art.

Presentation-only routes are excluded by design. Projects/kanban and issue templates are out of scope for this pass.

Findings

Nine, ranked by impact and tractability, each with the web route, the service function reached, swagger evidence, prior art, and a patch sketch. Ready-to-paste issue drafts for the five to file first.

The strongest is the merge box: the API returns a bare mergeable boolean while the web UI computes five distinct blocker reasons plus status-check and signing state, reachable only from ViewPullMergeBox. It sits on an open upstream issue from 2020 with no implementation attempt.

The most likely to land is the time estimate: upstream merged the read half in 2025 and stopped, leaving a field the API returns but cannot set.

Bearing on this repo's backlog

Two gaps that motivated the review are already fixed upstream, which supersedes the premises of issues #38 and #39:

  • POST /repos/{owner}/{repo}/pulls/comments/{id}/resolve and /unresolve exist — issue #39's exact ask.
  • POST /repos/{owner}/{repo}/pulls/{index}/comments/{id}/replies exists, and inline comments can be created via POST /pulls/{index}/reviews with a comments[] array — most of issue #38.

What remains of #38 is narrower: a pending review cannot be accumulated across calls, because the API submits it in the same request. Both issues are worth rewriting against what the instance actually supports.

Adds `.claude/gitea-web-vs-api.md`, a map of the capabilities Gitea's web UI exposes that its REST API does not, scoped to the issue / PR / review / comment / label / milestone domain. Analysed against `go-gitea/gitea` at commit `e8befe026853a90a9efca559ca9f9cac8b41fc88`. ## Method Every web route registered under the issue/PR paths in `routers/web/web.go` was paired against `routers/api/v1/api.go`; each unpaired route was then traced to the `services/` or `models/` function its handler calls, and that function checked for reachability from any API handler. Each surviving finding was cross-checked against the generated OpenAPI spec, and searched for upstream prior art. Presentation-only routes are excluded by design. Projects/kanban and issue templates are out of scope for this pass. ## Findings Nine, ranked by impact and tractability, each with the web route, the service function reached, swagger evidence, prior art, and a patch sketch. Ready-to-paste issue drafts for the five to file first. The strongest is the merge box: the API returns a bare `mergeable` boolean while the web UI computes five distinct blocker reasons plus status-check and signing state, reachable only from `ViewPullMergeBox`. It sits on an open upstream issue from 2020 with no implementation attempt. The most likely to land is the time estimate: upstream merged the read half in 2025 and stopped, leaving a field the API returns but cannot set. ## Bearing on this repo's backlog Two gaps that motivated the review are already fixed upstream, which supersedes the premises of issues #38 and #39: - `POST /repos/{owner}/{repo}/pulls/comments/{id}/resolve` and `/unresolve` exist — issue #39's exact ask. - `POST /repos/{owner}/{repo}/pulls/{index}/comments/{id}/replies` exists, and inline comments can be created via `POST /pulls/{index}/reviews` with a `comments[]` array — most of issue #38. What remains of #38 is narrower: a pending review cannot be accumulated across calls, because the API submits it in the same request. Both issues are worth rewriting against what the instance actually supports.
alexion added 1 commit 2026-07-18 15:57:36 -04:00
docs: map Gitea web UI vs REST API parity gaps
All checks were successful
CI / test (pull_request) Successful in 58s
CI / test (push) Successful in 54s
db2285b40d
Nine capabilities the web UI exposes that the REST API does not, in the
issue/PR/review domain, analysed against go-gitea/gitea at e8befe0.

Each finding cites the web route, the service function its handler
reaches, the swagger evidence, upstream prior art, and a patch sketch.
Ranked by impact and tractability, with issue drafts for the five to
file first.

Also records that resolve/unresolve review conversations and threaded
reply endpoints already exist upstream, which supersedes the premises of
issues #38 and #39.
alexion force-pushed docs/gitea-web-vs-api from 5de30b1c74 to db2285b40d 2026-07-18 15:57:36 -04:00 Compare
alexion merged commit db2285b40d into main 2026-07-18 16:07:55 -04:00
alexion deleted branch docs/gitea-web-vs-api 2026-07-18 16:07:55 -04:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: alexion/gitea-axi#43