Segmentation: multiple segments per element via optional start/end brackets

[deanleigh]

The idea

A segment is scissors: it isolates a piece of a single source element. Today a rule can grab one contiguous piece (one from/to). This issue lets a rule grab several pieces from the same element — e.g. "first three words" and "last three words" from one messy chunk.

The point is human flexibility: look at any element and cut out the bits you can see, without pre-deciding use cases.

Progressive disclosure (the key UX rule)

• One segment → no brackets. Add segment + boundary conditions, as today. Implicitly one segment for the whole rule. Nothing gets more verbose. Existing single-segment rules are unchanged (backwards compatible — Tailored Travel already relies on this).
• Multiple segments → explicit segmentStart / segmentEnd brackets. Only when you want more than one piece from an element do you demarcate where each begins and ends.

Current model (for reference)

segment is effectively a verb today — a mode-switch marker meaning "conditions after me are boundaries, not matchers." It resolves to a single from/to (SegmentEvaluator.cs). Supported piece conditions: textFollows (from), textPrecedes (to), number (to end of numeric run). One from, one to, one piece.

Proposed model

segment becomes a noun: a bounded, named piece. A rule may contain one implicit segment or several explicit ones.

• Implicit (single): segment + piece conditions → one piece (today's behaviour).
• Explicit (multiple): repeated segmentStart … conditions … segmentEnd groups, each producing a piece.

Detection signal: no explicit segmentStart = one implicit segment; one or more segmentStart = explicit multi-segment mode.

Open questions (for the spec, not decided here)

• Output of multiple pieces: combined into one string, or kept distinct? Deferred — "what happens to the pieces" is a separate downstream concern from the cutting. Cutting is the feature.
• Data shape: conditions are a flat list today. Explicit segments need grouping/bracketing in the data model. Needs design.
• Depends on ordering (Reorder rule conditions (mechanism only, sortOrder + up/down arrows) #90, done) — evaluation order of segment brackets matters.

Not in scope

• Typed coercion of extracted pieces (already exists for integers via Support mapping into non-text destination fields (integer, date) #34).
• Date extraction (separate).

Prerequisite / relation

• Builds on Reorder rule conditions (mechanism only, sortOrder + up/down arrows) #90 (condition ordering mechanism — merged).
• This needs a proper brainstorm → spec → plan before implementation. This issue captures the shape; it is not yet an agreed plan.

[deanleigh]

Framing: the video-editing metaphor

The whole feature maps cleanly onto non-linear video editing, which makes it instantly graspable (good for the eventual UI language):

• Razor / blade — cut the element at a boundary → segmentStart / segmentEnd
• Clip / segment — the piece between cuts
• In / out points — the segment's start and end markers
• Trim — adjusting a segment's boundaries
• Splice — join clips back together → map multiple segments to one destination field

This answers the deferred "what happens to the pieces?" question

Splice = the mapping step. A destination field receives one or more segments, spliced together in order. Ordering is already controllable via #90.

• Three segments → spliced → one field.
• Different clips → different fields (just splice each to its own target).

So the output model is simple and human: cut the clips you can see, splice the ones you want into a field. No need to pre-decide combine-vs-separate — splicing handles both.