While drafting backend/tests/test_trailing_plan.py for the changes
landed in b4e0985, the new tests surfaced a deeper false-positive the
earlier regex tightening missed.
For input "Let me explain:\n1. The function returns 42.\n\nThat's the
answer." the previous `(?:\s*(?:[-*•]|\d+\.)\s+[^\n]+\n?)+` allowed the
regex engine to backtrack and treat the in-prose "42." substring as a
second list-item marker: iter 1 consumed "1. The function returns 4"
and iter 2 consumed "2.\n\nThat's the answer." (with `\s+` greedily
crossing the empty-line break). The pattern then satisfied `\s*\Z` and
the buffer fired a spurious `Continue.` retry on what was already a
fully-formed answer.
Tighten the per-item boundary:
- `[ \t]*` before the marker (no newlines): forces the marker to sit
at the start of its own line. A mid-prose "42." cannot satisfy this
because the engine cannot rewind past the preceding `\n` without
invalidating the previous iteration's `[^\n]+\n` close.
- `[ \t]+` between the marker and content: blocks an `\s+`-driven
cross-newline reach into a closing paragraph.
- `(?:\n|\Z)` at end of item: a real line break OR end of buffer.
Preserves the "list at EOB with no trailing newline" case while
eliminating the backtrack route.
Land backend/tests/test_trailing_plan.py at the same time, covering:
- `_TRAILING_PLAN_INTENT` "let me know" closer exclusion (cycle-3 fix).
- `_TRAILING_PLAN_LIST` correctly fires on genuine trailing lists
(dash, asterisk, unicode bullet, numeric).
- `_TRAILING_PLAN_LIST` does NOT fire on list + closing paragraph,
list + closing sentence, list embedded mid-text, or the "42."
in-prose digit case.
- `_TRAILING_PLAN_COLON` fires on bare trailing intent-colons only.
- `_trailing_plan_hit` composite cases.
- The 600-char window slicing.
31 cases, all pass. Pins the regex behaviour against future regressions
inside the repo (the prior pin script lived only in the probing
workspace, not the studio tree).
7dbe18ab51