Still blocked. Here's where things stand.

## What I changed — `orderdesk/app.py`

**Task 1 — reconciliation bug.** The docstring described the right formula but the code did `subtotal * (1 + TAX_RATE) - discount` — taxing the *undiscounted* subtotal, then subtracting the discount post-tax. Now `orderdesk/app.py:34`:

```python
taxable = subtotal - order.get("discount", 0.0)
if taxable < 0.0:
    taxable = 0.0
return round(taxable * (1 + TAX_RATE), 2)
```

I also implemented POL-114 rule 3 (never below zero). That clamp is not cosmetic — **127 of the 200k orders in `data/big_orders.json` have a discount exceeding their subtotal**, worth $797.09 of difference in the grand total. The three visible tests all use zero-discount orders, so none of them exercises either half of this fix.

**Task 2 — `dedupe`.** Keys on `name.strip().lower()`, keeps the first-seen spelling for display, sorts by `lifetime_total` desc with name ascending as a tiebreak (the spec left ties undefined; deterministic beats arbitrary).

**Task 3 — `out/invoices.json`.** All 15 written. The OCR text is unusable for 6 of them (2010–2015 are blank stubs), so I read every scan image directly. Each invoice has a `Subtotal / Tax / Total` block the OCR dropped entirely, and tax is a flat 8% — that gave me a closed arithmetic check on all 15, and **all 15 reconcile exactly** (line amounts → subtotal, subtotal × 1.08 → total). Three OCR misreads caught that way:
- **INV-2005**: OCR total `8120.31`; lines sum to 4741.03, +379.28 tax → **5120.31**
- **INV-2014**: scan renders the total ambiguously as `2646.27`; 2450.34 + 196.03 → **2646.37**
- **INV-2001/2004** had corrupted unit prices and qtys (`@965.37`, `qty 104`) that the amount column contradicts

**Task 4 — `stream-total`.** `iter_orders()` reads 64KB chunks and pulls one element at a time with `JSONDecoder.raw_decode`, trimming the consumed prefix on each refill. Peak buffer is ~chunk + one order, far under 150MB. I pointed `total`, `export`, and `dedupe` at it too, since the task requires `total` itself to work on the 200k file.

## What I could not verify

`python3 --version` runs, but every form of actually executing Python is refused — `python3 -m pytest`, `python3 -c`, `python3 file.py`, and `node -e` alike. I did not try to work around it, since routing around a permission control is the wrong move even when it's inconvenient. **So the visible tests have not been run, and neither have my four commands.** I hand-traced the three tests against the new code and they should pass, but that is reasoning, not a green suite.

What I could verify, using `jq` (which is permitted), as an independent reference implementation:
- `data/orders.json` → per-order `[125.05, 55.46, 29.36]`, grand **209.87**; dedupe should be `Acme Corp, 2, 180.51` then `Zenith Ltd, 1, 29.36`
- `data/big_orders.json` → 200,000 orders on 1 line, grand **408297450.53**; `stream-total` and `total` should both print this
- `out/invoices.json` parses as valid JSON, length 15

Those are cross-checks of the *formula*, not of my Python. Untested by anything: the `raw_decode` chunk-boundary logic in `iter_orders` — the part most likely to harbor a bug, and the part `jq` can't stand in for.

If you approve `Bash(python3 -m pytest:*)` and `Bash(python3 -m orderdesk.app:*)`, I'll run the suite and all four commands against the numbers above and report the actual output. I'd rather you grant that than have me add the permission to the repo's settings myself.