117 lines
7 KiB
Markdown
117 lines
7 KiB
Markdown
# Web Sessions V1
|
|
|
|
Preparation list rows expose independent `editing_state` and `delivery_state`.
|
|
A local draft action saves one new ready revision on the same preparation and
|
|
then creates its delivery; a local ready revision is delivered directly.
|
|
Pending, acknowledged and remote-unknown preparations never create a second
|
|
delivery. The action is disabled while its request is running and every state
|
|
has visible text in addition to color.
|
|
|
|
Successful delivery admission immediately starts the configured common sync
|
|
orchestrator. If transport is unavailable, the durable pending delivery remains
|
|
retryable; the preparation is not reverted or recreated. When completed
|
|
history contains the delivery's exact `execution_session_id`, the preparation
|
|
leaves the active list while all preparation revisions, entries and delivery
|
|
provenance remain stored. Program completion continues to derive from the Core
|
|
`execution_state`, never from list disappearance.
|
|
|
|
The Sessions route implements four distinct views:
|
|
|
|
- Preparation: manual preparations and immutable AI proposals;
|
|
- Resume: lifecycle-backed execution drafts, continued only on Android;
|
|
- History: completed sessions, including explicit unknown end times.
|
|
- Programs: durable desktop planning definitions, import and explicit manual
|
|
preparation creation.
|
|
|
|
Manual preparation supports a title, session type, optional calendar date,
|
|
note, catalogue selection, duplicate occurrences, keyboard reordering,
|
|
equipment/load semantics and profile-compatible targets. Draft saves may remain
|
|
incomplete. Marking ready validates executable content; preparing for Android
|
|
then creates a distinct immutable delivery and reserved execution identity.
|
|
|
|
Every view has one stable descending presentation order. Preparation merges
|
|
manual preparations and proposals by valid planned civil date, then factual
|
|
`sort_timestamp`, then kind and stable identity. Undated or invalidly dated
|
|
items remain visible after valid dates. Resume uses the execution-draft recency
|
|
timestamp supplied by Core, and History uses the real start instant; both use
|
|
stable identity to break exact ties. Search and filters operate on the complete
|
|
paged result and reapply the same order. Late results from an older view or
|
|
query cannot replace the current list.
|
|
|
|
Web presentation defaults to French civil dates (`DD/MM/YYYY`) and 24-hour
|
|
times. A local **Display settings** dialog can select ISO dates. The versioned
|
|
preference is stored atomically with private permissions in
|
|
`$XDG_CONFIG_HOME/trainlog/web/preferences-v1.json`, falling back to
|
|
`$HOME/.config`; it is neither business data nor synchronized state. Missing
|
|
or invalid storage uses the French default, and invalid storage is reported.
|
|
Civil `YYYY-MM-DD` values are validated and never timezone-shifted. Zoned
|
|
timestamps preserve their instant and are presented in the browser timezone;
|
|
the original machine value remains in API data and `<time datetime>`.
|
|
|
|
Stored states remain wire-level enums, while Sessions presents contextual
|
|
French labels. A preparation derived from a proposal exposes the persisted
|
|
source identity and title as a stable deep link; the source digest remains a
|
|
technical detail and no title-based inference is performed.
|
|
|
|
Opening or deriving from an AI proposal never accepts, starts, deletes or
|
|
rewrites the source. Derivation records the exact proposal identity and imported
|
|
payload fingerprint. The Android screen labels manual preparations separately
|
|
and refuses to overwrite an active draft.
|
|
|
|
**Delete preparation** is a durable logical withdrawal, not physical evidence
|
|
purging. The protected DELETE command requires Host/Origin/CSRF, a bounded
|
|
idempotency key and the exact current revision. One desktop transaction records
|
|
the immutable withdrawal and makes the preparation unavailable for editing,
|
|
new delivery, active Sessions lists and the Dashboard projection. Revisions,
|
|
delivery rows, ACK evidence, the source proposal and all execution identities
|
|
remain intact.
|
|
|
|
The separately versioned `trainlog-session-preparations` V2 artifact carries
|
|
unacknowledged withdrawals and the exact linked delivery identities. Android
|
|
schema v23 stores one permanent withdrawal result per preparation. Pending
|
|
deliveries become `cancelled`; started deliveries, the active draft and all
|
|
completed facts remain unchanged and are recorded as `execution_preserved`.
|
|
The tombstone rejects an older delivery replay, including after process restart.
|
|
Desktop marks a withdrawal acknowledged only after the correlated Android
|
|
generation ACK. Until then Web reports that Android synchronization is pending.
|
|
|
|
Every deletable row has a separate right-edge trash action with an accessible
|
|
target. It never opens the detail. A focus-managed `alertdialog` names the item,
|
|
kind, relevant date and consequence; Cancel and Escape write nothing. Proposal
|
|
deletion records a durable logical withdrawal and publishes a bounded V2
|
|
proposal tombstone without deleting derived preparations or performed work.
|
|
Inactive execution drafts and completed sessions use the existing causal
|
|
operation/state boundary. Active or stale drafts conflict, and completed-session
|
|
deletion records a finalization so older snapshots cannot recreate the session.
|
|
|
|
Programs are planning data owned by desktop SQLite (introduced in v25 and
|
|
extended through v37). The Programs subtab
|
|
uses responsive cards and a timeline detail view backed by real imported
|
|
definitions, sessions, usage, and provenance data. Import first runs the
|
|
same strict Core validator in preview mode, then commits only after explicit
|
|
confirmation. Exact content replay is idempotent; same-ID divergent content is
|
|
a conflict. Archiving preserves definitions and derived preparations. Creating
|
|
a preparation from one active program session copies targets and provenance
|
|
into a new manual preparation but creates no delivery, execution or performed
|
|
data. Program imports preserve target weights expressed as either integer or
|
|
real JSON numbers. A Program row affected by the former integer-weight import
|
|
defect can still create an editable draft: its impossible zero weight becomes
|
|
an unspecified draft target without rewriting the imported Program. Archived
|
|
or deleted programs cannot be prepared.
|
|
|
|
Desktop schema v27 enriches each Program session with a persisted execution
|
|
state. Web displays `À faire`, `Préparée`, `En cours`, or `Effectuée`; completed
|
|
and in-progress states come from stable Android execution provenance, while
|
|
prepared comes from a live derived preparation. No title, date, position or
|
|
content heuristic is used.
|
|
|
|
The discrete right-edge Program trash action is accessible and opens a
|
|
confirmation dialog that names the program and its consequence. Focus moves
|
|
into that dialog, Escape and Cancel perform no mutation, and focus returns to
|
|
the initiating action. Deletion is terminal logical deletion: it is allowed for
|
|
active and archived programs, retains source and derived-preparation evidence,
|
|
and prevents resurrection and re-preparation. See
|
|
[Program format V1](program_format_v1.md).
|
|
|
|
This V1 does not provide live Web capture, historical correction, automatic
|
|
training generation, Analysis or the standalone Exercises route.
|