Make EasyCom event review wearer anchor first

docs/easycom_event_review_tool.md

@@ -24,8 +24,8 @@ python3 prepare_easycom_eot_int_review.py \
 
 The generator emits two independent files:
 
-- `easycom_eot_int_candidates.jsonl` contains EOT opportunities that pair a
-  non-wearer release with a later floor-level wearer `0->1` behavior anchor
+- `easycom_eot_int_candidates.jsonl` contains floor-level wearer `0->1`
+  behavior anchors with one or more admissible preceding non-wearer releases
   (`WEARER_ONSET`, `EOT_OPPORTUNITY_CANDIDATE`), only episode-ending wearer
   `1->0` boundaries where a new non-wearer onset satisfies
   `wearer_floor_start < other_onset < wearer_offset` and the same activity
@@ -49,11 +49,15 @@ continues across the resumed onset conservatively preserves a new wearer-entry
 candidate. Every decision is stored in `temporal_evidence`, including the raw
 gap, feedback IDs, competing IDs, threshold, and `floor_episode_merged` flag.
 
-After each non-wearer release, EOT construction scans forward until a
-floor-level wearer onset or a competing non-wearer onset. Silence length alone
-does not invalidate the opportunity. Each primary EOT candidate stores both
-`opportunity_anchor_seconds` and `behavior_anchor_seconds`, plus their response
-delay.
+EOT construction iterates floor-level wearer onsets, then searches backward for
+preceding non-wearer releases. A release is an admissible option only when the
+wearer stays silent and no new non-wearer onset or already-active other floor
+invalidates the interval before the wearer onset. Silence length alone does not
+invalidate an option. Each wearer onset produces at most one primary row. Its
+`opportunity_options` list contains the only release anchors that DeepSeek or a
+human may select; neither may invent a timestamp. The selected release is the
+opportunity anchor, the wearer onset is the behavior anchor, and their interval
+deterministically defines the valid EOT prediction interval.
 
 Paired wearer onsets and strictly qualified offsets are initially `unsure`;
 timing alone is not a semantic positive label. The INT prerequisite is
@@ -85,14 +89,15 @@ timeline; it is not sent to DeepSeek.
 
 ## 2. Add DeepSeek pre-labels
 
-Prompt v6 treats the EasyCom transcript marker `[L]` as laughter-only evidence,
+Prompt v7 treats the EasyCom transcript marker `[L]` as laughter-only evidence,
 not as a lexical floor take. Wearer laughter during another participant's
 retained turn is directed toward `EOT_WEARER_BACKCHANNEL`; non-wearer laughter
 overlapping a retained wearer turn is directed toward `INT_OTHER_BACKCHANNEL`.
 Ambiguous laughter remains `UNSURE`, and `[L]` alone is neither an exclusion
 reason nor evidence of a visible smile. The prompt also treats the two EOT
-anchors and strict INT ordering as deterministic prerequisites rather than
-asking the model to reconstruct them.
+anchor options and strict INT ordering as deterministic prerequisites. For a
+positive EOT response it must return `selected_opportunity_uid` from the supplied
+options; all other decisions use `null`.
 
 `needs_human_review` is not requested from DeepSeek: every pre-label enters the
 human queue by protocol, so the adjudicator assigns that boolean locally. This
@@ -125,8 +130,9 @@ DeepSeek sees candidate source, structured timing, per-speaker activity, and
 transcript together. It returns one of `POSITIVE`, `HARD_NEGATIVE`,
 `NOT_APPLICABLE`, `EXCLUDE`, or `UNSURE`; positives additionally receive
 `EOT_RESPONSE` or `INT_YIELD`, and hard negatives receive a named subtype. It
-cannot modify timestamps. The output preserves both the original rule candidate
-and the complete AI decision/provenance.
+cannot modify timestamps. The output preserves the original rule candidate,
+the selected EOT opportunity UID when applicable, and the complete AI
+decision/provenance.
 
 During live adjudication, the CLI displays a dependency-free progress bar over
 all candidate/pass work, including the current pass, batch, percentage, and
@@ -154,8 +160,9 @@ question, then presents the exact AI verdict/subtype with a plain-language
 meaning; the Accept control repeats that exact label so its effect is explicit.
 The common path is one operation:
 
-- **Accept** keeps the AI verdict/type;
-- **Relabel** expands verdict and subtype controls;
+- **Accept** keeps the AI verdict/type and its selected EOT opportunity anchor;
+- **Relabel** expands verdict and subtype controls and, for a positive EOT,
+  requires one of the supplied release anchors;
 - **Exclude** requires a concrete data-quality reason.
 
 The current primary-review UI deliberately has no second-review action. Older