fix(gitea): gitea-prs reference wrongly claims milestone is settable on PR create #104

New Issue

Claude · 2026-08-14T22:05:51Z

Claude commented

2026-08-14 22:05:51 +00:00

Found while opening PR #103 through the gitea-prs skill.

The claim

plugins/gitea/.apm/skills/gitea-prs/references/pull-requests.md:59 documents pull_request_write's milestone parameter as:

milestone (number, optional) — milestone ID, never a title; settable on both "create" and "update"

The "settable on create" half is wrong against this Gitea server.

Actual behaviour

pull_request_write method: "create" accepts milestone without error and silently drops it. There is no error, no warning, and no field in the response indicating the parameter was ignored. Confirmed three ways:

the milestone's open_issues count did not move (12 before the create, 12 after);
pull_request_read method: "get" on the new PR returned no milestone field at all;
issue_read method: "get" on the same number likewise returned no milestone field.

A follow-up pull_request_write method: "update" with the identical milestone: 6 applies it correctly — the read then returns "milestone": "Skills & Agents" and the count moves to 13.

Reproduction

PR #103 (feat(kyberforge): ADR-0020 context contract for skills and agents). Created with labels: [9, 23] and milestone: 6 in a single create call. Labels applied; milestone did not. A second call, method: "update" with only pull_number and milestone: 6, applied it.

Why this is easy to miss

labels and milestone are adjacent optional parameters on the same write, documented identically, and labels does apply correctly on create. The asymmetry means a caller who verifies the labels landed will reasonably assume the milestone did too. Nothing in the create response contradicts that — the response simply omits the milestone key, which is indistinguishable from a PR that was never given one.

Note the reference file already carries a "Milestone gotcha" callout, but it covers a different problem — that reads return a bare title string rather than an ID. It does not cover the write side.

Fix

Correct references/pull-requests.md to state that milestone is honoured only on "update", and that setting a milestone at creation time requires a follow-up update call. The existing "Milestone gotcha" section is the natural home for the addition. Worth checking whether the same drop affects assignees/reviewers on create while in there — untested, and the same silent-accept shape would apply.

Not blocked by the ADR-0020 gates

The fix touches only references/pull-requests.md, not SKILL.md. skill-size-check's files: pattern is ^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$ (verified at .pre-commit-config.yaml:275), so a reference-file edit does not trigger the new description/body gates. Whoever picks this up can fix it directly, without first retrofitting gitea-prs for #99.

Found while opening PR #103 through the `gitea-prs` skill. ## The claim `plugins/gitea/.apm/skills/gitea-prs/references/pull-requests.md:59` documents `pull_request_write`'s `milestone` parameter as: > `milestone` (number, optional) — milestone ID, never a title; settable on both `"create"` and `"update"` The "settable on `create`" half is wrong against this Gitea server. ## Actual behaviour `pull_request_write method: "create"` **accepts `milestone` without error and silently drops it.** There is no error, no warning, and no field in the response indicating the parameter was ignored. Confirmed three ways: - the milestone's `open_issues` count did not move (12 before the create, 12 after); - `pull_request_read method: "get"` on the new PR returned no `milestone` field at all; - `issue_read method: "get"` on the same number likewise returned no `milestone` field. A follow-up `pull_request_write method: "update"` with the identical `milestone: 6` applies it correctly — the read then returns `"milestone": "Skills & Agents"` and the count moves to 13. ## Reproduction PR #103 (`feat(kyberforge): ADR-0020 context contract for skills and agents`). Created with `labels: [9, 23]` and `milestone: 6` in a single `create` call. Labels applied; milestone did not. A second call, `method: "update"` with only `pull_number` and `milestone: 6`, applied it. ## Why this is easy to miss `labels` and `milestone` are adjacent optional parameters on the same write, documented identically, and **`labels` does apply correctly on `create`.** The asymmetry means a caller who verifies the labels landed will reasonably assume the milestone did too. Nothing in the create response contradicts that — the response simply omits the `milestone` key, which is indistinguishable from a PR that was never given one. Note the reference file already carries a "Milestone gotcha" callout, but it covers a different problem — that reads return a bare title string rather than an ID. It does not cover the write side. ## Fix Correct `references/pull-requests.md` to state that `milestone` is honoured only on `"update"`, and that setting a milestone at creation time requires a follow-up `update` call. The existing "Milestone gotcha" section is the natural home for the addition. Worth checking whether the same drop affects `assignees`/`reviewers` on `create` while in there — untested, and the same silent-accept shape would apply. ## Not blocked by the ADR-0020 gates The fix touches only `references/pull-requests.md`, not `SKILL.md`. `skill-size-check`'s `files:` pattern is `^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$` (verified at `.pre-commit-config.yaml:275`), so a reference-file edit does not trigger the new description/body gates. Whoever picks this up can fix it directly, without first retrofitting `gitea-prs` for #99.

Claude added this to the Skills & Agents milestone 2026-08-14 22:05:51 +00:00

Claude added the Kind/Bug

Priority

Medium

3

labels 2026-08-14 22:05:51 +00:00

Defame1297 referenced this issue from a commit

2026-08-17 17:03:35 +00:00

fix(gitea): correct which pull_request_write params apply on create

Defame1297 closed this issue

2026-08-17 17:03:35 +00:00

Claude referenced a pull request that will close this issue