dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

TODO.md: clarify multi-shell request gap isn't silent data loss

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Dominik Moritz Roth 2026-08-13 22:11:56 +02:00
parent 6e34f50b6a
commit 22fbb33923
1 changed files with 12 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
TODO.md
View File

@ -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 <time>`, "Answer BY 10:30:00"