130 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
siddharthd	22e4a1ead0	fix(splits): make every split account for 100% ... A 50/50 arrangement was stored as a single row saying "Sonu 50%". The arithmetic was never wrong — `myShare` resolves the payer's share as `100 - SUM(everyone else)`, so balances and per-user spend were correct throughout. It was still a bug, because a ledger is read as well as computed: on screen that row is a 50% share against a blank, which looks like half the money is unallocated and is indistinguishable from a split somebody abandoned half-finished. It also leaked. `getSharedTransactions` filters by participant with an EXISTS on an explicit split row, so filtering the Shared view by the payer silently dropped every transaction where their share was only ever implied. Four write paths could produce it, three of them unguarded: - the Slack nudge's share button, which inserted one row - `POST /api/transactions`, where the add form shows an amber total under 100 but saves anyway — this is how Lawn Mowing and Hedge Pruning were stored - `applyRuleActions`, where ten of the fourteen live split rules name only the other person `completeSplit` is now the single place that writes the remainder, and every one of those paths ends in it. The remainder goes to the transaction's *owner*, never to "me": the owner's row on their own transaction is excluded from both halves of the balance query, so it cannot create, enlarge or discharge a debt, whereas a row for me on someone else's transaction is a real obligation. That distinction is what makes this safe to apply to existing data. Also fixes the order panel's "Shared 50/50" toggle, which was inert in both directions: it posted a lone 50% row to share (rejected — must total 100%) and an empty array to un-share (rejected — array required), because no way to clear a split existed. DELETE on the splits route is that way. Backfill: 7 rows, verified against a row-level dump diff — 2549 -> 2556 rows, none removed, none modified — and participant balances byte identical before and after (Molina 19556.07, Sonu 20913.35). Every split in the database now totals 100%. Not done: a database-level constraint. Enforcing the sum needs a deferred constraint trigger, and the rule path commits its DELETE and INSERT as separate statements, so the trigger would reject the intermediate state. Making it work means wrapping every write path in a transaction, which is a larger change than the defect warrants.	2026-07-29 10:23:06 +10:00
siddharthd	dd0462a5f9	fix(orders): decode • so item options separate again ... `•` was missing from the entity table, and that was not cosmetic. DoorDash separates an item's name from its options with a bullet and parseDoorDashLineItems splits on the literal "•" — so left encoded, the split never happened and the line collapsed into the description: "Bucket and Side Pack (Meal Deals) • Hot Bucket • Chips" with options []. The entity showed on screen and the structure behind it was gone. Numeric entities are now decoded generically rather than one at a time, which is how $ came to be listed individually while its neighbours were not, and & resolves last so a literal "•" stays as written instead of turning into a bullet. Repaired the 47 stored rows by re-parsing the captured email behind each one rather than string-replacing the entity, since a replacement would have fixed the display and left options [] underneath. Rehearsed first: all 47 re-parsed, all 47 gained options, 0 line items lost, 0 amounts changed. Old values kept in dump/rollback-line-items-20260728-223737.json. Pre-existing — 22 rows predate today — but the pre-cutover backfill more than doubled the affected rows, which is what surfaced it. Verified in the Order details panel, not in SQL.	2026-07-28 22:38:38 +10:00
siddharthd	3144cf3176	feat(orders): record credits orders from before the cutover ... I1 refused any credits-funded order dated before 2026-01-09, storing nothing at all — no transaction and no metadata, so the receipt was discarded rather than kept as history. Its reason was splits, not spend: before the cutover shared expenses lived in SplitMyExpenses, and re-importing them would double-charge against carryover transaction 2348. That reason expired with 788219b, where ACTIVE_OBLIGATION became `settled = false AND transaction_date >= '2026-01-09'`. A pre-cutover split can no longer assert a debt, so a pre-cutover order cannot move a balance however it is recorded — and ingestion writes no splits at any date, which now has a test of its own. What the guard was still doing was hiding ordinary history: 275 orders, $9,799.96 of meals and rides across 2020-2025, invisible only because the money came from a gift-card balance instead of a card. The funding side stays as it is, deliberately. Some of those orders were paid from ShopBack gift cards that are themselves booked as expenses, so that portion is counted twice. The exposure is bounded at $3,411.16 over 14 loads and is probably smaller: the descriptors name no brand — "ShopBack Gift Cards SQ" is a batch code, and the card could be Amazon, Airbnb or Shell as easily as DoorDash — and six are categorised `gifts`, which may be real presents rather than self-funding. Reclassifying them on a guess would corrupt correct data to fix a double-count that cannot be shown. Only the ShopBack purchase emails can settle it, joined on total paid.	2026-07-28 22:20:03 +10:00
siddharthd	fe104a9618	fix(orders): read both legs of an Uber payment ... Uber Cash IS credits, and the payment line had become unreadable in the newer layout: "Payments Uber Cash 10/17/25 8:50 PM A$54.87" carries a timestamp between the label and the amount, and writes the currency as a prefix. Both defeated the pattern, so credits_amount stayed null and the order was filed as card-settled — sent looking for a card leg that does not exist, found nothing, and left as an orphan with no transaction and no card tail to match on. 118 captured messages sit in that state, and every one of them is pre-cutover, so reading them correctly means I1 skips them rather than storing enrichment that points at nothing. The card leg had the same blind spot, hidden behind the first: the gap between the mask and the amount was [^\d]{0,40}, which a timestamp breaks. While BOTH legs were unreadable a mixed payment still looked consistent — the order read as card-settled for the full total. Fixing only credits reads half an order, which validateOrderTotals correctly refuses. Found exactly that way: four messages that validated before began failing "payments sum to 34.92 but receipt states 43.60". Legs are summed rather than taken first, because one order can be charged in instalments and an instrument can carry no mask at all (PayPal). But a leg that already equals the stated total IS the payment, not an instalment: a Dubai trip prints an AED 17.67 authorisation and then the AED 577.83 settled charge, and adding the hold overstates the trip. A mixed credits+card order is unaffected — neither leg equals the total there, which is why it needs summing. A/B over all 776 captures: 468 parsed by both, zero change to any amount, currency or existing card tail, 0 lost, 118 credits figures newly read. Mutation-tested: dropping the exact-leg rule fails 2 tests, dropping the Uber Cash read fails 7.	2026-07-28 21:59:35 +10:00
siddharthd	63aaf1eb21	fix(orders): read A$ totals and credits-funded receipts ... Two parse bugs that between them made 218 of 776 captured messages unreadable. Neither was the "old template" they were filed as. Uber writes the currency three ways and only two were handled. "Total A$54.87" is what it sends for ordinary Australian orders — A$ misses [A-Z]{3} by one character — so 98 of 275 Uber Eats mails and 78 of 275 trip mails failed with "no Total found" while the amount sat in plain sight. Most were 2024-2025, i.e. current mail. NZ$, US$, S$, HK$, C$ and a bare rupee/euro/pound symbol are handled the same way. A bare "$" is still left unresolved on purpose: a dozen currencies use it, and the body-wide scan that reads the receipt's own stated code should win. A DoorDash order paid from credits states "Total Charged $0.00" truthfully, above a real subtotal. Read literally that is a $0 order, and validateOrderTotals rejected 88 of them as non-positive — discarding exactly the credit-funded spend this pipeline exists to surface. The order's value is its subtotal; recording zero would show the order and hide what it cost. Guarded on the receipt actually saying credits, so an empty mail still fails rather than inheriting a stray subtotal, and the header cross-check stands down for these or it rejects the figure the parser deliberately overrode. Measured A/B over all 776 captures: 254 parsed by both parsers with zero change to any amount or currency, 0 lost, 214 newly readable. Both fixes mutation-tested — reverting the regex fails 4 tests, removing the credits branch fails 3. Fixtures are real captured receipts, per the 2026-07-26 rewrite: the earlier synthetic suite passed while the parser could not read a real email. No history replay — I7 idempotency refuses re-reads and that needs an explicit update mode. This fixes ingest from here on.	2026-07-28 20:32:02 +10:00
siddharthd	7cf247951a	docs: the verdict scale, and the two Slack rules that cost real data	2026-07-28 19:17:25 +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	82f751cbf4	fix(slack): update the card via response_url, not the HTTP response ... Every press wrote correctly and then left the card showing stale state, so a working button looked dead — and a button that looks dead gets pressed again, which toggled the split back. That is how two orders got unshared while looking like nothing had happened. The cause was a wrong assumption in the original design: Block Kit interactivity ignores the HTTP response body. Replacing a message from the response is legacy attachment-style behaviour. The update has to go to payload.response_url, which needs no bot token — so it stays in the app rather than becoming another n8n node. Two things that were also invisible now speak up. The share guard used to return silently when it refused a three-way or uneven split, which is indistinguishable from a broken button; it now says which it was, as an ephemeral only the presser sees. Same for an unmapped Slack user. The response still echoes the rendered blocks. Slack ignores them, but it lets a card be rendered server-side without pressing anything — which is what stops the replay tooling from hand-writing a card with a guessed share state, the mistake that cost a real split earlier today.	2026-07-28 18:54:53 +10:00
siddharthd	9f0f38449b	feat(slack): ask the other person too, and put rating before sharing ... Two halves of the same requirement, one of which was quietly missing. Sharing split the money but never reached her: she is not in #smarthome, so the card whose caption said "both verdicts welcome" was one she could not see. Now a share DMs her a card of her own. A DM rather than adding her to the channel, so her surface stays "orders that concern me" instead of the whole house's ops feed. She was already in SLACK_USER_MAP, so her press files under participant 4. Only on the press that turns sharing ON, and only when someone else did the sharing. Re-notifying on every later rating press would turn one shared meal into a stream of DMs, which is how a nudge gets muted. Her card carries no share button: she is being told it was shared, not asked to decide, and two people toggling one split from separate copies of a card is a race with no upside. The app still holds no Slack bot token — it returns a notify instruction and n8n sends it, the same shape as the modal open. If SLACK_USER_MAP has no id for her the DM is skipped silently: the split is correct and complete either way, and failing the press over an unaddressable nudge would be the worse trade. Card reordered to rate -> details -> share. You judge the food, then decide who pays for it; asking "was this shared?" first inverts the order a person thinks in. The status caption moved under the share button it describes rather than sitting orphaned mid-card.	2026-07-28 18:33:25 +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	50c5b7c430	fix(slack): don't let one tap flatten a hand-made split ... Splits on orders are made by hand, so a third participant or an uneven share is a deliberate decision — and "Make it just me" deleted every split row regardless. A one-tap button silently destroying an arrangement made with more care than the tap that undid it is the same failure shape as the rewrite that dropped `settled`. Now it refuses when a participant other than the two consumers is present, or when the share is not 50. Verified against the running stack: a three-way split and a 70/30 both survive a press; a plain 50/50 still toggles off and back on. Also: the nudge reads share state instead of assuming false. Today a freshly ingested order has no splits — the 140 that do were split by hand after the backfill, not by a rule — but the label drives a destructive button, so a wrong assumption there costs data rather than a cosmetic error. One query is cheaper.	2026-07-28 16:40:53 +10:00
siddharthd	14d6b40578	feat(slack): per-item verdicts and a note, in a Slack modal ... The card can rate an order but cannot ask which dish or why: a message cannot collect free text, and an actions block caps at 25 elements while item counts vary per receipt. A modal is the only Slack-native answer, and it stays inside Slack — no browser, no app, which is the whole reason it exists rather than a link. The overall rating deliberately stays on the card. That is the thing done every time and it should cost one tap; this is for when something was notably good or bad. finance-app holds no Slack bot token by design, so it returns the view and n8n — which already has the credential — calls views.open. One copy of the token, no new secret, no compose change. Item text travels in private_metadata because a submission returns block ids and values, never labels, so there is otherwise no way back to which dish a radio button referred to. Capped at 20 rows: a grocery order runs long and nobody scrolls a modal to rate a tin of tomatoes. The modal does NOT write the rating. A form that silently reset a decision the user did not revisit is the same class of bug as the split rewrite that dropped `settled`.	2026-07-28 16:33:10 +10:00
siddharthd	8fbcbc5f83	fix(slack): one select instead of four rating buttons ... Slack's mobile client gives every button in an actions block its own full-width row, so the four ratings rendered as four stacked bars and the nudge filled the screen (user, with a screenshot). A select is one row and still one decision. The interactive route now resolves both shapes — a button carries `value`, a select carries it on `selected_option`. Reading only the former would have left sharing working while rating silently did nothing.	2026-07-28 16:22:49 +10:00
siddharthd	aaa36dd75e	feat(slack): answer the order nudge in Slack, without opening the app ... Being sent to a web app to answer "was this shared?" is enough friction that the question stops getting answered — which is the exact failure the nudge exists to prevent. So the buttons now act in place: pressing "Shared 50/50" writes the transaction_splits row and edits the message, and the app is never opened. Slack does NOT reach this route directly. It posts to an n8n webhook that forwards the raw body and signature headers here (user's suggestion). That is the better shape: n8n already terminates public webhooks, so the app keeps its blanket OAuth chain and gains no internet-facing unauthenticated route, and no Traefik change is needed. n8n cannot verify the signature itself — its Code sandbox has no `require`, so no `crypto`. Two independent gates, both failing closed: the shared x-ingest-token (came from n8n) and Slack's v0 signature over the raw body (came from Slack, not replayed within 5 minutes). An unset signing secret rejects everything rather than waving it through, because the alternative turns a misconfigured deploy into an open write endpoint. An unmapped Slack user is refused rather than defaulted to the owner. In a two-person household a wrong attribution is not a rounding error, it is the other person's opinion recorded under your name. Block Kit is built in the app (ingest returns slack_blocks) rather than in n8n expressions: a template string is untestable, and this shape has to stay in step with what the interactive endpoint re-renders after each press. Null when there is no transaction yet — a card-settled order is parked until its statement arrives, so there is nothing to split or rate. Also: /transactions now honours ?q=, so the link lands on the row instead of the top of an unfiltered ledger.	2026-07-28 15:50:06 +10:00
siddharthd	66a6a51fb8	docs: order verdicts are built; record the four load-bearing shape decisions	2026-07-28 15:43:20 +10:00
siddharthd	b8919a4775	feat(transactions): honour ?q= so a link can land on one row ... The Slack order nudge links here. Without it the link drops you at the top of an unfiltered ledger and the merchant has to be found by hand, which is how a nudge stops being opened.	2026-07-28 15:34:24 +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
siddharthd	d081d80a3f	docs: rewrite the shared-expenses section, which had gone false ... Every warning in it was inverted by this week's work: - "settled is dead data, false on every row" -- there are now 1,266 settled splits across 657 pre-2026 transactions. - "do not fix getParticipantBalances to exclude settled splits" -- it now excludes them, via ACTIVE_OBLIGATION, and must. - "settlement cannot be attributed per trip" -- migration 0022 added split_payments.trip_id and it is attributed. - "splits exist from 2026-01-09 only" -- pre-2026 transactions are now split deliberately, to stop them inflating spend. Replaced with what is actually true, including the rule that matters most: the cutover DATE is the primary balance gate and the settled flag only refines it, so pre-2026 expenses can be split freely.	2026-07-28 14:41:05 +10:00
siddharthd	db6b7f8375	docs(shared): the cutover date is the gate, the flag refines it	2026-07-28 13:54:46 +10:00
siddharthd	788219b9fd	fix(splits): the cutover date, not a boolean, is what gates a balance ... Nothing dated before 2026-01-09 can be owed, because carryover transaction 2348 already carries the entire pre-cutover balance as a single figure. ACTIVE_OBLIGATION now says so directly. This inverts which mechanism is load-bearing, and that is the point. Until now the only thing keeping $37,233.28 of paid debt out of the balances was transaction_splits.settled -- a boolean that any delete-and-recreate write path resets to false, as the split modal did until commit 6add958. Losing the flag on a pre-cutover row now costs nothing: the date still excludes it. The flag matters only on or after the cutover, marking the few settled outside this app. It also makes splitting history safe to do freely. A split on a 2024 grocery shop can now describe how the expense was shared -- which is what stops it inflating spend -- without asserting a debt that was settled years ago. That was the whole reason not to split pre-2026 expenses, and it no longer applies. The bound is inclusive because transaction 2348 is itself dated 2026-01-09; an exclusive one would drop the carryover and with it the entire pre-cutover balance. Corrects one live figure: a Woolworths on 2026-01-06 was split 50/50 three days before the cutover, double-counting $7.55 against the carryover. Sonu $5,428.08 -> $5,420.53. The test fixture default moved to 2026-06-15 -- it was 2024-06-15, which is now pre-cutover and made every balance fixture read zero. That the suite caught this is the guard working.	2026-07-28 13:52:30 +10:00
siddharthd	6add958132	fix(splits): editing a split must not resurrect a settled debt ... The route replaces every split for a transaction rather than editing in place, so the recreated rows took the column default settled=false. Opening the split modal on a historical transaction and saving it therefore converted a discharged obligation into a live one, with nothing on screen saying so. That is not theoretical. 657 pre-2026 transactions now carry settled splits imported from SplitMyExpenses -- $37,233.28 of balance that the carryover (transaction 2348) already accounts for. Editing one would double-count its share against a debt that was paid years ago. Now carries settled and settled_at across the rewrite, per participant, the same way the rules revert route already does. Changing someone's percentage does not re-open the obligation: it was settled outside this app and stays settled. A participant who was not on the transaction before is a genuinely new obligation and correctly starts unsettled. rule-actions.ts was already safe here -- it upserts ON CONFLICT DO UPDATE SET share_percent, so it never touches the flag.	2026-07-28 13:40:48 +10:00
siddharthd	3339a0b9b7	chore: ignore the scripts venv ... scripts/split_csv_match.py needs psycopg2, so scripts/ now has a venv beside it. This repo deploys from its working tree, so an untracked .venv would be swept into the Docker build context.	2026-07-28 13:32:31 +10:00
siddharthd	3b9d302ce2	docs(shared): record the grouped-payment allocation ... Sonu's two "transfer" payments are split by scope, Europe first and the remainder to household, chronologically so each settles what was outstanding when it was made. Both Europe tabs now read $0.00. No schema change was needed and that is the point worth writing down: split_payments has no unique constraint on linked_transaction_id, so one bank transfer carries one row per scope and the rows re-add to the transfer -- verified, 4111 sums to $3,779.33 and 4121 to $4,794.06. Her overall balance is unchanged at $5,428.08. Allocation moves money between tabs, never between people; that invariance is the check to repeat on any future re-allocation.	2026-07-28 13:02:56 +10:00
siddharthd	4fc8eeac95	docs(shared): record the Sonu+Sunny leg as its own trip ... Trip 3, 2026-04-12 to 2026-04-28, 124 rows, $9,914.24. It was marked only by tag 5 and so was invisible to every trip figure. It reads at first like a sharing scope overlapping the group trip, because the tag's earliest row is 17 March. It is not: that is a single advance booking (Ticketmaster Nanterre), 8 more rows fall on the 12 April handover day and were already held out of Europe 2026, and the remaining 115 run 13-28 April. A clean sequential leg. Also records that grouped payments need no schema change -- split_payments has no unique constraint on linked_transaction_id, so one transfer can carry a row per scope -- and that the 23 Apr Qantas booking is the flight to Bangkok starting a solo leg, which is why it stays out of this trip.	2026-07-28 12:59:53 +10:00
siddharthd	89300450a7	docs(shared): describe what was built, not what was proposed ... The 2026-07-26 document was a proposal marked "nothing built". Everything it described as broken is now fixed, and the fix is not the one it proposed, so leaving it in place would misdescribe the system to whoever reads it next. Records what the code now does: settled as the single balance gate, settled and trip_id as orthogonal axes, settling up by recording a payment rather than flipping a flag, and the reasons duplicates are superseded rather than deleted. Keeps the loan design intact and clearly marked as still a proposal -- it was never built and nothing in this work touched it. Also records that the proposal's own recommendation not to restate history from the CSVs was overturned, and why it was wrong: it measured the value in balances, where it is nil, and missed it in spend, where it is $35,259.	2026-07-28 12:06:56 +10:00
siddharthd	b4a116c134	feat(scripts): import the matched split history as settled ... Adds --write to the matcher. Wrote 1,242 split rows across 657 transactions. Imported settled, and that is the whole design. These obligations were discharged years ago on a platform we no longer run, and their residual is already carried by transaction 2348. Writing them unsettled would re-open roughly $40k of debts that were paid. ACTIVE_OBLIGATION keeps settled splits out of every owed figure while myShare/mySplitOf still count them, which is exactly the asymmetry this needs: the import exists to correct historical SPEND, not to move a balance. Effect: $35,259 leaves my historical spend -- $13,088 in 2024, $22,117 in 2025 -- because a $200 grocery shop that was always half hers no longer reads as $200 of mine. Balances are byte-identical before and after (Molina -1226.72/145, Sonu 5428.08/419), which is the assertion that matters. Shares are written as the CSV computed them, so a 50/50 row can land as 50.01/49.99. That is faithful rather than tidy; no transaction exceeds 100%. Rehearsed on the 37-row Rome file first (24 rows) and verified before the full run -- both the balances and one split read back through the API.	2026-07-28 12:02:57 +10:00
siddharthd	c9b000a428	feat(scripts): dry-run matcher for the SplitMyExpenses history ... Matches the five CSV exports against transactions already in the ledger and reports what it would do. Writes nothing -- importing is a separate step, and rehearsing it first is what catches the defects that tests do not. What it found, and why the number is what it is: 676 of 1,536 shareable rows match (44%). The ceiling is ledger coverage, not matcher quality. The CSVs describe 678 shared expenses in 2024 alone; the ledger holds 591 rows for the whole of that year, 3 to 72 a month, which is far less than a household actually spends. Most 2024 CSV rows have no transaction to attach a split to and never will. South Korea April 2024 matches 4 of 158 for that reason. Three decisions are encoded deliberately: - Date format is decided per FILE, not per row. The household export writes D/M/YYYY and the four trip exports write ISO, and 474 rows parse validly under both readings -- per-row guessing silently swaps January and February for some rows and not others. - A person's column is their net balance impact, not their share. The payer is whoever is positive; the other's share is |their negative| / cost. So a +cost/-cost row means the other party owes 100%, not that the expense was unshared -- the reading that would fake an arrangement change. - Matching is one-to-one, best pair first. The NZ trip has two identical $10.16 Uber rows against three ledger rows and four PayMyPark rows in the same shape; without this a ledger row is claimed repeatedly and the second CSV row looks matched while being unrepresented.	2026-07-28 12:00:18 +10:00
siddharthd	dbfbd5196d	fix(transactions): supersede rows imported twice instead of deleting them ... Statements 107, 142 and 143 bill overlapping periods on one ANZ account, so 31 transactions -- $42,040.68 -- are in the ledger twice. They are marked superseded, not deleted. Every child of transactions is ON DELETE CASCADE (splits, tags, overrides, expense_metadata, order_reviews), so deleting "the duplicate" destroys whatever curation sits on it, and which member of a pair holds that curation is an accident of import order: here 1 pair carries splits and 6 carry overrides, all on the surviving side, but nothing guarantees that. Superseding keeps the row, keeps its children, and makes a mistake one UPDATE to undo rather than a restore from backup. reconciled_with_id could not be reused. Its predicate is scoped to statement_id IS NULL on purpose -- a statement line pointing at something else is the survivor, not the duplicate -- and here both rows are statement lines. The exclusion goes into EXCLUDE_RECONCILED_SOURCE rather than into a new fragment, so every query already asking "count each purchase once" gets it without being edited. The trip cost queries did not use that fragment at all and now do; verified a no-op on current data (0 trip-tagged rows are either reconciled sources or duplicates), but they were one import away from double-counting. Most of the $42k is transfers and investments, which spend already excludes. The damage was elsewhere: duplicated rows in the list, and rules re-splitting a duplicate -- txn 3807 is one of these 31 and was a candidate for splitting earlier today. Balances are unchanged: no duplicate carried a split.	2026-07-28 11:54:25 +10:00
siddharthd	d5589b2980	feat(statements): flag billing periods that overlap another statement ... An account cannot be billed twice for the same day, so an overlap means those transactions are in the ledger twice. ANZ statements 107 and 143 overlap by 118 days and put roughly $42,000 of duplicate rows in; nothing anywhere said so. Two details decide whether this catches the real case: - Account numbers compare with non-digits stripped. The duplicate got in because the existing key compared raw text and ANZ wrote the same account as 408556264 on one statement and 4085-56264 on the other. - The range is half-open. These statements are issued back-to-back with one period ending the day the next starts, so inclusive bounds flagged 5 pairs of which 3 were consecutive and fine. Half-open leaves exactly the 2 real ones. NULL bounds are excluded rather than handed to daterange, where NULL means unbounded and an undated statement would overlap all of history. Detection only. It does not refuse the import or touch the duplicate rows -- cleaning those is separate, and must supersede rather than delete because every child of transactions is ON DELETE CASCADE and the curation sits on the duplicate side. Both subtleties have a test, and both fail if you undo them.	2026-07-28 11:46:45 +10:00
siddharthd	7a1acc32a9	feat(trips): say which direction a trip balance points ... A participant who has overpaid a trip showed as "$-816.16" under a column headed "Outstanding on this trip". A negative outstanding reads as a bug rather than as "they are ahead", so the sign is now spelled out: magnitude plus one of all square / owes you / ahead — you owe them, coloured the same way Shared colours the same three states. Also corrects the footer, which had gone stale and was now simply false. It said settlement could not be computed per trip because payments carried no trip attribution. Migration 0022 added split_payments.trip_id and the figures above it have been net of trip-scoped payments since. What a reader needs to know is the opposite of what it said: household-tab payments are the ones NOT counted here.	2026-07-28 11:39:11 +10:00
siddharthd	e92fcb709f	docs(trips): say whose money the trip total counts ... Total Spend is every payer's trip-tagged spending; the split figures directly below it are scoped to the owner. Two lenses on one screen read as one unless the card says which it is. The number is unchanged and deliberate -- a trip cost what the group put into it -- so this is a label, not a fix.	2026-07-28 11:30:37 +10:00
siddharthd	8c21893cc2	fix(trips): money that came back is not what the trip cost ... Every trip figure filtered on transaction_type IN ('debit','fee','interest'), which drops refunds and credits outright. A partly-refunded booking therefore read at its full price and the refund subtracted nothing, anywhere: the headline total_spend, the category breakdown, the daily chart, top merchants and the tag breakdown were all gross. This is the same defect the general analytics fixed once already, which is why NET_SPEND_ROWS and SPEND_SIGNED exist -- a refunded Expedia purchase read as $2,888.92 of spend until they did. Trip analytics never adopted them. Doing so now costs one predicate and one expression per query. getTrips/getTripById needed the trips alias moved to `tr`: the fragments assume `t` is `transactions`, and hand-inlining a copy rather than renaming is exactly how the reconciled-row exclusion drifted out of the analytics routes before. On Europe 2026 this is $821.12 -- a LuxuryEscapes booking with two part-credits against it, and a FreeNow hold adjustment. Fully cancelled bookings are a different case and are handled by untagging both legs from the trip by hand, because a trip never incurred a cost it cancelled. No balance moves: the owed query already excludes credits and a refund carries no split. There is a test asserting exactly that, and it passes with or without this change -- it is a guard, not a proof. The three that do prove it fail without it.	2026-07-28 11:25:03 +10:00
siddharthd	4fcb135805	fix(trips): a trip figure must only count what the owner is owed ... The per-trip owed number shipped in 689fadc counted every split on every trip transaction regardless of who paid, so it silently mixed debts owed to different people under one label. On Europe 2026 that meant Molina "owed" $21,572.12, of which $1,605.49 was her share of rows Sonu paid for — a real debt, but between the other two participants, and one they had already settled directly (split_payments id 5, Molina -> Sonu, exactly $1,605.49). A participant's own share of a row they themselves paid for was in there too, which is nobody's debt at all. Both sides needed scoping, not just one: the owed side to rows this owner paid for, and the paid side to payments made to this owner. Scoping only the first would have let a Molina -> Sonu payment reduce what Molina owes the owner. The corrected figures reproduce a number derived independently, months of data apart: Molina now reads -$816.16 on Europe, matching her known overpayment to the cent ($19,966.63 of splits against $20,782.79 paid). Sonu goes from $8,793.10 to $1,084.61, and the owner correctly disappears from a list of people who owe the owner. Found by checking a household total against what the app had been showing all along — the query was gross, gave a number about twice the real one, and I had quoted it as "owed". Worth stating plainly: the defect was not in the number the app displayed, it was in the number I computed to explain it.	2026-07-27 23:40:58 +10:00
siddharthd	ff0629462c	fix(ci): generate the Prisma client before running tests ... The pipeline has been red on every run since at least ae0c34f. npm ci installs dependencies but the Prisma client is generated into src/generated/prisma, which is gitignored — so a fresh CI checkout has no client and anything importing src/lib/db.ts fails with 'Cannot find package @/generated/prisma/client' before a single assertion runs. prisma generate reads only the schema, so it needs no database and no secrets. Worth noting why this went unnoticed for a dozen commits: a pipeline that is always red carries no signal, so it stopped being read.	2026-07-27 23:23:32 +10:00
siddharthd	ae23b03d5d	fix(trips): carry the currency and reconcile rules into the trip figure ... a4ab543 landed six hours ago and this branch rewrote one of the queries it had just fixed, quietly dropping both of its guarantees. That commit made EXCLUDE_RECONCILED_SOURCE "one fragment both sides import" because an inlined copy is how the reconciled-row exclusion drifted out of the analytics routes and double-counted 48 rows / $4,474.79. The trip owed query here had hand-inlined its own copy — the fragment assumes the alias `t` and this query used `tx`, so the path of least resistance was to re-create exactly the divergence that was being removed. Aliased to `t` so the fragments apply directly. The same commit made balances count rows whose AUD value is unknown rather than netting a foreign figure against AUD ones. The trip figure had no equivalent — on the query where it matters most, because a trip is where foreign rows actually live. A Europe total silently mixing EUR into AUD is the whole failure that fix was written to prevent. The column header still read "Share of this trip" while the number is now net of payments, which is the same class of drift a4ab543 set out to fix. It reads "Outstanding on this trip", carries the approx/unconverted caveat the Shared cards use, and greys a settled zero.	2026-07-27 23:15:28 +10:00
siddharthd	689fadc8b9	feat(shared): give a payment a tab to settle ... A payment has only ever recorded from, to, amount and date. That is why the per-trip owed figure did not exist — getTripAnalytics said so where the number should have been: "split_payments carries no trip attribution, so a payment cannot be assigned to a trip. Settlement is a property of the whole relationship." Every trip therefore read 100% unsettled, including trips paid in full. It is also why the Shared page silently drops payments under a tag filter. With one global pool there was nothing honest to subtract, so it showed gross splits under the same label. A tag is a view; a scope is a ledger. The scope is a trip, not a new settlement_contexts table. trips already has owner_id, dates and archived, and transaction_overrides.trip_id already decides membership. A second grouping beside it would be two unsynchronised scopes over the same rows, with no invariant saying which governs. NULL means the ongoing household tab, which never closes. settled answers a different question and the two must not be collapsed: trip_id is which tab, settled is whether the obligation is still live. Critically, a live obligation is NOT settled by flipping the flag — it is settled by recording the payment, and the balance nets to zero on its own. Doing both would subtract the settlement twice. So settled is written only by the historical import, for repayments made on a platform we no longer run, and there is deliberately no "mark settled" action. Both owed figures now exclude settled splits and the trip figure nets its own payments. Spend analytics (myShare/mySplitOf) deliberately still count settled rows: my half of a 2025 grocery shop is my spend whether or not the other half was ever repaid, and filtering them would re-inflate exactly the figures importing settled history exists to correct. Also drops /api/participants/[id]/balance. It had no consumers, no owner scoping, no debit/credit signs and no EXCLUDE_RECONCILED_SOURCE — a fourth balance implementation that disagreed with the others and would have imported three bugs if anything had aligned to it. getTripAnalytics had no test at all. It has five now, including the one that matters: a household payment must not make a trip look paid. Verified by mutation — neutering the settled filter fails three, and dropping the trip filter on payments fails that one.	2026-07-27 23:12:05 +10:00
siddharthd	a4ab543a6c	fix(analytics): make the displayed numbers mean what they say ... Six metric-integrity defects from the UI/IA review, plus two found while verifying the review's own claims against the code. The reconciled-row exclusion existed only in queries.ts. Every analytics route counted the superseded manual rows as spend — 48 rows, $4,474.79 of double count, invisible precisely because the transaction list looked right. It is now one fragment both sides import. The spend-pace chart computed its own totals in the browser: gross amounts, debits only, no personal share, no refunds, fees, interest or itemised loan repayments. On live data it ended July at $4,747.31 under a headline reading $3,597.10 — and its own baseline line was drawn from the split-adjusted monthly totals, so the two series in one chart disagreed with each other. Both now come from /api/analytics/daily, built from the same fragments as the headline. Fees aggregated every statement ever imported with no date filter, under a heading with no period, so a lifetime figure read as a current one and grew forever. Now bounded, labelled, and selectable. Comparisons no longer measure a month in progress against complete ones: the in-progress month is out of every baseline, and a selected current month is compared through the same day. Two the review did not catch: - Every analytics window was a day early. toISOString() on a local-midnight Date converts backwards through UTC. Surfaced only once fees started reporting the range it had used. - /monthly rounded per category, /daily per category-day, so the pace chart ended a few cents off the headline above it. Shared currency needed amending rather than applying. Reading s.currency would have labelled every order row AUD, since an order receipt has no statement and carries its own currency — the opposite convention from a foreign charge on an AUD statement, where amount IS AUD. NATIVE_CURRENCY's COALESCE order keeps the two apart. Balances also now count rows whose AUD value is genuinely unknown instead of netting a foreign figure against AUD ones. Latent today: no foreign transaction is currently split. Tag-filtered balance cards no longer claim "owes you". With a filter on, payments are deliberately not subtracted, so the figure is a split total and settling against it would record a payment for a debt that never was. Split-coverage warnings deliberately omitted (user decision).	2026-07-27 17:10:27 +10:00
siddharthd	5ee5ee24cf	feat(orders): expand a row to see the receipt it came from ... Enrichment is the point of the ingestion pipeline (DECISIONS ING-8) — a bank statement gives a date, an amount and a mangled descriptor, and everything that makes a transaction understandable arrives by email. It was all reachable only by opening the edit modal, which is a strange place to look for "what was in this order". Rows with a receipt behind them get a disclosure arrow in the description cell; clicking expands an inline panel with the line items, the pick-up and drop-off stops, the card tail and the provider's reference. Several rows can be open at once — the point is comparing orders without losing your place. The arrow appears only where `order_platform` is set. Putting one on every transaction would promise detail that mostly does not exist. OrderDetails moves out of edit-transaction-modal.tsx into its own component so both surfaces render the same thing; `bare` drops the modal's top border when it sits in a table row.	2026-07-27 11:52:33 +10:00
siddharthd	3bb67f370d	feat(orders): show where an Uber trip went, in the list ... Five rows all reading "Order - Uber Trip" are indistinguishable — the list gives you a date and an amount and nothing to tell one ride from another (user, 2026-07-27). Where the trip went is exactly what separates them, and it was already stored on expense_metadata.route since this morning; nothing in the list read it. getTransactions now joins the receipt (both directions — transaction_id OR matched_transaction_id, since a card-settled order points at the statement line instead) and the description cell renders "Terminal 2, Melbourne Airport (MEL) → 19 Lady Penrhyn Dr" in the same italic sub-line notes use. Two deliberate limits: - **A note the user wrote always wins.** This only fills an empty sub-line; it never occupies the notes field, which is theirs. - **Deliveries are excluded.** Their merchant already identifies them, so the restaurant's street address would be clutter on every food order. Gated on platform = 'uber'. The summary keeps the first two comma-segments of each address — a truncation, not a guess about geography. Uber puts the venue or street first, which is the identifying part; the full stops with their times stay in the title attribute.	2026-07-27 11:43:55 +10:00
siddharthd	6161ddc9de	fix(orders): don't restate a platform the merchant already names ... Trip rows read "Order - Uber Trip (Uber)". The suffix exists so you can tell where to go and look; when the merchant is literally "Uber Trip" it says nothing. What identifies a trip is its two addresses, and those are in the Order details panel. Existing rows updated in prod.	2026-07-27 11:33:37 +10:00
siddharthd	c656f5d26b	feat(orders): read Uber trips, and reject the charge summary that duplicates them ... Local rides are paid with credits (only overseas ones go on a card), so trips belong to this slice and were simply never fetched — the Graph query searched "order with Uber", the Eats subject. Captured 15 real messages from the mailbox via a dry-run before touching anything, which found two defects that no amount of reasoning about the template would have: **Uber sends two mails per trip.** A "charge summary" when the ride ends, then the real receipt when payment settles — same subject, same total. The summary carries no tripReference, so order_reference fell back to `msg:<message-id>` and I7 could not dedupe it against the receipt that follows. Every trip would have been recorded twice. It says so itself ("This is not a payment receipt ... You will receive a trip receipt when the payment is processed"), so it is now a NotAReceiptError — 200 and silent, like every other expected non-receipt. **Trip receipts label neither end of the journey.** Delivery receipts write "1:20 pm - Pick-up"; trips print the time alone. The split regex put the time into `label` and left `time` null. Time is now read properly, and a two-stop trip is labelled Pick-up/Drop-off positionally — only where the receipt was silent, so a template that does label its stops keeps its own wording. Verified against all 15 captured messages: 7 trips recorded, 5 charge summaries and 3 promotions skipped, 0 failures, no duplicate references. Two of the seven are AUD credits-funded ($84.78 + $47.97) and would become transactions; the five NZD ones are card-settled and correctly create provenance only (I5). Fixtures ut-00 (local credits trip), ut-01 (overseas card trip) and ut-summary (the charge summary) are captured mail, not written by hand.	2026-07-27 11:21:13 +10:00
siddharthd	4febf38292	test(orders): clean statement fixtures before ingest, not after ... These tests insert a Westpac statement and a `DD *DOORDASH ...` charge, and only removed them at the end of the test — so they survived into the next run, where `reconcileCardLeg` could match one at ingest time and resolve an order that was meant to park `awaiting_card_statement`. That is a real ordering bug in the fixtures regardless. It is my best explanation for the intermittent failure in "parks an unresolvable split", but I could not reproduce it: seeding the exact leftover row and running the old code passed anyway. So this is hygiene with a plausible mechanism, not a confirmed fix — if that test fails again, this was not the cause.	2026-07-27 11:01:23 +10:00
siddharthd	b6cd62f7b5	feat(orders): show the receipt in the transaction detail panel ... `expense_metadata` has held the itemised receipt since ingestion started and nothing in the UI ever read it. A transaction that came from a DoorDash or Uber Eats receipt showed a merchant and an amount, with the item list and the delivery addresses sitting unread in the row behind it (user, 2026-07-27). Adds GET /api/transactions/[id]/order and an "Order details" section in the edit modal: line items with their options, pick-up/delivery stops with times and addresses, the card tail when one was involved, and the provider's own order reference. Two details that matter: - The lookup resolves from **both** sides — `transaction_id` OR `matched_transaction_id`. A card-settled order creates no transaction of its own (I5); the receipt points at the statement line instead. Matching only on transaction_id would have left the panel blank on exactly the card-paid orders, which are the ones whose detail is hardest to find elsewhere. - An empty item list says so in words rather than rendering nothing. Uber itemises groceries but not restaurant orders, and orders ingested before the Uber item parser existed have none either — a blank section reads as a bug when it is usually the receipt. Read-only. This is what a provider sent; editing it would make provenance mean nothing.	2026-07-27 10:55:57 +10:00
siddharthd	df4b875b82	feat(orders): make an ingested order legible in the transactions view ... Four things the view could not tell you, all from reading the rows (user, 2026-07-27). **Which platform.** The parser has always known — it has to, to read the template — and then discarded it. "Order - Burger Corner" gives no way to know whether to open DoorDash or Uber Eats for the detail, and restaurants exist on both. Now stored on expense_metadata and named in the description: "Order - Burger Corner (Uber Eats)". Migration 0021 recovers it for the 101 backfilled rows from the order_reference shape — DoorDash receipts carry no id of their own so ingestion synthesises `msg:<message-id>`, Uber carries a real trip UUID, which makes the discriminator exact. **Bank said "Manual".** That label is derived, not stored, and "Manual" reads as "hand-entered, still awaiting a card line to match". A gift-card order has no card line coming, ever. It now reads "Gift Card", and — the part that actually mattered — credits joins cash in needsCardMatch(), so these stop sitting in the pending-reconciliation queue. All 81 were queued against a match that could not exist. **Uber line items were never parsed.** 67 of 101 orders had none. Uber itemises groceries but not restaurant orders, so some of that is genuine; the rest was simply unread. Its markup is better than DoorDash's — every cell carries a data-testid with the item's uuid, so qty/title/amount bind by id rather than by column position. Sold-out items (0.00) are kept: they are why a total is lower than what was ordered. **Uber prints pick-up and delivery addresses on every receipt** and they were thrown away. Captured as `route` [{label, time, address}], de-duplicated because the template renders the whole block twice for narrow screens. Wording is kept as printed ("Pick-up" on some receipts, "Pickup" on others) rather than normalised, so a template change stays visible. This is the same block a *trip* receipt uses for start and destination — rides are not ingested today, but the reader will not need changing when they are. Also stores source_email_subject/from, which order ingestion had left null on columns that already existed. Verified against the captured corpus: route on all 6 Uber fixtures, 5/5 items on the GLOMARK grocery receipt including the sold-out one. Production data updated by smarthome:docker/scripts/order-presentation-2026-07-27.sql (81 descriptions, `backfill` tag, re-run clean). `route` and Uber line items are parsed from here on only — recovering them for already-ingested orders means re-reading the mail, which I7 idempotency refuses by design.	2026-07-27 10:51:30 +10:00
siddharthd	ae0c34fce7	fix(orders): two defects the backfill exposed that tests could not ... Both were found by looking at the data after the live backfill, not by the suite — 105 tests were green while 85 rows were invisible and 4 were double counted. owner_id was NULL on every ingested order. Analytics scope on COALESCE(t.owner_id, s.owner_id), and an ingested order carries no statement, so the coalesce resolved to NULL and matched no owner. The rows existed in `transactions` and appeared in no view in the app. Ingestion now sets DEFAULT_OWNER_ID, and a regression test asserts the row survives the same COALESCE scoping the UI uses. [Family] orders are card-settled, not credits-funded. Their receipts name the payer ("Payments Siddharth LKR 3,783.20") and no instrument, which an earlier version read as credits. The card statement carries all four of them (CBA ...3893, exact foreign_currency_amount matches), so creating a transaction duplicated spend already recorded — the double-count I5 exists to prevent. They now record provenance only; the statement line is the transaction and is what carries the `family` tag that keeps them out of budgets. Production data corrected separately by smarthome:docker/scripts/fix-order-backfill-2026-07-27.sql. Also: reconciliation tests no longer assert global row counts. reconcilePendingOrders() scans every pending row, so leftovers from other files moved the totals — the source of an intermittent failure that only appeared on the first run after a source edit.	2026-07-27 10:41:10 +10:00
siddharthd	5db42f086f	fix(orders): match the card leg by masking, not by card brand ... Backfill dry-run over 130 real messages surfaced one 422: 'payments sum to 1.17 but receipt states 16.50'. The receipt is a mixed Uber payment — Uber Cash $1.17 + Westpac ••••8032 $15.33 — and the card regex only matched Visa|MasterCard|American Express|Amex, so an issuer-named leg was dropped entirely. validateOrderTotals correctly refused it rather than recording $1.17 as the cost of a $16.50 order. Anchors on the ••••NNNN masking instead, which also covers the form already seen in the corpus ('Mastercard ••••3893 (CBA Ultimate) CHF 51.23'). Fixture and regression test added. Also repoints .env.test at the current postgres-personal container IP and documents why: the container publishes no host port, so the address changes on every recreate and the whole integration suite fails with connection errors until it is refreshed.	2026-07-27 01:39:42 +10:00
siddharthd	1103397397	fix(orders): three defects found reviewing my own branch ... None of these were caught by 105 green tests, because the code they live in was barely tested and the HTTP path was not tested at all. 1. reconcilePendingOrders hardcoded category 'dining', so any order resolved through the deferred path booked as dining regardless of merchant — a Woolworths grocery order that parks and later reconciles was misfiled. That reintroduced, through the back door, exactly the misfiling resolveCategory() exists to prevent. Now calls it. 2. reconcileCardLeg never marked a statement line as consumed, so two orders on the same card inside the +/-4 day window both bound to the same charge and each booked its own credits remainder — double-counting spend. At 10-15 orders a month on one card that is not a corner case. Migration 0020 adds matched_transaction_id with a unique index; the matcher now excludes lines already claimed. 3. The ingest API returned HTTP 200 for every parse failure, and the Slack alert fires only on non-200. So the single most likely production failure — a provider template change breaking every order at once — was completely silent. Split into NotAReceiptError (promotions, delivery updates, refund and adjustment notices: 200, silent, expected traffic) and OrderParseError (it IS a receipt and would not parse: 422, alerts). Also: order_reference now anchors on Uber's own tripReference cell rather than 'first UUID in the document'. I had claimed to verify that the first UUID was always the order UUID; that check compared against zero samples and was vacuous. tripReference is present in all 29 captured receipts and, for ue-00, equals the UUID the PDF redirect resolves to. The positional fallback remains but only flags when there is genuine ambiguity. Adds the API route's first tests — auth gate and error taxonomy — plus anchoring regressions. 63 unit + 53 integration green on five consecutive runs; corpus holds at 63/65.	2026-07-27 01:15:39 +10:00
siddharthd	a9e251d969	feat(orders): amendments, family imports, and the ingest API ... Closes the three gaps left after the parser rebuild. Refund amendments. ue-05 is a real refund: 'Previous total $49.94 / Refund -$4.21 / New Total $45.73'. Uber reuses the order UUID across the receipt and the amendment, so the two can be matched. The transaction is reduced in place rather than offset with a second row — the order is one event whose cost changed, and a compensating row would misreport both the meal count and the merchant's spend. When the original was never ingested, nothing is invented. [Family] orders now import instead of parking. Their payment line names the payer, not an instrument ('Payments Siddharth LKR 3,783.20'), so no split is recoverable and there is no card leg to reconcile against — they would have sat pending forever, which fails the actual requirement to import and tag them. Treated as credits, flagged as an assumption. Safe because the family tag removes them from every budget regardless of instrument, and the LKR amount is preserved with amount_aud left NULL rather than asserting an FX rate. Ingest API. n8n now POSTs each message to /api/orders/ingest instead of parsing in a Code node — the n8n sandbox has no require or fs, so a parser there cannot be tested against the fixture corpus, which is the one thing that makes this parser trustworthy. Auth is a shared secret, since machine callers have no Traefik session header. Rejections return 422 and record nothing. 60 unit + 45 integration green on three consecutive runs; 63/65 corpus holds.	2026-07-27 00:48:20 +10:00
siddharthd	c82a22767f	feat(orders): wire the real parser in, defer card reconciliation ... Ingestion now runs on the rebuilt parser. Three substantive changes. Deferred card reconciliation. A 'MasterCard 8032 and/or credits' receipt never states the split, but the card leg lands on the statement — Subway's $29.08 order shows $13.06 on 8032, so $16.02 was credits. For a live order that statement is weeks away, so the split cannot be settled at ingest time. Such orders are now parked with provenance and no transaction, and reconcilePendingOrders() resolves them once the statement arrives. Backfill takes the same path and resolves immediately. Migration 0019 adds the columns that make an order resumable; applied to personal_test only, prod untouched. Payment detection bug, found by the new tests: the old regex delimited the 'Paid with' line on a double space, which whitespace collapsing removes. Every card and mixed receipt fell through to the credits branch — the Woolworths receipt booked $60.93 of credits spend that never happened. Category resolution reversed deliberately. Correction 1 said never default to dining; the implementation of that sent everything unrecognised to 'other', and knowing six merchants meant Carl's Jr, Taco Bell, Chilli India, Oporto, Schnitz and Souvlaki GR all landed there. Grocers are an enumerable set and restaurants are not, so match groceries explicitly and let the residual be dining. Tests rebuilt on real captured receipts; the synthetic fixtures are deleted. 60 unit + 41 integration green on three consecutive runs.	2026-07-26 22:43:10 +10:00
siddharthd	33db7d05ef	feat(orders): rebuild the receipt parser against real captured email ... The previous parser was written against synthetic fixtures shaped to match the code. It invented a table layout DoorDash does not send, generated order_reference from Math.random(), read the order date from a 'Date:' string present in no real message, and detected [Family] by searching the body for the substring 'family'. Its tests passed because the fixtures were built to satisfy it. Against 36 real DoorDash and 29 real Uber Eats receipts it does not work. Rebuilt from the real corpus. 63 of 65 now parse and validate; the 2 rejected are correctly rejected — one is an order-adjustment notice and one a refund, neither of which is a receipt. Corrects an inherited diagnosis: the Mad Mex 'Discounts -$24.09' was recorded as an HTML-flattening artefact masking a 'true discount of $9.45'. Parsing the table cells structurally returns the same figures and no $9.45 exists anywhere in the message — DoorDash genuinely prints a Discounts line that equals subtotal plus service fee, and the components fail to reconcile on 32 of 36 receipts. So the breakdown is stored as provenance and never gated on; validation instead cross-checks the two independently stated totals and the payment line, which is the number that becomes money. Real-world cases the corpus forced, none of which were in the spec: [Family] orders are LKR purchases for family in Sri Lanka (reading them as dollars inflates ~200x), Swiss orders arrive in CHF, grocery 'Final receipt' mails carry no Total Charged row, and a declined payment is printed alongside the successful retry and must be skipped or it records money that never moved. order_reference now comes from the Uber order UUID embedded in the body, or the provider message id where DoorDash supplies no order id at all — never random, so re-ingestion is genuinely idempotent.	2026-07-26 22:25:26 +10:00