Consolidate history and baseline into single file

[rwdaigle]

Summary

• Rename .history to history (non-hidden file)
• Consolidate baseline metadata directly into the history file using a special line format: baseline: version timestamp [summary]
• Add automatic migration from legacy .history and .baseline files for backwards compatibility
• Simplify state management with unified HistoryState struct

Test plan

• All 46 tests pass, including integration and fixture operation tests
• Backwards compatibility verified: legacy files are automatically migrated and deleted on first read
• Pre-commit hooks (formatting, clippy, tests) all pass

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View issue and 4 additional flags in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View issue and 8 additional flags in Devin Review.

[devin-ai-integration]

🔴 validate_baseline fails to account for migrations covered by existing baseline

The validate_baseline function prevents moving a baseline forward when migrations covered by an existing baseline are not in the applied history.

Click to expand

Scenario

1. User creates a baseline at version 1f700 (migration files deleted, baseline recorded)
2. User applies new migrations 1f710 and 1f720 (these get recorded in history)
3. User tries to move baseline forward to 1f720
4. Validation fails with "Cannot baseline: migration '1f700-xxx' has not been applied"

Root Cause

At src/baseline.rs:64-71, the validation checks that ALL migrations at or before the target version are in the applied list:

for migration in available {
    if version_lte(&migration.version, version) && !applied_ids.contains(migration.id.as_str())
    {
        bail!("Cannot baseline: migration '{}' has not been applied", migration.id);
    }
}

However, the function receives existing_baseline (line 41) but only uses it to check for backward movement (lines 50-57). It doesn't consider that migrations at or before the existing baseline version should be treated as "applied" for validation purposes.

Impact

Users cannot advance their baseline once they have an initial baseline set, unless all prior migrations happen to still exist in the applied history. This breaks the intended workflow of progressively moving baselines forward over time.

(Refers to lines 64-71)

Recommendation: Modify the validation to also consider migrations covered by the existing baseline as 'applied'. Add a check like: if let Some(b) = existing_baseline { if version_lte(&migration.version, &b.version) { continue; } } before checking the applied_ids.

---

Was this helpful? React with 👍 or 👎 to provide feedback.