Plan — BJ-2: BitbucketOAuthAuthProvider#

Summary#

Add a concrete BitbucketOAuthAuthProvider that extends the AtlassianOAuthAuthProvider base (BJ-1) and wire it into a new BitbucketModule under the PLATFORM_AUTH_PROVIDER token via a factory pattern mirroring src/github/github.module.ts:14.

Files#

Path	Action	Description
`src/atlassian/bitbucket-oauth-auth.provider.ts`	create	Concrete provider: `platform = 'bitbucket'`, token endpoint `https://bitbucket.org/site/oauth2/access_token`, `getBotUsername()` returns `BITBUCKET_BOT_USERNAME`.
`src/atlassian/bitbucket-oauth-auth.provider.spec.ts`	create	Unit test covering platform id, token endpoint, bot username resolution, and missing-config error.
`src/bitbucket/bitbucket.module.ts`	create	NestJS module with factory-registered `PLATFORM_AUTH_PROVIDER` gated on `BITBUCKET_OAUTH_CLIENT_ID`.
`src/app.module.ts`	modify	Import `BitbucketModule` alongside `GitHubModule`.

Steps#

Implement BitbucketOAuthAuthProvider extending AtlassianOAuthAuthProvider, overriding platform, the token endpoint, and getBotUsername() (throw typed error when BITBUCKET_BOT_USERNAME missing).
Create BitbucketModule with factory provider that instantiates BitbucketOAuthAuthProvider only when BITBUCKET_OAUTH_CLIENT_ID is configured; otherwise omit registration so module boots cleanly.
Register BitbucketModule in app.module.ts imports array.
Write unit spec: verify platform === 'bitbucket', verify getBotUsername() returns configured value and throws when unset, verify factory returns provider only when client id is set.
Run npm run lint and npm run test to confirm zero warnings and all specs pass.

Verification#

npm run test — new provider spec green, existing suite unchanged.
npm run lint — zero warnings (strict mode).
npm run build — compiles with no TypeScript errors.

Risks#

Depends on #540 (platform union includes 'bitbucket') and #541 (AtlassianOAuthAuthProvider base class). Both are OPEN; implementation cannot merge until they land on rc/atlassian-integration. Agent will BLOCK if deps absent at exec time.
BITBUCKET_* env vars are not yet in the Joi config schema (BJ-4); provider will read them with config.get() but a full e2e boot needs BJ-4 to pass validation.

Open Questions#

Does BJ-1's base class already implement getToken() (OAuth refresh flow) such that this subclass only overrides platform / endpoint / getBotUsername()? Assumption: yes — plan treats the subclass as thin. If base class is abstract for token logic, step 1 expands to include Bitbucket-specific refresh call.