4 Commits

Include renames

Author	SHA1	Message	Date
siddharthd	d4ff68363a	expense_metadata: every reader resolves the row a write lands on ... getTransactions' provenance LATERAL, merchantForTransaction and the Slack details modal all select on transaction_id = $1 OR matched_transaction_id = $1 with a bare LIMIT 1, so they could read a different row than replaceLineItems writes. Same ORDER BY as the match, the write and the order-detail GET. Defensive, not a live bug: measured 2026-08-21, expense_metadata holds 667 rows, 147 of them pointing-only, and ZERO transactions resolve to more than one row by either link. This changes nothing today. It is here so the readers still agree on the day multiplicity appears, which is the only condition under which any of them was ever wrong.	2026-08-21 18:23:31 +10:00
siddharthd	d458228625	feat(orders): a fifth verdict, 'bad', between ok and never again ... The jump from "OK" to "Never again" is too big and most disappointments live in the gap (user, 2026-07-28) — so a merely poor meal either flattered itself as OK or got blacklisted. Only 'never' raises the warning on a future order. A blacklist that fires for every mediocre delivery is one nobody reads, so 'bad' records the disappointment without triggering the alarm. Both set order_again = false — you would not choose either again — and that split between "would I order it" and "warn me about it" is the point of the extra level. Migration widens the CHECK; nothing is removed, so no existing row needs mapping.	2026-07-28 19:12:26 +10:00
siddharthd	0595d49d5c	fix(orders): the restaurant is the merchant, not the courier ... Reverses a change made on request. The platform in the headline fragmented the merchant: the same restaurant read as two, depending on who carried the bag, and that is not a distinction anyone rating the food cares about. It also already has a home — the expandable Order details panel renders expense_metadata.platform next to its heading, which is where the user asked for it. The fragmentation was worse than cosmetic. merchantVerdict joined on an exact merchant_normalized, and the platforms capitalise differently ("TEG Kebabs & Biryani" on Uber Eats, "TEG KEBABS & BIRYANI" on DoorDash), so one restaurant kept two separate histories and a "never again" recorded through one app never warned in the other — silently defeating the point of the memory. Now case-folded; verified on real data, where the DoorDash order sees 1 prior verdict against 0 before. 81 existing descriptions backfilled in one transaction, dry-run first and dumped beforehand. The regex is anchored to the end so suburb parens survive: "Order - Coles (Wyndham Vale) (Uber Eats)" becomes "Order - Coles (Wyndham Vale)", not "Order - Coles".	2026-07-28 17:51:36 +10:00
siddharthd	0cb46a087b	feat(orders): record what we thought of an order, per person ... The ledger already knew we had ordered from a place; it did not know the food was bad. Orders got repeated from places we disliked because nobody remembered by the time the next one went in. That is what the receipt ingestion was for (ING-9) and the last piece was missing: order_reviews existed as a table with no API, no UI and no writes. Four levels, not three. "Loved" and "liked" are both "would order again" but only one is worth a detour, and "ok" is not a recommendation. A verdict belongs to a person, not to an order. A shared meal produces two opinions and they routinely disagree — that disagreement is the useful part, and the old UNIQUE on transaction_id alone could not hold it. Now UNIQUE (transaction_id, participant_id), and the default is the signed-in user rather than the owner: Sonu authenticates through the same Traefik OAuth as participant 4, so an owner default would have filed her verdict under his name. Per-item opinions key on the item DESCRIPTION, not its index. An index is meaningless across orders; "the Pad Thai here is good" is the signal that has to survive into the next order from the same merchant. Only the two poles are offered — a per-item "ok" answers neither of the questions you ask at order time. Sharing is recorded as a real 50/50 split, not a decorative flag. The split already IS the record that an order was shared, and two records of one fact drift apart. An ABSENT item_verdicts means "leave them alone"; an empty array clears them. Without that distinction a note-only save silently wipes every per-item opinion — the same shape as the bug that reset `settled` on split rewrites, and just as invisible on screen. Mutation-tested: making keepItems a no-op fails exactly one test. mockDbWithPool gained queryRow. Omitting an export from the mock makes it undefined at the call site, which fails as "not a function" and reads like a code bug rather than a test-harness gap.	2026-07-28 15:31:22 +10:00