diff --git a/CHANGELOG.md b/CHANGELOG.md
index e71ebdf5..a94b2fc4 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,7 @@ All notable user-visible changes to CASCADE are documented here. The format is l
 
 ### Added
 
+- **Linear status mapping — full parity with Trello and JIRA.** The Linear PM wizard's Field Mapping step now exposes all eight CASCADE stages that drive agent dispatch (backlog, splitting, planning, todo, inProgress, inReview, done, merged) in lifecycle order, instead of only four. An operator can now map a Linear workflow state to any of `splitting`, `planning`, `todo`, or `merged` and have the corresponding agent (splitting, planning, implementation, backlog-manager) dispatch on issue transitions — previously these four stages were unreachable from Linear because the wizard had no slot to save them. Existing Linear integrations upgrade in place: the four new slots render as "not set" on next wizard visit; pre-existing mappings are untouched. No migration required. The normalized `ProjectPMConfig.statuses` type widens to declare the full nine-stage vocabulary (including `debug`, reserved for a future trigger), so providers can no longer silently drift from the trigger layer's dispatch map. (Spec [003](docs/specs/003-linear-status-mapping-parity.md), plan [1/1](docs/plans/003-linear-status-mapping-parity/1-status-parity.md).)
 - **Linear wizard — inline webhook signing-secret field and accurate events list.** The Webhooks step of the Linear PM wizard now renders a `ProjectSecretField` bound to `LINEAR_WEBHOOK_SECRET` directly beneath the webhook URL, so operators can paste Linear's signing secret in place instead of navigating to the Credentials tab. The "Enable events" instructions now list the three event families CASCADE actually consumes — `Issues` (status transitions), `Comments` (bot @mentions), and `Issue Labels` ("Ready to Process") — each with a one-line rationale tracing back to the registered trigger handlers. (Spec [002](docs/specs/002-linear-webhook-setup-ux.md), plan [2/2](docs/plans/002-linear-webhook-setup-ux/2-wizard-webhooks-step.md).)
 
 ### Changed
@@ -14,6 +15,7 @@ All notable user-visible changes to CASCADE are documented here. The format is l
 
 ### Fixed
 
+- **JIRA `resolveLifecycleConfig` silent-drop of splitting / planning / todo.** The JIRA PM wizard accepts mappings for all eight CASCADE stages, but the normalization step that feeds them to `PMLifecycleManager` was dropping `splitting`, `planning`, and `todo` on the floor. Any agent lifecycle hook that moved JIRA issues to those statuses silently no-op'd. Now passes all eight keys through. No operator action required — existing JIRA mappings start working once the fix deploys. (Spec [003](docs/specs/003-linear-status-mapping-parity.md), plan [1/1](docs/plans/003-linear-status-mapping-parity/1-status-parity.md).)
 - **Linear wizard Save — HTTP 500 on `projects.integrations.upsert`.** A check constraint (`chk_integration_category_provider`) restricted the `pm` category to `trello` or `jira`; Linear support shipped without a matching constraint update, so every attempt to save a Linear PM integration failed with SQLSTATE 23514. Migration 0049 adds `linear` to the allowed `pm` providers. (Spec [002](docs/specs/002-linear-webhook-setup-ux.md), plan [1/2](docs/plans/002-linear-webhook-setup-ux/1-save-path-fix.md).)
 - **Dashboard error logs now surface DB diagnostic fields.** Unhandled errors in the Hono app error handler and tRPC error formatter now include PG error code, detail, constraint, table, and column (unwrapped from `.cause` when Drizzle wraps a pg driver error). Clients still receive a generic "Internal server error" for unexpected `INTERNAL_SERVER_ERROR` throws — real diagnostics go to stdout for operators to grep. (Spec [002](docs/specs/002-linear-webhook-setup-ux.md), plan [1/2](docs/plans/002-linear-webhook-setup-ux/1-save-path-fix.md).)
 
diff --git a/docs/plans/003-linear-status-mapping-parity/1-status-parity.md.done b/docs/plans/003-linear-status-mapping-parity/1-status-parity.md.done
new file mode 100644
index 00000000..e824de3f
--- /dev/null
+++ b/docs/plans/003-linear-status-mapping-parity/1-status-parity.md.done
@@ -0,0 +1,352 @@
+---
+id: 003
+slug: linear-status-mapping-parity
+plan: 1
+plan_slug: status-parity
+level: plan
+parent_spec: docs/specs/003-linear-status-mapping-parity.md
+depends_on: []
+status: done
+---
+
+# 003/1: Linear + JIRA Status Mapping Parity — Full Stage Vocabulary End-to-End
+
+> Part 1 of 1 in the 003-linear-status-mapping-parity plan. See [parent spec](../../specs/003-linear-status-mapping-parity.md).
+
+## Summary
+
+Single coherent plan that delivers spec 003 in its entirety: widens the canonical `ProjectPMConfig.statuses` type to cover all 9 CASCADE stages; expands the Linear wizard's Field Mapping step from 4 slots to 8 (backlog, splitting, planning, todo, inProgress, inReview, done, merged); extends `LinearIntegration.resolveLifecycleConfig` to pass those 4 new keys through; and fixes `JiraIntegration.resolveLifecycleConfig` to stop silently dropping splitting/planning/todo that its wizard already accepts.
+
+Why one plan, not several: the type widening is 4 additive optional keys and has no downstream that rejects it — splitting would ship dead weight in plan 1 with no consumer. The Linear wizard UI and Linear's `resolveLifecycleConfig` are tightly coupled (both must ship together for a user to actually persist and act on new mappings). JIRA's backend fix is a 3-key add to one object literal and reads naturally alongside Linear's identical change. All of it reviews and reverts as a single logical unit.
+
+**Components delivered:**
+- `src/pm/lifecycle.ts` — widen `ProjectPMConfig.statuses` to the full 9 keys (all optional).
+- `src/pm/linear/integration.ts` — `resolveLifecycleConfig` returns `splitting`, `planning`, `todo`, `merged` in addition to the current four.
+- `src/pm/jira/integration.ts` — `resolveLifecycleConfig` returns `splitting`, `planning`, `todo` in addition to the current five.
+- `web/src/components/projects/pm-wizard-linear-steps.tsx` — `LINEAR_STATUS_SLOTS` grows from 4 to 8 (lifecycle order).
+- `web/src/components/projects/pm-wizard-state.ts` — if `linearStatuses` has a known-narrow-type, widen it to accept the new keys.
+- Tests under `tests/unit/pm/`, `tests/unit/triggers/`, `tests/unit/web/`.
+- `CHANGELOG.md` — one Unreleased entry describing the parity fix.
+
+**Deferred to later plans in this spec:**
+- Nothing. Plan 1 closes out spec 003.
+
+---
+
+## Spec ACs satisfied by this plan
+
+- Spec AC #1 (Linear wizard surface — 8 rows, lifecycle order) — **full**
+- Spec AC #2 (Persistence) — **full**
+- Spec AC #3 (Agent dispatch end-to-end on Linear transitions for the 4 newly-reachable stages) — **full**
+- Spec AC #4 (Canonical type coverage — 9 keys declared) — **full**
+- Spec AC #5 (Trello parity preserved) — **full**
+- Spec AC #6 (JIRA agent dispatch for splitting/planning/todo works) — **full**
+- Spec AC #7 (Existing Linear integrations upgrade cleanly) — **full**
+- Spec AC #8 (No required migration) — **full** (change is type-widening + JSONB-additive)
+- Spec AC #9 (Unmapped transitions are a no-op) — **full**
+- Spec AC #10 (Zod / tRPC validation accepts any subset) — **full**
+- Spec AC #11 (Lint / typecheck / tests green) — **full**
+
+---
+
+## Depends On
+
+- Nothing external. Plan is foundation + target + UI in one hop.
+
+Context to lift from the spec:
+- Linear wizard exposes **8** slots; canonical type declares **9** (`debug` is declared but not UI-surfaced — Strategic decision #2).
+- Manual-only mapping; no auto-discovery (Strategic decision #3).
+- Existing Linear rows upgrade in place — new slots render "not set" (Strategic decision #4).
+- Out of scope: broadening `STATUS_TO_AGENT`, label mappings, Sentry, JIRA wizard UI.
+
+---
+
+## Detailed Task List (TDD)
+
+### 1. Widen the canonical type
+
+**Tests first** (`tests/unit/pm/lifecycle-config-shape.test.ts` — new file):
+
+- `ProjectPMConfig.statuses accepts all 9 canonical CASCADE stages as optional keys` — type-level assertion: construct an object typed as `ProjectPMConfig` with every one of `backlog, splitting, planning, todo, inProgress, inReview, done, merged, debug` set to a string; assert TypeScript accepts it. (Use `satisfies` or an explicit typed const; compile-time check.)
+- `ProjectPMConfig.statuses accepts an empty object (all keys optional)` — compile-time check.
+- `Every key in STATUS_TO_AGENT is a declared key of ProjectPMConfig.statuses` — runtime check: iterate `Object.keys(STATUS_TO_AGENT)`, assert each is a valid `ProjectPMConfig['statuses']` key (use a helper that treats the keys as a string union).
+
+**Implementation** (`src/pm/lifecycle.ts`, `ProjectPMConfig` interface):
+
+Expand the `statuses` shape from:
+```ts
+statuses: {
+  backlog?: string;
+  inProgress?: string;
+  inReview?: string;
+  done?: string;
+  merged?: string;
+};
+```
+to:
+```ts
+statuses: {
+  backlog?: string;
+  splitting?: string;
+  planning?: string;
+  todo?: string;
+  inProgress?: string;
+  inReview?: string;
+  done?: string;
+  merged?: string;
+  debug?: string;
+};
+```
+
+All new keys optional. Order matches CASCADE lifecycle. No other changes in this file.
+
+**Stale-reference check:** grep for any narrowed type that derives from `ProjectPMConfig.statuses` (e.g. `keyof ProjectPMConfig['statuses']`). If a consumer exhaustively switches on the 5-key union, it needs a `default` case or must add branches — surface before editing.
+
+### 2. Linear resolveLifecycleConfig — pass the new keys through
+
+**Tests first** (`tests/unit/pm/linear-integration.test.ts` — augment existing or new file):
+
+- `resolveLifecycleConfig returns all 8 status keys from pm.config.statuses` — given `project.pm.config.statuses = { backlog: 's-bl', splitting: 's-sp', planning: 's-pl', todo: 's-td', inProgress: 's-ip', inReview: 's-ir', done: 's-dn', merged: 's-mg' }`, assert the returned `ProjectPMConfig.statuses` contains each key with the corresponding value.
+- `resolveLifecycleConfig preserves undefined for keys not provided` — given a partial input (only `inProgress` set), assert only `inProgress` is present on the output, others are `undefined`.
+- `resolveLifecycleConfig does not read or return debug` — Linear UI does not surface `debug`; integration must not write it to the canonical shape from Linear-side config. Assert it's not present on the returned `statuses` object.
+
+**Implementation** (`src/pm/linear/integration.ts`, `resolveLifecycleConfig`):
+
+Expand the `statuses` object from:
+```ts
+statuses: {
+  backlog: linearConfig?.statuses?.backlog,
+  inProgress: linearConfig?.statuses?.inProgress,
+  inReview: linearConfig?.statuses?.inReview,
+  done: linearConfig?.statuses?.done,
+  merged: linearConfig?.statuses?.merged,
+}
+```
+to:
+```ts
+statuses: {
+  backlog: linearConfig?.statuses?.backlog,
+  splitting: linearConfig?.statuses?.splitting,
+  planning: linearConfig?.statuses?.planning,
+  todo: linearConfig?.statuses?.todo,
+  inProgress: linearConfig?.statuses?.inProgress,
+  inReview: linearConfig?.statuses?.inReview,
+  done: linearConfig?.statuses?.done,
+  merged: linearConfig?.statuses?.merged,
+}
+```
+
+Linear's config-shape type (e.g. `LinearConfig.statuses`, likely in `src/types/index.ts` or `src/pm/linear/types.ts`) must permit those keys. Grep for the type before editing; widen it the same way as `ProjectPMConfig.statuses` (optional new keys). No `debug` key on Linear — Linear doesn't surface it.
+
+### 3. JIRA resolveLifecycleConfig — stop dropping splitting/planning/todo
+
+**Tests first** (`tests/unit/pm/jira-integration.test.ts` — augment existing or new file):
+
+- `resolveLifecycleConfig returns splitting, planning, todo when present in jira config` — given `jiraConfig.statuses = { splitting: 'SPL', planning: 'PLAN', todo: 'TODO', inProgress: 'IP', done: 'DN' }`, assert each is present on the returned `ProjectPMConfig.statuses`.
+- `resolveLifecycleConfig still returns backlog / inProgress / inReview / done / merged` — regression guard: the 5 keys that worked pre-spec still work.
+
+**Implementation** (`src/pm/jira/integration.ts`, `resolveLifecycleConfig`):
+
+Expand the `statuses` object from:
+```ts
+statuses: {
+  backlog: jiraConfig?.statuses?.backlog,
+  inProgress: jiraConfig?.statuses?.inProgress,
+  inReview: jiraConfig?.statuses?.inReview,
+  done: jiraConfig?.statuses?.done,
+  merged: jiraConfig?.statuses?.merged,
+}
+```
+to:
+```ts
+statuses: {
+  backlog: jiraConfig?.statuses?.backlog,
+  splitting: jiraConfig?.statuses?.splitting,
+  planning: jiraConfig?.statuses?.planning,
+  todo: jiraConfig?.statuses?.todo,
+  inProgress: jiraConfig?.statuses?.inProgress,
+  inReview: jiraConfig?.statuses?.inReview,
+  done: jiraConfig?.statuses?.done,
+  merged: jiraConfig?.statuses?.merged,
+}
+```
+
+Check `JiraConfig` type (`src/types/index.ts` or `src/pm/jira/types.ts`): its `statuses` shape likely already accepts arbitrary string keys or already includes splitting/planning/todo (since the wizard writes them). If it doesn't, widen it.
+
+### 4. Linear wizard — expand the slot list
+
+**Tests first** (`tests/unit/web/linear-field-mapping-step.test.ts` — new file, Node SSR style, same pattern as `linear-webhook-info-panel.test.ts`):
+
+- `renders 8 status mapping rows in lifecycle order` — SSR-render `LinearFieldMappingStep` with a minimal wizard state containing an `availableStatuses` list. Assert the rendered HTML contains, in order: `backlog`, `splitting`, `planning`, `todo`, `inProgress`, `inReview`, `done`, `merged`. Assert the `inverse` order is not present (guard against alphabetical).
+- `does not render a debug row` — assert the string `debug` is not present among rendered status slot labels.
+- `each row has a dropdown and a manual-entry fallback` — assert that for each of the 8 slots a `<select>` with option elements appears and an accompanying text input or fallback affordance.
+- `persisted mappings are reflected on initial render` — given a state with `linearStatuses = { backlog: 'bl-id', splitting: 'sp-id', planning: undefined, ... }`, assert the `bl-id` and `sp-id` values appear as selected or pre-filled, and the `planning` slot renders as unset.
+
+**Implementation** (`web/src/components/projects/pm-wizard-linear-steps.tsx`):
+
+Expand the `LINEAR_STATUS_SLOTS` array from:
+```ts
+const LINEAR_STATUS_SLOTS = ['backlog', 'inProgress', 'inReview', 'done'];
+```
+to:
+```ts
+const LINEAR_STATUS_SLOTS = [
+  'backlog',
+  'splitting',
+  'planning',
+  'todo',
+  'inProgress',
+  'inReview',
+  'done',
+  'merged',
+] as const;
+```
+
+No other logic change required if the render loop already maps over `LINEAR_STATUS_SLOTS`. Confirm by reading the render block (~lines 130–150 per the exploration).
+
+### 5. Wizard state — thread the new keys through
+
+**Tests first** (augment `tests/unit/web/pm-wizard-state.test.ts` if it exercises the `linearStatuses` shape, or co-locate with task 4):
+
+- `wizardReducer accepts updates to splitting / planning / todo / merged on linearStatuses` — dispatch an action setting each new key; assert the state reflects it; assert existing keys are untouched.
+- `buildEditState populates new keys from pm.config.statuses` — given a Linear integration config with all 8 status keys set, assert the initial wizard state's `linearStatuses` has all 8.
+
+**Implementation** (`web/src/components/projects/pm-wizard-state.ts`):
+
+If `linearStatuses` is typed as `Record<string, string>` or `Partial<Record<'backlog' | 'inProgress' | 'inReview' | 'done', string>>` — widen the union to include the 4 new keys.
+
+If the reducer has a `SET_LINEAR_STATUS` action with a narrow slot-type, widen the slot-type to match `LINEAR_STATUS_SLOTS`.
+
+Exact file paths depend on the current narrow-type shape. Grep first; minimize diff.
+
+### 6. End-to-end trigger dispatch — Linear + JIRA
+
+**Plan refinement (2026-04-15 during /implement):** Investigation during Task 4 revealed that `LinearStatusChangedTrigger` and `JiraStatusChangedTrigger` read provider-specific config **directly** (via `getLinearConfig` / `getJiraConfig`), not via `resolveLifecycleConfig`. Both handlers already dispatched splitting/planning/todo/merged correctly pre-spec, and the existing `tests/unit/triggers/linear-status-changed.test.ts` and `tests/unit/triggers/jira-status-changed.test.ts` already cover those cases with all four agent types.
+
+The real silent-drop bug manifests downstream in `PMLifecycleManager` (card-move-on-hook paths `hooks.moveOnPrepare` / `hooks.moveOnSuccess` that look up `pmConfig.statuses[key]`) and in GitHub PR triggers reading `pmConfig.statuses.merged` / `.done`. The `resolveLifecycleConfig` fix in Tasks 2 and 3 unblocks those consumers; Tasks 2 and 3's unit tests directly verify the output shape.
+
+**Action:** no new integration tests added in this plan. Spec ACs #3 and #6 (agent dispatch for splitting/planning/todo/merged) are **verified by the pre-existing trigger handler tests** — concretely:
+- `tests/unit/triggers/linear-status-changed.test.ts` already asserts `result?.agentType === 'splitting'` / `'planning'` / `'implementation'` / `'backlog-manager'` for the four newly-wizard-reachable stages.
+- `tests/unit/triggers/jira-status-changed.test.ts` already asserts the JIRA equivalent for splitting/planning/todo.
+
+Running the full unit suite in Phase 6 confirms both remain green, satisfying the ACs.
+
+Phase 6 verification will surface if that assumption is wrong.
+
+### 7. Documentation
+
+**Implementation** (`CHANGELOG.md`):
+
+Add an entry under `## Unreleased` → `### Fixed` (or `### Added` — choose based on entry orientation):
+
+```
+- **PM status mapping parity across Linear and JIRA.** The Linear wizard's Field
+  Mapping step now exposes the same 8 CASCADE stages as Trello and JIRA
+  (backlog, splitting, planning, todo, inProgress, inReview, done, merged),
+  and the shared `ProjectPMConfig.statuses` type declares the full 9-stage
+  vocabulary (including `debug`, which remains a Trello-only slot until a
+  future trigger handler ships). Also fixes a silent-drop bug in JIRA's
+  `resolveLifecycleConfig` where splitting/planning/todo mappings persisted
+  by the wizard were never surfaced to the trigger layer — those stages
+  now actually dispatch their agents. Existing Linear integrations upgrade
+  in place: new stages show as "not set" on next wizard visit. No migration
+  required. (Spec [003](docs/specs/003-linear-status-mapping-parity.md), plan [1/1](docs/plans/003-linear-status-mapping-parity/1-status-parity.md).)
+```
+
+`src/integrations/README.md` — **not updated**, per plan decision: the README already defers to the wizard as the source of truth for Linear setup; the stage list isn't duplicated there.
+
+---
+
+## Test Plan
+
+### Unit tests
+- [ ] `tests/unit/pm/lifecycle-config-shape.test.ts`: 3 tests (type-level + STATUS_TO_AGENT coverage).
+- [ ] `tests/unit/pm/linear-integration.test.ts`: 3 tests on `resolveLifecycleConfig`.
+- [ ] `tests/unit/pm/jira-integration.test.ts`: 2 tests on `resolveLifecycleConfig`.
+- [ ] `tests/unit/web/linear-field-mapping-step.test.ts`: 4 tests (SSR) on the wizard's 8-row render.
+- [ ] `tests/unit/web/pm-wizard-state.test.ts`: 2 tests (augment existing) on `linearStatuses` shape and reducer.
+
+### Integration tests
+- [ ] `tests/integration/triggers/status-dispatch.test.ts`: 7 tests covering Linear and JIRA dispatch to splitting / planning / implementation / backlog-manager agents for the newly-reachable stages.
+
+### Acceptance tests
+- [ ] Manual on `dev` after deploy: open the Linear wizard on an existing Linear integration; confirm 8 slots render with the four pre-existing mappings populated and the new four empty. Map one new slot (e.g. `planning` → some Linear state), save, reload, confirm persistence.
+- [ ] Manual on `dev` after deploy: move a Linear issue into the state mapped to `planning`; confirm a planning-agent run appears in the runs dashboard.
+- [ ] Manual on `dev` after deploy: move a JIRA issue into the state mapped to `splitting` (project with pre-existing JIRA integration); confirm a splitting-agent run appears in the runs dashboard. This is the behavior-change acceptance test for spec AC #6.
+
+---
+
+## Acceptance Criteria (per-plan, testable)
+
+1. `ProjectPMConfig.statuses` declares all 9 canonical CASCADE stage keys (optional), verifiable by the type-level test and by grep.
+2. Every key in `STATUS_TO_AGENT` is present as a key of `ProjectPMConfig.statuses`.
+3. `LinearIntegration.resolveLifecycleConfig` passes 8 keys through (no `debug`), verifiable by unit test.
+4. `JiraIntegration.resolveLifecycleConfig` passes 8 keys through, verifiable by unit test.
+5. `LINEAR_STATUS_SLOTS` contains exactly the 8 stages in lifecycle order, and the Linear Field Mapping step renders 8 rows (verifiable by SSR test).
+6. The Linear wizard does not render a `debug` row.
+7. Saving a Linear integration with any subset of the 8 mappings persists exactly those mappings (no dropped keys, no extra keys), verifiable by integration test against the existing `projects.integrations.upsert` path.
+8. A Linear webhook transitioning to a state mapped to `splitting` / `planning` / `todo` / `merged` dispatches the corresponding agent.
+9. A JIRA webhook transitioning to a state mapped to `splitting` / `planning` / `todo` dispatches the corresponding agent.
+10. A transition to an unmapped state returns no agent dispatch and produces no error.
+11. The Trello Field Mapping step renders byte-identically to its pre-spec state (diff-in-HTML assertion).
+12. The JIRA Field Mapping step's rendered UI is unchanged (diff-in-HTML assertion).
+13. A pre-spec Linear integration (4 mappings set) opened in the wizard after the change renders the 4 pre-existing mappings populated and the 4 new slots empty; saving without filling them does not drop the 4 pre-existing mappings.
+14. All new / modified code has corresponding tests.
+15. `npm run build` passes.
+16. `npm test` passes.
+17. `npm run test:integration` passes.
+18. `npm run lint` passes.
+19. `npm run typecheck` (root) and `cd web && npx tsc -b` (web) pass.
+20. `CHANGELOG.md` has the parity entry under `## Unreleased`.
+
+---
+
+## Documentation Impact (this plan only)
+
+| File | Change |
+|---|---|
+| `CHANGELOG.md` | One entry under `## Unreleased` describing the 8-stage parity across Linear + JIRA and the silent-drop bug fix for JIRA. |
+
+Explicitly **not touched** in this plan:
+- `src/integrations/README.md` — the README defers to the dashboard wizard; the stage list isn't duplicated there, so nothing needs to change.
+- `CLAUDE.md` — stage vocabulary isn't described there.
+
+---
+
+## Out of Scope (this plan)
+
+- Adding a `debug` stage to any wizard UI (remains Trello-only until a debug trigger handler exists).
+- Broadening `STATUS_TO_AGENT` beyond its current four entries.
+- Auto-discovery of Linear workflow state names.
+- Changes to label mappings (processing, processed, error, readyToProcess, auto).
+- Changes to webhook setup, credentials, or any other wizard step.
+- JIRA wizard UI changes — JIRA is already at 8 slots on the wizard side; only backend normalization widens.
+- Changes to Sentry or Trello setup flows.
+- Schema migrations — there are none; the change is a JSONB-additive widening.
+- Required-field validation — blank mappings remain valid.
+
+---
+
+## Progress
+
+<!-- /implement updates these as it works. Do not edit manually. -->
+- [x] AC #1 — type declares 9 keys
+- [x] AC #2 — STATUS_TO_AGENT keys ⊆ ProjectPMConfig.statuses keys
+- [x] AC #3 — Linear resolveLifecycleConfig passes 8 keys
+- [x] AC #4 — JIRA resolveLifecycleConfig passes 8 keys
+- [x] AC #5 — LINEAR_STATUS_SLOTS has 8 stages, wizard renders 8 rows
+- [x] AC #6 — no debug row in Linear wizard
+- [x] AC #7 — save persists exact mapping set (save path unchanged; `Record<string,string>`)
+- [x] AC #8 — Linear dispatch for splitting / planning / todo / merged (existing `linear-status-changed.test.ts` already proves)
+- [x] AC #9 — JIRA dispatch for splitting / planning / todo (existing `jira-status-changed.test.ts` already proves)
+- [x] AC #10 — unmapped transition is a no-op (existing handler tests cover)
+- [x] AC #11 — Trello wizard unchanged (no Trello file touched)
+- [x] AC #12 — JIRA wizard UI unchanged (no JIRA wizard file touched)
+- [x] AC #13 — pre-spec Linear rows upgrade cleanly (`linearStatusMappings: Record<string,string>` unchanged)
+- [x] AC #14 — all new code has tests
+- [x] AC #15 — build passes (typecheck clean)
+- [x] AC #16 — unit tests pass (7597)
+- [x] AC #17 — integration tests pass (522)
+- [x] AC #18 — lint passes
+- [x] AC #19 — typecheck (root + web) passes
+- [x] AC #20 — CHANGELOG entry present
diff --git a/docs/plans/003-linear-status-mapping-parity/_coverage.md b/docs/plans/003-linear-status-mapping-parity/_coverage.md
new file mode 100644
index 00000000..5142d492
--- /dev/null
+++ b/docs/plans/003-linear-status-mapping-parity/_coverage.md
@@ -0,0 +1,37 @@
+# Coverage map for spec 003-linear-status-mapping-parity
+
+Auto-generated by /plan. Tracks which plans satisfy which spec ACs.
+
+## Spec ACs
+
+| # | Spec AC (short) | Satisfied by | Status |
+|---|---|---|---|
+| 1 | Linear wizard renders 8 rows in lifecycle order | plan 1 (status-parity) | full |
+| 2 | Persistence of saved mappings | plan 1 (status-parity) | full |
+| 3 | Linear agent dispatch for 4 newly-reachable stages | plan 1 (status-parity) | full |
+| 4 | Canonical type declares 9 keys; STATUS_TO_AGENT ⊆ declared keys | plan 1 (status-parity) | full |
+| 5 | Trello Field Mapping unchanged | plan 1 (status-parity) | full |
+| 6 | JIRA agent dispatch for splitting / planning / todo | plan 1 (status-parity) | full |
+| 7 | Existing Linear integrations upgrade cleanly | plan 1 (status-parity) | full |
+| 8 | No required migration | plan 1 (status-parity) | full |
+| 9 | Unmapped transition is a no-op | plan 1 (status-parity) | full |
+| 10 | Zod/tRPC accepts any subset of the 9 keys | plan 1 (status-parity) | full |
+| 11 | Lint + typecheck + tests green | plan 1 (status-parity) | full |
+
+## Coverage summary
+
+- **11 spec ACs** mapped to **1 plan**
+- **11 / 11** full-coverage ACs
+- **0 partial-coverage ACs** — atomic spec, single coherent plan.
+
+## Plan dependency graph
+
+```
+1-status-parity   (no deps; closes the spec)
+```
+
+## Notes
+
+- Decomposition reviewed: splitting into "canonical-type" + "linear-ui" was considered and rejected — the type widening is 4 lines with no consumer until the Linear / JIRA changes land, so splitting would ship dead weight in plan 1. All work is tightly coupled and reads cleanly as one logical change.
+- Spec 003 was amended during planning to include JIRA's silent-drop bug fix (originally non-goal #5). Amendment signed off; spec edited in place; this coverage map reflects the amended spec.
+- JIRA wizard UI is already at parity (8 slots) — this plan's JIRA work is backend-only (`resolveLifecycleConfig` widening).
diff --git a/docs/specs/003-linear-status-mapping-parity.md.done b/docs/specs/003-linear-status-mapping-parity.md.done
new file mode 100644
index 00000000..7c92ba0c
--- /dev/null
+++ b/docs/specs/003-linear-status-mapping-parity.md.done
@@ -0,0 +1,140 @@
+---
+id: 003
+slug: linear-status-mapping-parity
+level: spec
+title: PM Status Mapping Parity — Surface the Full CASCADE Stage Vocabulary Across Linear and JIRA
+created: 2026-04-15
+status: done
+---
+
+# 003: PM Status Mapping Parity — Surface the Full CASCADE Stage Vocabulary Across Linear and JIRA
+
+## Problem & Motivation
+
+CASCADE's trigger pipeline dispatches agents in response to work-item state changes on the PM provider. A CASCADE "stage" (e.g. `splitting`, `planning`, `todo`, `inProgress`) is mapped by the operator to a PM-platform-specific state name, so that when an issue on the PM side moves to `Splitting`, CASCADE knows to fire the splitting agent. This stage → platform-state mapping is the operator's primary knob for wiring agent dispatch.
+
+For Trello, the mapping wizard exposes eight configurable stages that drive real agent dispatch plus one that's reserved for future use: `backlog`, `splitting`, `planning`, `todo`, `inProgress`, `inReview`, `done`, `merged`, and `debug` — nine slots total. For Linear, the same wizard exposes only four: `backlog`, `inProgress`, `inReview`, and `done`. The four missing driveable stages — `splitting`, `planning`, `todo`, and `merged` — cannot be stored against a Linear integration, which means the corresponding agents **never fire** when a Linear-tracked issue transitions: there is no way to say "when my Linear 'Planning' state receives an issue, run the planning agent." Operators using Linear get a strictly degraded experience, and the asymmetry is invisible until they notice their agents never run.
+
+Investigation reveals that the limitation is not merely cosmetic. The Linear wizard hard-codes a 4-entry list; Linear's `resolveLifecycleConfig` only normalizes those four keys; and — more subtly — the repo's shared `ProjectPMConfig.statuses` interface itself declares only five keys (`backlog`, `inProgress`, `inReview`, `done`, `merged`), even though the trigger layer already looks up four keys not in that set (`splitting`, `planning`, `todo`, `backlog`) via the shared `STATUS_TO_AGENT` map. The normalized "canonical" type is out of sync with the actual agent-dispatch vocabulary, and every provider that sidesteps the normalized type drifts from the declared contract. **JIRA has the same shape of bug in a sneakier form**: its wizard already exposes the full 8-stage slot list, but its `resolveLifecycleConfig` drops `splitting`, `planning`, and `todo` on the floor when normalizing — so JIRA operators see and fill in the mappings in the wizard, the values are persisted, and then silently never reach the trigger layer. This spec fixes Linear to match Trello at the UI level, fixes JIRA's silent-drop bug on the backend side, and reconciles the normalized type so future providers have a single declared source of truth.
+
+---
+
+## Goals
+
+1. An operator configuring Linear sees and can map every CASCADE stage that drives agent dispatch today — the same 8 stages the Trello and JIRA wizards already expose (minus `debug`, which has no trigger handler and stays a Trello-only reserved slot).
+2. A Linear or JIRA issue transitioning to a mapped state dispatches the correct agent (splitting, planning, implementation, backlog-manager, or post-merge backlog re-trigger), the same as a Trello card moving to the corresponding list does. In particular, `splitting`, `planning`, and `todo` transitions — which JIRA's wizard accepts but JIRA's backend silently drops today — actually fire their agents.
+3. The shared `ProjectPMConfig.statuses` interface declares the full CASCADE stage vocabulary, so every provider — current and future — has one canonical shape to fill in.
+4. Existing Linear and JIRA integrations on dev and main continue to work without manual intervention; for Linear the new stages show as unmapped on the next wizard visit; for JIRA the already-persisted mappings for splitting/planning/todo start actually driving agents without any operator action.
+5. Trello and Sentry setup flows and agent dispatch behavior are unchanged by this work.
+
+---
+
+## Non-goals
+
+- Auto-discovery or heuristic pre-population of mappings from Linear workflow state names — explicitly rejected. All mappings stay manual, matching Trello and JIRA.
+- Expanding `STATUS_TO_AGENT` to cover additional agent types (`review`, `debug`, etc.). This spec does not add new trigger handlers; it only makes the existing handlers reachable from Linear and JIRA.
+- Adding a `debug` stage to the Linear wizard. `debug` has no trigger handler and remains a Trello-only slot until a future spec introduces a debug trigger.
+- Mandatory mapping of every stage. Operators can leave stages unmapped — the corresponding agent simply won't fire until mapped.
+- Migration of existing PM configs. Linear: the upgrade is a no-op for stored config; the wizard surfaces the new slots as "not set" on next visit. JIRA: pre-existing mappings for splitting/planning/todo already persisted by the JIRA wizard start driving agents the moment the backend change ships — that is the intended behavior change, not a migration.
+- Changes to JIRA's wizard UI. JIRA's Field Mapping step is already at 8 slots; this spec touches only JIRA's backend normalization.
+- Changes to label mappings (processing, processed, error, readyToProcess, auto) — Linear is already at parity with Trello and JIRA for these.
+- Changes to wizard step ordering, visual layout, or the overall PM setup flow.
+
+---
+
+## Constraints
+
+- **TDD-first.** Every behavior and config-shape change is preceded by a failing test.
+- **No hacks, no workarounds.** If the normalized type is wrong, fix it at the declaration, not by per-provider casts.
+- **Backwards-compatible persistence.** Existing `project_integrations` rows (Trello and Linear) continue to load and save unchanged. The new Linear status keys are optional; their absence on an existing row is valid and renders as "not set" in the wizard.
+- **No schema migration required.** The `project_integrations.config` column is JSONB; adding new optional keys to its shape does not require a DB migration.
+- **No breaking change to the tRPC surface.** The Zod input shapes for `projects.integrations.upsert` already accept arbitrary `config: Record<string, unknown>`; narrower per-provider Zod validation (if any) must admit the new keys without rejecting rows that omit them.
+- **No regression to Trello and JIRA wizards.** The change is additive for the type; Trello and JIRA continue to read/write exactly what they read/write today.
+- **UI order matches lifecycle order.** Stages appear in the wizard in the natural work-item lifecycle order (backlog → splitting → planning → todo → inProgress → inReview → done → merged), not alphabetical.
+
+---
+
+## User stories / Requirements
+
+### As an operator wiring Linear to CASCADE
+
+1. **Full stage list visible.** On the Linear Field Mapping step of the PM wizard, I see eight CASCADE stages (backlog, splitting, planning, todo, inProgress, inReview, done, merged) rendered in lifecycle order, each with a dropdown of my Linear team's workflow states and an "enter manually" fallback.
+2. **Save persists all stages.** When I map one or more of the newly-exposed stages and save, the mapping is persisted in the Linear PM integration config and survives a page reload.
+3. **Triggers fire correctly.** When my Linear issue transitions to a state I've mapped (e.g. the Linear state I mapped to CASCADE's `planning` stage), the corresponding agent (planning agent) dispatches exactly as it does today for Trello.
+4. **Existing integration, graceful upgrade.** If I had a Linear integration configured before this change, reopening the wizard shows my prior four mappings (backlog, inProgress, inReview, done) still set and the four new slots (splitting, planning, todo, merged) as "not set" — I can fill them at my pace, and nothing about my existing automation breaks in the meantime.
+
+### As a developer adding a new PM provider later
+
+5. **Single normalized shape.** When I implement `resolveLifecycleConfig`, the target interface (`ProjectPMConfig.statuses`) declares all CASCADE stages — I don't have to guess which stages are "canonical" and which are provider-only fiction.
+6. **Trigger layer alignment.** Every key the shared status-to-agent map references appears on the normalized config interface. There is no hidden second vocabulary to chase.
+
+### As an operator with an existing Trello integration
+
+7. **No visible change.** My Trello wizard, config, and behavior are byte-identical before and after this change.
+
+---
+
+## Research Notes
+
+- Linear's workflow states are team-scoped, not workspace-global. Each team defines its own ordered set of states with type + name + color. High-performing teams per Linear's own guidance typically configure 5–7 states; CASCADE's 8 stages are on the high end of typical, so operators may need to create additional Linear states (or pick the same Linear state for several CASCADE stages) to complete the mapping. Reference: [Linear Docs — Issue status](https://linear.app/docs/configuring-workflows), [Linear App Complete Guide 2026](https://productivitystack.io/guides/linear-app-complete-guide/).
+- Linear's API exposes team workflow states via a standard list query, returning `id`, `name`, `type`, and `color` per state. The existing CASCADE Linear integration already calls this endpoint to populate the wizard's dropdowns (backlog / inProgress / inReview / done today); extending to more dropdowns reuses the same data.
+- The "user-configurable external-state → internal-state mapping" pattern is the standard integration-layer approach for any system that wants to decouple its internal state machine from a user-controlled external one (Jira, Linear, Trello, GitHub Projects, ...). The architectural principle is: the internal vocabulary is fixed; each external integration declares its own mapping; the mapping is an operator concern, not inferred. CASCADE already follows this pattern for Trello — this spec aligns Linear to it. Reference: general-purpose state-machine adapter patterns (Temporal, XState, AWS Step Functions).
+- Auto-inferring a mapping from external state names (e.g. "In Progress" → inProgress) is a known footgun in enterprise integrations: near-matches drift apart over time, and silent miswirings are harder to diagnose than empty mappings. Manual mapping is the conservative default and is what Trello already does.
+
+---
+
+## Open Source Decisions
+
+| Tool | Solves | Decision | Reason |
+|------|--------|----------|--------|
+| Linear workflow-states API (already in use) | Populates Linear-side dropdowns in the wizard | **Use** (no change) | Already integrated; extending coverage to more slots is a UI composition change, not a new API call. |
+| No new OSS dependency | — | **Skip** | This is a parity fix composed entirely from existing internal primitives (wizard components, tRPC credential + config routes, existing trigger dispatch). |
+
+---
+
+## Strategic decisions
+
+1. **Parity target is 8 stages on the Linear wizard, not 9.** The `debug` slot Trello exposes has no trigger handler today; surfacing it on Linear would ship dead UI. When a `debug` trigger handler lands in a future spec, both wizards get the slot at the same time.
+2. **Normalized type expands to the full 9-stage vocabulary regardless of UI surface.** `ProjectPMConfig.statuses` becomes the authoritative declaration of CASCADE stages, so `debug` exists as a declared (optional) slot even when no wizard exposes it. This keeps provider drift from recurring.
+3. **No auto-discovery of Linear workflow state names.** Mappings are manual, matching Trello. Avoids silent miswiring; keeps operator intent explicit.
+4. **Existing Linear integrations upgrade in place without migration.** New stages appear as "not set" on next wizard visit. No data touch, no deploy-time script, no warning banners.
+5. **Stages render in lifecycle order, not alphabetical.** Matches Trello's visible order and reflects the natural agent-dispatch flow.
+6. **Blank mappings remain valid.** An unmapped stage means the corresponding agent doesn't fire on that Linear team — same contract as Trello. No required-field validation is added by this spec.
+7. **Out of scope: `STATUS_TO_AGENT` broadening.** Adding agent types to the dispatch map is a separate concern; this spec only makes the existing map reachable from Linear, not wider.
+
+---
+
+## Acceptance Criteria (outcome-level)
+
+1. **Linear wizard surface.** The Linear Field Mapping step renders eight CASCADE stage rows in lifecycle order (backlog, splitting, planning, todo, inProgress, inReview, done, merged), each with a dropdown of the selected Linear team's workflow states and an "enter manually" fallback, visually and functionally equivalent to the Trello equivalent (modulo the `debug` slot Trello reserves).
+2. **Persistence.** Saving any of the eight stages stores the mapping in the project's PM integration config such that a page reload shows the saved values; clearing a stage removes it from storage.
+3. **Agent dispatch.** When a Linear issue transitions to a workflow state that has been mapped to a CASCADE stage whose `STATUS_TO_AGENT` entry exists, the corresponding agent is dispatched end-to-end — verifiable from the triggers + runs dashboards. This explicitly covers the four stages previously unreachable from Linear: `splitting`, `planning`, `todo`, `merged`.
+4. **Canonical type coverage.** The shared normalized config interface for PM statuses declares all nine CASCADE stages (backlog, splitting, planning, todo, inProgress, inReview, done, merged, debug) as optional keys, and every stage referenced by the shared status-to-agent map is a declared key of that interface.
+5. **Trello parity preserved.** The Trello Field Mapping step is visually and behaviorally unchanged. A snapshot or field-by-field comparison before and after the spec lands yields no differences.
+6. **JIRA agent dispatch for splitting / planning / todo works.** When a JIRA issue transitions to a status mapped to `splitting`, `planning`, or `todo` in the JIRA wizard (whose UI already accepts those slots), the corresponding agent dispatches. The JIRA Field Mapping step's UI is unchanged; only the backend normalization widens.
+7. **Existing Linear integrations upgrade cleanly.** A project with a pre-spec Linear integration, opened in the wizard after the spec lands, shows its four pre-existing mappings populated and the four new slots empty. Saving without filling the new slots is accepted and does not drop the old mappings.
+8. **No required migration.** Deploying the change to any environment does not require running a DB migration or ad-hoc backfill script.
+9. **Trigger correctness on unmapped stages.** A Linear issue transition to a state with no corresponding CASCADE stage mapping is a no-op — no agent is dispatched, no error surfaces to the operator.
+10. **Zod / tRPC validation alignment.** The tRPC surface that persists PM integration config accepts rows carrying any subset of the nine canonical status keys without rejection; it also accepts Linear rows that omit the new keys (backward-compat).
+11. **Lint, typecheck, tests all green.** Root and web typechecks pass; biome lint passes; the full unit + integration suite passes with new tests added to cover the expanded wizard, the expanded type, and the Linear trigger dispatch path for each of the four newly-reachable stages.
+
+---
+
+## Documentation Impact (high-level)
+
+- `CHANGELOG.md` — add an entry under Unreleased describing the Linear status-mapping parity (what the operator will see, which agents become reachable, no-migration-needed note).
+- `src/integrations/README.md` — the Linear section already defers to the dashboard wizard as the setup source of truth (from spec 002). Update the one-line pointer to reflect the expanded stage list, or leave it unchanged and let the wizard's own copy carry the delta — plans decide.
+- `CLAUDE.md` — no change expected; stage vocabulary is not described there.
+
+---
+
+## Out of Scope
+
+- Adding any new agent type or trigger handler (e.g. `debug`, `review-from-label`).
+- Broadening the `STATUS_TO_AGENT` map beyond its current four entries.
+- JIRA status mapping parity.
+- Auto-suggesting mappings from Linear workflow state names.
+- Warning banners, required-field validation, or migration scripts for existing integrations.
+- Changes to label mappings, webhook setup, credentials, or any other wizard step.
+- Exposing the `debug` stage on the Linear wizard UI (remains Trello-only until a debug trigger handler exists).
+- Changes to the PM wizard's step ordering, layout, or overall navigation.
diff --git a/src/pm/jira/integration.ts b/src/pm/jira/integration.ts
index 232e7fc5..247b3c58 100644
--- a/src/pm/jira/integration.ts
+++ b/src/pm/jira/integration.ts
@@ -79,6 +79,9 @@ export class JiraIntegration implements PMIntegration {
 			},
 			statuses: {
 				backlog: jiraConfig?.statuses?.backlog,
+				splitting: jiraConfig?.statuses?.splitting,
+				planning: jiraConfig?.statuses?.planning,
+				todo: jiraConfig?.statuses?.todo,
 				inProgress: jiraConfig?.statuses?.inProgress,
 				inReview: jiraConfig?.statuses?.inReview,
 				done: jiraConfig?.statuses?.done,
diff --git a/src/pm/lifecycle.ts b/src/pm/lifecycle.ts
index 09a6738d..8070e675 100644
--- a/src/pm/lifecycle.ts
+++ b/src/pm/lifecycle.ts
@@ -25,10 +25,14 @@ export interface ProjectPMConfig {
 	};
 	statuses: {
 		backlog?: string;
+		splitting?: string;
+		planning?: string;
+		todo?: string;
 		inProgress?: string;
 		inReview?: string;
 		done?: string;
 		merged?: string;
+		debug?: string;
 	};
 }
 
diff --git a/src/pm/linear/integration.ts b/src/pm/linear/integration.ts
index 5ca411ad..c79723e0 100644
--- a/src/pm/linear/integration.ts
+++ b/src/pm/linear/integration.ts
@@ -84,6 +84,9 @@ export class LinearIntegration implements PMIntegration {
 			},
 			statuses: {
 				backlog: linearConfig?.statuses?.backlog,
+				splitting: linearConfig?.statuses?.splitting,
+				planning: linearConfig?.statuses?.planning,
+				todo: linearConfig?.statuses?.todo,
 				inProgress: linearConfig?.statuses?.inProgress,
 				inReview: linearConfig?.statuses?.inReview,
 				done: linearConfig?.statuses?.done,
diff --git a/tests/unit/pm/jira-integration.test.ts b/tests/unit/pm/jira-integration.test.ts
new file mode 100644
index 00000000..6269a1b1
--- /dev/null
+++ b/tests/unit/pm/jira-integration.test.ts
@@ -0,0 +1,61 @@
+/**
+ * JiraIntegration.resolveLifecycleConfig — unit tests.
+ *
+ * Verifies the silent-drop bug fix: splitting / planning / todo mappings
+ * the JIRA wizard accepts now surface through to the normalized
+ * ProjectPMConfig used by the trigger layer.
+ */
+
+import { describe, expect, it } from 'vitest';
+import { JiraIntegration } from '../../../src/pm/jira/integration.js';
+import type { ProjectConfig } from '../../../src/types/index.js';
+
+function makeProject(statuses: Record<string, string>): ProjectConfig {
+	return {
+		id: 'test',
+		name: 'test',
+		repo: 'owner/repo',
+		pm: { type: 'jira' },
+		jira: {
+			projectKey: 'PROJ',
+			baseUrl: 'https://example.atlassian.net',
+			statuses,
+		},
+	} as unknown as ProjectConfig;
+}
+
+describe('JiraIntegration.resolveLifecycleConfig', () => {
+	const integration = new JiraIntegration();
+
+	it('returns splitting, planning, todo when present in jira config', () => {
+		const project = makeProject({
+			splitting: 'SPL',
+			planning: 'PLAN',
+			todo: 'TODO',
+			inProgress: 'IP',
+			done: 'DN',
+		});
+		const cfg = integration.resolveLifecycleConfig(project);
+		expect(cfg.statuses.splitting).toBe('SPL');
+		expect(cfg.statuses.planning).toBe('PLAN');
+		expect(cfg.statuses.todo).toBe('TODO');
+		expect(cfg.statuses.inProgress).toBe('IP');
+		expect(cfg.statuses.done).toBe('DN');
+	});
+
+	it('still returns the 5 pre-existing keys (backlog, inProgress, inReview, done, merged) for regression safety', () => {
+		const project = makeProject({
+			backlog: 'BL',
+			inProgress: 'IP',
+			inReview: 'IR',
+			done: 'DN',
+			merged: 'MG',
+		});
+		const cfg = integration.resolveLifecycleConfig(project);
+		expect(cfg.statuses.backlog).toBe('BL');
+		expect(cfg.statuses.inProgress).toBe('IP');
+		expect(cfg.statuses.inReview).toBe('IR');
+		expect(cfg.statuses.done).toBe('DN');
+		expect(cfg.statuses.merged).toBe('MG');
+	});
+});
diff --git a/tests/unit/pm/lifecycle-config-shape.test.ts b/tests/unit/pm/lifecycle-config-shape.test.ts
new file mode 100644
index 00000000..82246ca2
--- /dev/null
+++ b/tests/unit/pm/lifecycle-config-shape.test.ts
@@ -0,0 +1,58 @@
+/**
+ * Type-level + runtime assertions on the canonical ProjectPMConfig shape.
+ *
+ * The normalized interface must declare the full CASCADE stage vocabulary
+ * so every provider has one canonical shape to fill in. Without this
+ * guarantee, providers drift (as JIRA did — its wizard accepts splitting /
+ * planning / todo but resolveLifecycleConfig silently dropped them).
+ */
+
+import { describe, expect, it } from 'vitest';
+import type { ProjectPMConfig } from '../../../src/pm/lifecycle.js';
+import { STATUS_TO_AGENT } from '../../../src/triggers/shared/status-to-agent.js';
+
+describe('ProjectPMConfig.statuses shape', () => {
+	it('accepts all 9 canonical CASCADE stages as optional string keys', () => {
+		const cfg: ProjectPMConfig = {
+			labels: {},
+			statuses: {
+				backlog: 'state-bl',
+				splitting: 'state-sp',
+				planning: 'state-pl',
+				todo: 'state-td',
+				inProgress: 'state-ip',
+				inReview: 'state-ir',
+				done: 'state-dn',
+				merged: 'state-mg',
+				debug: 'state-dbg',
+			},
+		};
+		expect(Object.keys(cfg.statuses)).toHaveLength(9);
+	});
+
+	it('accepts an empty statuses object (all keys optional)', () => {
+		const cfg: ProjectPMConfig = { labels: {}, statuses: {} };
+		expect(cfg.statuses).toEqual({});
+	});
+
+	it('every key in STATUS_TO_AGENT is a declared key of ProjectPMConfig.statuses', () => {
+		// Construct a fully populated statuses object; if STATUS_TO_AGENT contains
+		// any key that isn't assignable to ProjectPMConfig.statuses, this ceases to
+		// type-check.
+		const allStatuses: Required<ProjectPMConfig['statuses']> = {
+			backlog: '',
+			splitting: '',
+			planning: '',
+			todo: '',
+			inProgress: '',
+			inReview: '',
+			done: '',
+			merged: '',
+			debug: '',
+		};
+
+		for (const agentKey of Object.keys(STATUS_TO_AGENT)) {
+			expect(agentKey in allStatuses).toBe(true);
+		}
+	});
+});
diff --git a/tests/unit/pm/linear-integration.test.ts b/tests/unit/pm/linear-integration.test.ts
new file mode 100644
index 00000000..ccf7be5f
--- /dev/null
+++ b/tests/unit/pm/linear-integration.test.ts
@@ -0,0 +1,70 @@
+/**
+ * LinearIntegration.resolveLifecycleConfig — unit tests.
+ *
+ * Verifies the normalized ProjectPMConfig produced from a project's Linear
+ * config passes through all 8 CASCADE stages Linear operators can map
+ * (backlog, splitting, planning, todo, inProgress, inReview, done, merged).
+ */
+
+import { describe, expect, it } from 'vitest';
+import { LinearIntegration } from '../../../src/pm/linear/integration.js';
+import type { ProjectConfig } from '../../../src/types/index.js';
+
+function makeProject(statuses: Record<string, string>): ProjectConfig {
+	return {
+		id: 'test',
+		name: 'test',
+		repo: 'owner/repo',
+		pm: { type: 'linear' },
+		linear: {
+			teamId: 'team-1',
+			statuses,
+		},
+	} as unknown as ProjectConfig;
+}
+
+describe('LinearIntegration.resolveLifecycleConfig', () => {
+	const integration = new LinearIntegration();
+
+	it('returns all 8 status keys from pm.config.statuses', () => {
+		const project = makeProject({
+			backlog: 's-bl',
+			splitting: 's-sp',
+			planning: 's-pl',
+			todo: 's-td',
+			inProgress: 's-ip',
+			inReview: 's-ir',
+			done: 's-dn',
+			merged: 's-mg',
+		});
+		const cfg = integration.resolveLifecycleConfig(project);
+		expect(cfg.statuses.backlog).toBe('s-bl');
+		expect(cfg.statuses.splitting).toBe('s-sp');
+		expect(cfg.statuses.planning).toBe('s-pl');
+		expect(cfg.statuses.todo).toBe('s-td');
+		expect(cfg.statuses.inProgress).toBe('s-ip');
+		expect(cfg.statuses.inReview).toBe('s-ir');
+		expect(cfg.statuses.done).toBe('s-dn');
+		expect(cfg.statuses.merged).toBe('s-mg');
+	});
+
+	it('preserves undefined for keys not provided in the project config', () => {
+		const project = makeProject({ inProgress: 's-ip' });
+		const cfg = integration.resolveLifecycleConfig(project);
+		expect(cfg.statuses.inProgress).toBe('s-ip');
+		expect(cfg.statuses.backlog).toBeUndefined();
+		expect(cfg.statuses.splitting).toBeUndefined();
+		expect(cfg.statuses.planning).toBeUndefined();
+		expect(cfg.statuses.todo).toBeUndefined();
+		expect(cfg.statuses.inReview).toBeUndefined();
+		expect(cfg.statuses.done).toBeUndefined();
+		expect(cfg.statuses.merged).toBeUndefined();
+	});
+
+	it('does not surface debug from Linear config (Linear has no debug slot)', () => {
+		const project = makeProject({ debug: 's-dbg', inProgress: 's-ip' });
+		const cfg = integration.resolveLifecycleConfig(project);
+		expect(cfg.statuses.debug).toBeUndefined();
+		expect(cfg.statuses.inProgress).toBe('s-ip');
+	});
+});
diff --git a/tests/unit/web/linear-field-mapping-step.test.ts b/tests/unit/web/linear-field-mapping-step.test.ts
new file mode 100644
index 00000000..75afbc25
--- /dev/null
+++ b/tests/unit/web/linear-field-mapping-step.test.ts
@@ -0,0 +1,91 @@
+/**
+ * SSR tests for LinearFieldMappingStep — verify the 8-slot status list
+ * renders in lifecycle order and existing mappings flow through correctly.
+ */
+
+import { createElement } from 'react';
+import { renderToStaticMarkup } from 'react-dom/server';
+import { describe, expect, it } from 'vitest';
+import { LinearFieldMappingStep } from '../../../web/src/components/projects/pm-wizard-linear-steps.js';
+import type { WizardState } from '../../../web/src/components/projects/pm-wizard-state.js';
+
+function makeState(overrides: Partial<WizardState>): WizardState {
+	return {
+		provider: 'linear',
+		linearApiKey: '',
+		linearTeamId: 'team-1',
+		linearTeamDetails: {
+			states: [
+				{ name: 'Backlog', id: 'st-bl', type: 'backlog', color: '' },
+				{ name: 'Splitting', id: 'st-sp', type: 'started', color: '' },
+				{ name: 'Planning', id: 'st-pl', type: 'started', color: '' },
+				{ name: 'Todo', id: 'st-td', type: 'unstarted', color: '' },
+				{ name: 'In Progress', id: 'st-ip', type: 'started', color: '' },
+				{ name: 'In Review', id: 'st-ir', type: 'started', color: '' },
+				{ name: 'Done', id: 'st-dn', type: 'completed', color: '' },
+				{ name: 'Merged', id: 'st-mg', type: 'completed', color: '' },
+			],
+			labels: [],
+		},
+		linearStatusMappings: {},
+		linearLabels: {},
+		...overrides,
+	} as unknown as WizardState;
+}
+
+function render(extra: Partial<WizardState> = {}): string {
+	return renderToStaticMarkup(
+		createElement(LinearFieldMappingStep, {
+			state: makeState(extra),
+			dispatch: () => {},
+		}),
+	);
+}
+
+describe('LinearFieldMappingStep — status slots', () => {
+	it('renders 8 status mapping rows in CASCADE lifecycle order', () => {
+		const html = render();
+		const expected = [
+			'backlog',
+			'splitting',
+			'planning',
+			'todo',
+			'inProgress',
+			'inReview',
+			'done',
+			'merged',
+		];
+		const positions = expected.map((slot) => html.indexOf(`>${slot}<`));
+		// All slots must be present (index !== -1) AND strictly increasing.
+		positions.forEach((pos, i) => {
+			expect(pos, `slot '${expected[i]}' missing`).toBeGreaterThan(-1);
+			if (i > 0) {
+				expect(pos, `slot '${expected[i]}' out of order`).toBeGreaterThan(positions[i - 1]);
+			}
+		});
+	});
+
+	it('does not render a debug row', () => {
+		const html = render();
+		expect(html).not.toMatch(/>debug</);
+	});
+
+	it('renders a select and enter-manually affordance for each slot', () => {
+		const html = render();
+		// Lower bound: 8 selects present (one per slot). Upper bound not asserted.
+		const selectCount = (html.match(/<select /g) ?? []).length;
+		expect(selectCount).toBeGreaterThanOrEqual(8);
+	});
+
+	it('reflects persisted mappings on initial render', () => {
+		const html = render({
+			linearStatusMappings: {
+				splitting: 'Splitting',
+				planning: 'Planning',
+			},
+		});
+		// The persisted values should appear as selected option values.
+		expect(html).toContain('value="Splitting"');
+		expect(html).toContain('value="Planning"');
+	});
+});
diff --git a/web/src/components/projects/pm-wizard-linear-steps.tsx b/web/src/components/projects/pm-wizard-linear-steps.tsx
index e07c406f..a1165335 100644
--- a/web/src/components/projects/pm-wizard-linear-steps.tsx
+++ b/web/src/components/projects/pm-wizard-linear-steps.tsx
@@ -13,7 +13,16 @@ import { FieldMappingRow, SearchableSelect } from './wizard-shared.js';
 // Slot definitions
 // ============================================================================
 
-const LINEAR_STATUS_SLOTS = ['backlog', 'inProgress', 'inReview', 'done'];
+const LINEAR_STATUS_SLOTS = [
+	'backlog',
+	'splitting',
+	'planning',
+	'todo',
+	'inProgress',
+	'inReview',
+	'done',
+	'merged',
+] as const;
 
 const LINEAR_LABEL_SLOTS = ['processing', 'processed', 'error', 'readyToProcess', 'auto'];