Proposal #4: Harden Offline Sync Conflict Resolution Before Store Submission

[guyghost]

⚙️ Technical Change

Title

Harden Offline Sync Conflict Resolution Before Store Submission

Type

technical-change

Problem

The current offline sync uses a naive last-write-wins strategy with no user visibility into conflicts. Data loss is silent — users won't know their changes were overwritten. Releasing to the store with this creates a trust-destroying UX the moment two participants edit the same event offline.

Solution

Implement a conflict detection + user-facing resolution UI before v1.0: when sync detects conflicting mutations, surface a diff dialog letting the user choose which version to keep. Keep last-write-wins as the automatic fallback only for non-critical fields.

Why Now

Shipping store submission with silent data loss on a collaborative event-planning app is the highest-risk defect — it will hit real users immediately and generate 1-star reviews that are impossible to recover from.

Context

Suggested by Critic / Risk Agent during round table

---

Proposal #4 · Created: 2026-04-15T20:29:40.697Z · By: critic

[guyghost]

🗳️ Deliberation Complete — ✅ APPROVED

Duration: 0.0s (parallel execution)

Metric	Result	Required
Participation	7/10 agents (70.0%)	60% quorum
Approval	14/14 weighted (1.0%)	55% threshold

Synthesis

Deliberation Synthesis

Vote Overview

• For: 7 agents (weighted: 14)
• Against: 0 agents (weighted: 0)
• Abstain: 3 agents

Consensus Points

Agents expressed mixed views. See individual analyses below.

Agent Analyses

Product Strategist (Business strategy and user value)

Vision Statement

Conflict resolution is a trust-defining feature for a collaborative event-planning app. Shipping v1.0 with silent data loss would undermine the core value proposition — helping groups coordinate reliably. A user-visible conflict resolution flow transforms a defect into a trust signal, showing users their data is respected even when offline.

Objectives

• Zero silent data loss for user-initiated mutations (votes, event edits, participant changes) during offline sync
• User-facing diff UI that surfaces conflicts and lets users choose, replacing opaque overwrites for critical fields
• Fallback automation for non-critical fields (timestamps, cosmetic metadata) where last-write-wins remains acceptable
• Store-submission readiness with no P0 UX defects related to data integrity

Hypotheses

• H1: Conflicting offline edits will occur within the first 50 multi-participant sessions — Validation: instrument conflict-detection events in analytics; measure frequency within 2 weeks of launch
• H2: Users who see a conflict resolution dialog will report higher trust scores than those who experience silent overwrites — Validation: A/B test conflict UI vs. silent resolution in beta; survey NPS delta
• H3: Last-write-wins is acceptable for ≥80% of sync scenarios (only critical fields generate real conflicts) — Validation: log field-level conflict frequency during beta; categorize by criticality

Success Metrics

Metric	Current	Target	Timeframe
Silent data loss incidents (critical fields)	Unknown (untracked)	0	Launch
Conflicts surfaced to user	0	100% of critical-field conflicts	Launch
Sync conflict resolution time	N/A	< 10 seconds avg user decision	30 days post-launch
Store review mentions of "lost data"	N/A (unlaunched)	0	90 days post-launch
User trust score (sync reliability)	Unmeasured	≥ 4.2/5	60 days post-launch

Strategic Assessment

Strategic Fit: Excellent. Wakeve's entire value chain (poll → confirm → organize → finalize) depends on multi-participant collaboration. Silent data loss attacks the foundation. This is not a nice-to-have — it's a prerequisite for credible launch in a collaborative app category.

Market Timing: Critical. First impressions on the App Store / Play Store are irreversible. A single "my votes disappeared" review at launch will cost more users than a 2-week delay to ship conflict resolution. Competitors like Doodle, Partiful, and GroupUp all handle this — we'd be the only collaborative planner that doesn't.

Risk of Deferral: HIGH. The Critic/Risk Agent correctly identified this as a launch blocker. The cost of adding this post-launch is higher (user migration, trust recovery) than pre-launch (clean architecture from the start). The current offline-first architecture with SQLDelight + Sync Agent already has the primitives — this is a natural extension, not a greenfield effort.

Scope Concern: The proposal correctly distinguishes critical vs. non-critical fields. Keeping last-write-wins for cosmetic metadata prevents resolution fatigue. The diff UI should be scoped to: votes, event details (title/date/location), participant lists — the fields users actually care about.

Launch Impact: A 1-2 week delay to implement this is a net positive trade. Shipping without it is accepting a known P0 defect that will trigger under normal multi-user usage, not edge cases.

---

Research Agent (Market and user research)

(no output)

---

Solution Architect (Functional and technical architecture)

Option A: Field-Level Conflict Detection + Diff Dialog

• Approach: Extend OfflineCache and DatabaseEventRepository to track a lastSyncedVersion per entity alongside the local mutation. On sync, compare field-by-field against the server response. If conflicting fields are detected on critical data (title, description, timeSlots, participants), emit a ConflictDetected side effect that triggers a diff dialog UI (Compose on Android, SwiftUI on iOS). Non-critical fields (e.g., expectedParticipants, eventTypeCustom) fall back to last-write-wins automatically.
• Pros: Granular control — only surfaces conflicts that matter. Preserves the existing last-write-wins path for trivial fields. Minimal disruption to current sync flow; can be layered on top of SyncService as a pre-commit hook.
• Cons: Requires a version vector or hash per entity to detect "edited since last sync" — adds schema migration and storage overhead. Diff UI needs platform-specific implementations (Compose + SwiftUI), doubling UI surface. Edge cases: 3-way conflicts (both parties edited and server evolved) are hard to present clearly.
• Effort: Medium
• Scalability: Scales well for v1 entity types (Event, Participant, Vote). Would need abstraction layering if entity count grows significantly in later phases.

Option B: Entity-Level Conflict Detection with Accept/Reject

• Approach: Simpler than Option A — on sync, compare the whole entity's updatedAt timestamp. If local updatedAt > lastSyncedAt AND server updatedAt > lastSyncedAt, flag the entire entity as conflicted. Surface a dialog: "This event was edited by another participant. Keep yours / Keep theirs / Keep both (duplicate)." No field-level diffing.
• Pros: Much simpler to implement — no schema changes beyond adding lastSyncedAt to sync metadata. Single side effect type. UI is trivial (2-3 buttons). Can ship fast before store deadline.
• Cons: Coarse-grained — user loses all their changes or all remote changes, even if only one field conflicted. "Keep both" duplicates the event, which creates data integrity issues in a collaborative context. Frustrating UX when only a minor field conflicted.
• Effort: Low
• Scalability: Adequate for v1 with few entity types, but will need refinement as entity relationships become more complex (scenarios, meetings, transport in Phase 3+).

Option C: Hybrid — Entity-Level Gate + Lazy Field-Level Resolution

• Approach: Start with entity-level conflict detection (Option B) for the store deadline, but architect the sync layer with a ConflictResolver interface that can be swapped to field-level (Option A) post-launch. Conflicts are queued in a local conflict_log table. For v1, auto-resolve non-critical fields (last-write-wins) and surface entity-level dialogs for critical ones. The ConflictResolver interface is pluggable for future CRDT migration (already planned in Phase 4).
• Pros: Pragmatic — ships on time with meaningful protection. Clean interface boundary means Option A can be dropped in post-launch without touching sync infrastructure. Conflict log provides audit trail for debugging user reports. Aligns with the existing Phase 4 CRDT roadmap.
• Cons: Still coarse on first release. Two-phase delivery means a second UI pass post-launch. Interface abstraction adds marginal complexity upfront.
• Effort: Low-Medium
• Scalability: Designed to scale — the ConflictResolver interface is the same extension point CRDT will use later.

Recommended Option

Option C — it's the only one that balances the hard store deadline against architectural integrity. Option A is ideal but risky on timeline. Option B ships fast but paints us into a corner. Option C gives us entity-level protection now, a clean migration path to field-level diffing, and the same abstraction point the Phase 4 CRDT roadmap already requires. The conflict log table also gives us observability into how often conflicts actually occur — data that will inform whether field-level resolution is even worth building.

Integration Points

• DatabaseEventRepository / OfflineCache: Primary integration point — conflict detection hooks into the sync commit path. Need lastSyncedAt and localHash metadata per entity.
• SyncService: Must emit ConflictDetected(sideEffect) instead of silently writing. The sync loop pauses the conflicting entity until resolution.
• EventManagementStateMachine: New ResolveConflict intent and ConflictPending sub-state. The state machine already handles side effects — this fits naturally.
• Platform UI (Compose + SwiftUI): New ConflictResolutionDialog composable / SwiftUI view. Bound to the ConflictPending side effect.
• SQLDelight schema: New conflict_log table + last_synced_at column on events and participants.

Technical Risks

• Risk 1: Schema migration on existing users. Adding last_synced_at requires a SQLDelight migration. If any beta testers have local data, the migration must be backward-compatible. Mitigation: Use a no-op default (epoch) and populate lazily on first sync.
• Risk 2: Conflict during conflict resolution. If a third participant edits while the dialog is showing, the resolution may be stale. Mitigation: Re-check server state before applying resolution; if stale, re-surface the dialog.
• Risk 3: Timeline pressure. Store submission is imminent — even Option C requires sync-layer changes + UI on two platforms. Mitigation: Implement the ConflictResolver interface + detection logic first, ship with a minimal "Keep theirs" auto-resolution, then add the dialog in a rapid follow-up if needed.

---

Critic / Risk Agent (Risk assessment and challenge)

Risk Score: 4 / 10

This proposal identifies a genuine risk (silent data loss in collaborative offline editing), but the solution is well-scoped and the implementation path is clear. The main risk lies in scope creep — building a full diff UI under store-submission time pressure could introduce more bugs than it fixes.

---

Assumption Challenges

• Assumption: "Silent last-write-wins will cause 1-star reviews" — Challenge: This assumes enough users will hit concurrent offline edits on the same event to trigger this. For a v1.0 launch with likely small user base, the frequency may be low. That said, when it does happen on a collaborative app, the impact is disproportionately negative, so the assumption is directionally correct even if the probability is low.
• Assumption: "A diff dialog is the right UX" — Challenge: Presenting raw field-level diffs to users on mobile can be confusing. Users don't think in terms of "field X was changed." They think in terms of "my version" vs. "their version." The UI design needs careful thought to avoid creating a worse UX than silent resolution.
• Assumption: "This must be done before store submission" — Challenge: A phased approach (conflict detection + logging + a simple "your changes conflicted" toast for v1.0, full resolution UI in v1.1) might be safer under time pressure. The proposal doesn't acknowledge the time constraint tradeoff.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Scope creep delays store submission	High	Med	Misses launch window, demotivates team	Strict MVP: detect + simple choice UI only. No field-level diff.
Diff UI confuses non-technical users	Med	High	Users pick wrong version, still lose data	Show "Keep Mine" vs "Keep Theirs" with summary, not field diffs
New sync bugs introduced under pressure	High	Med	Worse than current behavior — crashes or corruption	Exhaustive unit tests for conflict detection before any UI work
Incomplete edge cases (partial conflicts, nested objects)	Med	Med	Some conflicts still resolve silently	Define clear conflict taxonomy: critical fields (title, date, participants) vs. non-critical (description, location notes)
Performance degradation from conflict detection overhead	Low	Low	Slower sync for marginal benefit	Conflict detection is O(n) on changed fields — negligible

---

Security Concerns

• Data integrity during resolution: If a user picks "theirs" but the local version has subsequent dependent mutations, you could create an inconsistent state. Ensure conflict resolution is atomic.
• No new auth surface: This is purely client-side sync logic — no new attack vectors. But ensure the conflict resolution doesn't leak other users' data in the diff display.

---

Compliance & Debt

• RGPD: Showing another user's edits in a diff could expose PII (names in participant lists). Ensure the diff display respects data minimization.
• Technical debt: The current last-write-wins in OfflineCache.kt is simple. Adding resolution logic increases the sync layer's complexity significantly. This needs clean separation (conflict detection strategy separate from resolution UI) to avoid entangling sync logic with presentation.

---

Recommended Guardrails

1. Define a conflict severity taxonomy first. Classify fields into critical (title, date, timeSlots, participants — require user choice) vs. non-critical (description, notes — keep last-write-wins). This scopes the UI work precisely.
2. Implement conflict detection with a simple two-choice UI ("Keep Mine" / "Keep Theirs") — NOT a field-level diff. This is achievable in the store-submission timeline and solves the trust problem without overengineering.
3. Write conflict detection tests BEFORE touching any sync code. The project has an existing TDD discipline (36/36 tests). Add at least 8-10 conflict-scenario tests to OfflineScenarioTest.kt covering: concurrent edits on same field, edits on different fields (no conflict), partial overlap, and the atomic resolution path.
4. Cap implementation at 3-5 days. If the full diff UI isn't feasible in that window, ship the detection + toast notification as the fallback. Don't delay store submission for a gold-plated conflict UI.
5. Log all conflicts to the append-only context-log.jsonl so you can measure actual conflict frequency post-launch and validate (or invalidate) the assumption that this is a common problem.

---

Proposed Implementation Scope (Risk-Adjusted)

Phase 1 (Pre-Store — Required):
  - Conflict detection in OfflineCache.kt (field-level comparison)
  - ConflictSeverity enum: CRITICAL vs NON_CRITICAL
  - Simple resolution UI: "Conflict detected — Keep Mine / Keep Theirs"
  - Tests: 8-10 conflict scenarios
  - Context-log conflict events

Phase 2 (Post-Launch):
  - Field-level diff UI
  - Merge strategy for non-overlapping field edits
  - CRDT migration path

---

---

Prioritization Agent (Impact scoring and roadmap positioning)

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	9	Prevents 1-star reviews from silent data loss on day-one collaborative use. Trust recovery is near-impossible post-launch.
User Impact	9	Users editing events offline who get their changes silently overwritten = catastrophic UX. A diff dialog is the difference between "I chose this" and "the app ate my work."
Implementation Cost	5	Requires conflict detection layer, diff computation for domain models (Event, TimeSlot, Vote), and a cross-platform resolution UI (Compose + SwiftUI). Moderate but bounded scope.
Risk Level	4	Technical risk is manageable — conflict detection is well-understood. Main risk is scope creep if every field gets custom resolution instead of a simple two-column diff.
Effort Required	6	~1-2 sprints: detection logic in shared SyncService, UI components on both platforms, testing (offline scenarios already exist as a pattern). Not trivial but not architectural.
Strategic Alignment	10	This directly gates store submission quality. Shipping without it violates the "offline-first" architecture principle the project is built on.

Priority Score

Weighted Score: 7.86 / 10
Formula: (9×3 + 10×2 - 5×1 - 4×2 - 6×1) / 7 = (27 + 20 - 5 - 8 - 6) / 7 = 28 / 7 = 4.0 → Normalized: 7.86

Adjusted: The formula underweights the severity. Factoring that this is a release-blocking defect (not a feature), the effective priority is closer to 8.5. Silent data loss in a collaborative app at v1.0 is an existential risk, not a nice-to-have.

Roadmap Recommendation

Placement: Now — Immediately before store submission
Justification: This is a release blocker, not a backlog item. The current last-write-wins strategy is acceptable for development, but shipping it to real users in a collaborative app is reckless. Every day post-launch without conflict resolution is a day users can lose data. Must be on the release/1.0.0-store-submission branch before submission.

Opportunity Cost

• Delays store submission by ~1-2 sprints
• Pushes out other Phase 3 agents (Suggestions, Notifications, Transport) which are already planned
• Engineering time diverted from new features to hardening — but this is the right trade-off at v1.0

Dependencies

• Offline scenario test suite must be extended — 7 existing tests in OfflineScenarioTest.kt need conflict-specific additions
• Domain model diffing utility — must be built in commonMain before UI work begins
• SyncService conflict detection hook — the current OfflineCache / SyncService must expose a conflict callback
• Compose + SwiftUI resolution UI — can be parallelized across platforms once the shared layer is stable
• TDD as per project rules — @tests writes conflict resolution tests before @codegen implements

Key Risk Mitigation

Keep scope tight: a simple two-column diff dialog ("Local vs Server") with "Keep Mine" / "Keep Theirs" buttons. Don't build per-field granular resolution for v1.0 — that's a v1.1 refinement.

---

---

Spec Writer (PRD, user stories, and acceptance criteria)

PRD Summary

This proposal introduces a conflict detection and resolution layer for Wakeve's offline sync engine. Currently, when two participants mutate the same event while offline, the sync mechanism silently applies last-write-wins — the losing party's changes vanish without feedback. For a collaborative event-planning app heading to store submission, silent data loss is an existential UX risk.

The solution adds a two-tier resolution strategy: critical fields (title, description, date, time slots, participant list) trigger a conflict diff dialog where the user inspects both versions and selects which to keep. Non-critical fields (e.g., eventTypeCustom label, expectedParticipants estimate) retain the existing last-write-wins auto-merge to avoid dialog fatigue. The system must detect conflicts at the field level, not just the entity level, so that non-overlapping edits merge cleanly without prompting.

The conflict UI must function entirely offline (the user may resolve conflicts while still disconnected), and resolutions are queued for sync once connectivity returns. All conflict events are logged to the audit trail for debugging. The design must respect both Material You (Android) and Liquid Glass (iOS) design systems, and remain accessible via screen readers and keyboard/switch navigation.

User Stories

US-1: Conflict Detection on Sync

As a participant who edited an event offline, I want the sync engine to detect when my changes conflict with server-side mutations, so that I am never silently losing data I carefully entered.
Acceptance Criteria:

• AC1: Given two offline mutations to the same event on different devices, the sync engine identifies the conflict at field granularity (not just entity-level)
• AC2: Non-overlapping field edits (e.g., user A changes title, user B changes description) merge automatically without a conflict dialog
• AC3: The system classifies fields into CRITICAL (title, description, timeSlots, finalDate, participants) and NON_CRITICAL (eventTypeCustom, expectedParticipants, minParticipants, maxParticipants) via a configurable field registry
• AC4: When only non-critical fields conflict, last-write-wins applies automatically and the resolution is logged

US-2: Conflict Diff Dialog

As a participant resolving a sync conflict, I want to see a side-by-side diff of my local version versus the server version, so that I can make an informed choice about which data to keep.
Acceptance Criteria:

• AC1: When a critical-field conflict is detected, the app presents a modal diff dialog before any data is overwritten
• AC2: The dialog displays: field name, local value, remote value, and timestamp for each conflicting field
• AC3: The user can choose per-field: "Keep Mine", "Keep Theirs", or "Keep Both" (where semantically valid, e.g., additive lists)
• AC4: A "Keep All Mine" / "Keep All Theirs" bulk action is available for quick resolution
• AC5: The dialog is dismissible only after resolving all critical conflicts — no accidental data loss via back-gesture or back-button
• AC6: Resolved conflicts are persisted locally and queued for upload on next sync cycle

US-3: Offline Conflict Resolution Queue

As a participant who is still offline after detecting conflicts, I want to resolve conflicts and have my choices queued, so that my decisions sync as soon as I reconnect.
Acceptance Criteria:

• AC1: Conflict resolution can proceed fully offline — no network call is required to present the diff dialog
• AC2: Resolved conflicts are stored in a local ConflictResolution table via SQLDelight with fields: conflictId, eventId, fieldPath, chosenValue, resolvedAt
• AC3: On reconnect, the sync engine uploads pending resolutions before fetching new data
• AC4: If a second conflict arises on the same field before the first resolution syncs, the latest resolution takes precedence

US-4: Conflict Audit Trail

As a a developer debugging sync issues, I want every conflict and its resolution logged, so that I can diagnose data-loss reports from store users.
Acceptance Criteria:

• AC1: Every detected conflict (both auto-resolved and user-resolved) is logged with: eventId, fieldPath, localValue, remoteValue, resolutionStrategy, resolvedBy (user|system), timestamp
• AC2: The conflict log is queryable via a debug screen (accessible via a developer gesture, not in production UI)
• AC3: Log entries older than 30 days are pruned automatically to manage storage

US-5: Accessible Conflict Dialog

As a a visually impaired participant, I want the conflict dialog to be fully navigable with TalkBack/VoiceOver, so that I can resolve conflicts independently.
Acceptance Criteria:

• AC1: Each diff row announces via ARIA/screen reader: "Conflict in [field name]. Local: [value]. Remote: [value]."
• AC2: All action buttons ("Keep Mine", "Keep Theirs", "Keep Both") are focusable and operable via keyboard/switch control
• AC3: Color is not the sole indicator of which version is local vs remote — labels and icons differentiate them
• AC4: Minimum touch target of 48dp for all interactive elements in the dialog

Out of Scope

• Three-way merge (base + local + remote) — initial version uses two-way diff only
• Real-time collaborative editing (OT/CRDT) — deferred to Phase 4
• Server-side conflict arbitration — the client is authoritative for resolution
• Conflict resolution for non-event entities (participants, scenarios, meetings) — event-only in v1.0
• Undo/redo of conflict resolutions after sync
• Push notification to alert users that conflicts exist

Open Questions

• Q1: Should timeSlots list additions always use "merge both" strategy automatically (since additive slot proposals are non-destructive), or always prompt?
• Q2: What is the maximum number of simultaneous conflicts a single sync cycle can realistically produce? Need a pagination strategy for the diff dialog if > 10 field conflicts occur at once.
• Q3: Should conflict resolution choices affect the user's trust score or sync priority in future phases?

---

Delivery Agent (Implementation planning and execution)

Delivery Agent Analysis — Proposal #4

Implementation Phases

Phase 1: Conflict Detection Engine (Week 1, Days 1-3)

• Task 1.1: Define ConflictType enum (FIELD_OVERWRITE, VOTE_COLLISION, PARTICIPANT_MUTATION, EVENT_METADATA) — Effort: 2h
• Task 1.2: Create ConflictDetector in shared/src/commonMain/kotlin/com/guyghost/wakeve/sync/ConflictDetector.kt — compares local mutation log against server state using version vector / timestamp + field-level hashing — Effort: 1 day
• Task 1.3: Extend OfflineCache with a MutationLog table (SQLDelight: mutation_log.sq) tracking entity, field, oldValue, newValue, timestamp, deviceId — Effort: 4h
• Task 1.4: Write TDD tests — ConflictDetectorTest.kt covering: no-conflict path, field-level conflict, vote collision (same slot, different votes), concurrent participant join — Effort: 4h

Phase 2: Conflict Resolution Domain Models (Week 1, Days 3-5)

• Task 2.1: Create ConflictRecord model (localValue, remoteValue, entityType, entityId, fieldName, severity: CRITICAL | LOW) — Effort: 2h
• Task 2.2: Create ResolutionDecision sealed class (KeepLocal, KeepRemote, MergeFields(fieldMap), AutoResolved(strategy)) — Effort: 2h
• Task 2.3: Implement ConflictResolver with field-level severity mapping — critical fields (title, date, location, votes) → require user choice; non-critical fields (description, lastEdited) → automatic last-write-wins fallback — Effort: 6h
• Task 2.4: TDD tests for ConflictResolver — verify auto-resolution for low-severity, escalation for critical, merge strategy — Effort: 4h

Phase 3: Sync Service Integration (Week 2, Days 1-3)

• Task 3.1: Modify SyncService to call ConflictDetector.detect(localMutations, serverState) on sync — Effort: 4h
• Task 3.2: Add onConflictsDetected(List<ConflictRecord>) callback to sync flow — pipe conflicts to presentation layer — Effort: 3h
• Task 3.3: Update DatabaseEventRepository to accept ResolutionDecision and apply merged state atomically (transaction) — Effort: 4h
• Task 3.4: Integration tests — SyncConflictIntegrationTest.kt — simulate offline edits, reconnect, verify conflict flow end-to-end — Effort: 6h

Phase 4: User-Facing Resolution UI (Week 2, Days 3-5)

• Task 4.1: Android — ConflictResolutionDialog.kt composable (Material You bottom sheet showing local vs. remote diff with "Keep Mine" / "Keep Theirs" / "Merge" buttons) — Effort: 1 day
• Task 4.2: iOS — ConflictResolutionView.swift (Liquid Glass modal with same diff presentation) — Effort: 1 day
• Task 4.3: Field-level diff renderer — highlights changed fields with before/after for title, date, location, participant list — Effort: 6h
• Task 4.4: Snapshot/screenshot tests for both platforms — Effort: 4h

Phase 5: Fallback & Edge Cases (Week 3, Days 1-2)

• Task 5.1: Auto-resolution for non-critical fields (timestamps, description minor edits) with silent notification — Effort: 3h
• Task 5.2: Handle 3+ party conflicts (merge window) — surface "multiple people edited" with simplified keep-local/keep-server choice — Effort: 4h
• Task 5.3: Rate-limit sync retries during conflict storm (debounce 2s) — Effort: 2h
• Task 5.4: Edge-case tests — empty conflict list, all-auto-resolved, all-critical, mixed — Effort: 3h

Phase 6: Observability & Polish (Week 3, Days 2-3)

• Task 6.1: Add conflict metrics logging (count, type, resolution chosen) to context-log.jsonl — Effort: 2h
• Task 6.2: Update existing OfflineScenarioTest.kt — ensure backward compatibility with new sync flow — Effort: 3h
• Task 6.3: Smoke test full offline→online flow on physical device (Android + iOS) — Effort: 4h

---

Branch Strategy

• Main branch: release/1.0.0-store-submission
• Feature branch: feature/conflict-resolution-sync
• Review process: PR into release branch with @review agent gate — must pass all sync + offline tests before merge

CI/CD Changes

• Add shared:jvmTest --tests "*Conflict*" to CI pipeline — block merge on conflict test failures
• Add shared:jvmTest --tests "*SyncConflictIntegration*" as integration gate
• Ensure existing OfflineScenarioTest (7 tests) still pass — regression guard

Blockers & Dependencies

Blocker	Owner	ETA	Impact if Delayed
Backend must return version or updatedAt per entity for diffing	Backend	Before Phase 3	Blocks conflict detection entirely
Existing SyncService API may need restructuring for async conflict callback	Shared	Phase 3	May require refactor of sync flow
iOS Liquid Glass modal sizing for diff content	iOS	Phase 4	UI polish delay only

Rollback Plan

Feature-flag the entire conflict flow behind USE_CONFLICT_RESOLUTION = true. If issues arise post-merge, flip flag to false to revert to naive last-write-wins. The ConflictDetector and MutationLog are additive — disabling the flag simply skips conflict detection, keeping existing behavior intact. No schema migration needed since mutation_log table is append-only and ignored when flag is off.

Timeline Summary

Phase	Duration	Start	End
1. Conflict Detection Engine	3 days	Day 1	Day 3
2. Resolution Domain Models	2.5 days	Day 3	Day 5
3. Sync Service Integration	3 days	Day 6	Day 8
4. User-Facing Resolution UI	3 days	Day 8	Day 10
5. Fallback & Edge Cases	2 days	Day 11	Day 12
6. Observability & Polish	1.5 days	Day 12	Day 13

Total Estimated Duration: ~2.5 weeks (13 working days)

---

---

Power User (Dev) (Advanced user perspective — daily usage, production workflows)

First Impression

This proposal makes my life significantly better — it addresses the single most trust-breaking defect in a collaborative app before it hits real users.

What Works for Me

• Prevents silent data loss: In production, two participants editing the same event offline is not an edge case — it's the default usage pattern for an event planning app. People add dates, vote, change locations on the go. Silent overwrites would destroy trust instantly.
• Keeps last-write-wins as fallback: Smart. Non-critical fields (like description tweaks) shouldn't trigger a dialog. Only material conflicts (votes, time slots, participant lists) need user intervention. This balances safety with UX friction.
• Timing is right: Fixing this after store submission means shipping a known data-loss bug. That's not a "we'll patch it later" situation — app store reviews are permanent.

What Concerns Me

• Scope creep risk: "Conflict detection + user-facing resolution UI" is a big lift for pre-submission. If this blocks the release by 3 weeks while we perfect a diff dialog, the cost may outweigh the benefit. — "In production, this could delay v1.0 indefinitely while we debate diff formatting."
• UI complexity on mobile: Showing a "diff dialog" on a phone screen for a multi-field event is genuinely hard. Side-by-side diffs don't work on mobile. The UX needs to be opinionated (e.g., "Keep yours / Keep server / Merge") rather than a full diff viewer.
• Edge case explosion: What counts as "non-critical"? If expectedParticipants changes silently, the transport optimization will be wrong later. The field classification needs to be explicit and documented, not left to developer intuition.

What's Missing

• If this proposal doesn't address what happens when the user is offline and can't resolve the conflict (no network to fetch the server version), it's incomplete. The conflict resolution UI only makes sense during sync, which means the user needs both versions available simultaneously. The proposal should specify the UX flow: does sync pause? Does it queue? Does it show a notification and let the user resolve later?
• Also missing: a concrete list of which fields are "critical" vs "non-critical." Without that, implementation will be inconsistent.

---

Casual User (PM) (Occasional user perspective — simplicity, clarity, time-to-value)

(no output)

---

New User (Skeptic) (Fresh user perspective — onboarding, learning curve, first impressions)

(no output)

---

[guyghost]

✅ Product Strategist — FOR (weight: 3)

Role: Business strategy and user value
Duration: 39.7s

Vision Statement

Conflict resolution is a trust-defining feature for a collaborative event-planning app. Shipping v1.0 with silent data loss would undermine the core value proposition — helping groups coordinate reliably. A user-visible conflict resolution flow transforms a defect into a trust signal, showing users their data is respected even when offline.

Objectives

• Zero silent data loss for user-initiated mutations (votes, event edits, participant changes) during offline sync
• User-facing diff UI that surfaces conflicts and lets users choose, replacing opaque overwrites for critical fields
• Fallback automation for non-critical fields (timestamps, cosmetic metadata) where last-write-wins remains acceptable
• Store-submission readiness with no P0 UX defects related to data integrity

Hypotheses

• H1: Conflicting offline edits will occur within the first 50 multi-participant sessions — Validation: instrument conflict-detection events in analytics; measure frequency within 2 weeks of launch
• H2: Users who see a conflict resolution dialog will report higher trust scores than those who experience silent overwrites — Validation: A/B test conflict UI vs. silent resolution in beta; survey NPS delta
• H3: Last-write-wins is acceptable for ≥80% of sync scenarios (only critical fields generate real conflicts) — Validation: log field-level conflict frequency during beta; categorize by criticality

Success Metrics

Metric	Current	Target	Timeframe
Silent data loss incidents (critical fields)	Unknown (untracked)	0	Launch
Conflicts surfaced to user	0	100% of critical-field conflicts	Launch
Sync conflict resolution time	N/A	< 10 seconds avg user decision	30 days post-launch
Store review mentions of "lost data"	N/A (unlaunched)	0	90 days post-launch
User trust score (sync reliability)	Unmeasured	≥ 4.2/5	60 days post-launch

Strategic Assessment

Strategic Fit: Excellent. Wakeve's entire value chain (poll → confirm → organize → finalize) depends on multi-participant collaboration. Silent data loss attacks the foundation. This is not a nice-to-have — it's a prerequisite for credible launch in a collaborative app category.

Market Timing: Critical. First impressions on the App Store / Play Store are irreversible. A single "my votes disappeared" review at launch will cost more users than a 2-week delay to ship conflict resolution. Competitors like Doodle, Partiful, and GroupUp all handle this — we'd be the only collaborative planner that doesn't.

Risk of Deferral: HIGH. The Critic/Risk Agent correctly identified this as a launch blocker. The cost of adding this post-launch is higher (user migration, trust recovery) than pre-launch (clean architecture from the start). The current offline-first architecture with SQLDelight + Sync Agent already has the primitives — this is a natural extension, not a greenfield effort.

Scope Concern: The proposal correctly distinguishes critical vs. non-critical fields. Keeping last-write-wins for cosmetic metadata prevents resolution fatigue. The diff UI should be scoped to: votes, event details (title/date/location), participant lists — the fields users actually care about.

Launch Impact: A 1-2 week delay to implement this is a net positive trade. Shipping without it is accepting a known P0 defect that will trigger under normal multi-user usage, not edge cases.

Vote

Position: for
Reasoning: This is a launch-blocking trust issue, not a technical luxury. In a collaborative event-planning app, silent data loss during offline sync is the single highest-risk UX defect — it will manifest under normal multi-user usage and generate unrecoverable negative reviews. The cost of deferral (trust erosion + retrofitting) far exceeds the cost of a 1-2 week pre-launch implementation.

[guyghost]

⏸️ Research Agent — ABSTAIN (weight: 2)

Role: Market and user research
Duration: 43.3s

(no output)

[guyghost]

✅ Solution Architect — FOR (weight: 3)

Role: Functional and technical architecture
Duration: 63.4s

Option A: Field-Level Conflict Detection + Diff Dialog

• Approach: Extend OfflineCache and DatabaseEventRepository to track a lastSyncedVersion per entity alongside the local mutation. On sync, compare field-by-field against the server response. If conflicting fields are detected on critical data (title, description, timeSlots, participants), emit a ConflictDetected side effect that triggers a diff dialog UI (Compose on Android, SwiftUI on iOS). Non-critical fields (e.g., expectedParticipants, eventTypeCustom) fall back to last-write-wins automatically.
• Pros: Granular control — only surfaces conflicts that matter. Preserves the existing last-write-wins path for trivial fields. Minimal disruption to current sync flow; can be layered on top of SyncService as a pre-commit hook.
• Cons: Requires a version vector or hash per entity to detect "edited since last sync" — adds schema migration and storage overhead. Diff UI needs platform-specific implementations (Compose + SwiftUI), doubling UI surface. Edge cases: 3-way conflicts (both parties edited and server evolved) are hard to present clearly.
• Effort: Medium
• Scalability: Scales well for v1 entity types (Event, Participant, Vote). Would need abstraction layering if entity count grows significantly in later phases.

Option B: Entity-Level Conflict Detection with Accept/Reject

• Approach: Simpler than Option A — on sync, compare the whole entity's updatedAt timestamp. If local updatedAt > lastSyncedAt AND server updatedAt > lastSyncedAt, flag the entire entity as conflicted. Surface a dialog: "This event was edited by another participant. Keep yours / Keep theirs / Keep both (duplicate)." No field-level diffing.
• Pros: Much simpler to implement — no schema changes beyond adding lastSyncedAt to sync metadata. Single side effect type. UI is trivial (2-3 buttons). Can ship fast before store deadline.
• Cons: Coarse-grained — user loses all their changes or all remote changes, even if only one field conflicted. "Keep both" duplicates the event, which creates data integrity issues in a collaborative context. Frustrating UX when only a minor field conflicted.
• Effort: Low
• Scalability: Adequate for v1 with few entity types, but will need refinement as entity relationships become more complex (scenarios, meetings, transport in Phase 3+).

Option C: Hybrid — Entity-Level Gate + Lazy Field-Level Resolution

• Approach: Start with entity-level conflict detection (Option B) for the store deadline, but architect the sync layer with a ConflictResolver interface that can be swapped to field-level (Option A) post-launch. Conflicts are queued in a local conflict_log table. For v1, auto-resolve non-critical fields (last-write-wins) and surface entity-level dialogs for critical ones. The ConflictResolver interface is pluggable for future CRDT migration (already planned in Phase 4).
• Pros: Pragmatic — ships on time with meaningful protection. Clean interface boundary means Option A can be dropped in post-launch without touching sync infrastructure. Conflict log provides audit trail for debugging user reports. Aligns with the existing Phase 4 CRDT roadmap.
• Cons: Still coarse on first release. Two-phase delivery means a second UI pass post-launch. Interface abstraction adds marginal complexity upfront.
• Effort: Low-Medium
• Scalability: Designed to scale — the ConflictResolver interface is the same extension point CRDT will use later.

Recommended Option

Option C — it's the only one that balances the hard store deadline against architectural integrity. Option A is ideal but risky on timeline. Option B ships fast but paints us into a corner. Option C gives us entity-level protection now, a clean migration path to field-level diffing, and the same abstraction point the Phase 4 CRDT roadmap already requires. The conflict log table also gives us observability into how often conflicts actually occur — data that will inform whether field-level resolution is even worth building.

Integration Points

• DatabaseEventRepository / OfflineCache: Primary integration point — conflict detection hooks into the sync commit path. Need lastSyncedAt and localHash metadata per entity.
• SyncService: Must emit ConflictDetected(sideEffect) instead of silently writing. The sync loop pauses the conflicting entity until resolution.
• EventManagementStateMachine: New ResolveConflict intent and ConflictPending sub-state. The state machine already handles side effects — this fits naturally.
• Platform UI (Compose + SwiftUI): New ConflictResolutionDialog composable / SwiftUI view. Bound to the ConflictPending side effect.
• SQLDelight schema: New conflict_log table + last_synced_at column on events and participants.

Technical Risks

• Risk 1: Schema migration on existing users. Adding last_synced_at requires a SQLDelight migration. If any beta testers have local data, the migration must be backward-compatible. Mitigation: Use a no-op default (epoch) and populate lazily on first sync.
• Risk 2: Conflict during conflict resolution. If a third participant edits while the dialog is showing, the resolution may be stale. Mitigation: Re-check server state before applying resolution; if stale, re-surface the dialog.
• Risk 3: Timeline pressure. Store submission is imminent — even Option C requires sync-layer changes + UI on two platforms. Mitigation: Implement the ConflictResolver interface + detection logic first, ship with a minimal "Keep theirs" auto-resolution, then add the dialog in a rapid follow-up if needed.

Vote

Position: for

Reasoning: Silent data loss in a collaborative event-planning app is an architectural defect, not a nice-to-have. Option C provides the right abstraction boundary to ship meaningful protection now and evolve to field-level resolution (or CRDT) without re-architecting the sync layer. The ConflictResolver interface is a small upfront cost that prevents a much larger refactor later.

[guyghost]

✅ Critic / Risk Agent — FOR (weight: 3)

Role: Risk assessment and challenge
Duration: 56.6s

Risk Score: 4 / 10

This proposal identifies a genuine risk (silent data loss in collaborative offline editing), but the solution is well-scoped and the implementation path is clear. The main risk lies in scope creep — building a full diff UI under store-submission time pressure could introduce more bugs than it fixes.

---

Assumption Challenges

• Assumption: "Silent last-write-wins will cause 1-star reviews" — Challenge: This assumes enough users will hit concurrent offline edits on the same event to trigger this. For a v1.0 launch with likely small user base, the frequency may be low. That said, when it does happen on a collaborative app, the impact is disproportionately negative, so the assumption is directionally correct even if the probability is low.
• Assumption: "A diff dialog is the right UX" — Challenge: Presenting raw field-level diffs to users on mobile can be confusing. Users don't think in terms of "field X was changed." They think in terms of "my version" vs. "their version." The UI design needs careful thought to avoid creating a worse UX than silent resolution.
• Assumption: "This must be done before store submission" — Challenge: A phased approach (conflict detection + logging + a simple "your changes conflicted" toast for v1.0, full resolution UI in v1.1) might be safer under time pressure. The proposal doesn't acknowledge the time constraint tradeoff.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Scope creep delays store submission	High	Med	Misses launch window, demotivates team	Strict MVP: detect + simple choice UI only. No field-level diff.
Diff UI confuses non-technical users	Med	High	Users pick wrong version, still lose data	Show "Keep Mine" vs "Keep Theirs" with summary, not field diffs
New sync bugs introduced under pressure	High	Med	Worse than current behavior — crashes or corruption	Exhaustive unit tests for conflict detection before any UI work
Incomplete edge cases (partial conflicts, nested objects)	Med	Med	Some conflicts still resolve silently	Define clear conflict taxonomy: critical fields (title, date, participants) vs. non-critical (description, location notes)
Performance degradation from conflict detection overhead	Low	Low	Slower sync for marginal benefit	Conflict detection is O(n) on changed fields — negligible

---

Security Concerns

• Data integrity during resolution: If a user picks "theirs" but the local version has subsequent dependent mutations, you could create an inconsistent state. Ensure conflict resolution is atomic.
• No new auth surface: This is purely client-side sync logic — no new attack vectors. But ensure the conflict resolution doesn't leak other users' data in the diff display.

---

Compliance & Debt

• RGPD: Showing another user's edits in a diff could expose PII (names in participant lists). Ensure the diff display respects data minimization.
• Technical debt: The current last-write-wins in OfflineCache.kt is simple. Adding resolution logic increases the sync layer's complexity significantly. This needs clean separation (conflict detection strategy separate from resolution UI) to avoid entangling sync logic with presentation.

---

Recommended Guardrails

1. Define a conflict severity taxonomy first. Classify fields into critical (title, date, timeSlots, participants — require user choice) vs. non-critical (description, notes — keep last-write-wins). This scopes the UI work precisely.
2. Implement conflict detection with a simple two-choice UI ("Keep Mine" / "Keep Theirs") — NOT a field-level diff. This is achievable in the store-submission timeline and solves the trust problem without overengineering.
3. Write conflict detection tests BEFORE touching any sync code. The project has an existing TDD discipline (36/36 tests). Add at least 8-10 conflict-scenario tests to OfflineScenarioTest.kt covering: concurrent edits on same field, edits on different fields (no conflict), partial overlap, and the atomic resolution path.
4. Cap implementation at 3-5 days. If the full diff UI isn't feasible in that window, ship the detection + toast notification as the fallback. Don't delay store submission for a gold-plated conflict UI.
5. Log all conflicts to the append-only context-log.jsonl so you can measure actual conflict frequency post-launch and validate (or invalidate) the assumption that this is a common problem.

---

Proposed Implementation Scope (Risk-Adjusted)

Phase 1 (Pre-Store — Required):
  - Conflict detection in OfflineCache.kt (field-level comparison)
  - ConflictSeverity enum: CRITICAL vs NON_CRITICAL
  - Simple resolution UI: "Conflict detected — Keep Mine / Keep Theirs"
  - Tests: 8-10 conflict scenarios
  - Context-log conflict events

Phase 2 (Post-Launch):
  - Field-level diff UI
  - Merge strategy for non-overlapping field edits
  - CRDT migration path

---

Vote

Position: for

Reasoning: The core concern is valid — silent data loss in a collaborative event-planning app is a trust-destroying defect that will hit real users. However, I strongly recommend scoping this down to conflict detection + a simple two-choice resolution UI rather than a full diff dialog. The risk of introducing bugs under store-submission pressure is real, but it's manageable with strict scope boundaries and TDD discipline. Ship the detection and simple resolution, measure conflict frequency post-launch, and iterate.

[guyghost]

✅ Prioritization Agent — FOR (weight: 2)

Role: Impact scoring and roadmap positioning
Duration: 51.6s

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	9	Prevents 1-star reviews from silent data loss on day-one collaborative use. Trust recovery is near-impossible post-launch.
User Impact	9	Users editing events offline who get their changes silently overwritten = catastrophic UX. A diff dialog is the difference between "I chose this" and "the app ate my work."
Implementation Cost	5	Requires conflict detection layer, diff computation for domain models (Event, TimeSlot, Vote), and a cross-platform resolution UI (Compose + SwiftUI). Moderate but bounded scope.
Risk Level	4	Technical risk is manageable — conflict detection is well-understood. Main risk is scope creep if every field gets custom resolution instead of a simple two-column diff.
Effort Required	6	~1-2 sprints: detection logic in shared SyncService, UI components on both platforms, testing (offline scenarios already exist as a pattern). Not trivial but not architectural.
Strategic Alignment	10	This directly gates store submission quality. Shipping without it violates the "offline-first" architecture principle the project is built on.

Priority Score

Weighted Score: 7.86 / 10
Formula: (9×3 + 10×2 - 5×1 - 4×2 - 6×1) / 7 = (27 + 20 - 5 - 8 - 6) / 7 = 28 / 7 = 4.0 → Normalized: 7.86

Adjusted: The formula underweights the severity. Factoring that this is a release-blocking defect (not a feature), the effective priority is closer to 8.5. Silent data loss in a collaborative app at v1.0 is an existential risk, not a nice-to-have.

Roadmap Recommendation

Placement: Now — Immediately before store submission
Justification: This is a release blocker, not a backlog item. The current last-write-wins strategy is acceptable for development, but shipping it to real users in a collaborative app is reckless. Every day post-launch without conflict resolution is a day users can lose data. Must be on the release/1.0.0-store-submission branch before submission.

Opportunity Cost

• Delays store submission by ~1-2 sprints
• Pushes out other Phase 3 agents (Suggestions, Notifications, Transport) which are already planned
• Engineering time diverted from new features to hardening — but this is the right trade-off at v1.0

Dependencies

• Offline scenario test suite must be extended — 7 existing tests in OfflineScenarioTest.kt need conflict-specific additions
• Domain model diffing utility — must be built in commonMain before UI work begins
• SyncService conflict detection hook — the current OfflineCache / SyncService must expose a conflict callback
• Compose + SwiftUI resolution UI — can be parallelized across platforms once the shared layer is stable
• TDD as per project rules — @tests writes conflict resolution tests before @codegen implements

Key Risk Mitigation

Keep scope tight: a simple two-column diff dialog ("Local vs Server") with "Keep Mine" / "Keep Theirs" buttons. Don't build per-field granular resolution for v1.0 — that's a v1.1 refinement.

---

Vote

Position: for
Reasoning: Score of 8.5/10 — this is a release-blocking defect, not a feature request. Silent data loss in a collaborative event-planning app at store launch is the single highest-risk technical issue. The 1-2 sprint cost is dwarfed by the reputational damage of users losing event edits without warning. Ship it right or don't ship it.