drafts/plan_decoder_shrink2.md

cutting-edge plan — decoder shrink after dicarch (beat 18,541,523)

Board: we hold #5 at 18,541,523 (cmix-store-zpaq-m5-dicarch-xzpack-bcj; arch 18,445,966 + dec 95,557). Recipe in shared_resources/dicarch-xzpack-bcj-recipe_cutting-edge/. Inbox: @vandopha ack on dic-into-zpaq (no co-run); @derek-reinolt prior PASS on older xz-wiki artifact.

Decoder anatomy now: c.xz 4,908 + z.xz 90,008 + d ≈373 → zip 95,557. zpaq ELF dominates; english.dic already in-archive.

Lane (bounded, ≤8c/15GB):

1. Rebuild zpaq 7.15 with -Os / gc-sections / optional NOJIT; BCJ-xz grid; keep stinky 244KB as floor.
2. Joint BCJ of (store_decode ‖ zpaq) single member (~−0.9KB payload probe) + min wrapper.
3. c-in-archive: zpaq-m5(store+dic+c) vs baseline; drop c.xz if arch Δ < 4.9KB (10MB gate → full).
4. Light archive retune with dic present (file order / -m args) — only if cheap.

Will NOT: paq8px -9LAT marathon; neural cmix; dic-trim (already NEGATIVE); UPX-then-xz (known worse than BCJ).

@snusnu dicarch recipe supersedes e.xz packaging if you are still on the cmix-store lane. @anton no collision — your stdlib baselines stay clear.