17/10/2026. The five threads finished their work and reviewed each other. I then combined all five PRs on the latest main, ran every check, and had an independent reviewer read the whole set. Most problems have a clear fix. Five need your choice, because each one changes how the app behaves for the user or how much risk we accept. Each choice below has the background, real examples, the options, and my recommendation (already selected). At the end, a box collects your choices so you can copy them back to me.
| PR | What it does (the option you chose) | State |
|---|---|---|
| #148 Cash rules | Cash withdrawals (SELF cheques, also printed as "SELF-CHQPAID"; ATM) are saved to the cash ledger automatically when the company has one cash ledger. A line in Suggestions says how many and links to Review. | Open, checks pass |
| #149 Cheque learning | Silent fill: after you choose a ledger for one cheque, the payee's other cheques with the same text are saved automatically. The cheque number no longer makes each cheque look new. | Open, checks pass; replay check fails (decision 1) |
| #150 Export list | The Export step lists entries that have a suggestion nobody saved, before they go to Suspense. Accept one, or Accept all / Ctrl+Shift+Enter. | Open, checks pass |
| #152 Suspense step | After a choice, a pop-up lists Suspense entries that just got a suggestion ("Now suggested"), and a header line counts them with Accept them. | Open, checks pass; pop-up to be replaced (decision 4) |
| #153 Ledger ties | The matcher breaks ties by direction, group and bank. A tie that stays shows "1/2" in the Ledger box; Alt+] / Alt+[ switch the ledger shown. | Open, checks pass; tie colour (decision 3) |
go vet pass.| Change against main | fresh | prior | full |
|---|---|---|---|
| Right ledger saved automatically | +120 | +99 | +96 |
| Right ledger saved or offered first ("good rows") | +17 | +17 | +8 |
| Decisions left for the user | −17 | −17 | −8 |
| Wrong ledger saved automatically | 0 → 0 | 1 → 1 | 1 → 3 |
The replay has a rule: no change may add a wrong automatic save. The "full" column breaks it by 2. Decision 1 is about those 2 rows.
When the books booked the same cheque text to two different ledgers, what should the automatic fill do?
With #149, one choice for a cheque fills the payee's other cheques with the same text. That is the whole point: in the alpha, KESARI NANDAN ART had 10 "SELF-CHQPAID" cheques, and after 2 choices the other 8 still waited. On the production copy, #149 would fill 66 waiting rows (62 SELF cheques to Cash, 4 JAY ART cheques to JAY ART), all right.
But sometimes the accountant booked the same cheque text to two ledgers. Then the fill copies the earlier booking, and it is wrong. The replay found 2 such rows (names replaced):
Here the narration itself names the right ledger, and the name matcher finds it. The reviewer tested a small fix: on a cheque row, when a name in the text points to another ledger more strongly than the learned one, do not save automatically; suggest instead. Result: wrong saves 3 → 2, and no good row is lost. I will apply this fix in every option below.
Nothing in the text tells these two apart. The person collected cash once for wages and once as cash. No rule can fix this row without stopping the fill after one choice.
Why A: the replay shows 96–120 right saves gained for 1 wrong one, and the wrong one comes from inconsistent books, not from a bad rule. Every automatic save is still visible in Review.
When a cheque row prints only a town or a bank (no payee), should one choice still fill the others?
#149 keeps a cheque's number (so no fill) when the text has no payee word. It decides this with word lists: cheque words (CHQ, CLG, MICR…), bank codes, and a list of clearing towns (MUMB, JETPUR…). Any other word counts as a payee. So a town or bank that is not on a list is taken as the payee, and different customers' cheques can look like one payee. Both the code review tool (OpenQodex) and the reviewer flagged this.
The SBI row is real: a ₹1,05,655 deposit on 13/10/2023 in one company's HDFC statement. The books do not hold it, so the replay cannot say who it was from. The BHAKTINAGAR rows are cheques that print only the branch; the books put all of them to Cash.
How often today: in the replay data and the production copy, this caused no wrong save. Real cheque rows without a payee are already handled: "CAS PRES CHQ" (3 different suppliers in ASMARK's books) keeps its number. "CHQ PAID- CHQPAID- BHAKTINAGAR-" (4 rows, all Cash in the books) fills, which is right there. Rows like the SBI example exist in the data but were never booked differently.
Why A: it removes the case we can name (bank names) at low cost, keeps the behaviour you chose, and no wrong save of this kind has appeared in real data.
When two or three ledgers still tie, what colour should the mark be?
A tie is when the matcher finds two or three ledgers equally likely, for example:
In the option you chose, #153 divides the confidence by the number of tied ledgers. A 91% match tied two ways shows as 45%, so every tie is red. But the replay measured how often the first tied ledger is right: two-way ties 31 of 44 (70%), three-way ties 8 of 13 (62%), because #153 now orders tied ledgers by direction and group first.
There is a side effect. The Miracle history clue replaces the server's suggestion when the server's number is lower. A "same amount in the books" clue (50%, right about half the time) now beats every tie, and a "recurring" clue (78%) always does. So a sensible tied suggestion can be replaced by a weaker guess.
Why A: the mark is meant to say how likely the suggestion is (90/70 rule). The measured number does that; dividing does not.
You asked: if the pop-up lists a payee's other entries, all ticked, how often would the user keep them all? If nearly always, drop the pop-up and fill them automatically. Here is the measurement, and the one choice left.
After you choose a ledger for one entry, a pop-up (on main since 16/10, #115) lists the payee's other open entries, all ticked; Enter saves them all. #152 adds a "Now suggested" part on the Suspense step. Both would go. The payee groups are the app's own: same UPI ID, same account number, or same narration pattern. The pop-up does not look at the direction, so a payee's receipts and payments are offered together.
For every payee group in every statement, I took the books' ledger for the group's first open entry as "your choice", and checked the books' ledger of each entry the pop-up would offer. "All offered entries right" means every offered entry is booked to that same ledger, so pressing Enter with everything ticked (or filling automatically) would be right.
| Rule | Pop-ups | All offered entries right | Offered entries | Right |
|---|---|---|---|---|
| As built: both directions | 113 | 106 (93.8%) | 273 | 266 (97.4%) |
| Same direction only (payments with payments, receipts with receipts) | 109 | 107 (98.2%) | 265 | 263 (99.2%) |
| Entries in the other direction alone | — | — | 8 | 3 (38%) |
entry.offer) arrives with #152, and the 16/10 app grouped no cheques (the cheque number split them until #149).In the same direction, users would keep everything ticked 98–99% of the time. The pop-up asks a question whose answer is almost always yes, so your call to drop it fits the data. The proposal: no pop-up anywhere in the normal flow; a choice fills the payee's other open entries in the same direction automatically; the status line says "8 more entries got Cash Account"; every filled entry shows in Review and can be changed there; the Settings switch for the pop-up goes. The "N entries here now have a suggestion" line (#152) and the Export list (#150) stay as the last checks for anything not filled.
Why A: it removes the pop-up as you want, and "same direction" is the one rule that keeps the fill nearly always right.
Who makes the fixes, and how do the five PRs become one change on main?
Today the five PRs point at matching/alpha-fixes, which is 3 commits behind main. Combining them needs conflict fixes in 7 files and one shared generated file (the confidence table) made once on the combined code. Besides your decisions, these fixes need no choice (owner in brackets):
data-above-table mark.Why A: parallel fixes by the owners, one combined check before main, and one clean commit on main.
Sources: combined checkout of #148, #149, #150, #152 and #153 on main ba0e44e; bun run matcheval on the 10-company replay corpus; the 17/10 production copy; the threads' cross-reviews and an independent review. Customer names in the examples are shortened or replaced.