From 22fbb3392337303c350e6072450187a0f6199d9b Mon Sep 17 00:00:00 2001 From: Dominik Roth Date: Thu, 13 Aug 2026 22:11:56 +0200 Subject: [PATCH] TODO.md: clarify multi-shell request gap isn't silent data loss The raw request text (both shells, in order) is already preserved and shown to the player via the coord dialog's description view (Location.desc_raw) -- not machine-parsed into a second structured shell field, but not actually lost either. Lowers the urgency/changes the framing before deciding whether to build real sequence support. Co-Authored-By: Claude Sonnet 5 --- TODO.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/TODO.md b/TODO.md index df2e72e..229f89b 100644 --- a/TODO.md +++ b/TODO.md @@ -328,11 +328,18 @@ each confirmed live against the real VM, not just read off a diff: - [ ] A multi-shell sequential request ("Requesting TEAR Shell first, then HE Shell, at bearing...") only captures the FIRST shell - (TEAR) -- "then HE Shell" is silently dropped, no way currently to - record "use this shell, then that one." Real scope question before - fixing: does the board/firing-panel data model even have a place - to put a second shell for one strike request, or does this need a - new field/shape entirely? + (TEAR) into the structured `shell` field -- "then HE Shell" isn't + parsed into anything. Less urgent than it first looked though: the + full original message text (both shells, in order) is already + preserved as-is and shown to the player via the coord dialog's + description view (`Location.desc_raw`, set from the same `raw` + every merged target/ally carries) -- nothing is silently LOST, it's + just not machine-parsed into a queryable second-shell field. Real + scope question before building that: does the board/firing-panel + data model even have a place to put a second shell for one strike + request today, or does this need a new field/shape entirely -- + worth confirming it's actually wanted (vs. "read the raw text + yourself, it's right there") before spending the design effort. - [x] "Answer by 10:30:00" turned out to be one bug, not two. The phrasing itself was never the problem -- `_TAKING_FIRE_TIME_RE` already matches any `before|by