-
Gitea user account used by Claude Code with Gitea MCP to manage repositories: read/write issues and PRs, comment on changes, and perform merge/review actions with appropriate permissions.
- Joined on
2026-06-20
Folded in from #100 (closed): two dangling routing targets, both hostage to this retrofit
#100 tracked four skill descriptions whose boundary clauses named targets that do not resolve. Two are…
Collateral for the gitea-prs retrofit: three stale claims in SKILL.md
PR #106 (fixing #104) corrected references/pull-requests.md on which pull_request_write parameters each method…
Review round two: 11 defects found, all fixed, plus one reversed decision
A five-way review of this branch at de84d1b found 11 defects. Six commits (b1ea14d..d42f636) fix them. Two blind…
Both open design decisions closed — pushed as 54d7bd8
The two items left open at the bottom of the previous comment are resolved. Two commits on top of 79c9089.
Review findings addressed — pushed as 79c9089
Four commits on top of e7ebc66. Every blocker and major from the review above is closed; the two items I left open are design decisions,…
Submitted as a comment review — Gitea rejects REQUEST_CHANGES from the PR author's own account. Treat it as request-changes: B1 is a confirmed blocker and B2/B3/B5 are confirmed vacuous-green paths.
This is factually wrong about the validator. check_boundary() is called at both scopes — agent-audit/scripts/validate.sh:1124 (plugin/APM) and :1213 (project/user) — and I confirmed it fires on a real agent file (apm-orchestrate.agent.md emits a boundary SUGGESTION).
This trigger is too broad. validate.sh exits 1 on ordinary content FAILs — the normal outcome of auditing any non-compliant skill, i.e. the entire #99 population — so "if any of the three fails" loads 1,302 words of script-troubleshooting prose on nearly every real audit. That is a context-budget regression inside the skill that enforces the context budget, and the reference file itself opens "Nothing here is needed on a clean run".
Vacuous green, and shared verbatim by all three validators. A non-string YAML value is str()-coerced and then measured as a Python repr. All rc=0:
Vacuous green. The closing marker \r?\n[ \t]*---[ \t]* matches at any indentation, so a --- line inside a block scalar terminates the frontmatter early and the remainder of the description is silently reclassified as body.
Blocker. _authoring_root() falls back to the nearest .git ancestor, so it returns truthy in any git repo. _collect_authoring_root() then contributes zero names (no plugins/*/.apm/), and this else branch never runs — _deployed_roots is dead code in every git-tracked repo, which is the only case it was written for.
This is factually wrong about the validator. check_boundary() is called at both scopes — agent-audit/scripts/validate.sh:1124 (plugin/APM) and :1213 (project/user) — and I confirmed it fires on a real agent file (apm-orchestrate.agent.md emits a boundary SUGGESTION).
This trigger is too broad. validate.sh exits 1 on ordinary content FAILs — the normal outcome of auditing any non-compliant skill, i.e. the entire #99 population — so "if any of the three fails" loads 1,302 words of script-troubleshooting prose on nearly every real audit. That is a context-budget regression inside the skill that enforces the context budget, and the reference file itself opens "Nothing here is needed on a clean run".