fix: pass labels and reviewers through PR creation call chain (#44) (#44)

[jafreck]

Summary

PR labels and reviewers configured via config.pullRequest.labels and config.pullRequest.reviewers were silently dropped when creating a pull request. This fix extends the CreatePullRequestParams interface with these fields and threads them through the entire call chain: the phase executor, the GitHub API layer, and the Azure DevOps provider.

Closes #44

Changes

• src/platform/provider.ts: Added optional labels?: string[] and reviewers?: string[] fields to the CreatePullRequestParams interface.
• src/executors/pr-composition-phase-executor.ts: Updated createPullRequest() call to forward ctx.config.pullRequest.labels and ctx.config.pullRequest.reviewers.
• src/github/api.ts: Updated GitHubAPI.createPullRequest() to conditionally include labels and reviewers in the create_pull_request MCP tool call arguments (only when non-empty).
• src/platform/azure-devops-provider.ts: After PR creation, sets labels via the ADO POST /labels endpoint and adds reviewers by resolving their identity GUIDs via the VSSPS identities API then calling PUT /reviewers/{id}. Both operations are non-critical — failures are logged as warnings.
• tests/github-provider-parsing.test.ts: Added tests verifying that labels and reviewers are forwarded to the MCP call, and that omitting them produces no extra keys in the payload.
• tests/pr-composition-phase-executor.test.ts: Added tests verifying that labels and reviewers from ctx.config.pullRequest are passed to createPullRequest().
• tests/azure-devops-provider.test.ts (new file): Comprehensive unit tests for the ADO provider's PR creation, labels, and reviewers forwarding logic, including failure-tolerance behavior.

Implementation Details

The GitHub provider path was the simpler change: the MCP create_pull_request tool already supports labels and reviewers, so only the parameter plumbing was missing. For Azure DevOps, labels and reviewers require separate REST calls after initial PR creation. Reviewer resolution requires an extra identity lookup against the VSSPS API to convert an email/alias string into the GUID that the ADO reviewers endpoint expects. Failures in these post-creation calls are treated as non-critical warnings to preserve overall PR creation success.

Testing

• Unit tests added for PRCompositionPhaseExecutor, GitHubAPI, and AzureDevOpsProvider covering labels and reviewers passthrough.
• Tests cover the empty/default case (no extra keys or API calls) and the populated case.
• ADO provider tests verify failure tolerance: label/reviewer errors log a warning and do not throw.
• All existing tests continue to pass.

Integration Verification

• Install: pass
• Build: pass
• Tests: pass

Notes

• The Azure DevOps reviewer resolution step uses searchFilter=AccountName against the VSSPS identities API. If a reviewer string is not an exact account name match, the identity lookup will return no results and a warning is logged — the reviewer is skipped rather than failing the PR creation.
• Azure DevOps uses POST /labels per label (one call per label), not a batch endpoint, which is consistent with the ADO API design.
• No config schema changes were needed: pullRequest.labels already defaults to ['cadre-generated'] and pullRequest.reviewers already defaults to [].

Cadre Process Challenges

This section is required for all CADRE-generated PRs (dogfooding data).
Document honestly what was difficult, confusing, or error-prone when CADRE processed this issue.

• Issue clarity: The issue was well-specified with clear acceptance criteria. The one ambiguity (ADO labels vs. tags, and reviewer ID format) was noted in the analysis — the agent had to make a reasonable assumption (POST per label, VSSPS identity lookup for reviewers).
• Agent contracts: No significant contract mismatches were observed. The implementation-planner correctly identified 7 tasks and their dependency order.
• Context limitations: No file tree was available to the issue-analyst agent, requiring it to infer file paths from naming conventions. This worked well for this codebase but could fail in projects with non-standard layouts.
• Git/worktree: No branch, worktree, or commit issues encountered during this run.
• Parsing/output: Agent outputs parsed correctly without schema mismatches.
• Retry behavior: No retries were needed in this run.
• Overall: The biggest friction point was the Azure DevOps reviewer flow — the ADO REST API requires a two-step identity resolution that isn't obvious from the issue description, requiring the agent to make an inference about the correct endpoint and request shape.

Closes #44