fix(jira): read issue type from issueTypes.task, not never-written issueTypes.default (MNG-1769)

[aaight]

Summary

Fixes MNG-1769 — the JIRA wizard persists the operator's Task mapping under issueTypes.task, but JiraPMProvider.createWorkItem read issueTypes.default (a key nothing ever wrote), so every JIRA issue was hardcoded to type "Task", silently ignoring the operator's mapping. The adapter unit-test fixture itself used default, masking the bug in CI while the manifest configFixture already used task.

Same "wizard writes X → runtime reads Y" failure shape as MNG-1768; this PR mirrors its parity-guard approach.

Changes

• Core fix (src/pm/jira/adapter.ts) — createWorkItem now reads this.config.issueTypes?.task ?? 'Task'. The 'Task' fallback is retained for configs that never set a mapping (backward compatible). Updated the block comment to document the issueTypes.task contract.
• Actionable error (src/pm/jira/adapter.ts) — createIssue is wrapped in try/catch. On failure, a best-effort getIssueTypesForProject(projectKey) call re-throws an error naming the attempted issue type and the project's discovered non-subtask types. The diagnostic fetch is itself guarded so a discovery failure re-throws the original creation error unchanged.
• Fixture + tests (tests/unit/pm/jira/adapter.test.ts) — corrected the misleading mockConfig fixture (default/subtask → task: 'Story'); updated the existing create test to assert the mapping is honored; added parity, fallback, regression (legacy default ignored), and enriched-error tests.
• Dead-config cleanup (web/src/components/projects/pm-providers/jira/issue-type-step.tsx) — removed the unused subtask wizard row (no consumer, no subtask-creation path); narrowed onMappingChange role type to 'task'. Updated the step test accordingly.
• Docs (src/integrations/README.md) — documented the issueTypes.task contract, the intentional non-reading of default, the actionable-error behavior, and why subtask is not consumed.

Behavior change

Projects that explicitly mapped Task to a non-Task type were silently broken and now work. Projects with a Task type and no mapping (or a Task mapping) are unchanged — the fallback still yields 'Task'. No migration needed (nothing ever wrote issueTypes.default). A previously-saved issueTypes.subtask value stays in config, harmlessly unread.

Testing

• npx vitest run --project unit-core tests/unit/pm/jira/adapter.test.ts — 72 passing
• npx vitest run tests/unit/web/jira-issue-type-step.test.ts tests/unit/web/pm-wizard-hooks.test.ts — passing
• npx vitest run --project unit-core tests/unit/integrations/pm-conformance.test.ts — passing (configFixture already uses task)
• tests/unit/architecture-docs.test.ts — passing
• Backend + web typecheck clean; biome clean on changed files

🤖 Generated with Claude Code

🕵️ claude-code · claude-opus-4-8 · run details

[codecov]

Codecov Report

❌ Patch coverage is 94.87179% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pm/jira/adapter.ts	94.87%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[nhopeatall]

Summary

APPROVE — a correct, complete, and well-tested fix for the issueTypes.default → issueTypes.task key mismatch. The runtime read is now the sole consumer, config flows through generically, and the frontend/backend/docs changes are consistent. Faithfully implements all five work-item steps (MNG-1769).

Verification

• Core fix is complete. createWorkItem now reads this.config.issueTypes?.task ?? 'Task'. Grepped the whole tree — src/pm/jira/adapter.ts:210 is the only runtime reader of issueTypes.*; nothing else reads .default/.subtask and nothing writes .default. getJiraConfig → JiraConfig.issueTypes (Record<string,string>) passes the key through unchanged, so a saved { task: 'Story' } actually reaches the adapter. Manifest configFixture and config-schema already used task.
• Enriched error is sound. enrichCreateIssueError guards the getIssueTypesForProject discovery call in its own try/catch and re-throws the original error on discovery failure. getIssueTypesForProject exists and returns {name, subtask}[], so the !t.subtask filter is correct. Neither PM caller (friction/materialize.ts, alerting/_shared/materialize.ts) inspects the error type, so wrapping it in a new Error is safe.
• Frontend narrowing is safe. onMappingChange: (role: 'task', …) — the sole caller (jira/wizard.ts:319) dispatches SET_JIRA_ISSUE_TYPE whose key: string accepts 'task'. buildIntegrationConfig still serializes issueTypes generically; a previously-saved subtask value hydrates and re-saves harmlessly, matching the documented behavior.
• Tests. Ran tests/unit/pm/jira/adapter.test.ts (72 ✓) and tests/unit/web/jira-issue-type-step.test.ts (7 ✓) locally; CI 7/7 green. Fixture correction + parity/fallback/regression/enriched-error coverage all present.

Minor (non-blocking, optional)

• src/pm/jira/adapter.ts:274-281 — the enriched message frames every createIssue failure as an issue-type problem ("Map the Task role to one of these…"). For a non-issue-type 400 (e.g. a missing required field) that's slightly misleading, though the root cause is preserved via Original error: …. Fine to leave as-is since the common failure mode is exactly the invalid-issue-type case this targets.

🕵️ claude-code · claude-opus-4-8 · run details