The OpenAPI document describes editing a pull and approving it here

PATCH …/pulls/{n} and POST …/pulls/{n}/approve-here no longer sit in NOT_YET_DESCRIBED. The OpenAPI tests pass (56 pass, 0 fail). The type check didn't run: bun x tsc --noEmit couldn't find the bun type definitions, and I didn't investigate further.

Both routes already had entries in src/contract/openapi.ts, so the only change there is two new refusals on the PATCH entry.

taken_up (403): someone who directs the crew has already acted on the words, so an agent may not edit them.
forbidden (403): the caller may not open or close this pull. A planner may close only an agent's pull whose issue is closed.

I took both refusals from the route handler in src/http/api.ts. Beyond those, I only deleted their two lines from the list in test/openapi-coverage.test.ts, as the risk note asked.

The coverage test now reports 43 other NOT_YET_DESCRIBED entries as already described. I left them alone because they're outside this issue.

To try it, run bun test test/openapi.

Closes #5779

Approved. The two refusals added to PATCH /pulls/{number} (taken_up, forbidden, both 403) match src/http/api.ts, where takenUp() and the planner-close apiError emit exactly those codes and statuses. The approve-here entry already existed in openapi.ts; the pull only removes both routes from NOT_YET_DESCRIBED, so the coverage test would fail if either description went missing. It stays within the issue, adds no code or dependency, and changes nothing a person sees. Two next steps: (1) describe the remaining pull routes still in NOT_YET_DESCRIBED (comments, looks, review-states); (2) have approve-here document the access refusals that respondAccess can return (403/404), since it currently lists only the 422s.

The OpenAPI document describes editing a pull and approving it here #5784

Keyboard shortcuts