feat(planning): save conflict detection (409) for plans, empires and cx, and per-key preference merge for multi-tab planning

[jplacht]

What and why

When people plan in several tabs, plan, empire and CX saves silently overwrite each other (last write wins). A preference PATCH replaces the whole plan_overrides dict, so per-plan settings from another tab are lost. With this change, a save based on an outdated version is rejected with 409 instead of overwriting, and a preference PATCH only changes the keys and plan overrides it sends.

Changes

• Version and conflict check:
  • Plan, empire and CX responses carry modified_at.
  • PUT accepts an optional base_modified_at and answers 409 ({"detail", "code": "conflict", "modified_at"}) when the row has changed since.
  • The check runs under a row lock inside the saving transaction (planning/api/serializers/conflict.py).
• Empire version: empires get config_modified_at (migration with backfill) as their version, so empire state syncs and cx-junctions never cause a conflict. It is read-only in the admin.
• Preferences: PATCH /user/preferences/ merges planOverrides per plan uuid, and null deletes one.
• Plan deletion: deleting a plan removes its override from the owner's preferences.
• Backward compatible: without base_modified_at, saves work as before.

How it was verified

QA passed after 2 rounds (1 full, 1 scoped).

• Definition of Done: uv run ruff check, ruff format --check, ty check and pytest (849 passed).
• Code review: all 11 acceptance criteria pass.
• In the running app (e2e stack, current main frontend):
  • All 11 criteria pass at the API level, covering 200/409/overwrite for plan, empire and CX, state sync, preference merge and plan delete.
  • In the browser, plan, empire, CX and profile saves and the Management delete all work, with no validation errors.
• UI audit: 0 regressions versus baseline.
• /sync-api: spectacular --validate is clean and nothing breaks for the frontend.

Deploy order

This can deploy on its own, any time before the frontend counterpart (multitab-02-frontend), which will send base_modified_at and handle the 409.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 15 complexity · 0 duplication

Metric	Results
Complexity	15
Duplication	0

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.05% coverage variation

Metric	Results
Coverage variation	✅ +0.05% coverage variation (-1.00%)
Diff coverage	✅ 100.00% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (56c2521)	4895	4685	95.71%
Head commit (1d9d7cb)	4947 (+52)	4737 (+52)	95.76% (+0.05%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#77)	65	65	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}