fy59/trainlog
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

release: prepare v0.1.4

Browse source
This commit is contained in:
fy59 2026-09-22 18:28:12 +02:00
parent b4fd753ac5
commit 5d58071601
8 changed files with 159 additions and 89 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
CHANGELOG.md
View file

@ -1,7 +1,16 @@
# Changelog
## Unreleased — 0.1.4
## 0.1.4 — 2026-09-22
- Added the frozen Bluetooth Classic RFCOMM synchronization transport without
changing full-generation business semantics. The paired deployment selects
Bluetooth before MTP, authenticates the configured bonded Android peer with
the persisted Trainlog peer identity, rate-limits reconnect noise, and keeps
MTP as the wired recovery transport. This transport is for Trainlog data
synchronization only; heart-rate sensor ingestion remains future 0.1.5 work.
- Refreshed the Web next-session projection after synchronization and added
factual body-measurement trend charts through the existing bounded analysis
read model without introducing health interpretation or estimated metrics.
- Fixed Program progress for sessions started from a delivered manual
preparation. The preparation companion now carries its stable Program and
Program-session provenance through Android start, finalization, restart and

51
README.md
View file

@ -1,22 +1,22 @@
# Trainlog
Synchronization uses one generation/ACK engine over USB/MTP first and an
optional private Google Drive mirror/fallback. Drive contains only versioned
Trainlog artifacts under its separate Sync namespace; desktop and Android
SQLite databases always remain local. Android can process PC USB requests from
an explicitly enabled, visibly notified background service, while Drive checks
follow Android's bounded background scheduling.
Synchronization uses one generation/ACK business engine across versioned
local transports. The paired 0.1.4 deployment prefers Bluetooth Classic RFCOMM
and falls back to direct USB/MTP; the separately configured private Drive path
remains available to the legacy mirror/fallback workflow. No transport copies
SQLite databases between devices.
Trainlog is a local-first workout and body-data system. Trainlog Core owns
business truth and canonical desktop persistence. Its native Android app is the
field companion, its C17/Notcurses desktop TUI is the administration and
technical surface, and its local browser Web sibling provides the implemented
Dashboard, Sessions, Programmes, and Exercises surfaces while reserving Analyse
for separately contracted work.
Dashboard, Sessions, Programmes, Exercises, and factual Analyse/Sleep Diary
surfaces.
Android and desktop each own a local SQLite database. The desktop database is
the canonical long-term history. Trainlog synchronizes versioned JSON artifacts
over direct MTP; it never copies SQLite database files between devices.
over its authenticated local transports and optional configured Drive workflow;
it never copies SQLite database files between devices.
## Product split
@ -24,7 +24,7 @@ over direct MTP; it never copies SQLite database files between devices.
|---|---|
| Android | Capture and quickly correct sets, repetitions, loads, durations, and continuous activities; reorder active and completed-session occurrences; capture feedback, J+1 follow-ups, body measurements, and AI proposals; trigger sync; show quick summaries. |
| Desktop TUI | Administer, inspect, maintain, import/export, correct canonical history, and provide technical tools. |
| Local Web (0.1.4 development) | Display Dashboard, Programmes, Sessions, Exercises and factual Analyse workspaces. Analyse includes the Sleep Diary editor, 18:00-to-18:00 agenda and local vector PDF export. |
| Local Web (0.1.4) | Display Dashboard, Programmes, Sessions, Exercises and factual Analyse workspaces. Analyse includes the Sleep Diary editor, 18:00-to-18:00 agenda and local vector PDF export. |
No interface reconstructs business truth from SQLite tables. The local Web is
a sibling adapter, not an extension of the TUI. On `main`, its loopback-only
@ -34,8 +34,8 @@ make the remaining placeholder routes functional.
The top-level `/programmes` route is an operational daily calendar for active
Programs. Sessions → Programmes remains the technical administration/import,
list, detail, archive, and delete surface.
Web Exercises administration is implemented. The 0.1.4 development cursor is
the Web Dashboard and Analyse V1 read-model workspace.
Web Exercises administration is implemented. Version 0.1.4 also includes the
factual Dashboard/Analyse read model and the synchronized Sleep Diary workspace.
## Releases
@ -52,8 +52,8 @@ Each published stable release provides:
- SHA-256 checksums.
Both mirrors publish the same Trainlog product version and release assets. The
latest stable version is **0.1.3** on Android and desktop; this is one shared
Trainlog version, not separate interface versions. Version 0.1.2 is the
latest stable version is **0.1.4** on Android and desktop; this is one shared
Trainlog version, not separate interface versions. Version 0.1.3 is the
previous stable release.
Trainlog presents French by default, with English selectable
@ -109,14 +109,14 @@ independent.
### Daily synchronization on an opted-in installation
After explicitly enabling Android background synchronization once, connect and
unlock the paired phone and select **Synchronize** in the local Web Dashboard.
USB/MTP is preferred when the Trainlog peer is usable; the separately selected
private Drive folder is updated as a mirror and is the fallback transport. Wait
until Web reports the correlated generation and acknowledgements. A failure
remains durable and should be diagnosed before retrying; do not delete
generation, ACK, database, or backup files. Full-generation mode and Drive
remain trusted per-installation configuration.
After explicitly enabling the paired local synchronization path, keep Bluetooth
enabled on Android and the desktop and select **Synchronize** in Trainlog when
an explicit run is wanted. The current paired deployment prefers authenticated
Bluetooth Classic RFCOMM and uses direct USB/MTP as the wired recovery path.
The existing private Drive workflow remains separately configured. Wait until
the correlated generation and acknowledgements complete; a failure remains
durable and should be diagnosed before retrying rather than deleting protocol,
database, or backup files.
### Build from source
@ -157,7 +157,7 @@ updates; generating a replacement key is not a normal release procedure.
### Linux runtime dependencies
The published v0.1.3 x86-64 desktop runtime is dynamically linked. Its tagged
The published v0.1.4 x86-64 desktop runtime is dynamically linked. Its tagged
source directly requires compatible versions of:
- glibc and the GCC support runtime;
@ -169,7 +169,7 @@ source directly requires compatible versions of:
- Notcurses Core;
- the standard math library.
Version 0.1.3 additionally links GNU libmicrohttpd and yyjson for the local Web
Version 0.1.4 additionally links GNU libmicrohttpd and yyjson for the local Web
adapter and Dashboard layout configuration. Those are not retroactive
requirements of the pre-Web v0.1.1 tagged source.
@ -184,6 +184,9 @@ assuming one universal package command.
- Android is optional when using the desktop TUI alone. USB/MTP synchronization
requires the Android companion, libudev, libmtp, and an unlocked connected
device.
- Bluetooth synchronization requires BlueZ on Linux plus Python 3.11 or newer
with D-Bus and GObject bindings. It is a Trainlog synchronization transport,
not a heart-rate sensor implementation.
- `trainlog-syncd` installation expects a systemd user session. Manual TUI
synchronization does not require the user service.
- `rclone` is required for desktop Google Drive synchronization and automatic

73
docs/current_state.md
View file

@ -1,20 +1,21 @@
# Current implementation state
Full-generation Web synchronization now selects an actually usable MTP peer
before USB, falls back to a separately configured private Drive generation
namespace, and mirrors successful USB conversations to Drive on a best-effort
basis without rolling back USB. Both transports move the same generation/ACK
bytes; neither transports SQLite. Android has an explicitly enabled foreground
USB listener with mandatory notification and a private-folder Drive grant with
bounded WorkManager checks. Both use the same concurrency-guarded generation
Full-generation synchronization uses one generation/ACK business engine across
versioned transports. On the paired 0.1.4 deployment, automatic local selection
is Bluetooth Classic RFCOMM first and direct USB/MTP second. The desktop BlueZ
service accepts only the configured bonded Android address, Android proves the
persisted Trainlog peer identity in the first bounded frame, and reconnect noise
is rate-limited so proximity does not create repeated generations. MTP remains
the wired recovery path. The separately configured private Drive transport
remains available to its legacy mirror/fallback workflow. No transport copies
SQLite.
Android synchronization paths share the same concurrency-guarded generation
coordinator as SyncScreen. That coordinator has one process-wide ownership
arbiter: explicit foreground intent has priority over automatic background
resumption, while the foreground service may remain alive without owning the
resumption, while a foreground service may remain alive without owning the
conversation. An automatic run yields cooperatively at safe boundaries; its
durable generation is retained for a correlated handoff rather than deleted.
Background actionability distinguishes a new request or new correlated remote
evidence from a merely stale resumable generation, preventing five-second
terminal retry loops.
Direct-MTP publication now has an explicit Android visibility boundary.
Durable immutable generation files are submitted to MediaProvider and all scan
@ -55,22 +56,17 @@ keeps the independent target intact on save, and leaves sibling occurrences
unchanged on save or cancellation. A set-based target-only occurrence can add
or change equipment without fabricating a performed set.
The opt-in full-generation path is operational on the private daily
installation. Android explicit synchronization uses a dedicated coordination
filename carrying the unchanged request-v1 payload. Legacy V3 signalling is
additive and occurs only after a fresh strict V3 snapshot succeeds; daemon
request identities are deduplicated across both bounded channels. The loopback
Web control and foreground Android coordinator use
the production direct-libmtp adapter, correlated manifest/ACK V1 objects, and
persistent peer identities. Controlled USB and private Drive validation proved
the complete Web-initiated request, generation, import, publication, and ACK
conversation without opening SyncScreen for each run. USB remains preferred;
the private `Trainlog/Sync/v1` namespace is configured as a verified mirror and
fallback, independently from `Trainlog/AI`. Cross-transport replay is
idempotent and neither transport carries SQLite.
The full-generation path is operational on the paired daily installation.
Bluetooth Classic is the primary local byte transport, MTP remains the wired
recovery transport, and the existing private Drive namespace remains separately
configured for its supported mirror/fallback path. All carry the same bounded
generation/ACK artifacts and persistent peer identities; cross-transport replay
is idempotent and no transport carries SQLite. The Bluetooth transport does not
yet ingest heart-rate sensor data.
The public Android release chain advances from v0.1.1 versionCode 2 through
v0.1.2 versionCode 3 to v0.1.3 versionCode 4 under certificate SHA-256
v0.1.2 versionCode 3 and v0.1.3 versionCode 4 to v0.1.4 versionCode 5 under
certificate SHA-256
`5ef41117da107c9805ae3215c5ec823cff06216610e6e4f7542a754161c71bd2`.
Higher-numbered private validation builds used a separate Android Debug
certificate and are not members of the public update-signature chain.
@ -85,7 +81,7 @@ The rollout packager now keeps the legacy request daemon and one-shot helper in
the same relocatable, hashed bundle as the Web generation coordinator, avoiding
mixed-checkout user-service execution during the controlled rollout.
Snapshot date: **2026-09-20**.
Snapshot date: **2026-09-22**.
`TRAINLOG_CODE_READABILITY_V1` normalizes the recent generation-MTP,
generation/ACK, Android-backup, Web Dashboard serialization, tests, doubles and
@ -103,9 +99,9 @@ Android is the field companion: it captures training and body data, preserves
the active draft, receives AI proposals, triggers synchronization, and shows
quick summaries. The C17/Notcurses TUI is the administration, inspection,
maintenance, import/export, and technical-tooling surface. The local Web
sibling now provides its embedded application shell and implemented Dashboard;
its future business surfaces will own broader analysis, program/session
preparation, and exercise workflows through Trainlog Core.
sibling provides its embedded application shell, Dashboard, Sessions,
Programmes, Exercises, factual Analyse views, and Sleep Diary
workflow through Trainlog Core.
Trainlog Core owns business truth. The desktop SQLite database remains the
canonical local source of truth and long-term history; no interface owns a
@ -120,7 +116,7 @@ parallel implementation of its rules.
| Android SQLite | schema v26; Sleep Diary V1 is additive in v26 |
| Mobile snapshot | V3 active; V1/V2 readable legacy inputs; explicit V4 codec staged, not selected by transport |
| Desktop terminal backend | Notcurses only |
| Trainlog product version | `0.1.4` development, synchronized across Android and desktop; latest stable release: `v0.1.3` |
| Trainlog product version | `0.1.4` stable, synchronized across Android and desktop; latest stable release: `v0.1.4` |
| Interface language | `TRAINLOG_I18N_V0_1_1=PASS`: French default; English selectable in Settings → Language on both surfaces |
| AI history export | `TRAINLOG_AI_EXPORT_V1` active |
| AI session proposals | `TRAINLOG_AI_SESSION_DRAFT_V1=VALIDATION_PENDING` |
@ -138,7 +134,7 @@ parallel implementation of its rules.
| Web Dashboard tiles | `WEB_DASHBOARD_TILES_V1=PASS/FROZEN` |
| Web Dashboard visualizations | `WEB_DASHBOARD_VISUALIZATIONS_V1=PASS/FROZEN` |
| Web Dashboard V1 | `WEB_DASHBOARD_V1=PASS/FROZEN` |
| Sleep Diary V1 | Implemented on the 0.1.4 review branch: timestamped causal diary, stable Web/Android capture, full-generation companion and fully localized FR/EN local vector PDF; the Web Agenda, Chronology and factual summary adopt the latest persisted revision without reload, use one exact 18:00-to-18:00 projection and isolate all visible data to the active night despite out-of-order reads; medication choices expose dose/unit, while real-Firefox mutation/date-switch/reload coverage plus a section-local error boundary protect capture |
| Sleep Diary V1 | `SLEEP_DIARY_V1=PASS`: timestamped causal capture, Android/Web editing, full-generation synchronization, exact 18:00-to-18:00 agenda projection, medication snapshots, and localized FR/EN vector PDF export |
| Web Sessions V1 | `TRAINLOG_WEB_SESSIONS_V1=PASS/FROZEN` (controlled desktop/Android deployment validated) |
| Web Sessions deletion and Programs V1 | `TRAINLOG_WEB_SESSIONS_DELETE_AND_PROGRAMS_V1=PASS` (private grouped rollout validated) |
| Programs presentation, Android projection, and deletion | `TRAINLOG_PROGRAMS_PRESENTATION_ANDROID_DELETE_V1=PASS` (private coordinated deployment and restart/replay validated) |
@ -148,17 +144,18 @@ parallel implementation of its rules.
| Web sync API V1 | `TRAINLOG_WEB_SYNC_API_V1=PASS/FROZEN` |
| Web sync button V1 | `TRAINLOG_WEB_SYNC_BUTTON_V1=PASS/FROZEN` |
| Sync Web end-to-end wrapper | `TRAINLOG_SYNC_WEB_END_TO_END_V1=PASS/FROZEN` (isolated) |
| Private full-generation rollout | `TRAINLOG_SYNC_FINALIZATION_AND_ROLLOUT_V1=PASS` (direct MTP, one authorized phone) |
| Private full-generation rollout | `TRAINLOG_SYNC_FINALIZATION_AND_ROLLOUT_V1=PASS` (authenticated Bluetooth primary transport with direct MTP recovery on one authorized phone) |
| Local Web | `TRAINLOG_WEB_V1=CONTRACT_FROZEN / IMPLEMENTATION_STARTED` |
| Web Exercises V1 | `TRAINLOG_WEB_EXERCISES_V1=PASS` |
| Current operational cursor | `TRAINLOG_WEB_ANALYSIS_V1` (implemented and visually refined, user review pending) |
| Current operational cursor | `TRAINLOG_CARDIO_V1_NEXT_CONTRACT`: heart-rate sensor ingestion starts in 0.1.5 and remains distinct from the frozen Bluetooth synchronization transport |
| Complete synchronization gap contract | Frozen dependency contract; operational USB/Drive slices required by v0.1.2 are delivered |
| Isolated synchronization test environment | `TRAINLOG_SYNC_TEST_ENV_V1=PASS/FROZEN` |
| Synchronization characterization | `TRAINLOG_SYNC_CHARACTERIZATION_V1=PASS/FROZEN` |
| Synchronization data/lifecycle slice | `TRAINLOG_SYNC_DATA_LIFECYCLE_V1=PASS/FROZEN` |
| Synchronization causal deletion slice | `TRAINLOG_SYNC_CAUSAL_DELETE_V1=PASS/FROZEN` |
| Synchronization generation/ACK slice | `TRAINLOG_SYNC_GENERATION_ACK_V1=PASS/FROZEN` (explicit staged entry points; active transport remains V3) |
| Generation MTP and Android backup | Software complete and validated in the authorized private physical-device rollout |
| Bluetooth synchronization transport | `TRAINLOG_SYNC_BLUETOOTH_TRANSPORT_V1=PASS/FROZEN`; independent from future heart-rate sensor ingestion |
| Generation MTP and Android backup | Software complete and retained as the authorized wired recovery path |
Desktop and Android schema numbers are independent. Neither changes the frozen
Trainlog JSON V1 contract.
@ -408,10 +405,10 @@ The full Android lint comparison against an isolated clean `main` worktree is
unchanged at ten pre-existing errors: one `NewApi`, one
`LocalContextConfigurationRead`, and eight bilingual `StringFormatMatches`
diagnostics. This UI tranche adds no lint error and changes no lint policy.
The next private daily Android candidate remains on development
`versionName=0.1.4`; only its strictly increasing `versionCode` may be supplied
as a build-time override. No public tag or release is created by that private
candidate process.
The stable Android 0.1.4 source uses `versionName=0.1.4` and public
versionCode 5. Private validation builds may still supply only a strictly
increasing `versionCode` as a build-time override; that does not create a
public release or change schemas and protocols.
The private Program execution rollout installed desktop schema v27 and the
signed nondebuggable Android versionCode 17/schema v25 update without

1
docs/releases/README.md
View file

@ -6,6 +6,7 @@ than later development. GitHub and Forgejo publication must preserve the
existing release, tag, status, and assets while keeping their note bodies equal
to the corresponding source file.
- [Trainlog v0.1.4](v0.1.4.md)
- [Trainlog v0.1.3](v0.1.3.md)
- [Trainlog v0.1.2](v0.1.2.md)
- [Trainlog v0.1.1](v0.1.1.md)

57
docs/releases/v0.1.4.md Normal file
View file

@ -0,0 +1,57 @@
Trainlog v0.1.4 extends the local-first training workflow with factual
analysis, a synchronized Sleep Diary, improved prepared-session execution, and
an authenticated Bluetooth synchronization transport.
## Analyse and Dashboard
- The local Web Analyse workspace exposes factual 7/30/90-day and all-history
views through Trainlog Core.
- Activity, active-Program progress, compatible exercise metrics, persisted MAX
results, BODY ZONE exposure, and body measurements share the bounded Core
read model used by Dashboard summaries.
- Body-measurement trends are charted from persisted observations, and the next
session projection refreshes after synchronization.
- Analyse deliberately does not invent readiness, fatigue, recovery, body-fat,
or estimated performance values.
## Sleep Diary
- Sleep Diary V1 is available across desktop schema v29 and Android schema v26.
- Entries use absolute timestamped events, causal revisions, appreciations,
notes, medication catalog entries, and timestamped intake snapshots.
- The Web agenda uses one exact 18:00-to-18:00 projection and follows the latest
locally persisted revision without leaking another selected night.
- Local vector PDF reports are available in French and English.
- Sleep Diary participates in the full-generation synchronization and
acknowledgement flow.
## Android session execution
- Prepared continuous-duration exercises remain planning-only until actual work
is explicitly recorded.
- Target-only continuous and set-based occurrences can be edited without
fabricating performed activity or duplicate occurrences.
- Equipment can be created and selected from the active-session editor while
preserving the current durable draft.
- Program provenance is preserved through preparation, Android execution,
completion, synchronization, and progress display, including safe recovery
of compatible historical deliveries.
## Bluetooth synchronization
- The paired deployment adds Bluetooth Classic RFCOMM as the primary local
Trainlog synchronization transport and retains direct MTP as wired recovery.
- The desktop accepts only the configured bonded Android device, and Android
proves the persisted Trainlog peer identity before exchanging bounded frames.
- Reconnect noise is rate-limited and does not create repeated generations.
- This Bluetooth feature transports Trainlog synchronization data only.
Heart-rate sensor ingestion is intentionally deferred to the 0.1.5 cardio
cycle.
## Assets
- `trainlog-android-v0.1.4.apk`: signed public Android APK.
- `trainlog-tui-linux-x86_64-v0.1.4`: Linux x86-64 runtime bundle containing
the TUI, local Web adapter, synchronization helpers, Bluetooth transport
helper, and required catalogs.
- `SHA256SUMS`: SHA-256 checksums for both artifacts.

37
docs/roadmap.md
View file

@ -5,9 +5,10 @@ physical libmtp, verified backups, signing continuity, migrations, correlated
ACKs, restart, and idempotent replay passed. Generation mode remains an
explicit per-installation opt-in. The additive private Drive transport and
Android background software are implemented and validated with fake transport
and the private production namespace. USB remains preferred, Drive is the
configured mirror/fallback, and Android background operation retains its
documented post-reboot platform limits.
and the private production namespace. Stable v0.1.4 adds authenticated
Bluetooth Classic RFCOMM as the primary paired local transport and retains direct MTP as wired recovery; Drive
remains a separately configured supported path. Android background operation
retains its documented post-reboot platform limits.
This document owns future work. The implemented baseline is summarized in
[current_state.md](current_state.md); completed narratives and evidence belong
@ -23,19 +24,20 @@ Android executes in the field, captures actual work/feedback, and returns data.
```
Future work must preserve the frozen Trainlog JSON V1 contract, stable
identities, actual-versus-planned separation, direct MTP transport, and the
distinction between measured values and estimates.
identities, actual-versus-planned separation, the frozen synchronization
transport boundaries, and the distinction between measured values and
estimates.
## Current baseline
Stable v0.1.2 is the release baseline for the v0.1.3 development cycle.
Stable v0.1.4 is the release baseline for subsequent development.
Desktop schema v29, Android schema v26, Notcurses, direct `Documents/Trainlog`
storage, mobile export V3, Training Knowledge V1, Body Zones V1, Training
Feedback V1/V2, STATS V1, and Session Generator V1 are implemented. Session
Generator V1 is hidden pending V2. AI session-draft exchange retains its
explicit manual validation gate. APP_SHELL_V1 remains useful historical design
evidence, but its September 2026 observations must be revalidated against the
v0.1.3 baseline rather than treated as a current implementation plan.
v0.1.4 baseline rather than treated as a current implementation plan.
`TRAINLOG_WEB_V1=CONTRACT_FROZEN / IMPLEMENTATION_STARTED`; its local-only
CLI/HTTP infrastructure, embedded frontend shell and the frozen Dashboard data
contract, frozen interactive grid, versioned layout persistence and factual
@ -43,9 +45,9 @@ tile rendering exist. The Dashboard's bounded progression and BODY ZONES
visualizations and Sessions V1 are implemented. The top-level `/programmes`
route is an operational daily active-Program calendar, while
Sessions → Programmes remains the technical administration/import, list,
detail, archive, and delete surface. Web Exercises V1 is implemented. The
0.1.4 `TRAINLOG_WEB_ANALYSIS_V1` branch now owns the factual Dashboard/Analyse
read-model foundation and stops before merge for visual inspection.
detail, archive, and delete surface. Web Exercises V1, the factual
Dashboard/Analyse read-model foundation, and Sleep Diary V1 are included in
stable v0.1.4.
The corrective prepared-item projection, bounded phase-owned MTP outbox,
Sessions presentation correction, local date preference and durable preparation
withdrawal are implemented. The withdrawal uses the separate versioned
@ -54,16 +56,17 @@ mobile snapshot or `TRAINLOG_FORMAT_V1` contracts.
## Current cursor
The v0.1.4 cursor proceeds from stable v0.1.3 and its validated Web, Program
execution, USB/Drive generation, ACK, and causal-deletion contracts without
reopening those completed gates.
Stable v0.1.4 closes the Analyse/Sleep Diary cycle and freezes the Bluetooth
Classic synchronization transport independently from future sensor work.
Sleep Diary V1 is implemented on `trainlog-0.1.4-sleep-diary-v1` and remains
under grouped review before integration. Heart-rate sensor ingestion remains
future scope; absolute diary timestamps are its prepared extension boundary.
The next development cycle is 0.1.5 cardio. Android will own heart-rate sensor
discovery/acquisition and timestamped local capture; synchronized desktop/Web
surfaces will consume recorded measurements and will not connect directly to
the sensor. Heart-rate ingestion must not reuse or overload the frozen Trainlog
Bluetooth synchronization transport contract.
```text
CURRENT_OPERATIONAL_CURSOR=TRAINLOG_WEB_ANALYSIS_V1
CURRENT_OPERATIONAL_CURSOR=TRAINLOG_CARDIO_V1_NEXT_CONTRACT
```
The focused `TRAINLOG_SYNC_CAUSAL_DELETE_V1_CLOSEOUT` is complete before this

10
docs/sync_exchange.md
View file

@ -2,8 +2,8 @@
## Sleep Diary companion
`trainlog-sleep-diary` version 1 is finalized on the unreleased 0.1.4 review
branch with both the medication catalog and the entry-owned intake snapshots.
`trainlog-sleep-diary` version 1 is finalized in stable v0.1.4 with both the
medication catalog and the entry-owned intake snapshots.
The artifact preserves catalog and diary causal parents, rejects concurrent
siblings and resurrection, and treats an exact revision replay as idempotent.
This completion happened before publication or freezing of the companion;
@ -19,9 +19,9 @@ revalidated and acknowledged by a later generation. Imported tips are already
validated and acknowledged because their containing generation was durably
consumed. Draft and synchronized state are not inferred from wall-clock time.
`trainlog-sleep-diary`, version 1, is emitted by full generations on the 0.1.4
Sleep Diary branch. It is optional when consuming an older generation so a
pre-domain artifact remains replayable. It carries bounded complete entry snapshots with
`trainlog-sleep-diary`, version 1, is emitted by full generations in stable
v0.1.4. It is optional when consuming an older generation so a pre-domain
artifact remains replayable. It carries bounded complete entry snapshots with
stable identities, the current immutable revision and causal parent,
offset-bearing timestamps, appreciations, notes and logical deletion. Exact
revision replay is unchanged; sibling revisions and resurrection after deletion

8
docs/tests.md
View file

@ -714,10 +714,10 @@ tagged source state, and the tag, Android `versionName`, Meson project version,
TUI product version, asset names, and release title must agree.
Private update rollout may set `TRAINLOG_ANDROID_VERSION_CODE` to a positive
integer above the installed package while retaining the current development
`versionName=0.1.4`. The version-code override is build-only and does not change
any schema or exchange-format version. Private daily candidates must not
downgrade the logical product version to the earlier 0.1.2 stable line.
integer above the installed package while retaining the tagged product
`versionName`. The version-code override is build-only and does not change any
schema or exchange-format version. Private daily candidates must never
downgrade the logical product version.
For `TRAINLOG_UI_ANDROID_WEB_UNIFICATION_V1`, `lintDebug` was also run from a
detached clean worktree at the exact `main` baseline and from the mission