Defame1297
be9b8d277f
gitea-files' always-loaded Gotchas said "content is base64 both ways" without qualification. The `main` text carried an exception for `withLines: true` and both halves were dropped. Verified live: `get_file_contents` with `withLines: true` returns plain JSON text while the same response still reports `"encoding":"base64"`. An agent that follows the recommendation two sentences later and applies the unconditional decode gets garbage, with the response's own field confirming the wrong answer. Exception restored, and the lying field named. gitea-orchestrate was never updated for `rename_branch`: absent from the operation enum, so an agent caller got "unknown operation", and absent from the destructive-confirm list, though branches.md requires a rename with open PRs or a protection rule to be confirmed exactly as `delete_branch` is. Added to both — the confirm gate rather than the enum alone, because accepting the operation without it routes around a rule the skill states while appearing to support it. The compatibility frontmatter, which the agent reads, still omitted the tool too. Two more always-loaded Gotchas contradicted their own reference files, and the Gotcha was wrong both times: issues and PRs are distinguishable on a list item by the `html_url` path segment (confirmed live — #129 at /pulls/, #128 at /issues/), and `get_repository_tree` takes `tree_sha`, not `ref`. `review_comments` was asserted as unconditionally present on the PR get response. It is absent on a PR with no review comments, so the claim is downgraded to present-when-non-zero rather than stated as response shape. The label-exclusivity relocation moved the rule out of label-inference.md and into labels.md without updating sources.md, leaving the one rule in this branch that writes differently to live repos citing a file that no longer carries it. The rule itself is correct as it stands and `main` was wrong — every Kind/* label on this instance is exclusive:false, every Priority/* and Status/* is true — so only the provenance record is corrected. Routing: gitea-workflow lost the human-caller discriminator and widened from status checks to any request, which sent "close #42" to a branch that resolves the number and presents detail without ever closing it. gitea-branches and gitea-issues regain trigger phrasings the retrofit dropped. Refs: #92
2.2 KiB
source_keys
| source_keys | ||
|---|---|---|
|
Reading files, directories and trees
All three read calls select what to read with ref — a branch name, tag, or commit SHA. On
get_repository_tree the same value goes in tree_sha despite the name.
Single file
get_file_contents(owner, repo, ref, path).
The response carries the file's sha at the top level, not nested under content. That field
is the write-ready SHA, so capture it whenever a write may follow.
Content comes back base64-encoded — decode it — unless withLines: true was passed, in which
case content is already plain text: a JSON array of {"line": N, "content": "..."} objects.
The response reports "encoding": "base64" either way, so that field is wrong under withLines
and decoding on its word yields garbage. Pass withLines: true only when you need numbered lines
to quote specific lines back to the user; omit it for a normal content fetch.
One directory level
get_dir_contents(owner, repo, ref, path) returns the immediate entries only — name, path, type,
size. No recursion, no content, no sha.
Whole repository tree
get_repository_tree(owner, repo, tree_sha, recursive). Set recursive: true to walk
subdirectories in one call.
The response sets truncated: true when one page does not hold every entry. Page through with
page/per_page (defaults 1 and 30) until a page returns fewer entries than per_page.
Neither listing is a SHA source for a write
get_dir_contents entries carry no sha at all. get_repository_tree entries do carry a blob or
tree hash, but reaching it costs an extra round trip and returns no content. get_file_contents is
the canonical path for a write's SHA: one call returns the decoded content and the write-ready
sha together.
A 404 that is really a 403
These reads gate on write:repository, not on read access alone, and some Gitea endpoints answer
an under-scoped token with 404 instead of 403 so they do not leak whether the resource exists. A
404 on a path you are confident about is a scope problem until proven otherwise — check the token's
configured scopes before concluding the file or directory does not exist.