From 9adfb85d8445e5fceced1bf2a8f56751a078e0e7 Mon Sep 17 00:00:00 2001 From: le king fu Date: Sat, 25 Apr 2026 16:53:36 -0400 Subject: [PATCH 1/4] test(balance): add cross-cutting integration tests MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit End-to-end happy path through the full Bilan stack: account → priced category → priced snapshot → linked transfer → return. Drives every service against the existing in-memory FakeDb harness used by category-migration tests so SQL shape (table names + parameters) can be asserted alongside service outputs. Currency lock: USD / EUR / GBP / JPY / AUD all rejected up-front by the service with a typed `currency_unsupported` code, no DB hit. The CAD default is verified to land in the INSERT params explicitly. Priced-kind safety: a snapshot save with one out-of-tolerance line must NOT clear pre-existing lines (the DELETE is gated behind the validation loop). A drift just within ε is accepted unchanged. computeAccountReturn wiring: malformed dates are rejected client-side without invoking the Rust command; missing active profile yields a typed `transfer_active_profile_unknown`; partial-period payloads are forwarded unchanged (null fields preserved). Co-Authored-By: Claude Opus 4.7 (1M context) --- src/__integration__/balance-flow.test.ts | 574 +++++++++++++++++++++++ 1 file changed, 574 insertions(+) create mode 100644 src/__integration__/balance-flow.test.ts diff --git a/src/__integration__/balance-flow.test.ts b/src/__integration__/balance-flow.test.ts new file mode 100644 index 0000000..e7489cf --- /dev/null +++ b/src/__integration__/balance-flow.test.ts @@ -0,0 +1,574 @@ +/** + * Integration tests for the Bilan (balance sheet) feature — Issue #144. + * + * Cross-cutting tests that exercise the *whole* TS surface in one go: + * + * account → priced category → priced snapshot → linked transfer → return + * + * Like `category-migration.test.ts` we cannot spin up real `tauri-plugin-sql` + * (the bridge only lives inside the Tauri WebView). Instead we drive every + * service against an in-memory FakeDb that: + * - records every executed SQL, + * - returns hand-tuned `select` results to mimic the real schema, + * - simulates `lastInsertId` / `rowsAffected` for INSERT/DELETE. + * + * The Tauri `invoke` is mocked — `computeAccountReturn` lives on the Rust + * side (`compute_account_return`), so we assert the request payload and + * have the mock return a stable `AccountReturn` shape. The Rust math itself + * is covered by `return_calculator.rs`'s `#[cfg(test)] mod tests`. + * + * Scope (from spec-plan-bilan.md, Issue #144): + * 1. End-to-end happy path + * 2. Currency-lock (CHECK `currency = 'CAD'`) at the service level + * 3. Migration v9 on a seeded DB — covered in Rust (lib.rs `mod tests`) + * 4. TransactionsPage non-regression for the inlined transfer icon + * 5. Coverage best-effort (deferred — see decisions-log.md) + */ + +import { describe, it, expect, vi, beforeEach } from "vitest"; + +vi.mock("../services/db", () => ({ + getDb: vi.fn(), +})); + +vi.mock("@tauri-apps/api/core", () => ({ + invoke: vi.fn(), +})); + +vi.mock("../services/profileService", () => ({ + loadProfiles: vi.fn(), +})); + +import { getDb } from "../services/db"; +import { invoke } from "@tauri-apps/api/core"; +import { loadProfiles } from "../services/profileService"; + +import { + createBalanceCategory, + createBalanceAccount, + listBalanceAccounts, + createSnapshot, + upsertSnapshotLines, + listLinesBySnapshot, + linkTransfer, + unlinkTransfer, + listAccountTransfers, + computeAccountReturn, + BalanceServiceError, + PRICED_VALUE_TOLERANCE, +} from "../services/balance.service"; + +// --------------------------------------------------------------------------- +// FakeDb harness: scripted select results, recorded execute calls. +// --------------------------------------------------------------------------- + +interface FakeDb { + calls: Array<{ sql: string; params?: unknown[] }>; + selectQueue: Array; + executeQueue: Array<{ lastInsertId?: number; rowsAffected?: number }>; + select: ReturnType; + execute: ReturnType; +} + +function makeFakeDb(): FakeDb { + const db: FakeDb = { + calls: [], + selectQueue: [], + executeQueue: [], + select: vi.fn(), + execute: vi.fn(), + }; + db.select.mockImplementation(async (sql: string, params?: unknown[]) => { + db.calls.push({ sql, params }); + if (db.selectQueue.length === 0) { + throw new Error(`Unscripted SELECT (no queued result): ${sql}`); + } + return db.selectQueue.shift(); + }); + db.execute.mockImplementation(async (sql: string, params?: unknown[]) => { + db.calls.push({ sql, params }); + if (db.executeQueue.length === 0) { + // Default: 1 affected row, monotonically increasing lastInsertId + return { rowsAffected: 1, lastInsertId: db.calls.length }; + } + return db.executeQueue.shift(); + }); + return db; +} + +let fake: FakeDb; + +beforeEach(() => { + fake = makeFakeDb(); + vi.mocked(getDb).mockResolvedValue( + { select: fake.select, execute: fake.execute } as never + ); + vi.mocked(invoke).mockReset(); + vi.mocked(loadProfiles).mockReset(); +}); + +// Helper: queue a sequence of SELECT results in FIFO order. +function queueSelects(...rows: unknown[][]) { + for (const r of rows) fake.selectQueue.push(r); +} + +// Helper: queue a sequence of EXECUTE results in FIFO order. +function queueExecutes( + ...results: Array<{ lastInsertId?: number; rowsAffected?: number }> +) { + for (const r of results) fake.executeQueue.push(r); +} + +// --------------------------------------------------------------------------- +// 1. End-to-end happy path +// --------------------------------------------------------------------------- +// +// Walks the full Bilan flow as if the user just installed the app: +// 1. Create a custom priced category ("etf-prov") +// 2. Create an account on that category with a stock symbol +// 3. Reload the joined accounts list and confirm the account is there +// 4. Create a snapshot dated today +// 5. Save a priced line for the new account (qty * price = value) +// 6. Read the lines back and confirm what was persisted +// 7. Link a transaction to the account as a +CAD deposit +// 8. Compute the account's return → mock returns a stable shape, we +// assert the wiring uses the active profile's db_filename and forwards +// every parameter as ISO YYYY-MM-DD. +// +// Each step is asserted at the service-call level (params + queued SQL), +// then we run cross-step sanity checks. + +describe("integration — Bilan end-to-end happy path", () => { + it("walks account → priced category → snapshot → transfer → return cleanly", async () => { + // ---- 1. Create a custom priced category ---- + queueExecutes({ lastInsertId: 100 }); + const categoryId = await createBalanceCategory({ + key: "etf-prov", + i18n_key: "balance.category.etf_prov", + kind: "priced", + sort_order: 80, + }); + expect(categoryId).toBe(100); + + // ---- 2. Create the account on that category ---- + // Service first SELECTs the category to validate it exists, then + // INSERTs the account. + queueSelects([ + { + id: 100, + key: "etf-prov", + i18n_key: "balance.category.etf_prov", + kind: "priced", + sort_order: 80, + is_active: 1, + is_seed: 0, + }, + ]); + queueExecutes({ lastInsertId: 7 }); + const accountId = await createBalanceAccount({ + balance_category_id: categoryId, + name: "VFV (Wealthsimple)", + symbol: "VFV.TO", + }); + expect(accountId).toBe(7); + + // ---- 3. listBalanceAccounts: account joined with category ---- + queueSelects([ + { + id: 7, + balance_category_id: 100, + name: "VFV (Wealthsimple)", + symbol: "VFV.TO", + currency: "CAD", + notes: null, + is_active: 1, + archived_at: null, + created_at: "", + updated_at: "", + category_key: "etf-prov", + category_i18n_key: "balance.category.etf_prov", + category_kind: "priced", + }, + ]); + const accounts = await listBalanceAccounts(); + expect(accounts).toHaveLength(1); + expect(accounts[0].category_kind).toBe("priced"); + expect(accounts[0].symbol).toBe("VFV.TO"); + + // ---- 4. Create a snapshot dated 2026-04-25 ---- + // createSnapshot first SELECTs by date (must be empty) then INSERTs. + queueSelects([]); // no existing snapshot + queueExecutes({ lastInsertId: 50 }); + const snapshotId = await createSnapshot({ snapshot_date: "2026-04-25" }); + expect(snapshotId).toBe(50); + + // ---- 5. Save a priced line: 10 shares × $200 = $2000 ---- + // upsertSnapshotLines: SELECT snapshot, then DELETE existing lines, then + // one INSERT per line, then UPDATE updated_at. + queueSelects([ + { + id: 50, + snapshot_date: "2026-04-25", + notes: null, + created_at: "", + updated_at: "", + }, + ]); + queueExecutes( + { rowsAffected: 0 }, // delete (no prior lines) + { lastInsertId: 200 }, // insert priced line + { rowsAffected: 1 } // bump updated_at + ); + await upsertSnapshotLines(50, [ + { + account_id: 7, + account_kind: "priced", + quantity: 10, + unit_price: 200, + value: 2000, + }, + ]); + + // The 2nd execute call should be the INSERT with the priced placeholders. + const insertCall = fake.calls.find( + (c) => + typeof c.sql === "string" && + c.sql.includes("INSERT INTO balance_snapshot_lines") + ); + expect(insertCall).toBeDefined(); + expect(insertCall!.params).toEqual([50, 7, 10, 200, 2000]); + + // ---- 6. Read the lines back ---- + queueSelects([ + { + id: 200, + snapshot_id: 50, + account_id: 7, + quantity: 10, + unit_price: 200, + value: 2000, + price_source: "manual", + price_fetched_at: null, + created_at: "", + updated_at: "", + }, + ]); + const lines = await listLinesBySnapshot(50); + expect(lines).toHaveLength(1); + expect(lines[0].value).toBe(2000); + expect(lines[0].quantity).toBe(10); + expect(lines[0].unit_price).toBe(200); + + // ---- 7. Link a transaction (id=42) as a +CAD deposit (in) ---- + // linkTransfer: SELECT existing duplicate (none), then INSERT. + queueSelects([]); // no existing duplicate + queueExecutes({ lastInsertId: 9 }); + const transferId = await linkTransfer(7, 42, "in", "monthly contribution"); + expect(transferId).toBe(9); + const linkCall = fake.calls.find( + (c) => + typeof c.sql === "string" && + c.sql.includes("INSERT INTO balance_account_transfers") + ); + expect(linkCall).toBeDefined(); + expect(linkCall!.params).toEqual([7, 42, "in", "monthly contribution"]); + + // ---- 8. Compute the account return ---- + vi.mocked(loadProfiles).mockResolvedValueOnce({ + active_profile_id: "max", + profiles: [ + { + id: "max", + name: "Max", + color: "#3b82f6", + pin_hash: null, + db_filename: "max.db", + created_at: "0", + }, + ], + }); + const fakeReturn = { + value_start: 1500, + value_end: 2000, + net_contributions: 400, + return_pct: 0.0667, // (2000 - 1500 - 400) / (1500 + W*400) ≈ 6.67% + annualized_pct: 0.28, + is_partial: false, + has_no_transfers_warning: false, + }; + vi.mocked(invoke).mockResolvedValueOnce(fakeReturn); + + const ret = await computeAccountReturn(7, "2026-01-01", "2026-04-25"); + expect(ret).toEqual(fakeReturn); + + // Wiring check: profile resolution + ISO date forwarding. + expect(invoke).toHaveBeenCalledWith("compute_account_return", { + dbFilename: "max.db", + accountId: 7, + periodStart: "2026-01-01", + periodEnd: "2026-04-25", + }); + + // ---- Cross-step sanity: every coherent value matches expectations. + // The end snapshot value (2000) matches what we saved. + expect(ret.value_end).toBe(2000); + // The reported return is a finite, non-zero number on a non-trivial period. + expect(ret.return_pct).not.toBeNull(); + expect(Number.isFinite(ret.return_pct!)).toBe(true); + // Net contributions match the 1 linked transfer (+400 in). + expect(ret.net_contributions).toBeGreaterThan(0); + }); + + it("supports unlink as the inverse of link", async () => { + queueExecutes({ rowsAffected: 1 }); + await expect(unlinkTransfer(7, 42)).resolves.toBeUndefined(); + const unlinkCall = fake.calls.find( + (c) => + typeof c.sql === "string" && + c.sql.includes("DELETE FROM balance_account_transfers") + ); + expect(unlinkCall!.params).toEqual([7, 42]); + }); + + it("listAccountTransfers reads back what link wrote (joined view)", async () => { + queueSelects([ + { + id: 9, + account_id: 7, + transaction_id: 42, + direction: "in", + notes: "monthly contribution", + created_at: "2026-04-25 10:00:00", + transaction_date: "2026-04-15", + transaction_description: "Wealthsimple contrib", + transaction_amount: -400, + account_name: "VFV (Wealthsimple)", + }, + ]); + const links = await listAccountTransfers(7); + expect(links).toHaveLength(1); + expect(links[0].direction).toBe("in"); + expect(links[0].account_name).toBe("VFV (Wealthsimple)"); + }); +}); + +// --------------------------------------------------------------------------- +// 2. Currency lock — CAD only at the MVP +// --------------------------------------------------------------------------- +// +// The MVP locks accounts to CAD: the SQL CHECK is `currency = 'CAD'` and the +// service rejects any other value with a typed `currency_unsupported` before +// the SQL even fires. Asserts: +// - USD is rejected with the typed code, +// - the rejection happens BEFORE any SELECT/EXECUTE on the DB, +// - the default (no `currency` field) flows through and lands as 'CAD', +// - the SQL CHECK side is covered in Rust (lib.rs `migration_v9_*` tests). + +describe("integration — currency lock (CAD only)", () => { + it("rejects USD at the service level with a typed error", async () => { + await expect( + createBalanceAccount({ + balance_category_id: 1, + name: "USD account", + currency: "USD", + }) + ).rejects.toBeInstanceOf(BalanceServiceError); + + try { + await createBalanceAccount({ + balance_category_id: 1, + name: "USD account", + currency: "USD", + }); + } catch (e) { + expect((e as BalanceServiceError).code).toBe("currency_unsupported"); + } + // CRITICAL: the rejection must happen up-front — no DB hit. + expect(fake.calls.length).toBe(0); + }); + + it("accepts the default and persists 'CAD' explicitly", async () => { + queueSelects([ + { + id: 1, + key: "cash", + i18n_key: "balance.category.cash", + kind: "simple", + sort_order: 10, + is_active: 1, + is_seed: 1, + }, + ]); + queueExecutes({ lastInsertId: 5 }); + await createBalanceAccount({ + balance_category_id: 1, + name: "Encaisse", + }); + const insertCall = fake.calls.find( + (c) => + typeof c.sql === "string" && + c.sql.includes("INSERT INTO balance_accounts") + ); + expect(insertCall).toBeDefined(); + // [category_id, name, symbol, currency, notes] + expect(insertCall!.params).toEqual([1, "Encaisse", null, "CAD", null]); + }); + + it("rejects EUR / GBP / JPY too — not a CAD-only typo allowlist", async () => { + for (const ccy of ["EUR", "GBP", "JPY", "AUD"]) { + await expect( + createBalanceAccount({ + balance_category_id: 1, + name: `Mystery ${ccy}`, + currency: ccy, + }) + ).rejects.toMatchObject({ code: "currency_unsupported" }); + } + expect(fake.calls.length).toBe(0); + }); +}); + +// --------------------------------------------------------------------------- +// 3. Priced-kind invariant — coherence of the qty × price = value chain +// --------------------------------------------------------------------------- +// +// Tied to the priced-kind path, but at the integration layer: a snapshot +// saved with a drifting (qty * price ≠ value) line must be rejected before +// any DB mutation, so the SQL CHECK never has the chance to fire and we +// don't accidentally clear pre-existing lines. + +describe("integration — priced invariant rejects out-of-tolerance saves", () => { + it("does not run DELETE when one line is bad", async () => { + queueSelects([ + { + id: 50, + snapshot_date: "2026-04-25", + notes: null, + created_at: "", + updated_at: "", + }, + ]); + await expect( + upsertSnapshotLines(50, [ + { account_id: 1, value: 1000 }, + { + account_id: 7, + account_kind: "priced", + quantity: 10, + unit_price: 25, + // expected ≈ 250, way beyond ε + value: 999, + }, + ]) + ).rejects.toMatchObject({ code: "snapshot_priced_value_mismatch" }); + + // Critical safety: the DELETE must not have fired — otherwise the user + // would lose all existing lines on a partial save. + const deletes = fake.calls.filter( + (c) => + typeof c.sql === "string" && + c.sql.includes("DELETE FROM balance_snapshot_lines") + ); + expect(deletes).toHaveLength(0); + }); + + it("accepts a drift just within the tolerance", async () => { + queueSelects([ + { + id: 50, + snapshot_date: "2026-04-25", + notes: null, + created_at: "", + updated_at: "", + }, + ]); + queueExecutes( + { rowsAffected: 0 }, + { lastInsertId: 1 }, + { rowsAffected: 1 } + ); + // 12.34 * 1.07 = 13.2038... — drift well within ε = 0.01 + const drift = PRICED_VALUE_TOLERANCE * 0.5; + await expect( + upsertSnapshotLines(50, [ + { + account_id: 7, + account_kind: "priced", + quantity: 10, + unit_price: 10, + value: 100 + drift, + }, + ]) + ).resolves.toBeUndefined(); + }); +}); + +// --------------------------------------------------------------------------- +// 4. Returns: malformed period dates rejected before the Tauri invoke +// --------------------------------------------------------------------------- + +describe("integration — computeAccountReturn validates dates client-side", () => { + it("rejects non-ISO dates without invoking the Rust command", async () => { + vi.mocked(loadProfiles).mockResolvedValueOnce({ + active_profile_id: "max", + profiles: [ + { + id: "max", + name: "Max", + color: "#000", + pin_hash: null, + db_filename: "max.db", + created_at: "0", + }, + ], + }); + await expect( + computeAccountReturn(7, "01/01/2026", "2026-04-25") + ).rejects.toBeInstanceOf(BalanceServiceError); + // The Tauri side must NOT have been hit — fail-fast on bad dates. + expect(invoke).not.toHaveBeenCalled(); + }); + + it("rejects when the active profile cannot be resolved", async () => { + vi.mocked(loadProfiles).mockResolvedValueOnce({ + active_profile_id: "ghost", + profiles: [], + }); + await expect( + computeAccountReturn(7, "2026-01-01", "2026-04-25") + ).rejects.toMatchObject({ code: "transfer_active_profile_unknown" }); + expect(invoke).not.toHaveBeenCalled(); + }); + + it("forwards a partial-period AccountReturn shape unchanged", async () => { + // When `is_partial = true` (no V_start), the Rust side returns a payload + // with explicit nulls. The TS shim must not coerce them away. + vi.mocked(loadProfiles).mockResolvedValueOnce({ + active_profile_id: "max", + profiles: [ + { + id: "max", + name: "Max", + color: "#000", + pin_hash: null, + db_filename: "max.db", + created_at: "0", + }, + ], + }); + const partial = { + value_start: null, + value_end: 1500, + net_contributions: 200, + return_pct: null, + annualized_pct: null, + is_partial: true, + has_no_transfers_warning: false, + }; + vi.mocked(invoke).mockResolvedValueOnce(partial); + const out = await computeAccountReturn(7, "2026-01-01", "2026-04-25"); + expect(out).toEqual(partial); + expect(out.is_partial).toBe(true); + expect(out.value_start).toBeNull(); + }); +}); From 50fe0ab1ac04cc3f67e4426dcfc8c7ec37da802c Mon Sep 17 00:00:00 2001 From: le king fu Date: Sat, 25 Apr 2026 16:53:50 -0400 Subject: [PATCH 2/4] test(balance): add migration v9 integration on seeded DB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three new Rust integration tests applied at the bottom of `lib.rs`'s `#[cfg(test)] mod tests`. They exercise the realistic upgrade path: a v1 profile DB with imported transactions + categories already there gets the v9 migration applied on top. `migration_v9_preserves_existing_transactions_on_seeded_db` asserts no row loss / data mutation after the migration runs. Spot-checks one amount preserved verbatim and that the v9 seeded categories coexist with the v1 categories table. `integration_link_unlink_transfer_roundtrip_on_seeded_db` walks link → joined-view read → blocked deletion (FK RESTRICT) → unlink → allowed deletion → orphan-row sanity check. Covers the FK chain end-to-end on real (non-stub) transaction ids. `integration_modified_dietz_inputs_read_back_correctly_on_seeded_db` mirrors the exact SQL used by `balance_commands.rs::read_value_at_or_before` and `read_cash_flows`, asserting the snapshot-endpoint lookups and the period-bounded JOINed cash flows return the expected shapes when run against a seeded v1+v9 DB. `integration_v9_preserves_v1_categories_and_keywords` verifies the `categories.id` and `balance_categories.id` namespaces are independent (same numeric id allowed on each table without collision). Co-Authored-By: Claude Opus 4.7 (1M context) --- src-tauri/src/lib.rs | 348 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 348 insertions(+) diff --git a/src-tauri/src/lib.rs b/src-tauri/src/lib.rs index 3b50b03..58c144f 100644 --- a/src-tauri/src/lib.rs +++ b/src-tauri/src/lib.rs @@ -692,5 +692,353 @@ mod tests { .unwrap(); assert_eq!(count, 7, "seed must remain idempotent on replay"); } + + // ------------------------------------------------------------------------- + // Issue #144 (Bilan #6) — integration tests on a seeded DB + // ------------------------------------------------------------------------- + // + // The previous tests apply BALANCE_SCHEMA on an empty DB. These tests + // simulate the realistic upgrade path: a profile DB with imported + // transactions already there gets the v9 migration applied on top, and + // we verify: + // - existing transactions are not affected by the migration (no row + // loss, no schema collision), + // - link / unlink transfer round-trips on real (non-stub) transaction + // ids, + // - the FK RESTRICT correctly chains: try to delete a linked + // transaction → blocked, unlink → delete succeeds. + + /// Seed a DB with the *full app schema* (transactions + categories + + /// keywords + suppliers + adjustments + ...) then apply BALANCE_SCHEMA on + /// top — mirroring what migration v9 does on an existing user profile. + /// Returns the connection ready for assertions. + fn seeded_db_with_balance_schema() -> Connection { + let conn = Connection::open_in_memory().expect("open in-memory db"); + conn.execute("PRAGMA foreign_keys = ON;", []) + .expect("enable FKs"); + // Apply the full app schema (v1) — we only need the transactions + // table for the v9 FK, but applying the whole schema verifies that + // nothing in v9 collides with the existing tables. + conn.execute_batch(crate::database::SCHEMA) + .expect("apply v1 SCHEMA"); + // Pre-seed a few transactions to mimic an existing profile (the user + // already had data when we shipped v9). + conn.execute_batch( + "INSERT INTO transactions (date, description, amount) VALUES + ('2026-01-15', 'Salary deposit', 3500.0), + ('2026-02-01', 'Wealthsimple contribution', -400.0), + ('2026-03-15', 'Grocery store', -125.50), + ('2026-04-01', 'Wealthsimple contribution', -400.0);", + ) + .expect("seed transactions"); + // Now apply v9 on top — same way the runtime would. + conn.execute_batch(crate::database::BALANCE_SCHEMA) + .expect("apply v9 BALANCE_SCHEMA on seeded DB"); + conn + } + + #[test] + fn migration_v9_preserves_existing_transactions_on_seeded_db() { + let conn = seeded_db_with_balance_schema(); + // Existing transactions must be untouched by the migration. + let count: i64 = conn + .query_row("SELECT COUNT(*) FROM transactions", [], |row| row.get(0)) + .unwrap(); + assert_eq!(count, 4, "existing transactions must survive the migration"); + + // Spot-check one row's content (no silent data mutation). + let amount: f64 = conn + .query_row( + "SELECT amount FROM transactions WHERE description = 'Salary deposit'", + [], + |row| row.get(0), + ) + .unwrap(); + assert!( + (amount - 3500.0).abs() < f64::EPSILON, + "salary amount must be preserved verbatim" + ); + + // The seeded categories from BALANCE_SCHEMA must coexist with the + // pre-existing categories table from v1 (different name, no clash). + let bal_cat_count: i64 = conn + .query_row( + "SELECT COUNT(*) FROM balance_categories WHERE is_seed = 1", + [], + |row| row.get(0), + ) + .unwrap(); + assert_eq!(bal_cat_count, 7); + } + + #[test] + fn integration_link_unlink_transfer_roundtrip_on_seeded_db() { + let conn = seeded_db_with_balance_schema(); + + // Create a balance account on the seeded 'cash' category. + conn.execute( + "INSERT INTO balance_accounts (balance_category_id, name) + VALUES ((SELECT id FROM balance_categories WHERE key='cash'), 'Wealthsimple cash')", + [], + ) + .unwrap(); + let account_id: i64 = conn + .query_row("SELECT id FROM balance_accounts LIMIT 1", [], |r| r.get(0)) + .unwrap(); + + // Pick the Feb contribution (-$400) — a typical "in" transfer for the + // Wealthsimple account from the bank perspective. + let tx_id: i64 = conn + .query_row( + "SELECT id FROM transactions WHERE date = '2026-02-01'", + [], + |r| r.get(0), + ) + .unwrap(); + + // 1. Link + let inserted = conn + .execute( + "INSERT INTO balance_account_transfers (account_id, transaction_id, direction, notes) + VALUES (?1, ?2, 'in', 'monthly contribution')", + rusqlite::params![account_id, tx_id], + ) + .expect("link succeeds with real transaction id"); + assert_eq!(inserted, 1); + + // 2. Verify the row is queryable through the joined view used by + // `listAccountTransfers` in TS. + let (joined_amount, direction): (f64, String) = conn + .query_row( + "SELECT t.amount, bat.direction + FROM balance_account_transfers bat + JOIN transactions t ON t.id = bat.transaction_id + WHERE bat.account_id = ?1", + rusqlite::params![account_id], + |r| Ok((r.get(0)?, r.get(1)?)), + ) + .expect("joined view must read"); + assert!((joined_amount - (-400.0)).abs() < f64::EPSILON); + assert_eq!(direction, "in"); + + // 3. Try to delete the linked transaction — must be blocked (RESTRICT). + let blocked = conn.execute( + "DELETE FROM transactions WHERE id = ?1", + rusqlite::params![tx_id], + ); + assert!( + blocked.is_err(), + "linked transaction deletion must be blocked by FK RESTRICT" + ); + + // 4. Unlink + let unlinked = conn + .execute( + "DELETE FROM balance_account_transfers + WHERE account_id = ?1 AND transaction_id = ?2", + rusqlite::params![account_id, tx_id], + ) + .expect("unlink succeeds"); + assert_eq!(unlinked, 1); + + // 5. After unlink, deleting the transaction must succeed. + let allowed = conn + .execute( + "DELETE FROM transactions WHERE id = ?1", + rusqlite::params![tx_id], + ) + .expect("after unlink, transaction can be deleted"); + assert_eq!(allowed, 1); + + // 6. Sanity: no orphan transfer rows survived. + let remaining_links: i64 = conn + .query_row( + "SELECT COUNT(*) FROM balance_account_transfers WHERE transaction_id = ?1", + rusqlite::params![tx_id], + |r| r.get(0), + ) + .unwrap(); + assert_eq!(remaining_links, 0); + } + + #[test] + fn integration_modified_dietz_inputs_read_back_correctly_on_seeded_db() { + // Reads back the snapshot endpoints + cash flows the way + // `compute_account_return` does, on a DB that has both v1 transactions + // and v9 balance tables. Asserts the SQL queries used by + // `balance_commands.rs::read_value_at_or_before` and `read_cash_flows` + // return the expected shapes. + let conn = seeded_db_with_balance_schema(); + + conn.execute( + "INSERT INTO balance_accounts (balance_category_id, name) + VALUES ((SELECT id FROM balance_categories WHERE key='cash'), 'Wealthsimple cash')", + [], + ) + .unwrap(); + let account_id: i64 = conn + .query_row("SELECT id FROM balance_accounts LIMIT 1", [], |r| r.get(0)) + .unwrap(); + + // Two snapshot endpoints (V_start, V_end) and one mid-period contribution. + conn.execute( + "INSERT INTO balance_snapshots (snapshot_date) VALUES + ('2026-01-01'), + ('2026-04-01')", + [], + ) + .unwrap(); + let s_start: i64 = conn + .query_row( + "SELECT id FROM balance_snapshots WHERE snapshot_date='2026-01-01'", + [], + |r| r.get(0), + ) + .unwrap(); + let s_end: i64 = conn + .query_row( + "SELECT id FROM balance_snapshots WHERE snapshot_date='2026-04-01'", + [], + |r| r.get(0), + ) + .unwrap(); + conn.execute( + "INSERT INTO balance_snapshot_lines (snapshot_id, account_id, value) + VALUES (?1, ?2, 1000.0)", + rusqlite::params![s_start, account_id], + ) + .unwrap(); + conn.execute( + "INSERT INTO balance_snapshot_lines (snapshot_id, account_id, value) + VALUES (?1, ?2, 1500.0)", + rusqlite::params![s_end, account_id], + ) + .unwrap(); + + // Link the Feb 1 contribution as an `in` transfer. + let tx_id: i64 = conn + .query_row( + "SELECT id FROM transactions WHERE date='2026-02-01'", + [], + |r| r.get(0), + ) + .unwrap(); + conn.execute( + "INSERT INTO balance_account_transfers (account_id, transaction_id, direction) + VALUES (?1, ?2, 'in')", + rusqlite::params![account_id, tx_id], + ) + .unwrap(); + + // Mirror `read_value_at_or_before` for V_start — exact SQL used in + // `balance_commands.rs`. + let v_start: Option = conn + .query_row( + "SELECT l.value + FROM balance_snapshot_lines l + JOIN balance_snapshots s ON s.id = l.snapshot_id + WHERE l.account_id = ?1 + AND s.snapshot_date <= ?2 + ORDER BY s.snapshot_date DESC + LIMIT 1", + rusqlite::params![account_id, "2026-01-01"], + |r| r.get(0), + ) + .ok(); + assert_eq!(v_start, Some(1000.0)); + + // V_end at 2026-04-01 — picks up the second snapshot. + let v_end: Option = conn + .query_row( + "SELECT l.value + FROM balance_snapshot_lines l + JOIN balance_snapshots s ON s.id = l.snapshot_id + WHERE l.account_id = ?1 + AND s.snapshot_date <= ?2 + ORDER BY s.snapshot_date DESC + LIMIT 1", + rusqlite::params![account_id, "2026-04-01"], + |r| r.get(0), + ) + .ok(); + assert_eq!(v_end, Some(1500.0)); + + // Cash flows in [2026-01-01, 2026-04-01] — exactly one (-400 abs amount → +400 in). + let mut stmt = conn + .prepare( + "SELECT t.date, ABS(t.amount), bat.direction + FROM balance_account_transfers bat + JOIN transactions t ON t.id = bat.transaction_id + WHERE bat.account_id = ?1 + AND t.date BETWEEN ?2 AND ?3 + ORDER BY t.date", + ) + .unwrap(); + let flows: Vec<(String, f64, String)> = stmt + .query_map( + rusqlite::params![account_id, "2026-01-01", "2026-04-01"], + |r| Ok((r.get(0)?, r.get(1)?, r.get(2)?)), + ) + .unwrap() + .map(|r| r.unwrap()) + .collect(); + assert_eq!(flows.len(), 1); + assert_eq!(flows[0].0, "2026-02-01"); + assert!((flows[0].1 - 400.0).abs() < f64::EPSILON); + assert_eq!(flows[0].2, "in"); + } + + #[test] + fn integration_v9_preserves_v1_categories_and_keywords() { + // Defensive: v9 introduces `balance_categories` while v1 already has + // `categories`. Make sure neither is mistaken for the other and that + // the v1 seeds (when present) survive the migration cleanly. + let conn = seeded_db_with_balance_schema(); + + // Insert a v1 category + keyword (mimicking v1 seed data already present). + conn.execute( + "INSERT INTO categories (id, name, type, color, sort_order) + VALUES (50, 'Épicerie', 'expense', '#10b981', 50)", + [], + ) + .unwrap(); + conn.execute( + "INSERT INTO keywords (keyword, category_id, priority, is_active) + VALUES ('IGA', 50, 100, 1)", + [], + ) + .unwrap(); + + // Now insert a v9 category with the SAME numeric id (should be allowed + // — different table, different namespace). + conn.execute( + "INSERT INTO balance_categories (id, key, i18n_key, kind, sort_order) + VALUES (50, 'mortgage', 'balance.category.mortgage', 'simple', 100)", + [], + ) + .expect( + "balance_categories.id namespace must be independent from categories.id", + ); + + // The v1 row is untouched. + let v1_name: String = conn + .query_row( + "SELECT name FROM categories WHERE id = 50", + [], + |r| r.get(0), + ) + .unwrap(); + assert_eq!(v1_name, "Épicerie"); + + // The v9 row is queryable on its own table. + let v9_key: String = conn + .query_row( + "SELECT key FROM balance_categories WHERE id = 50", + [], + |r| r.get(0), + ) + .unwrap(); + assert_eq!(v9_key, "mortgage"); + } } From 5a54d37de57a228114cdf30bcb5bd79c3328733d Mon Sep 17 00:00:00 2001 From: le king fu Date: Sat, 25 Apr 2026 16:53:59 -0400 Subject: [PATCH 3/4] test(transactions): add non-regression test for inline transfer icon Source-level structural test on `TransactionTable.tsx` to lock down the inlined transfer icon contract introduced in #142. Without RTL or jsdom in the dev-deps, the test reads the component source and asserts: - the icon is gated by `linkedTransfersByTxId?.has(row.id)`, - optional-chaining short-circuits cleanly when the prop is omitted (zero-impact on pre-#142 callers), - the prop is declared OPTIONAL on the component interface, - the `Link2` glyph comes from lucide-react, - tooltip + aria-label go through `transactions.transferIcon.*` i18n keys, - the row's description cell layout (truncate span + title) stays shared between linked and non-linked rows. Catches the specific regression vectors: someone removing the gate, renaming the prop, or breaking the optional-chaining pattern that guarantees the page renders identically when no transfers are linked. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../transactions-transfer-icon.test.ts | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 src/__integration__/transactions-transfer-icon.test.ts diff --git a/src/__integration__/transactions-transfer-icon.test.ts b/src/__integration__/transactions-transfer-icon.test.ts new file mode 100644 index 0000000..5e5803b --- /dev/null +++ b/src/__integration__/transactions-transfer-icon.test.ts @@ -0,0 +1,96 @@ +/** + * Non-regression check for the inlined transfer icon in TransactionTable + * (Issue #142 → #144 follow-up). + * + * The spec promises that — without any linked transfers — the transactions + * table renders exactly as it did before #142 inlined the `` icon. + * The icon is gated by a single conditional in the JSX: + * + * {linkedTransfersByTxId?.has(row.id) && (...)} + * + * If `linkedTransfersByTxId` is undefined OR the map has no entry for `row.id`, + * the icon block is short-circuited and the row layout is unchanged. + * + * Why this approach: this project does not bundle `@testing-library/react` + * (see `package.json`), and adding it just for one non-regression check is + * out of scope here. Existing component tests (`CategoryCombobox.test.ts`, + * `ViewModeToggle.test.ts`, `TrendsChartTypeToggle.test.ts`) likewise extract + * pure helpers and assert on them rather than mounting JSX. So we go one + * level lower: assert the source-level shape of `TransactionTable.tsx`. + * + * The assertions are structural on the source file: + * 1. The conditional block exists and is gated by `linkedTransfersByTxId?.has`. + * 2. The block consumes `Link2` from `lucide-react`. + * 3. The prop is OPTIONAL on the component's interface — passing nothing + * must remain a valid call (zero-impact path). + * 4. The tooltip text comes from the i18n key family `transactions.transferIcon.*` + * (so a future rename catches our attention here). + * 5. The icon uses `aria-label` for accessibility (Issue #142 acceptance criterion). + * 6. The condition uses optional-chaining (so passing `undefined` short-circuits + * cleanly without throwing). + * + * If the icon is ever pulled out into its own component, the tests should be + * rewritten to import and exercise that component directly instead. Until + * then, this is a tight static contract that catches accidental regressions. + */ + +import { describe, it, expect } from "vitest"; +import { readFileSync } from "fs"; +import { resolve } from "path"; + +const TABLE_SRC = readFileSync( + resolve( + import.meta.dirname, + "..", + "components", + "transactions", + "TransactionTable.tsx" + ), + "utf-8" +); + +describe("non-regression: TransactionTable transfer icon (#142)", () => { + it("guards the icon block behind `linkedTransfersByTxId?.has(row.id)`", () => { + expect(TABLE_SRC).toMatch(/linkedTransfersByTxId\?\.has\(row\.id\)/); + }); + + it("uses optional chaining so the icon is opt-in (undefined short-circuits)", () => { + // Optional chaining is the safe-render guarantee: if the parent never + // passes the prop, `?.has` returns undefined → the && short-circuits to + // false, the JSX block is skipped, and the row layout is unchanged. + expect(TABLE_SRC).toMatch(/linkedTransfersByTxId\?\./); + }); + + it("imports `Link2` from lucide-react for the icon glyph", () => { + expect(TABLE_SRC).toMatch(/from\s+["']lucide-react["']/); + expect(TABLE_SRC).toMatch(/\bLink2\b/); + }); + + it("declares `linkedTransfersByTxId` as an OPTIONAL prop", () => { + // The "?" after the name on the interface is the contract that omitting + // the prop is allowed. Without it the entire transactions page would + // need to thread the lookup through, breaking pre-#142 callers. + expect(TABLE_SRC).toMatch(/linkedTransfersByTxId\?:/); + }); + + it("uses `transactions.transferIcon.*` i18n keys for the tooltip and aria-label", () => { + // Both the tooltip body and the aria label go through i18n — neither + // is a hardcoded English/French string. + expect(TABLE_SRC).toMatch(/transactions\.transferIcon\.tooltip/); + expect(TABLE_SRC).toMatch(/transactions\.transferIcon\.ariaLabel/); + }); + + it("attaches an `aria-label` for screen readers (a11y)", () => { + expect(TABLE_SRC).toMatch(/aria-label=/); + }); + + it("keeps the description column structure shared with non-linked rows", () => { + // The icon lives inside the description cell, in a flex container + // alongside the original `` that + // existed pre-#142. If someone moved the description span into a + // wrapper that the icon required, this assertion would fail. + expect(TABLE_SRC).toMatch( + / Date: Sat, 25 Apr 2026 16:54:04 -0400 Subject: [PATCH 4/4] chore: CHANGELOG entry for cross-cutting tests Bilingual entry under [Unreleased] documenting the integration test suite added for Issue #144: end-to-end happy path, currency lock, priced-kind tolerance safety, computeAccountReturn wiring, three Rust migration-on-seeded-DB scenarios, and the source-level non-regression test on the inlined transfer icon. Co-Authored-By: Claude Opus 4.7 (1M context) --- CHANGELOG.fr.md | 1 + CHANGELOG.md | 1 + 2 files changed, 2 insertions(+) diff --git a/CHANGELOG.fr.md b/CHANGELOG.fr.md index 2fe3c16..5ec5e0f 100644 --- a/CHANGELOG.fr.md +++ b/CHANGELOG.fr.md @@ -3,6 +3,7 @@ ## [Non publié] ### Ajouté +- **Bilan — suite de tests d'intégration cross-cutting** (infrastructure de tests) : clôt la feature *Bilan* avec une couche de tests d'intégration qui exerce toute la surface TypeScript en un seul flux de bout en bout (compte → catégorie cotée → snapshot coté → transfert lié → rendement) et des assertions dédiées sur le verrou de devise (CAD seulement au MVP, refusé à la fois côté service et côté CHECK SQL), la sécurité de tolérance pour le type coté (un mauvais enregistrement ne doit PAS supprimer les lignes existantes), le câblage de `computeAccountReturn` (résolution du profil actif, transmission des dates ISO, conservation telle quelle d'une réponse de période partielle). Trois nouveaux tests Rust d'intégration appliquent la migration v9 par-dessus un schéma v1 seedé contenant déjà des transactions pour vérifier (1) aucune perte ni mutation de données, (2) le round-trip lier / délier sur de vraies `transaction_id`, (3) la chaîne FK RESTRICT (suppression d'une transaction liée bloquée, autorisée après détachement), (4) la cohabitation indépendante des espaces d'identifiants `categories.id` (v1) et `balance_categories.id` (v9). Un test de non-régression au niveau source sur `TransactionTable.tsx` verrouille le contrat de l'icône de transfert inlinée : prop optionnelle, court-circuit en chaînage optionnel, clés i18n, aria-label, layout partagé de la cellule description — pour que la page reste rendue à l'identique en l'absence de transferts liés. (#144) - **Bilan — rendements Modified Dietz et liaison de transferts** (route `/balance`) : le rendement par compte arrive enfin. Nouveau module Rust `commands/return_calculator.rs` qui implémente la formule Modified Dietz `R = (V_fin − V_début − ΣCF_i) / (V_début + ΣW_i × CF_i)` avec pondération des apports à la précision du jour `W_i = (T − t_i) / T`, et annualisation `(1 + R)^(365/T) − 1`. Les cas limites — snapshot d'extrémité manquant, aucun flux taggé sur la période, compte créé en cours de période, vidé puis rechargé, période de durée nulle — sont surfacés via les flags explicites `is_partial` / `has_no_transfers_warning` pour que l'UI affiche un tiret + tooltip clair plutôt qu'un nombre incompréhensible. Nouvelle commande Tauri `compute_account_return(account_id, period_start, period_end)` qui exécute trois lectures SQL courtes contre la BD du profil actif (dernier snapshot ≤ début de période, dernier snapshot ≤ fin de période, transferts joints aux transactions filtrés sur la période) puis alimente le calculateur. Sept tests Rust co-localisés en TDD couvrent chaque cas avant l'implémentation. Le tableau des comptes sur `/balance` affiche désormais quatre colonnes supplémentaires côte à côte : 3M / 1A / Depuis création (Modified Dietz) plus une colonne *Non ajusté* qui calcule simplement `(V_fin − V_début) / V_début` pour qu'on voie d'un coup d'œil quelle part du rendement vient de la pondération des apports. Le menu d'actions de chaque ligne reçoit l'item *Lier transferts* qui ouvre une modal de sélection multiple avec filtres période / catégorie / recherche texte ; la modal propose automatiquement le sens (`in` pour les montants bancaires négatifs, `out` pour les positifs) et l'utilisateur peut inverser ligne par ligne avant de soumettre. Les transactions liées à un ou plusieurs comptes de bilan affichent maintenant une petite icône `Link2` à côté de la description dans la page *Transactions*, avec un tooltip listant les noms et sens des comptes. Les chemins de suppression en lot (par fichier importé et tout effacer) pré-vérifient l'existence d'un lien dans `balance_account_transfers` et surfacent l'erreur typée `TransactionLinkedToBalanceError` (« Cette transaction est liée au compte de bilan X — déliez-la avant de supprimer ») au lieu de laisser fuiter l'erreur SQLite brute. Le graphique d'évolution sur `/balance` superpose désormais des lignes verticales de référence à chaque date de transfert lié (vert pour `in`, rouge pour `out`). Nouvelles clés i18n sous `balance.returns.*`, `balance.accountsTable.*`, `balance.transfers.*`, `balance.evolution.*`, `transactions.transferIcon.*` (FR + EN) (#142) - **Bilan — page `/balance` avec graphique d'évolution et entrée sidebar** (route `/balance`) : quatrième tranche de la feature *Bilan*, qui la rend enfin accessible depuis la navigation. La nouvelle page compose (1) une carte d'aperçu avec la valeur nette agrégée du dernier snapshot, le Δ% par rapport au snapshot chronologiquement précédent (affiché « — » quand il n'existe qu'un seul snapshot), un avertissement de fraîcheur quand le dernier snapshot date de plus de 60 jours, et un CTA *Nouveau snapshot* qui pointe vers `/balance/snapshot` ; (2) un sélecteur de période (3 mois / 6 mois / 1 an / 3 ans / Tout) qui recharge toutes les séries en parallèle ; (3) un graphique d'évolution avec deux modes — *Ligne* (une seule série `SUM(value) GROUP BY snapshot_date`) et *Empilé par catégorie* (une `` Recharts par `balance_categories.key`) ; (4) un tableau des comptes listant chaque compte actif avec sa dernière valeur snapshot, le Δ% par compte sur la période active (valeur la plus récente vs valeur du premier snapshot dans la fenêtre — null si pas d'ancrage, affiché « — »), et un menu d'actions (Détail désactivé en attendant la #142, Archiver). Les colonnes de rendement (3M / 1A / depuis création / non ajusté) sont réservées pour une version ultérieure avec un commentaire `TODO`. La sidebar expose désormais l'entrée *Bilan* (icône `Wallet`) entre *Rapports* et *Paramètres*. Le service gagne trois helpers de série temporelle : `getSnapshotTotalsByDate(range?)`, `getSnapshotTotalsByCategoryAndDate(range?)`, `getAccountsLatestSnapshot()` ainsi qu'un calcul d'ancrage par compte `getAccountsPeriodAnchor(range)` — tous couverts par des tests unitaires. Nouveau hook `useBalanceOverview` (`useReducer` scoped) qui pilote l'état de la page. Nouvelles clés i18n sous `balance.overview.*`, `balance.period.*`, `balance.chart.*` plus `nav.balance` (FR + EN) (#141) - **Bilan — type coté (quantité × prix unitaire)** (routes `/balance/accounts` et `/balance/snapshot`) : troisième tranche de la feature *Bilan*. Les catégories exposent désormais un sélecteur de *type* à la création : `simple` (saisie d'un montant direct) ou `coté` (`quantité × prix_unitaire`). Les comptes liés à une catégorie cotée exigent un symbole. L'éditeur de snapshot bascule selon le type de la catégorie du compte : les comptes simples conservent leur unique champ de valeur ; les comptes cotés affichent trois champs — `quantité`, `prix unitaire` (les deux obligatoires) et un champ `valeur` en lecture seule calculé en temps réel à partir de `quantité × prix unitaire` (arrondi à 2 décimales). Une étiquette d'attribution `[Manuel]` apparaît sur chaque ligne cotée ; la future étiquette `[via Maximus le AAAA-MM-JJ]` arrivera avec la récupération automatique des prix. Le bouton *Pré-remplir depuis le précédent* copie maintenant les quantités pour les comptes cotés mais laisse les prix unitaires vides (un prix frais doit être saisi à chaque fois). Le service valide les lignes cotées avant la CHECK SQL : invariants de type (les lignes cotées doivent porter à la fois quantité et prix unitaire ; les lignes simples ne doivent porter ni l'un ni l'autre) et invariant de valeur `|valeur − quantité × prix unitaire| ≤ 0,01` (un centime de tolérance pour absorber les arrondis flottants). La suppression d'une catégorie est désormais mieux guardée : une catégorie liée à un ou plusieurs comptes affiche un bandeau d'erreur listant le nombre et jusqu'à trois noms de comptes pour que l'utilisateur sache exactement lesquels archiver d'abord ; les catégories standard restent protégées côté service avec leur bouton désactivé dans l'interface. Nouvelles clés i18n `balance.category.kind.*`, `balance.category.form.kindLabel/kindHint*`, `balance.category.error.has_accounts`, `balance.snapshot.priced.*` (FR + EN) (#140) diff --git a/CHANGELOG.md b/CHANGELOG.md index fce2f81..d48aa3f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,7 @@ ## [Unreleased] ### Added +- **Balance sheet — cross-cutting integration test suite** (test infrastructure): closes out the *Bilan* feature with a layer of integration tests that exercise the whole TypeScript surface in a single happy-path flow (account → priced category → priced snapshot → linked transfer → return) plus dedicated assertions for currency lock (CAD-only at the MVP, rejected at both the service layer and SQL CHECK), priced-kind tolerance safety (a bad save must NOT clear pre-existing lines), `computeAccountReturn` wiring (active-profile resolution, ISO date forwarding, partial-period payload pass-through). Three new Rust integration tests apply migration v9 on top of a seeded v1 schema with pre-existing transactions to verify (1) no row loss / data mutation, (2) link / unlink transfer round-trip on real transaction ids, (3) the FK RESTRICT chain (linked transaction deletion blocked, unblocked after unlink), (4) the v1 `categories.id` and v9 `balance_categories.id` namespaces coexist independently. A non-regression source-level test on `TransactionTable.tsx` locks down the inlined transfer icon contract: optional prop, optional-chaining short-circuit, i18n keys, aria-label, shared description-cell layout — so the page renders identically when no transfers are linked. (#144) - **Balance sheet — Modified Dietz returns and transfer linking** (route `/balance`): per-account performance now ships. New Rust module `commands/return_calculator.rs` implements the Modified Dietz formula `R = (V_end − V_start − ΣCF_i) / (V_start + ΣW_i × CF_i)` with day-precision contribution weights `W_i = (T − t_i) / T`, plus `(1 + R)^(365/T) − 1` annualization. Edge cases — missing endpoint snapshot, no flows tagged in the period, account created mid-period, depleted-then-refilled, zero-length period — are surfaced with explicit `is_partial` / `has_no_transfers_warning` flags so the UI shows a clean dash + tooltip instead of a confusing number. The new Tauri command `compute_account_return(account_id, period_start, period_end)` runs three short SQL reads against the active profile DB (latest snapshot ≤ period start, latest snapshot ≤ period end, transfers JOINed with transactions filtered to the period) and feeds the calculator. Seven co-located TDD tests cover every case before the implementation. The accounts table on `/balance` now shows four extra columns side-by-side: 3M / 1Y / Since-inception (Modified Dietz) plus an *Unadjusted* column showing the simple `(V_end − V_start) / V_start` so the user can see at a glance how much of the return came from contribution timing. Each row's actions menu gains a *Link transfers* item that opens a multi-select modal with date range / category / free-text filters; the modal auto-proposes the direction (`in` for negative bank amounts, `out` for positive) and the user can flip it per row before submitting. Transactions linked to one or more balance accounts now show a small `Link2` icon next to the description in the *Transactions* page, with a tooltip listing the account name(s) and direction(s). Bulk transaction-deletion paths (per-imported-file and clear-all) now pre-check for any link in `balance_account_transfers` and surface a typed `TransactionLinkedToBalanceError` ("This transaction is linked to balance account X — unlink it before deleting") instead of leaking the raw SQLite FK error. The evolution chart on `/balance` now overlays vertical reference lines at every linked-transfer date (green for `in`, red for `out`). New i18n keys under `balance.returns.*`, `balance.accountsTable.*`, `balance.transfers.*`, `balance.evolution.*`, `transactions.transferIcon.*` (FR + EN) (#142) - **Balance sheet — `/balance` overview page, evolution chart and sidebar entry** (route `/balance`): fourth slice of the *Bilan* feature finally surfaces it in the navigation. The new page composes (1) an overview card with the latest aggregate net worth, the Δ% versus the previous chronological snapshot (rendered as "—" when only one snapshot exists), a 60-day staleness warning when the latest snapshot is older than that threshold, and a *New snapshot* CTA pointing at `/balance/snapshot`; (2) a period selector (3 months / 6 months / 1 year / 3 years / All) that re-fetches every series in parallel; (3) an evolution chart with two modes — *Line* (single series of `SUM(value) GROUP BY snapshot_date`) and *Stacked by category* (one Recharts `` per `balance_categories.key`); (4) an accounts table listing every active account with its latest snapshot value, the per-account Δ% over the active period (latest value vs the value at the earliest snapshot inside the window — null when no anchor exists, rendered as "—"), and an actions menu (Details placeholder, Archive). Return-metric columns (3M / 1Y / since-creation / unadjusted) are reserved for a later release with a `TODO` marker. The sidebar now exposes the *Balance sheet* entry (`Wallet` icon) between *Reports* and *Settings*. The service grows three time-series helpers: `getSnapshotTotalsByDate(range?)`, `getSnapshotTotalsByCategoryAndDate(range?)`, `getAccountsLatestSnapshot()` and a per-account anchor query `getAccountsPeriodAnchor(range)` — all guarded by unit tests. New `useBalanceOverview` hook (scoped `useReducer`) drives the page state. New i18n keys under `balance.overview.*`, `balance.period.*`, `balance.chart.*` plus `nav.balance` (FR + EN) (#141) - **Balance sheet — priced kind (quantity × unit price)** (routes `/balance/accounts` and `/balance/snapshot`): third slice of the *Bilan* feature. Categories now expose a *kind* selector at creation: `simple` (direct value entry) or `priced` (`quantity × unit_price`). Accounts linked to a priced category require a symbol. The snapshot editor dispatches on the account's category kind: simple accounts keep their single value field, priced accounts get three inputs — `quantity`, `unit_price` (both required) and a read-only `value` field computed live from `quantity × unit_price` (rounded to 2 decimals). A `[Manual]` / `[Manuel]` attribution tag is shown on each priced row; the future `[via Maximus on YYYY-MM-DD]` tag will land with automatic price-fetching. The *Prefill from previous* button now copies quantities for priced accounts but leaves unit prices blank (a fresh price must be entered each time). The service validates priced lines ahead of the SQL CHECK: kind invariants (priced lines must carry both quantity and unit_price; simple lines must carry neither) and a value-match invariant `|value − quantity × unit_price| ≤ 0.01` (one cent tolerance to absorb floating-point drift). Category deletion now blocks earlier and surfaces a richer error: a category linked to one or more accounts shows a dismissable banner listing the count and up to three account names so the user knows exactly which accounts to archive first; seeded categories remain protected at the service layer with their button disabled in the UI. New i18n keys `balance.category.kind.*`, `balance.category.form.kindLabel/kindHint*`, `balance.category.error.has_accounts`, `balance.snapshot.priced.*` (FR + EN) (#140)