## Summary When creating tasks (or other write operations) with `--no-commit` during a session, the writes exist on the session's Dolt branch but are **silently discarded** when `session merge` is called. The merge reports `conflicts: 0, status: merged` — success — but the writes are gone. ## Steps to Reproduce ```bash synthesist session start test-session synthesist --session=test-session phase set plan # Create 27 tasks with --no-commit synthesist --session=test-session --no-commit task create tree/spec "Task 1" --id t1 synthesist --session=test-session --no-commit task create tree/spec "Task 2" --id t2 # ... repeat # Merge synthesist session merge test-session # Output: { "conflicts": 0, "session": "test-session", "status": "merged" } # Check synthesist task list tree/spec # Output: { "tasks": null } ← all tasks lost ``` ## Expected Behavior `--no-commit` should batch writes into the session branch without committing each one individually, but they should still be **included in the merge**. Either: 1. `session merge` should auto-commit any uncommitted changes on the session branch before merging, or 2. `--no-commit` should warn/error if the session is about to be merged with uncommitted changes, or 3. The docs should explicitly state that `--no-commit` requires a manual commit before merge ## Actual Behavior - Writes with `--no-commit` succeed (return valid JSON, no errors) - `session merge` succeeds (reports 0 conflicts) - All `--no-commit` writes are silently discarded - No warning, no error — data loss is invisible ## Impact In practice this means any batch operation using `--no-commit` for performance (e.g., importing 30+ campaign items) will lose all data on merge. The only workaround is to omit `--no-commit` entirely and accept a git commit per operation. ## Environment - synthesist v5.3.2 - macOS arm64 - Dolt-backed storage