fix(bitbucket): send reviewer user.name instead of user.slug

[imagile-bot]

Summary

Bitbucket Server pull request create/update requests serialized reviewers as reviewers[].user.slug, but the Data Center REST API identifies a user by reviewers[].user.name (the username). Bitbucket Server rejects the request when slug is sent instead, so pncli bitbucket create-pr --reviewers and pncli bitbucket update-pr --reviewers failed.

addReviewer already used the correct user.name shape — this brings createPR and updatePR in line with it.

Changes

• src/services/bitbucket/client.ts: createPR and updatePR now serialize each reviewer as { user: { name } } instead of { user: { slug } }.
• src/services/bitbucket/client.test.ts: added coverage asserting createPR/updatePR send user.name in the request body.

Testing

• npm run typecheck — pass
• npm run lint — pass
• npm test — pass (639 tests)

Closes #461

Generated with Claude Code

[github-actions]

Small, well-scoped fix: brings createPR/updatePR reviewer serialization in line with addReviewer's existing correct user.name shape for Bitbucket Data Center. Verified the surviving 'slug' references elsewhere in client.ts are unrelated (repo slug, participants URL path). New tests follow existing conventions and cover both single/multiple reviewers. No breaking change — reviewers field always held usernames.

[github-actions]

Small, well-scoped fix: brings createPR/updatePR reviewer serialization in line with addReviewer's existing correct user.name shape for Bitbucket Data Center's /rest/api/1.0 reviewer bodies. Verified the surviving slug references elsewhere in client.ts are unrelated (repo slug in fromRef/toRef, and the /participants/{userSlug} path segment in needsWorkPR, which is the correct field for that endpoint). New tests follow the existing addReviewer test pattern and cover both single and multiple reviewers. No breaking change — the reviewers field on CreatePROpts/UpdatePROpts always held usernames per the --reviewers help text, only the internal request-body key changes.

No bugs, security issues, or pattern deviations found.

[github-actions]

Claude finished @kolatts's task in 1m 34s —— View job

---

Reviewing PR #462

• Clean up stale Claude feedback comments — deleted 3 stale github-actions[bot] comments and dismissed 2 prior formal reviews from github-actions[bot]
• Gather context (diff via git diff origin/main...HEAD, changed files, CLAUDE.md rules)
• Review code quality/correctness
• Review CLI UX
• Review security
• Review bugs/edge cases
• Check adherence to existing patterns
• Submit formal GitHub review (approve or request changes)

Summary

Small, well-scoped fix. createPR and updatePR (src/services/bitbucket/client.ts:114, :124) were serializing reviewers as { user: { slug } }, but Bitbucket Server's Data Center REST API (/rest/api/1.0) identifies a user by name (the username), not slug. addReviewer (client.ts:337) already used the correct { user: { name } } shape — this brings the two other call sites in line, matching the repo's Deployment Variant — Target Self-Hosted convention (same precedent as Jira's name-vs-accountId split).

Correctness: Verified every other slug reference in client.ts is unrelated and correctly left alone:

• client.ts:103,110 — opts.repo as a repository slug in fromRef/toRef, a different field.
• client.ts:315 — r.user.slug === currentUser.slug identity comparison in needsWorkPR.
• client.ts:324 — /participants/{userSlug} URL path segment, which Bitbucket Server's API documents as userSlug.

Types/back-compat: reviewers?: string[] on CreatePROpts/UpdatePROpts was always meant to hold usernames — the --reviewers <users> CLI help text already says "usernames" (commands.ts:98,120,181). Only the internal request-body key changes; no public type, flag, or JSON envelope field is renamed, so this isn't a breaking change under CLAUDE.md's "Changing Existing Behavior" rules.

Tests: The two new tests in client.test.ts follow the existing addReviewer test pattern (vi.stubGlobal('fetch', ...) capturing { url, method, body }), asserting the fixed shape ({ user: { name: 'jsmith' } }) for both createPR (multiple reviewers) and updatePR (single reviewer), per the repo's Testing Rule.

No bugs, security issues, or pattern deviations found.

Review submitted: ✅ Approved via mcp__github__create_and_submit_pull_request_review.

Process note

npm/npx invocations (typecheck/lint/test) require approval not available in this sandbox, so I couldn't independently re-run the gates. The change is small enough to verify by direct inspection (shown above), and the PR description states all three gates pass locally (639 tests).

Superseded by a newer automated review

[github-actions]

Small, well-scoped fix. createPR and updatePR (src/services/bitbucket/client.ts:114, :124) were serializing reviewers as { user: { slug } }, but Bitbucket Server's Data Center REST API (/rest/api/1.0) identifies a user by name (the username), not slug. addReviewer (client.ts:337) already used the correct { user: { name } } shape — this brings the two other call sites in line, matching the repo's Deployment Variant — Target Self-Hosted convention (same precedent as Jira's name-vs-accountId split).

Correctness: Verified every other slug reference in client.ts is unrelated and correctly left alone:

• client.ts:103,110 — opts.repo as a repository slug in fromRef/toRef, a different field.
• client.ts:315 — r.user.slug === currentUser.slug identity comparison in needsWorkPR.
• client.ts:324 — /participants/{userSlug} URL path segment, which Bitbucket Server's API documents as userSlug.

Types/back-compat: reviewers?: string[] on CreatePROpts/UpdatePROpts was always meant to hold usernames — the --reviewers <users> CLI help text already says "usernames" (commands.ts:98,120,181). Only the internal request-body key changes; no public type, flag, or JSON envelope field is renamed, so this isn't a breaking change under CLAUDE.md's "Changing Existing Behavior" rules.

Tests: The two new tests in client.test.ts follow the existing addReviewer test pattern (vi.stubGlobal('fetch', ...) capturing { url, method, body }), asserting the fixed shape ({ user: { name: 'jsmith' } }) for both createPR (multiple reviewers) and updatePR (single reviewer), per the repo's Testing Rule (no live network dependency).

No bugs, security issues, or pattern deviations found.