# Detection proposes, the human disposes — there is no unattended mode

Every automatic result the slicer produces — skew angle, cut positions, source
type, staff height, ink bounds — is a **suggestion the user confirms or modifies**
before it is committed. There is no batch mode, no headless "slice this folder",
and no code path that writes a bundle without a human having looked at it.

This is a constraint on the tool's shape, not a UI preference, which is why it
gets an ADR: it deletes an entire phase of the original plan and it will look
like a missing feature to anyone who finds the detection code and wonders why it
isn't wired to a CLI.

## Why

The corpus is PDFs from a choir's distribution channel, and quality varies
wildly — clean vector engravings at one end, noisy scans with a previous owner's
pencil markings at the other. **Testing showed the detection algorithms produce
unusable slices on any source with speckles or otherwise poor quality.** Not
slightly-off slices: unusable ones.

But the same testing showed the suggestions land *close* on decent sources —
close enough that correcting them is faster than placing cuts from scratch. So
detection earns its place as an accelerator, and loses any claim to being
load-bearing.

## What this rejected

The original plan's **Phase A** was a deliberately non-interactive CLI:
rasterize, auto-deskew, auto-detect boundaries, write numbered slices, and fix
the misses by hand in GIMP. Its justification was "learn the failure modes before
designing the editor," which is a good idea.

It doesn't survive the premise. A CLI whose output can't be trusted has GIMP as
its repair path — routing work back into the manual process the project exists to
remove. A diagnostic variant (dump per-page PNGs with proposed cuts drawn in red)
was considered and also dropped: it only re-shows a failure already confirmed by
testing, and the editor shows the same thing live.

Release 1 is therefore the editor and detection together. There is no smaller
first release that is actually usable.

## Consequences

- **Manual placement is the primary interaction**, not a correction affordance.
  The editor must be fully usable with detection producing nothing.
- **Despeckling targets the detector, not the output.** The known failure mode is
  specks, so a median blur and a small-component filter clean the row-darkness
  profile the detector reads; the shipped pixels come from the levels-adjusted
  image.
- Cut placement is deliberately **forgiving** — anywhere in the whitespace gap
  yields the same output, since trim crops to ink afterwards. Precision is not
  asked of the human.
- The editor should surface **slice edges**, not just cut lines, so trim
  anomalies (a speck anchoring the bounding box) are visible rather than
  discovered later in the viewer.