Bank Ledger Bug Hunt: Five Production Bugs

This problem departs from the standard three-phase arc. There is no feature to add and no optimization to do. The codebase is a small bank ledger with five independent production-style bugs planted in it, and the test suite has five scenarios that fail until each bug is fixed. Your job is to find and fix all five. The shape of this exercise mirrors what real on-call engineers do: a service is misbehaving in several ways at once, and you triage by reading the failing tests, scoping the suspect code, forming a hypothesis per failure, fixing the smallest thing, and verifying with the next test run. The AI is most useful here as a fast pair of eyes for scanning files; it is least useful when you let it propose a rewrite of a method without showing you which line was actually wrong. The codebase ```java class Account { String accountId; String holderName; long balance; // cents; long avoids floating-point money boolean frozen; } class Transaction { String accountId; // the account this transaction concerns String type; // "DEPOSIT", "WITHDRAW", "TRANSFER_IN", "TRANSFER_OUT" long cents; String counterpartyAccountId; // for transfers; null otherwise } class Bank { public String createAccount(String holderName); // returns a new accountId public void deposit(String accountId, long cents); public void withdraw(String accountId, long cents); public void transfer(String fromId, String toId, long cents); public long getBalance(String accountId); public List<Transaction> getHistory(String accountId); public void freezeAccount(String accountId); } ``` The behaviour the tests expect - All amounts are integer cents and must be strictly positive. Zero or negative amounts on `deposit`, `withdraw`, or `transfer` throw `IllegalArgumentException`. - `withdraw` requires sufficient funds. Insufficient funds throw `IllegalStateException`. The balance is unchanged on failure. - `transfer` requires both accounts to exist, the source to have sufficient funds, and the source to not be frozen. Failures throw and leave both balances unchanged. - `freezeAccount` flips a flag. While an account is frozen, `withdraw` and source-side `transfer` throw `IllegalStateException`. Deposits and incoming transfers still work, because real banks freeze the outflow side only. - `getHistory(accountId)` returns the transactions that involve this account, in chronological (insertion) order. For a transfer, both the source account and the destination account see one entry each (`TRANSFER_OUT` and `TRANSFER_IN`). - Unknown account ids throw `IllegalArgumentException`. The validator runs five scenarios 1. bug1_transfer_credits_destination: after `A` (balance $100) transfers $40 to `B` (balance $0), `A` has $60 and `B` has $40. The bug is that the destination's balance never gets credited. 2. bug2_overdraft_rejected: `withdraw` on insufficient funds throws `IllegalStateException` and leaves the balance untouched. `transfer` from a source that does not have the funds also throws and leaves both balances untouched. 3. bug3_amounts_must_be_positive: `deposit`, `withdraw`, and `transfer` reject zero and negative amounts with `IllegalArgumentException`. State is unchanged on rejection. 4. bug4_frozen_account_rejects_outflow: a frozen account cannot `withdraw` and cannot be the source of a `transfer`. Both throw `IllegalStateException`. The frozen account can still receive deposits and incoming transfers. 5. bug5_history_is_per_account: `getHistory(accountId)` returns only the transactions that involve this account, in insertion order. The bug is that it returns the bank's entire global history regardless of the account id. The scenarios are independent. Fixing them in any order produces incremental progress on the per-test count.