Day 11: History Is a Feature

Why History Matters

Backups are snapshots. They capture "here's your data at this moment." But they don't answer the harder questions:

• What changed between yesterday and today?
• When did I add that transaction?
• Did a rule modify something without me noticing?
• How do I sync changes between devices?

The operation log answers all of these. History isn't metadata. History is a feature.

What We Built

An append-only operation log that records every successful mutation:

// Every LedgerService action creates an Operation

transaction.create  → New transaction added
transaction.update  → Transaction modified
transaction.delete  → Transaction deleted
transfer.create    → New transfer (2 transactions)
transfer.delete    → Transfer deleted
split.create       → New split transaction
reconciliation.toggle → Reconciliation changed
rule.apply         → Rule executed
backup.restore     → Restored from backup

The Append-Only Rule

Operations are never mutated or deleted. Once written, they're permanent.

Operation Log vs. Backups

They solve different problems:

Building Sync Without Networking

Here's the key insight: sync is not a network problem. It's a data structure problem.

Most apps build sync by choosing a sync provider first: Firebase, Supabase, custom WebSocket server. Then they retrofit their data model to match.

We did the opposite. We built the sync mechanics first—the operation log, the append-only constraint, the minimal payloads—without any networking. The network layer is just a transport detail that can be added later.

// Future sync bundle (no networking required to design)

Operations: [op1, op2, op3, ...]
    │
    ▼
Sync Bundle (JSON)
    │
    ▼
Another Device
    │
    ▼
Replay Operations

The operation log makes this possible. When we're ready for sync, we'll have already solved the hard problems: ordering, conflicts, replay.

The Activity History View

Every workspace now has a History page showing:

• Chronological list of all operations
• Human-readable summaries ("Created transfer ($250.00)")
• Filter by type and date to find specific changes
• Timestamps showing when each action occurred

It's read-only for now. Undo/redo might come later, but the foundation is there.

Building on Tested Invariants

Last sprint we built a regression suite proving all our invariants hold. This sprint, we extended it with 11 new tests:

// Operation Log Tests
✓ Transaction create emits operation
✓ Transaction update emits operation
✓ Transaction delete emits operation
✓ Transfer create emits operation
✓ Transfer delete emits operation
✓ Split create emits operation
✓ Reconciliation toggle emits operation
✓ Operations have deterministic payload structure
✓ Failed action does not emit operation
✓ Backup includes operations
✓ Restore preserves operation order and timestamps

Total: 45 tests pass

The operation log builds directly on the LedgerService foundation we hardened in Sprint 10. Tests compound.

The Public Roadmap

We also launched /roadmap—a public page showing exactly where we are and where we're going:

• 10 sprints complete building foundations
• Sprint 11 (this one) adding history
• 6 more sprints to 1.0 (scheduled rules, CSV import, budgets, multi-currency, templates)

The roadmap also explains our philosophy: the core product is local-first and dependency-free. External services (bank sync, cloud backup, shared workspaces) will be optional premium plugins.

What Comes Next

With history now explicit, we can:

• Add scheduled rules that create operations at specific times
• Implement CSV import and log each imported transaction
• Build sync bundles when we're ready for multi-device
• Add undo/redo by replaying operations