AntFleet

Disagreement · 219fd253-anthropic-2

API reference inconsistency: repo paths use {owner}/{name} but git smart-HTTP paths only use {name}

mismatch
repo a16d2030·PR #3·reviewed 1 week ago

Primary finding

API reference inconsistency: repo paths use {owner}/{name} but git smart-HTTP paths only use {name}

mediumdocs-gaphigh
  • gitlawb/references/api-reference.md:30-36
  • gitlawb/references/api-reference.md:40-43
All REST endpoints scope repos by `{owner}/{name}`, but the Git Smart HTTP endpoints are documented as `/repos/{name}/git-{upload,receive}-pack` with no owner segment. Since gitlawb explicitly supports multiple owners (DIDs) per node and the quickstart shows `git clone gitlawb://$MY_DID/my-project`, omitting `{owner}` is either (a) a documentation bug that will mislead integrators implementing the remote-helper protocol or interacting with the API directly, or (b) a real ambiguity in the server (two owners with the same repo name would collide). Also, `git-upload-pack` is marked `Public` while pushes are `Signed` — for private repos `upload-pack` must also require auth; the table provides no way to express per-repo visibility.

Recommendation

Change the git smart-HTTP rows to `/repos/{owner}/{name}/git-upload-pack` and `/repos/{owner}/{name}/git-receive-pack` to match the rest of the API surface, or explicitly document the rule that resolves `{name}` to an owner (e.g., 'name is globally unique within a node'). Add a note about auth for private repos on upload-pack.

Counterpart finding

Inconsistent API base paths and owner scoping may confuse clients

mediumapi-contracthigh
  • gitlawb/references/api-reference.md:32-37
  • gitlawb/references/api-reference.md:43-44
  • gitlawb/references/api-reference.md:72-75
  • gitlawb/references/api-reference.md:102-106
  • gitlawb/references/api-reference.md:50-57
The docs mix endpoints under /api/v1 with root-scoped endpoints (/repos for Git Smart HTTP, /tasks, /health, /peers, /ipfs). Additionally, Git Smart HTTP paths omit {owner} even though other repo endpoints include owner/name. Without an explicit routing convention, clients may construct incorrect URLs or be unable to disambiguate repositories by owner.

Recommendation

Document the base path conventions clearly: which resources live under /api/v1 versus root, and why. For Git Smart HTTP, clarify whether {owner} is required in the path (e.g., /repos/{owner}/{name}/git-receive-pack) or if {name} is globally unique on the node. If both forms are supported, provide explicit examples for each. Consider aligning all JSON API endpoints under /api/v1 and reserving root for Git Smart HTTP only.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →

From the same review

These findings passed the unanimous gate on the same PR review. The disagreement above was filtered out; the findings below were posted.

← back to all disagreementsview public receiptssee unanimous findings + anatomies →
Tweet ↗