fix(gitea): correct token-scope claim in gitea-branches docs

SKILL.md, README.md, and references/{branches,commits}.md claimed
list_branches, list_commits, and get_commit "work with write:issue
alone." This contradicted docs/research/docs/gitea/overview.md, which
documents write:repository as gating both reads and writes for
repo-scoped tool families (Gitea hides these reads behind write
scope). The prior empirical justification was invalid: it tested under
a token holding both write:issue and write:repository simultaneously,
which doesn't isolate which scope actually enabled the reads.

Corrected all four files to state that list_branches, create_branch,
and delete_branch require write:repository, confirmed directly by
overview.md's scope enumeration. list_commits/get_commit are flagged
as inferred to need the same scope by analogy rather than an
overview.md-confirmed fact, since overview.md's write:repository
enumeration names PR/branch/file/release/tag but not commits — this
distinction surfaced during an independent audit pass and is now
called out explicitly so the claim isn't overstated.

Bumped SKILL.md metadata.version 0.1.0 -> 0.1.1 (patch: doc
correction, no behavior change).
This commit is contained in:
2026-07-05 19:12:09 +00:00
parent 3a4ae44500
commit 18ec0ab0ff
4 changed files with 21 additions and 10 deletions

View File

@@ -73,6 +73,9 @@ protected, every time, regardless of how the request is phrased.
## Token scope
`list_branches` works with `write:issue` alone. `create_branch` and `delete_branch` need
`write:repository`. All three are verified working empirically under a token with both scopes
(`write:issue` + `write:repository`).
All three — `list_branches`, `create_branch`, `delete_branch` — require `write:repository`. Gitea
gates reads behind write scope for repo-scoped operations, so `list_branches` needs the same scope
as the write operations, not `write:issue` alone. An earlier version of this doc claimed
`write:issue` alone was sufficient for `list_branches`, based on empirical testing under a token
that held both `write:issue` and `write:repository` simultaneously — that test didn't isolate the
variable, so it couldn't actually establish `write:issue` alone as sufficient.