@@ -7,6 +7,72 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- **Live detection.** On camera-like scenes the locate → crop → decode loop read about
+  half the codes it was shown and reported dozens of values that were not there, at
+  ~1 s per decode pass. It now reads 97.5% of 1D and 83% of 2D codes on the same scenes
+  with no wrong values, in tens of milliseconds (`examples/liveeval.rs`,
+  `tests/live_pipeline.rs`):
+  - `scan1d` treated a whole scan line as one barcode and required both crop edges to
+    be light; it now thresholds locally, cuts each line into quiet-zone-delimited spans,
+    fits module width and bar/space bias jointly, and samples band-averaged profiles at
+    any angle.
+  - `pipeline::scan_1d` believed any single decode although half its decoders have no
+    check character; readings now need cross-scanline consensus, quiet zones, a
+    plausible length, and must not be a fragment of a longer reading.
+  - The EAN/UPC width reader ignored quiet zones, reading a UPC-E out of the left half
+    of any EAN-13 and out of other symbologies and text.
+  - `detect::locate` only recognised barcodes within ~15° of the frame axes, was blinded
+    by uneven lighting (global Otsu), let a single false finder hit turn a text blob into
+    a top-ranked "QR" that swallowed the barcode inside it, and gave decoders no
+    orientation. It is now gradient-orientation based with local binarization, and
+    reports each linear region's reading axis and an oriented box.
+  - The App Clip scanner decoded ordinary barcodes and text into fluent-looking URLs
+    (its payload RS is far too weak for thousands of hypotheses per frame); it now
+    requires real ring structure and the template byte. Aztec no longer "decodes" a
+    blank patch (all-zero codewords are a valid RS codeword).
+  - QR and App Clip scanning no longer spend hundreds of milliseconds on code-free
+    frames.
+  - `FrameDetector` matched `Hints` by exact fingerprint equality, which sensor noise
+    and hand shake defeat on every frame; it now matches by position plus a tolerant
+    fingerprint.
+  - Web demo: a wasm trap or failed fetch left a decode worker "busy" forever, silently
+    disabling decoding for the session; the crop batch was truncated before barcodes
+    were prioritised, so busy scenes never decoded theirs.
+- Encoders now conform where they did not (output unreadable by other tools): Aztec
+  orientation marks, Data Matrix 144×144 block interleave, Micro QR M1/M3 padding,
+  Code 16K symbol value 106, one-track Pharmacode gap, Grid Matrix numeral/byte modes,
+  DotCode corner-forced masks.
+- Decoders now read what other encoders produce: DataBar Expanded methods 3–14, PDF417
+  byte shift 913, Code 128 / Code 16K / Codablock F FNC4, Code 49 numeric mode, Code 16K
+  modes 5/6, rMQR ECI, Aztec latched punctuation and FLG(n), DotCode macros and error
+  correction, Code 39 / Code 11 at 3:1 print ratio, Telepen cropped to its last bar.
+- Panics on hostile input: IMb, Mailmark, Han Xin, DataBar Expanded, DotCode and MaxiCode
+  decoders; App Clip URLs with non-ASCII near the scheme; `MatrixBuf::new` overflow; CLI
+  `--scale`, giant PNG headers, closed stdout.
+- Many decoders accepted malformed or non-canonical input (out-of-range numeric groups,
+  aliased Kanji, empty payloads, over-wide elements, unvalidated termination bars, Micro
+  QR M1 "error correction") that either mis-decoded or could not re-encode.
+- CLI: option parsing (flags swallowing data, unknown options ignored, surplus
+  arguments), alpha-channel PNGs decoding as solid black.
+
+### Added
+
+- `pipeline::scan_1d_at`, `scan_stacked_at`, `scan_linear_at`: decode a located linear
+  region along its known reading axis (1D readers, then the PDF417 family).
+- `scan1d::scan_spans`, `scan1d::refine_axis`, `ScanOptions::around`;
+  `imgproc::orient::gradient_angle_peaks`; `codes::ean::decode_edges_within`;
+  `detect::fingerprint_distance`.
+- `Location::rotation` and an oriented `outline` on linear `detect::locate` candidates.
+
+### Changed
+
+- `LocateOptions::anisotropy` is now a rotation-invariant gradient coherence (default
+  `0.7`) and `edge_density` a fraction of edge pixels; `ScanOptions::angles_deg` accepts
+  any angle.
+- One-track Pharmacode renders with the standard two-module gap (`max_modules` 78).
+
 ## [0.1.4](https://github.com/KarpelesLab/anydcode/compare/v0.1.3...v0.1.4) - 2026-09-15
 
 ### Added
 
@@ -91,29 +91,38 @@ lighting and cylinder curvature; clean-render envelope in `tests/harness_image.r
 real-capture envelope (bottle and can labels down to ≈4.6 px/module) in
 `tests/real_world.rs`.
 
-² 1D detection is the shared **`scan1d`** luminance front-end (edge detection →
-run-length → normalized `LinearPattern`), feeding each symbology's decoder. The
-end-to-end pixel→symbol path is verified for Code 128, Code 39 and EAN-13 in
-`tests/scan1d_pipeline.rs`; it applies to any standard bar/space linear code.
-Through `pipeline::scan_1d` the read is rotation-complete: mirrored patterns cover
-180°, and any other angle is handled by estimating the crop's dominant texture
-orientation and derotating before the rescan (`tests/rotated1d.rs`). The shared
-`pipeline::scan_1d` / `scan_all` entry points (and so the CLI and the demo) currently
-try the Code 128, EAN/UPC, Code 93, Code 39, ITF and Codabar decoders; the other
-linear decoders are driven by handing `scan1d::scan_lines` candidates to
-`scan1d::try_decode`. DataBar (finder-pattern based) and Pharmacode need dedicated
-samplers.
-
-³ Data Matrix ships an image sampler: Otsu binarization → largest-component isolation
-→ solid-L finder + timing-edge line fitting → perspective corners → `imgproc` grid
+² 1D detection is the shared **`scan1d`** luminance front-end. Each scan line is a
+band-averaged profile (real pixels, no interpolation) thresholded against a sliding
+local mid-level, then **cut into spans** at every run too wide to be a symbol element —
+so a label edge, a dark surface beyond the label, print beside the code or a second
+code on the same line do not disturb the read — and each span is quantized on its own
+with a joint module-width / bar-vs-space-bias fit. Scan lines run at any angle, straight
+out of the frame. `pipeline::scan_1d` tries horizontal, then the crop's
+edge-orientation peaks, then vertical; `pipeline::scan_1d_at` takes a known reading
+axis (the locator reports one), refined by profile sharpness. Readings are accepted by
+**consensus**, not on a single decode: at least two scan lines must agree, the span must
+show real quiet zones, the payload must be plausibly long for its symbology (only
+Code 128, Code 93 and EAN/UPC carry a check character), and a reading that is a fragment
+of a longer, equally supported one is dropped. EAN/UPC additionally has a width-ratio
+reader for curved and blurred captures. The shared entry points currently try the
+Code 128, EAN/UPC, Code 93, Code 39, ITF and Codabar decoders; the other linear decoders
+are driven by handing `scan1d::scan_spans` candidates to `scan1d::try_decode`. DataBar
+(finder-pattern based) and Pharmacode need dedicated samplers. End-to-end coverage:
+`tests/live_pipeline.rs`, `tests/scan1d_pipeline.rs`, `tests/rotated1d.rs`.
+
+³ Data Matrix ships an image sampler: Otsu binarization → the largest few dark
+components tried in turn (so a dark surface or print beside the code does not displace
+it) → solid-L finder + timing-edge line fitting → perspective corners → `imgproc` grid
 sampling, with symbol size and grid chirality confirmed by Reed–Solomon. Robust to
 any-angle rotation, scale, blur/noise and (size-graded) tilt; envelope in
 `tests/datamatrix_image.rs`.
 
 ⁴ PDF417 (finder-less) is located by its start/stop guard columns → RANSAC edge fit →
 affine grid sampling → RS-corrected decode. Handles upright, rotation ≤±10°, scale,
 blur and noise; perspective keystoning is out of scope (no interior anchor). Envelope
-in `tests/pdf417_image.rs`.
+in `tests/pdf417_image.rs`. On the live path the locator reports a PDF417 as a linear
+region with its axis, and `pipeline::scan_linear_at` derotates the crop by it first, so
+located symbols read at any rotation.
 
 ⁶ Aztec, Micro QR and rMQR ship image samplers built on their native fiducials:
 Aztec's bullseye (equal-run cross-section scan → the enclosed light annulus floods
@@ -225,44 +234,70 @@ assert_eq!(encoder.encode(&decoded).unwrap(), encoding);
 
 For a camera feed you rarely want to fully decode every frame. The `detect` module
 provides a fast, symbology-agnostic **locator** that returns the *position* of every
-code (a bounding quad + coarse family guess) in a single downscaled pass, **without
-decoding** — the cheap stage of the two-stage `Detect` → `Analyze` pipeline. It is
-recall-biased but structurally picky: concentric-finder detection backs matrix
-guesses, scene-sized merged blobs, text rows/columns masquerading as barcodes and
-non-code ink densities are gated out, overlapping duplicates of one physical code are
-suppressed, and a close-up code that defeats the texture pass is still reported from
-its finder hits alone:
+code (a quad + coarse family guess) in a single downscaled pass, **without decoding** —
+the cheap stage of the two-stage `Detect` → `Analyze` pipeline.
+
+It box-averages the frame down, thresholds it against its *local* neighbourhood (so a
+lighting falloff, a shadow or a code on a dark product still binarizes), and sums each
+tile's gradients into a structure tensor. A tile whose edges all share one direction is
+a patch of bars — **at any rotation** — and such tiles cluster only with neighbours on
+the same axis, so a barcode separates from the print around it and comes back as a box
+*aligned with the code* plus its **reading axis** (`Location::rotation`). Incoherent
+edge-dense tiles are matrix/texture; concentric-finder hits (cross-checked on both axes
+and a diagonal) vouch for QR/Aztec. It is recall-biased but structurally picky: linear
+regions need a barcode's worth of unbroken bars filling their box, finderless matrix
+guesses need two well-separated tones at code-like ink coverage, scene-sized blobs and
+duplicates are dropped, and a close-up code that defeats the texture pass is still
+reported from its finders alone.
 
 ```rust
 use anyd::detect::{locate, LocateOptions};
-
-let candidates = locate(&frame, &LocateOptions::default());
-for c in &candidates {
-    // c.location — where the code is; c.symbology — family guess.
-    // Hand off to the matching sampler/decoder only for new regions.
+use anyd::pipeline::{scan_all, scan_linear_at};
+
+for c in locate(&frame, &LocateOptions::default()) {
+    // c.location.outline — where; c.symbology — family guess; for a linear region
+    // c.location.rotation — the axis to scan along. Crop the outline's bounds (plus a
+    // margin) and decode just that:
+    //   linear  → scan_linear_at(&crop, axis)   (1D readers, then PDF417 family)
+    //   matrix  → scan_all(&crop)
 }
 ```
 
+`detect::FrameDetector` wraps this as a `Detect` that also reuses `Hints`: a candidate
+is matched to a previously decoded symbol when it sits where that symbol was *and* looks
+like it (a noise- and shift-tolerant ink fingerprint), so known codes skip re-analysis
+without a swapped-in code inheriting the old value.
+
 Benchmark (`cargo bench --bench detect`, dependency-free, `std::time::Instant`),
 locating **all** codes of all families per frame vs. a full QR decode:
 
 | resolution | locate median | locate FPS | full QR decode | detect speedup |
 |-----------:|--------------:|-----------:|---------------:|---------------:|
-| 640×480    | 0.29 ms | ~3400 | 12.1 ms | ~41× |
-| 1280×720   | 0.70 ms | ~1430 | 14.1 ms | ~20× |
-| 1920×1080  | 1.53 ms | ~650  | 17.4 ms | ~11× |
+| 640×480    | 0.43 ms | ~2300 | 4.5 ms  | ~10× |
+| 1280×720   | 1.24 ms | ~800  | 6.6 ms  | ~5×  |
+| 1920×1080  | 2.75 ms | ~360  | 10.1 ms | ~4×  |
+
+Those frames are pristine renders on white, which any locator finds. The number that
+matters is end-to-end on camera-like scenes — codes planted off-centre in a 720p frame,
+rotated 0–90°, on a page, a dark surface or amid print, under a 2:1 lighting falloff,
+blurred and noisy — replayed through the same locate → crop → decode loop a front-end
+runs (`cargo run --release --example liveeval`):
+
+| | read rate | wrong values | decode time / frame |
+|---|---:|---:|---:|
+| 1D (EAN-13, Code 128, Code 39, ITF) | 97.5% | 0 | ~50 ms crop batch |
+| 2D (QR, Aztec, PDF417, Data Matrix) | 83% | 0 | ~120 ms whole-frame pass |
 
-Recall 100% and false-positive rate 0% on the benchmark's planted-code frames.
-Locating is comfortably real-time at every resolution; decoding then runs only on the
-regions the locator hands off (and `Hints` lets already-decoded codes be skipped
-across frames).
+Data Matrix is the weak one (its sampler needs a clean surround); QR and Aztec are at
+97–100%. `tests/live_pipeline.rs` pins this behaviour in CI, including the things that
+must *not* read: text, half an EAN-13 (structurally a UPC-E), ITF fragments.
 
 The demo page shows the intended live wiring: the main thread runs `locate` on a
-half-resolution grab ~30×/s, a crop worker decodes located regions off-thread —
-routed by family, so linear crops take the fast 1D path (`scan_1d` is
-rotation-complete via mirrored patterns and gradient-orientation derotation) — a
-second worker sweeps the full frame for self-localizing 2D codes, and decoded locks
-are position-tracked across frames so the overlay follows the code between reads.
+half-resolution grab ~30×/s; a crop worker decodes located regions off-thread, linear
+crops first and along their reported axis; a second worker reads self-localizing 2D
+codes off the frame, alternating the half-resolution frame with the central half at
+full resolution; and decoded locks are position-tracked across frames so the overlay
+follows the code between reads.
 
 ## Command-line tool (`anyd`)