Persist the dates the form always collected and always threw away
The creation form has always offered real date and time pickers, and the write kept only the label derived from them. The user chose a date; the broker never saw it. Five fields went that way, on create and on update alike, because the shape defined nowhere for them to land. `startDate`, `endDate`, `startTime` and `endTime` are now on the Event shape and carried end to end. `date` is untouched -- it is the label the lists display, and nothing derives one from the other. `themes` is deliberately left out: it is a repeated value, so it needs a cardinality decision rather than one more optional string, and nothing consumes it. Proven on the running application, both paths, asserted only after a reconnect because the optimistic overlay shows the values before anything is durable: written 2026-12-05 / 09:15, read back identical; edited to 2027-01-22 / 08:05, read back identical. An event missing the fields renders clean -- the time line simply absent, nothing thrown. The recorded generator drift no longer reproduces. Regenerating from the UNCHANGED shape produced bytes identical to the committed bindings, which is how the additive diff was separated from the generator's own; that separation was the point of running it twice, and it turned a warning into a measurement. The doctrine still carries the old warning and is now wrong about it. Also worth having: the form composes its label from the ISO values joined, not from the French wording the doctrine gives as its example.
This commit is contained in:
@@ -0,0 +1,7 @@
|
||||
# Doc-debt — app-architecture
|
||||
|
||||
> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
|
||||
> One block = one "big change": `why` + `files` + `verify` (leaves to review).
|
||||
|
||||
## Raw markers (consolidate into blocks, then delete)
|
||||
- TOUCHED src/shared/context/FestipodDataContext.tsx @2026-08-17 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
|
||||
Reference in New Issue
Block a user